[deuch]

Hello,

I've bought a Xtreamer Ultra and i've got some problems with some videos : Let me explain to you :

Some videos provite stutter like frame drops but the frame drop counter doesn't change (seen with the o key).

But i've noticed that the current FPS down to 21fps instead of beeing constant to 23.976.

LibVADPU is activate, and auto framerate to (so it's not a judder problem because video is displayed at 23.976).

I've made a lot of test, with A/V synchro and different version of linux and nvidia drivers and settings (powermize to off to have full performance of the GPU) :

Openelec.tv with latest drivers
ubuntu 10.04 + XBMC (normal version and VDPAU branch)
Windows 7 + XBMC

I'm using those 3 MKV samples : http://deuch.free.fr/videos/

Video is not smooth, and especially between 30 et 35s in the tunnel, you have one or two stutters.

I want to precise that on the same hardware and with those 2 last configurations above, VLC works great and do not provide stutter.

I've got this kind of errors in the log file :

Code:

8:05:00 T:140564347483904 M:3917172736 ERROR: CDVDPlayerAudio::DecodeFrame - Decode Error. Skipping audio packet
18:05:01 T:140564438509312 M:3917172736 ERROR: Previous line repeats 2 times.
18:05:01 T:140564438509312 M:3917172736 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 6496, consumed: 0
18:05:01 T:140564438509312 M:3917172736 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 6564, consumed: 0
18:05:01 T:140564438509312 M:3917172736 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 6402, consumed: 0
18:05:01 T:140564438509312 M:3917172736 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 6206, consumed: 0
18:05:12 T:140564347483904 M:3916640256 ERROR: CDVDPlayerAudio::DecodeFrame - Decode Error. Skipping audio packet
18:05:42 T:140564599924736 M:3917139968 ERROR: Previous line repeats 61 times.

It appears that there is a lot of audio problems and some video problem. I've remux the video without audio and it helps a little, but it's not perfect.

I think it's a well know problem with XBMC, but will be have a solution to that ? The oprimized nvidia branch doesn't help very much and my old Xtreamer Pro (realtek) works like a charm with those videos.

I've got another samples which doesn't work great ...

Please, find a solution to have the perfect PCHC !

[deuch]

This is the output of xbmc.log : http://pastebin.com/UjUGKP8M

And there are samples used :

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

First is with DTS 6.1 sound and the second is without sound. The second is smoother than the first (but not perfect)

I'm using openelec with the last official nvidia drivers and hardware accelaration enabled, no video post processing and standard upscale. No A/V sync and adjust framerate enabled

Playback is perfect with VLC

[deuch]

I've compiled the last version of the optimized branch for ION2 and the same samples provided stutter.

But, with the sample without sound, no sttuter !! So it is a problem of the demuxer ?

[deuch]

So any idea Team XBMC ? sound demuxing problem ? Can you check it please ?

A lot of french users have this problem ...

[TheSwissKnife]

Remux with forced 24/1001 in mkvmerge (demux completely then in another step remux to be safe).

Then post result & debug log, with sync set as drop/dupe.

[deuch]

I've remuxed the file (extract tracks dirst and remux it with 23.976 forced) :

This is the log results : http://pastebin.com/49imjLps

The first launch is with Sync AV to Playback (drop/dude audio)

The 3 launch after that are without AV Sync and provides different behaviour.

I will post the remuxed sample in a few minutes

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

[bobo1on1]

It's a problem with the dts audio timestamps and how ffmpeg handles them, there's not much that can be done about it at the moment.

[deuch]

I've got the same problem with FLAC audio tracks ... http://deuch.free.fr/videos/stutter-test.mkv

Does ffmpeg team is aware of the problem ?

[TheSwissKnife]

So did they not play ok? Logs look pretty clean, perhaps I am missing something. I would have thought the remux would fix all timestamps to be perfect, leaving only clock sync issues.

[deuch]

The first record in the file is the remux one with AV sync (drop/dude audio). It plays well (nearly, audio is not so good), no "frame drop" (or very subtle). How can i check sync issues ?

There is this kind or error for the first run :

17:46:04 T:140172064499456 M:3860996096 ERROR: Seek, failed to copy 4236438 bytes to history

In the 2,3 and 4 loop (no av sync this time), i've got this kind of error :

17:54:14 T:140172077283072 M:3776647168 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 9102, consumed: 0
17:54:14 T:140172077283072 M:3776647168 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 11975, consumed: 0

But remux files seems to works better. Some "frame drop"/stutter appears sometimes randomly but less frequently. Before it was always at the same timecode (nearly)

I can do more tests if you want or you can download my sample to take a look.

[TheSwissKnife]

17:54:14 T:140172077283072 M:3776647168 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 9102, consumed: 0
17:54:14 T:140172077283072 M:3776647168 WARNING: Decode - avcodec_decode_video didn't consume the full packet. size: 11975, consumed: 0

Don't worry too much about those if only a few. they are caused for example by a flush/reset replaying a history of demuxed data requesting to be dropped so that decoder can get to the same place and the implementation does not adequately track the delay through the decoder so those are generally dropped decoder packets as requested by the player.

Trouble withp laying your file is that if system specific eg clock sync then I won't see it. If pts of DTS track then I would probably see it. Also I no longer use the normal xbmc version so its a pain for me to test.

If it got noticably better than at least part of the issue is the timestamps as bobo1on1 said. They are badly muxed in the first place and nothing is done to try to smooth out the large jitters that should not be there. Additionally xbmc keeps its av sync using those values and does not wait too long before trying to resync.

Now what is your refresh rate of your display? If not very close to 23.976Hz you may see sync issues due to that.

EDIT: Also confirm that you play without subtitles.

[deuch]

I'm playing those files WITH subtitles. I'm using perfect 23.976 (i've got a video scaler Lumagen Radiance XD that handle it perfectly and provides me a lot of information about refresh rate).

When i said that VLC handle perfectly this video, this is what i've done :

XBMC and VLC installed on the same Linux (Ubuntu 10.04).
Refresh Rate set to 23.976 in both test
Same file played on the same place (NAS via SMB)
Sound via HDMI (downmixed to 2.0)
Hardware acceleration ON (XBMC and VLC too)
Skip frames disabled in VLC
Subtitles activated
No A/V sync in XBMC

And it works with VLC, no stutters, no audio/video drop. Same thing with my Xtreamer Pro.

I've exactly the same behaviour with Windows 7 for VLC and XBMC.

I do not need to remux my files to be perfectly played with VLC (Windows and MacOS) or other NMT players (Dune, Xtreamer etc ...)

So if it's a ffmepg problem, can they solve it ?

If you want i can made some more testing. Just ask me what do you want to test

[TheSwissKnife]

1. Does it play well or better without subtitles?
2. Which sync method does it play best - looking only at video continuity and with no subtitles?
3. Does it play perfectly without audio and without subtitles?
4. The refresh rate is not related to your Lumagen but rather your graphics card. The Lumagen is accepting it but its clock is accomodating what it is being fed from the card.
5. ffmpeg demux is not really the problem if the timecodes are wrong, but perhaps it could be more forgiving in cases where they are wrong.

demux out the audio timecodes using mkvextract and look at them. DTS is 10.6666666ms but the timecodes will be integer accumulating the 0.6666666 error until enough to add 1 to a timecode etc. You can see in spreadsheet if they are rubbish.

[deuch]

I will test your suggestions.

The Ultra output 23.976Hz and not 24Hz or other fancy stuff. (59.94Hz too and not 60Hz).

So it's not a problem of output frequency. I wall made new sample and do some testing with/without subtiles, sound etc ... And check too the audio timecode.

Thanks for your help !

[TheSwissKnife]

23.976 is not exactly 23.97024 or whatever (24/1001). No clock is perfect. So you may actually 23.971 for example and audio clock may be a tiny bit out in the other direction - combining makes enough to have to skip/dup something (Audio or video). I solve this by trying to find better modeline to tune the refresh rate to closer to the value required to match audio clock but trial and error is only method (though I added some code to help monitor how far out). Now I don't expect the clock sync is enough to cause more than one video frame issue every few minutes though.

Subtitles are a problem as they block the renderer from presenting a video frame when any new characters/fonts are needed to be cached. If that is long enough to miss a vertical blank you will get a "duplicated" video frame on screen. I wrote a ttf subs pre-caching patch for that.