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.

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).

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).



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.

@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.

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

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

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.

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.

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.

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!

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.

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.