Posts: 325
Joined: Sep 2010
Reputation:
17
2011-03-04, 02:23
(This post was last modified: 2011-03-05, 03:35 by TheSwissKnife.)
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!
Posts: 325
Joined: Sep 2010
Reputation:
17
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.
Posts: 325
Joined: Sep 2010
Reputation:
17
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.