• 1
  • 16
  • 17
  • 18
  • 19(current)
  • 20
Jerky playback Dharma B2 and SVN /Ion
TheSwissKnife Wrote:Well let me know which font to try and if not installed already the steps to take etc. My code tweaks show the stutter as video render drops without me having to watch the film.

Ok, tried with standard Windows 7 arial.ttf (774476 bytes) and the issue seems to be gone. I have not tested my entire library, but watched some problematic movies and have not noticed any stutter, neither SD (software) nor HD (DXVA). So far, so good. Smile

Right now I am experimenting with "Segoe Media Center SemiBold.ttf" as it looks a little bit better to me than standard Arial and is even smaller (117420 bytes).
Reply
Whatever this border font pupose is...the processing is the cause of the issue. If the hardware has a problem processing this loop then the subtitles text below will show the issue immediately (simply copy into a .srt subtitle file and browse to attach to an mkv film (for example) you choose).

On my hardware with the border font loop operational I get 3 stutters for normal then italic then bold. I would suggest that if this loop is actually useful in some way (though I don't know what) that there should be a switch to disable it optionally (ideally in GUI but otherwise just via advancedsetttings.xml).

Code:
1
00:00:30,616 --> 00:00:32,700
NORMAL
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,

2
00:00:40,616 --> 00:00:42,700
<i>ITALIC
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,</i>

3
00:00:50,616 --> 00:00:52,700
<b>BOLD
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,</b>


4
00:01:30,616 --> 00:01:32,700
NORMAL
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,

5
00:01:40,616 --> 00:01:42,700
<i>ITALIC
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,</i>

6
00:01:50,616 --> 00:01:52,700
<b>BOLD
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ç É Ö Ş İ Ü
a b c d e f g h i j k l m n o p q r s t u v w x y z ç é ğ ö ş ı ü
? ! " " ; : @ # ~ % $ ( ) . ,</b>


EDIT: Some clues here... http://forum.xbmc.org/showthread.php?tid=83486 I really think now this should be added to subtitles GUI config screen

EDIT2: Further to this I tried an m2ts bluray file still with border fonts still disabled and get lots of intermittent stutters too. CPU never goes above around 28% (in 1 second samples) for the whole machine (4 thread - dual core atom d510). Assuming there is no strange issue where xbmc threads are not really being given the access to the cores then it certainly seems like the subtitle code really needs to be pulled out into its own thread. This might be more than I can chew -any pointers would be welcome.
Reply
@bobo1on1. I could do with some advice on the pullupcorrection code. Having got some stable changes I then started to test on non-23.976p/24p material and hit issues straight away which seem to be to do with the video pts values being not at all uniform. The pullupcorrection codes looks very complex so I was hoping for an overview of what it is trying to correct. Currently I have some files that claim to be 29.97p for example and I am seeing the pts skipping by 2 frame durations or not changing at all - is the correction supposed to be fixing these if it finds a pattern? I could simply try to get OutputPicture to brute force fix any pts which is more than 190% or less than 90% frame duration delta since previous - but I think this is likely to cause more harm than good.

I am now not even sure what a good 29.97p timecode sequence should look like nor for that matter 25p.
Reply
Hmm interesting, so it's because of new font rendering method. That explains why it worked flawlessly before. wish we could disable the border within GUI or advancedsettings.xml Nerd
Reply
ezechiel1917 Wrote:Hmm interesting, so it's because of new font rendering method. That explains why it worked flawlessly before. wish we could disable the border within GUI or advancedsettings.xml Nerd

As I said it 'mostly' addresses the issue (I guess for Atom CPU) but when I play my Leon m2ts direct copy from bluray I still get subtitle related stutters which I assume shows that simply having the subtitles render in the same thread as video render is a recipe for disaster.
Reply
I think the timecode issue I am seeing with some 29.97 files is a problem with the files (despite them being from good sources I think) but once again it would seem that other players deal with it better, and so I think I will add in these checks in OutputPicture() to see if that helps.

I have also re-enabled switch resolution to match file frame rate - but every now and again I get xbmc crashing with this. Before I spend another day trying to track this down, since I don't think my changes could be responsible, would someone have any input/pointers? Example backtraces below - but it always looks different.


Code:
*** glibc detected *** /usr/lib/xbmc/xbmc.bin: corrupted double-linked list: 0x09b223d8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x45c8591]
/lib/tls/i686/cmov/libc.so.6(+0x6e72f)[0x45cb72f]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x5c)[0x45ccf9c]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0x14a7c07]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep9_S_createEjjRKSaIcE+0x66)[0x1481d06]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep8_M_cloneERKSaIcEj+0x38)[0x1482978]
/usr/lib/libstdc++.so.6(_ZNSs7reserveEj+0x4d)[0x14837ad]
/usr/lib/libstdc++.so.6(_ZNSs6appendEPKcj+0x8b)[0x1483a1b]
/usr/lib/xbmc/xbmc.bin(_ZN4CLog3LogEiPKcz+0x6a8)[0x8299d48]
/usr/lib/xbmc/xbmc.bin(_ZN20CVideoReferenceClock21CorrectVBlankTrackingEPx+0x3ca)[0x85e90da]
/usr/lib/xbmc/xbmc.bin(_ZN20CVideoReferenceClock11UpdateClockEix+0x40)[0x85ea760]
/usr/lib/xbmc/xbmc.bin(_ZN20CVideoReferenceClock6RunGLXEv+0x97)[0x85eb687]
/usr/lib/xbmc/xbmc.bin(_ZN20CVideoReferenceClock7ProcessEv+0x84)[0x85ec204]
/usr/lib/xbmc/xbmc.bin(_ZN7CThread12staticThreadEPv+0x85)[0x82c5055]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e)[0x2d996e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x462aa4e]


Code:
*** glibc detected *** /usr/lib/xbmc/xbmc.bin: corrupted double-linked list: 0x0ad36fa0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x5c07591]
/lib/tls/i686/cmov/libc.so.6(+0x6b9ce)[0x5c079ce]
/lib/tls/i686/cmov/libc.so.6(+0x6dafd)[0x5c09afd]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x5c)[0x5c0bf9c]
/usr/lib/xbmc/xbmc.bin(_ZN7CStdStrIcE7FormatVEPKcPc+0x20)[0x8224730]
/usr/lib/xbmc/xbmc.bin(_ZN7CStdStrIcE3FmtEPKcz+0x2b)[0x822480b]
/usr/lib/xbmc/xbmc.bin(_ZN4CLog3LogEiPKcz+0x119)[0x82997b9]
/usr/lib/xbmc/xbmc.bin(_ZN6CVDPAU12CheckRecoverEb+0x40)[0x87c9570]
/usr/lib/xbmc/xbmc.bin(_ZN6CVDPAU5CheckEP14AVCodecContext+0x25)[0x87cb2a5]
/usr/lib/xbmc/xbmc.bin(_ZN20CDVDVideoCodecFFmpeg6DecodeEPhidd+0x147)[0x87c2c77]
/usr/lib/xbmc/xbmc.bin(_ZN15CDVDPlayerVideo7ProcessEv+0x534)[0x8673a24]
/usr/lib/xbmc/xbmc.bin(_ZN7CThread12staticThreadEPv+0x85)[0x82c5055]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e)[0x48196e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x5c69a4e]
Reply
Well that's easy to test, revert your changes see if it still crashes.

TheSwissKnife Wrote:@bobo1on1. I could do with some advice on the pullupcorrection code. Having got some stable changes I then started to test on non-23.976p/24p material and hit issues straight away which seem to be to do with the video pts values being not at all uniform. The pullupcorrection codes looks very complex so I was hoping for an overview of what it is trying to correct. Currently I have some files that claim to be 29.97p for example and I am seeing the pts skipping by 2 frame durations or not changing at all - is the correction supposed to be fixing these if it finds a pattern? I could simply try to get OutputPicture to brute force fix any pts which is more than 190% or less than 90% frame duration delta since previous - but I think this is likely to cause more harm than good.

I am now not even sure what a good 29.97p timecode sequence should look like nor for that matter 25p.
It depends, if there's a stable pattern in the differences for more than 120 timestamps, it will fix them, if not, it won't.
Reply
A lot of changes and intermittent so testing to be sure is time consuming. I was hoping someone might have seen something similar to save me the toil. EDIT: I understand this is likely caused by a double free() and since this is intermittent even now my changes may simply make it more likely to run into the corruption making it even more difficult to solve if it is not a coding issue on my part.

As for the timestamps - I guess I need to get an m2ts timecode dumper to be sure if there is no pattern.

While trying to resolve this timecode issue I come back to a nagging problem...the video decoder flush. I can see that VC_FLUSHED bit makes it try to clear down all but the last packet - presumably by sending a drop message. But I still see some packets from that drop set then continue on to be decoded causing pts jumps. For example: pts 0, 167000, 83000, 42000 get decoded, and only 0 is passed to OutputPicture() so far, then the decoder flush comes along and drop messages are put for those, but in the end I see OutputPicture() called subsequently for pts 0, 83000, 167000. I would expect to see only 167000 perhaps. What is the intended logic here - and why does it go so wrong?

EDIT: To be clearer of this decoder flush problem I can play the file without the display refresh rate change and I get all video frames played correctly 0, 42000, 83000, 125000, 167000 etc, when I enable the refresh rate change I get the decoder flush and then will see 0, 83000, 167000, play missing those 2 packets despite them all still appearing to be available for decode.

EDIT2: This appears to be because the decoder dropping is only alternate packets ("hurry up" code I think). Why does the comment in the DVDVideoProcess() code about buffering packets state it must buffer packets (ie up to 7 seconds demuxer messages) to recover from a decoder flush, only for it then upon detection of such a decoder flush to just throw them all away and except for the last one send a drop request? Am I missing something? Should I see some ill effect from disabling the drop requests - because I don't think I do. Is this because I am using hardware decoding? Confused!
Reply
I have now established that the subtitles in m2ts are typically not text (ie are PGS bitmaps)...and this is all handled by ffmpeg so subtitle related stutters here are outside the control of xbmc/dvdplayer. So it seems the TTF subtitles issue is probably solved completely by not using the border font.
Reply
But I have at least fixed the lingering PGS subtitles by reducing the max linger time down to 5 seconds as ffmpeg sets to 20secs for all PGS subs.

Back to the TTF subtitles. I am going to re-enable borderfont and simply initialise the "rasterized" cache with all characters in all forms. However I could do with some help here - I need a nice solution that gives me all the printable glyphs into a string. Currently I bunged in the obvious ones and it takes 2.5 seconds to process them but for every new character that appears after that I can assume around 5ms delay so it is still not quite good enough. @bobo1on1 or anyone else got any suggestions for a method somewhere that gives me the full set for the font being used?

EDIT: I am not even sure how to get any character outside the 1-127 ASCII range to be inserted, despite them being accepted from subtitle file/stream.
Reply
Now that we know what causes subtitle stutter is it possible to have some sort of fix implemented? Preferably an option of switch which turns on/off subtitle border in Settings - Video - Subtitles? Or at least to advancedsettings.xml in case it's not wanted in GUI.
@TheSwissKnife: would you be able to post a patch @ trac?Wink
Reply
I was hoping for something better than my one line change which avoided the borderfont loop. I can't believe only Atom users see this issue given that it seems like 5ms per new character (ie for each style), so I am surprised that there is not more interest. I will post my findings here soon, but my C++ is very basic and am not sure my solution will be very neat without some help.

EDIT:

Some more info for those interested:

Generally the bulk of the problem time is spent in CGUIFontTTFGL::Begin() when the texture is not already loaded. This then takes 2-35ms and on average around 5ms (most of which is in the 2 calls to glBindTexture()). There is also a little time spent in CGUIFontTTFBase::CacheCharacter() when not cached sometimes up to 5ms but generally and on average less than 1ms.

EDIT2:

Perhaps for the future there is a way to be more efficient.

http://developer.nvidia.com/object/bindl...phics.html

EDIT3:

Now without border fonts the time spent in glBindTexture() is hugely less presumably because the size of texture is so much smaller (at least 10 times less). It seems that CGUIFontTTFBase::Load() increases the cell height (m_cellHeight) by a factor of 3 or 4 for border font load. Even when doubling the subtitle font size without having borders enabled the times are still around 5 times less. Could this cell height value adjust be wrong?

EDIT4: I have now implemented a reasonable solution with pre-caching of first 512 chars in 4 styles, and an initial inivisible subtitle. This works well so far. Will test further and post the adjustments.
Reply
I have now performed extensive testing and enhanced the patch to suit.

I have:

1. introduced advanced settings option to disable border font (for those who don't like/need this, or find performance still not good enough with other fixes options).

2. introduced advanced settings option to enable pre-caching of ttf subtitle characters (defaulting to character codes 0-255).

3. enabled a simple invisible subtitle pre-init immediately after font load which helps to prevent initial stutters by initialising some of the raster/text drawing code.

4. introduced a limit on the cell height increase used for border fonts, so that such fonts when reasonably large use no more than double the height of the original font. This combined with 3. alone reduces the issue dramatically (and probably removes it for some).

5. introduced advanced settings option to choose which unicode character codes to pre-cache (overriding the default 0-255). In this way only the characters required for your languages etc will be loaded in this way, avoiding wasted time at startup and raster or system memory space issues.

6. added some error log printing for raster space allocation failures.

7. added advanced settings option to control overlay subtitle linger time (and default to 5 seconds), away from ffmpeg 20 seconds annoyance.

In my environment I can now have border fonts enabled and load up over 512 characters (in 4 styles) with arial font size over 50. No stutters and no subtitle render processing overhead exceeding a millisecond at a time (actually much less). Much more characters or font size and I soon hit raster size issues (8192 pixels).

I have no idea how to use trac so I will now try to apply to a fresh git download, test on that, then put the patch here if someone wants it.
Reply
sounds great! looking forward to try it out Smile
Reply
ezechiel1917 Wrote:sounds great! looking forward to try it out Smile

Well I just built the new tree from git and I get no subtitles at all at present without any of my changes. I am not sure what I might done wrong yet.

EDIT: Someone changed the code in DVDPlayer.cpp GetCurrentSubtitle() to not process when audio is stalled and I test with "no audio" samples. This change is a bug as far as I am concerned, so I have fixed it too. Alas however there seem to be so many other regressions in this latest xbmc I don't know where to start. It crashes even more often with the "corrupted double-linked list" issue and goes into render slo mo where it was fine before. Perhaps I have something strange in my environment - I am not sure. Anyone else had any success with current git?
Reply
  • 1
  • 16
  • 17
  • 18
  • 19(current)
  • 20

Logout Mark Read Team Forum Stats Members Help
Jerky playback Dharma B2 and SVN /Ion0