Jerky playback Dharma B2 and SVN /Ion

I have only a 32-bit linux build at present as I have not attempted to setup a Window build environment. I have started to find some time to look into my open issues...

1. audio stream change resulting in initial 7 second discrepancy between video and audio
EDIT - I can see quickly this is caused by CDVDPlayer:: CheckPlayerInit() which uses current.dts as a audio resync which is about 7-8 seconds ahead of current playing audio. I need to work out what is the best to fix this bug.
2. ff/rw not smooth on video, and a/v sync fluctuates too much during
3. possibly try to mute rather than do packet silence (to avoid the pause-play audio stutter) - not sure this is a good idea though
4. subtitles blocking video renderer (stutter)
5. seek when paused not displaying still frame for new seek position
6. test with other material (and refreshrates) eg interlaced, various fps, etc
7. try to add frame-by-frame, slow-mo, etc

Anyone know if the only sensible way to get the demuxer to go back the 7-8 seconds for the audio is to do a full seek resulting in video seek too?

EDIT: Results are ok with a demuxer seek but of course not great a seek is not very exact and creates an obvious stutter. Better than 7 seconds of resyncing though I think.

Back again! But it seems I am not the only one who has not had much time lately. Has there really been no updates to trunk for 6 weeks? I want to sync my tweaks to the latest before I get going again.

Regarding these bugs, no updates afaik, subtitles caching is most annoying one for me as it stutters even with 720p videos. I really wish you can track it down and incorporate fix. Thumbs up!

TheSwissKnife Wrote:Back again! But it seems I am not the only one who has not had much time lately. Has there really been no updates to trunk for 6 weeks? I want to sync my tweaks to the latest before I get going again.

Hi,

They changed to git now. You can fin them on github:
https://github.com/xbmc

ezechiel1917 Wrote:Regarding these bugs, no updates afaik, subtitles caching is most annoying one for me as it stutters even with 720p videos. I really wish you can track it down and incorporate fix. Thumbs up!

Yes, it annoys the hell out of me too. The resolution will not affect this I think. Ideally the subtitle renderer needs to be made into a separate thread so that it can't block the video render. I had stopped looking because this one looked the most difficult to solve. I have been using my fixes for 1., 2. & 5. now and they seem to work well or at least better then the trunk I started with. A/v sync is always well maintained through different actions (as well as ffmpeg will allow I think), and the visible required adjustment to video for no drift seems quite accurate. I would think it would be quite easy to implement 7. and I have so far seen no real need for 3. So attempt thorough testing on other files/fps/xbmc-sync-settings/windows-7 is probably the next thing for me to do.

Gujs Wrote:Hi,

They changed to git now. You can fin them on github:
https://github.com/xbmc

Ah...that would explain it. Darn it...now I have to learn this and it doesn't look so friendly. Certainly not so easy to peruse the diffs.

I've found out problem causing subtitle stutter may be default arial.ttf font itself. I've tried different custom fonts (Arial, Calibri) and I couldn't notice stutter anymore! Not properly tested through whole video yet, but I'm definitely not seeing that annoying stutter compared to default font when first time normal or styled subtitles appear (also no WARNING: Decode - avcodec_decode_video didn't consume the full packet. in log). Is it possible that default one is more resources hungry? Original arial.ttf is 4,2MB size vs 700-800KB those I've tested.

Even with this fact I think playback should be stutter free with builtin font, and I don't remember having this issue with 9.11 version.

Hope this helps.

ezechiel1917 Wrote:I've found out problem causing subtitle stutter may be default arial.ttf font itself. I've tried different custom fonts (Arial, Calibri) and I couldn't notice stutter anymore! Not properly tested through whole video yet, but I'm definitely not seeing that annoying stutter compared to default font when first time normal or styled subtitles appear (also no WARNING: Decode - avcodec_decode_video didn't consume the full packet. in log). Is it possible that default one is more resources hungry? Original arial.ttf is 4,2MB size vs 700-800KB those I've tested.

Even with this fact I think playback should be stutter free with builtin font, and I don't remember having this issue with 9.11 version.

Hope this helps.

Thanks. That is useful to know - I will have a play (though now I am not sure whether to first try to sync up with latest git version - I see some useful adjustments for the GetCacheTime/GetDelay functions that might make a/v sync more accurate and I think there might be some ffmpeg adjustments).

I am probably off the mark but I suspect the font is in some way loaded into the graphics controller and it is this initial load that takes some time. I certainly can't see any operating system related paging during the pause that would make me think it is xbmc or file caching related. Anyone feel free to correct my slightly wild guess.

Might just be the rendering of the font that takes a long time, if that's the case it should be offloaded to a different thread.