Kodi Community Forum
Video stuttering in Linux - Printable Version

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

Pages: 1 2 3 4 5 6 7 8 9


- deuch - 2011-07-07

TheSwissKnife Wrote:1. There is no such thing as "perfect video timing with scaler/TV etc". If you are saying that your modeline is accepted happily as a mode 32 23.976p signal then fine - but there is a large range of modelines that would give the same effect, and most will have different refresh rate. More importantly, none of them will exactly match your audio chip clock rate, but you might be close enough to only drift slowly so that the delta is less than an audio or video frame over a few hours. Please take the time to understand this fundamental point.

2. WITHOUT audio AND WITH subtitle works or not? - you have not made this clear.

3. With sync method audio drop/dupe (not dude), and no subtitles do you have VIDEO stutter or not? You don't make it clear the way you write. I am not interested in the fact you get audio stutter at this stage - so don't mention at this stage. If you get video stutter please confirm that this happens without the codec screen up and if there is anything in the debug log around that time (with a few seconds). How many stutters do you see through the sample on average? The way I remember the standard xbmc code is that you need a 100ms delta between audio pts and clock for it to move the clock in drop/dupe mode so if this is happening with good timecodes then you really have a big problem with the audio driving on your system.

I will try sample later - please (re-)post the link to the version that you are now using after remux.

All my video system works perfectly fine.
I'm understanding the "problem" of audio and video sync with multiple clocks.
But why other software works with the same hardware and the same file ? Does XBMC choose a bad solution to handle this sync ? It's the first time that i've this kind of issue with a soft (or a hardware). I can easily compare because i've a lot a NMT and different PC with different software. It's the first time that i've to tweak and made test just to be able to play a video file. So yes i'm a little angry because i can not understand why this kind of probleam can appear in 21st.

I will check all the point you asked me and will try to be more clear (english is not my native language so sometimes i do not express myself very clearly).

I can say that subtitles do not provide stutter even with or without audio (i'm using a another font than arial.ttf). To not have stutter, i've to remove the audio track.

I've stutter without A/V sync. After remuxing the file, i've got stutter gain. Less than before, but it still present (with audio and subtitles and no A/V).

I can test with A/V but it help a bit, but far from perfect. Maybe you can debug with the results of this test, but it doesn't solve my problem.

My sample :

Original :

http://deuch.free.fr/videos/ultra-sample.mkv

Without sound :

http://deuch.free.fr/videos/ultra-sample-no-sound.mkv

Remuxed :

http://deuch.free.fr/videos/ultra-sample-remux.mkv

Even the remuxed file provides some stutter (during the travelling on the pyramid and sometimes in the tunnel after a another play)


- bibi - 2011-07-07

Hi,

I'm back after a few testing. To remember, i have stutters with all 24p files (DTS, AC3...) with "adjust refresh rate" ON... If the video are played at 60Hz (3:2 pulldown), it doesnt stutter but the playback is kind of unsmooth. Also i use analog audio.

My xorg.conf has been made with the help of this thread : "http://forum.xbmc.org/showpost.php?p=506251&postcount=1"

I tried without subtiles and it stills occurs.
I tried with "adjust refresh rate" ON and all synchro option (drop/dupe audio...) and it still occurs.

What i still need to try :

- Use working custom modeline (i tried with a custom modeline at 23.976 from a web calculator but my TV indicates me that it's not a valid format Oo; but i'm pretty sure it's valid cause i get it with good refresh rate (horizontal and vertical) and good pixel clock. Anyway when i try the modeline from my EDID but with a manual configuration (NOEdidmode... in xorg.conf) it doesn't work as well Eek.

- remux files with good timestamp, video are on my server and i can't use a gui for mkvmerge cause my nxserver cant deport the gui and i am too lazy to use console Big Grin (if you have a script, i looked for one on the web but couldn't get a script without weird dependances (i'm on arch) -> i'm gonna test your files this week-end (Deutch)

- Test without Vdpau...

- Test with HDMI, i will get an HC-amplificator in september... Wink . I hope AE engine will get in trunk at this time for my new installation in my new home Big Grin

-Test on windows, well i don't think it will happen for a long time

Anyway, i really like XBMC. It's nice to see so many people involved in such an open-source project which targets mainly linux.

Keep on guys !

Bibi


- TheSwissKnife - 2011-07-07

avpap Wrote:And you deserve a BIG Thanks for your efforts.

Thanks for the thanks but honestly I don't do it for appreciation. I would much rather see the community effort working as it should. That is (and I don't mean to be rude as feedback is almost ok in this thread, unlike some others I offered my help in) other users putting in more effort than they might actually like to so that we can move forward together. So really I mean I am happy when I see people step out of their comfort zone and try to learn at least a little bit - that is the reason I try to give explanations that some may find complicated. I would be happy to expand on things I write that are not understood - and also will (perhaps not so happily ;-)) admit when I have made an error (and there will be many), so please try to learn, refute and enhance.


- TheSwissKnife - 2011-07-07

deuch Wrote:All my video system works perfectly fine.
I'm understanding the "problem" of audio and video sync with multiple clocks.
But why other software works with the same hardware and the same file ? Does XBMC choose a bad solution to handle this sync ? It's the first time that i've this kind of issue with a soft (or a hardware). I can easily compare because i've a lot a NMT and different PC with different software. It's the first time that i've to tweak and made test just to be able to play a video file. So yes i'm a little angry because i can not understand why this kind of probleam can appear in 21st.
I understand why you bring other players into the subject as sometimes it helps to know that things could work better, but often it does not help to keep mentioning it - there are architectural differences and design choices that mean comparisons are sometimes unhelpful.

Quote:I can say that subtitles do not provide stutter even with or without audio (i'm using a another font than arial.ttf). To not have stutter, i've to remove the audio track.
Looking at those files I think the subtitle is overlay format rather than ttf so the font config choice may not be relevant here.

Quote:I've stutter without A/V sync. After remuxing the file, i've got stutter gain. Less than before, but it still present (with audio and subtitles and no A/V).

I can test with A/V but it help a bit, but far from perfect.

What do you mean by without A/V sync? I don't ask about any test with subtitles. I am suggesting you start by focussing on a test where display refresh rate matches video stream fps (as you have stated this should be fine), and "sync playback to display" is set and sync method is "drop/dupe audio". Don't use codec info and don't have subtitles, but have debug enabled. Look for video stutter and then look in debug log for the corresponding time of this event. Ideally state how many periods of stutter are seen and whether it felt like a dropped video frame or frame playing for longer than it should and/or any other observation.


- TheSwissKnife - 2011-07-07

bibi Wrote:What i still need to try :

- Use working custom modeline (i tried with a custom modeline at 23.976 from a web calculator but my TV indicates me that it's not a valid format Oo; but i'm pretty sure it's valid cause i get it with good refresh rate (horizontal and vertical) and good pixel clock. Anyway when i try the modeline from my EDID but with a manual configuration (NOEdidmode... in xorg.conf) it doesn't work as well Eek.

- remux files with good timestamp, video are on my server and i can't use a gui for mkvmerge cause my nxserver cant deport the gui and i am too lazy to use console Big Grin (if you have a script, i looked for one on the web but couldn't get a script without weird dependances (i'm on arch) -> i'm gonna test your files this week-end (Deutch)

remux is crucial first step - and must demux fully then remux with forced 24/1.001 rate, and up-to-date mkvmerge. I am not sure what @deuch was doing wrong when he did this the first few times.

modeline calculation is a pain because tv/receiver/processor may refuse to sync with esoteric lines. My setup goes through a processor that seems happy to accept a wide range of modelines so I can tune in to match the audio clock more or less perfectly. When I tried going to display directly I remember having issues. As soon as I get round to it I will create a branch with my refresh rate measurement and clock sync drift info in codec info overlay - that helps to see the delta.


- Robotica - 2011-07-07

TheSwissKnife Wrote:I understand why you bring other players into the subject as sometimes it helps to know that things could work better, but often it does not help to keep mentioning it - there are architectural differences and design choices that mean comparisons are sometimes unhelpful.

Just know that XBMC's DVDPlayer is behind in development compared to most known players (like MPC, VLC, Mplayer, etc.). Sometimes due to architecture, sometimes due to interest (VAAPI and intel/amd hardware) or choices (following FFMPEG). And off course the number of devs for eacht player is different.

In the end it doesn't matter that much.


- TheSwissKnife - 2011-07-07

Robotica Wrote:Just know that XBMC's DVDPlayer is behind in development compared to most known players (like MPC, VLC, Mplayer, etc.). Sometimes due to architecture, sometimes due to interest (VAAPI and intel/amd hardware) or choices (following FFMPEG). And off course the number of devs for eacht player is different.

In the end it doesn't matter that much.

I would not dispute that the player is probably more primitive overall, but I think for example it got vdpau support (partly via ffmpeg support) pretty early compared to others - though I wasn't really involved at the time.


- TheSwissKnife - 2011-07-07

deuch Wrote:Remuxed :

http://deuch.free.fr/videos/ultra-sample-remux.mkv

Even the remuxed file provides some stutter (during the travelling on the pyramid and sometimes in the tunnel after a another play)

I just downloaded that file and it is still looking like crap timecodes to me. I remuxed myself and it then plays ok on my current setup - though first few seconds are an issue while the sync sorts itself out (because I have not yet re-merged my sync tweaks for that). So please triple check you are playing a file with good timecodes.


- X3lectric - 2011-07-07

http://deuch.free.fr/videos/ultra-sample.mkv

plays 1000% ok no dropped frames no jerky video no lack of audio sync, its just smoother than a babys bottom... nice piece of anime, not that I usually or often watch anime.


- X3lectric - 2011-07-07

Just reminds me of this

http://forum.xbmc.org/showthread.php?tid=89353

Now thats a test.

start and finish with 14 frames (its like that at video start, so not really considered a problem) on Asrock ION 330 HT

cheers


- deuch - 2011-07-08

X3lectric Wrote:http://deuch.free.fr/videos/ultra-sample.mkv

plays 1000% ok no dropped frames no jerky video no lack of audio sync, its just smoother than a babys bottom... nice piece of anime, not that I usually or often watch anime.

What the version do you use of XBMC ? What kind of patches or branch do you use ? Not the official one i suppose ?


- X3lectric - 2011-07-08

I use XBMClive (xbmcbuntu install) with everything official XBMC and I compile XBMC from GIT source, patches and other fixes on my signature or blog or has been posted on these forums. Its Lucid based or Ubuntu 10.04, Nvidia drivers, 275.09.07 vdpau acceleration.


- deuch - 2011-07-08

X3lectric Wrote:I use XBMClive (xbmcbuntu install) with everything official XBMC and I compile XBMC from GIT source, patches and other fixes on my signature or blog or has been posted on these forums. Its Lucid based or Ubuntu 10.04, Nvidia drivers, 275.09.07 vdpau acceleration.

So now, what is the magic trick to have the same result ? Because i don't care about the origin of the problem, i want to have a solution to my (and not only me) problem.

Because i'm very surprised that you don't have problem with this file if you are using the official XBMC (witout Audio Engine ?).

So if you have a perfect setup, maybe it will be a good thing to post a HOW-TO to achieve the same result as yours.


- TheSwissKnife - 2011-07-08

I have no idea how @x3electric can play that file without issue. xbmc mainline from git will move the clock to the audio pts it thinks is playing if it is more 100ms out regardless of sync method. That file has 177ms pts swing which might just reduce to around 100ms once the pts values have been pattern processed. It may be that the 100ms is just about avoided and this condition is not hit eg if the error was say slightly in the opposite direction to begin with. However if using skip-dupe sync method then a 10ms swing in pts (averaged over 1 second) will generate an audio drop or dupe, and if using sync method of audio clock then a swing of 42ms approx (refresh rate frame cycle time) would cause the clock to move. The timecodes have many sections where it would seem that they would drift out easily enough to hit one of those conditions (eg especially around the 35second mark). The only way I can see that file playing ok is with a pts smoothing/tracking patch.

@deuch please fix the file properly and try as originally discussed.


- X3lectric - 2011-07-08

deuch Wrote:So now, what is the magic trick to have the same result ? Because i don't care about the origin of the problem, i want to have a solution to my (and not only me) problem.

Because i'm very surprised that you don't have problem with this file if you are using the official XBMC (witout Audio Engine ?).

So if you have a perfect setup, maybe it will be a good thing to post a HOW-TO to achieve the same result as yours.

Its all been discussed to death, fixes posted tweaking all over for various systems.

My system based in lucid also has alsa 1.0.24, proper xorg.conf, latest drivers and vdpau libs, bleeding edge XBMC, and advancedsettings.xml refresh overrides and all can be found on my signature, if you want me to type another 30 to 40 THOUSAND words into a special how-to, sorry, not at the moment.

Your file just works idk or can explain to you why it does or why your system doesn't. Your problem is hardly new.

My ppa has superior version for main components for lucid including audio via alsa video and the very latest or last vdpau, amongst a few.

//:Edit

Your on ION2 and me on ION1

You are experiencing same problems with all openelec, Lucid and Windows, that alone is food for thought.

+ I have never worked with a ION2.

If your using lucid the slew of stuff (drivers and vdpau libs alsa etc...) I've had to upgrade and tweak (xorg.conf and advancedsettings.xml refresh overrides) is mostly on my signature and the rest is on these forums.

All I know is this, your main file works, idk why it works it just does, if your not willing to try and fix yourself following said how-tos and what theswissknife is saying, none can help you but yourself.

Im on a ION1 which is inferior to ION2 on both GPU and CPU counts. As I said I dont have ION2 experience. All I know is this, your issue is hardly new and has been covered.