+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: Video stuttering in Linux (/showthread.php?tid=103671)
- TheSwissKnife - 2011-07-08
In "theory" the main issue in this case is not related to vdpau nor to the nvidia chip at all. ION1 and ION2 should not be hugely different (and note some ION2s have only 8 cores). At least that is how I see it - the audio timecodes (I have no checked the video ones) are bad and xbmc from mainline code has a primitive way of doing a/v sync that makes it susceptible to following them effectively without filtering or smoothing etc.
Us humans can get agitated by lip-sync issues in the region of 30ms early audio or 80ms late audio - and some can notice even less then that.
xbmc tries to keep audio in sync with clock within either a video frame duration (refresh rate cycle length) or 10ms (over simplification). The clock is essentially based on the refresh rate and video stream if you are using sync do display. The audio pts measure is based on a audio delay offset (ie how long the audio layer says it is taking for audio to move through the buffers etc to be presented) - this part is beyond my comprehension. Anyway if the audio timestamps fluctuate wildly from the video timestamps that are driving the clock values there the audio player will move the clock or drop/dupe audio packets. If clock gets moved you can assume a video stutter should be witnessed (because clock is always moved in whole video frame units). The audio drop/dupe and clock moves are recorded in the debug log - not codec screen (something that I have enhanced to include in my own versions previously).
- deuch - 2011-07-08
I've post a "normally" good remuxed file :
http://deuch.free.fr/videos/ultra-sample-remux-2.mkv
I'm trying to compile a version with Audio Engine to check if it's helping or not (but i've already my idea about that).
- wsnipex - 2011-07-08
deuch Wrote:What the version do you use of XBMC ? What kind of patches or branch do you use ? Not the official one i suppose ?
I just tried the sample and it also play butter smooth here with hardware acceleration(vaapi).
My setup:
Athlon X3, ATI onboard GFX(4250)
Ubuntu Natty
latest ATI drivers(11.6),
vvapi from x-org/edgers and x-swat ppas
xbmc pre Eden compiled from git master without any patches
- deuch - 2011-07-08
wsnipex Wrote:I just tried the sample and it also play butter smooth here with hardware acceleration(vaapi).
My setup:
Athlon X3, ATI onboard GFX(4250)
Ubuntu Natty
latest ATI drivers(11.6),
vvapi from x-org/edgers and x-swat ppas
xbmc pre Eden compiled from git master without any patches
Which sample did you try ?
- deuch - 2011-07-08
I'm using a version with Audio Engine and it worst than before
- TheSwissKnife - 2011-07-08
deuch Wrote:I've post a "normally" good remuxed file :
http://deuch.free.fr/videos/ultra-sample-remux-2.mkv
I'm trying to compile a version with Audio Engine to check if it's helping or not (but i've already my idea about that).
What is a normally good remuxed file? How does it play in detail on your system - please answer my previous questions, or at least explain why you are not able to.
- deuch - 2011-07-08
This is a file remuxde with 4.8.0 of mkvmerge instead of 4.3.0 (which provides bad timecode) with good timecodes.
With this files, there is no stutter. So it's a good news.
The bad news is that i don't want to remux all of my files (4TB).
And there is another problems with other files with good timecode : freeze for 1s etc ...
So i think i will never see the end of the tunnel
- TheSwissKnife - 2011-07-08
deuch Wrote:This is a file remuxde with 4.8.0 of mkvmerge instead of 4.3.0 (which provides bad timecode) with good timecodes.
With this files, there is no stutter. So it's a good news.
The bad news is that i don't want to remux all of my files (4TB).
And there is another problems with other files with good timecode : freeze for 1s etc ...
So i think i will never see the end of the tunnel
I don't understand. No stutter at all but freeze for 1s? Please explain thoroughly with the properly muxed file the xbmc config (sync method etc), and post debug log and corresponding times where you observe an issue. Once you know that your problem is only audio timecodes you can look at applying the dts timecode smoothing patch, if you really don't want to remux your files - be warned though when you have crap timecodes there is no player that can guarantee to play these files properly if seeking - they have to guess a starting point if they start at non-zero of skip packets. If it were me I would start remuxing by looking into batch processing them - crap data would always make me feel like any weird effect was a result of that.
- deuch - 2011-07-08
No this file is ok
I talk about other file with good timecodes but random freeze. I will try to find this kind o file.Where is the DTS patch ? Does this patch works only with DTS audio track (i guess so but ...). Because the other problem (freeze or stutter) with other videos files are with AAC or MP3 audio track, not DTS.
- TheSwissKnife - 2011-07-08
deuch Wrote:No this file is ok
Where is the DTS patch ? Does this patch works only with DTS audio track (i guess so but ...). Because the other problem (freeze or stutter) with other videos files are with AAC or MP3 audio track, not DTS.
If you lump all problems as one you will probably never resolve. Please make it clear when a particular problem is solved. So now we say that this sample after remuxing properly with latest mkvmerge v4.8 plays with no issues at all regardless of sync method and with subtitles enabled not affecting it?
This is not specific to DTS audio as far as I understand but the issue is common with DTS in mkv container.
http://trac.xbmc.org/ticket/10891
How do you know your other problem files have good or bad timecodes? Assume always that the problem might be different.
- deuch - 2011-07-08
Files remuxed, no sync method and subs on. And now it works. I've check with 2 other files and it's ok now. But for me it's not a solution. I don't want to remux my files because XBMC can handle it properly.
But after remuxing some files and check the timecodes (and verify that there are good), i've got freeze sometimes. I will try to make samples.
- TheSwissKnife - 2011-07-08
deuch Wrote:Files remuxed, no sync method and subs on. And now it works. I've check with 2 other files and it's ok now. But for me it's not a solution. I don't want to remux my files because XBMC can handle it properly.
But after remuxing some files and check the timecodes (and verify that there are good), i've got freeze sometimes. I will try to make samples.
What is "no sync method"? I have not seen that.
And as I said seek will never work with any real guarantee if you don't make these corrupt files correct - it is the ONLY real solution. Now laziness may mean that can't be bothered to fix the corruption but then if you want to use xbmc you will have to incorporate the patch possibilities in some way. I for one hope it never makes it into xbmc.
- deuch - 2011-07-08
Sync playback to display always disabled.
And i'm usinf openelec so it's more difficult to add a patch
And at this time i think that i will not spend more time with XBMC. I think that 2 weeks it's A LOT of time. With my cheap NMT (80$) i can play my file without remuxing or stuttering. With DTS or not etc ...So instead of debugging XBMC and applied a lot of patches, i prefer enjoying my videos wit ha simple and working box. And with Zappiti i've got the same gui than XBMC (Jukebox and other things). I do not have the tons of add-ons, it's true ... But for me the most part are unstable, so it's adding problems rather real functionnality. Too bad that XBMC team do not choose to handle those problem more seriously.
- TheSwissKnife - 2011-07-09
deuch Wrote:Sync playback to display always disabled.Why do you do that? I don't think I ever suggested it. "sync playback to display" is best enabled (IMO), and then the choice is "sync method" for the audio to clock sync, either "drop/dupe" or "audio clock" (assuming you want passthru as I think that is in general the right way to do it). BTW, IMO the best way to do this (and I don't know how the audio engine implements it) is to do a/v sync using a combination - drop/dupe immediately after any play speed event change to get perfectly sync'd with video, then do whichever is preferred after (ie either drop/dupe in audio or drop/dupe in video).
Quote:Too bad that XBMC team do not choose to handle those problem more seriously.
I am not part of that team and I happen to think not having it fix rubbish files is fine. @bobo1on1 is part of that team and contributed a lot towards the patch so you might find he is open to including it - I just hope if it does make it in can be switched off as I would hate to see it forced.
- bossanova808 - 2011-07-09
These stutter problems happen with standard 'scene' h264 hdtv rips and Web-DLs so while they may be 'rubbish' files they probably represent a huge proportion of what XBMC users actually play. No one wants a gross hack that causes other serious side effects in general - but from other systems success with these files, it appears it's possible to build a more 'fault tolerant' player that can cope with these sorts of things....which has to be a good thing overall for XBMC surely?