Kodi Community Forum

Full Version: SVN Dharma / video skips / CDVDPlayerAudio:: Discontinuity
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Okay, I gave up. After checking all forum threads dealing with similar issues and trying everything more or less obvious, I decided to post a new thread. Either my setup is f*d up on two different systems (then I'm asking for your help guys), or something is wrong in Dharma branch (then I will do everything I can to help fixing the bug).

Problem description:

100% reproducible on two different systems: skips in video playback, in exactly same places. Everytime playbaks skips, log file says something like:

Code:
DEBUG: CDVDPlayerAudio:: Discontinuity - was:415136666.650000, should be:414988833.324750, error:-147833.325249

Full xbmc.log from both systems during playback of the same sample (see below):

#1: http://pastebin.com/UdJjYm35
#2: http://pastebin.com/si5bD8QK

Video source:

Code:
Seems stream 0 codec frame rate differs from container frame rate: 2000.00 (2000/1) -> 23.98 (24000/1001)
Input #0, matroska, from 'grim-matrix.int.mkv':
  Duration: 02:16:17.89, start: 0.000000, bitrate: N/A
    Stream #0.0(eng): Video: h264, yuv420p, 1920x800, PAR 1:1 DAR 12:5, 23.98 tbr, 1k tbn, 2k tbc
    Stream #0.1: Audio: ac3, 48000 Hz, 6 channels, s16
    Stream #0.2(eng): Subtitle: 0x0000
    Stream #0.3(fre): Subtitle: 0x0000
    Stream #0.4(ita): Subtitle: 0x0000
    Stream #0.5(dut): Subtitle: 0x0000
    Stream #0.6(por): Subtitle: 0x0000
    Stream #0.7(spa): Subtitle: 0x0000

Sample here: http://spin.ict.pwr.wroc.pl/amo/matrix-sample.mkv

Bitrate is ~10MBit when skips occur. I play much higher bitrate 1080p videos with no judder at all. This is the only source where I was able to find this error so far.

The most visible moments, where skips occur (but there are more of them):
  1. Trinity walks away from Neo, just before she's off the screen
  2. First scene with window cleaners, when the one on te left side of the screen stands up
  3. Neo's boss leans back

NOTE: I've tried playing it with stock MPlayer (software only, xv output) and playback was fine.

Hardware/Software setup:
  1. Zotac ION, Atom 330 1.6Ghz, HT
    • Linux mbox 2.6.34-gentoo-r2 #1 SMP PREEMPT Sun Aug 1 15:42:13 CEST 2010 x86_64 Intel® Atom™ CPU 330 @ 1.60GHz GenuineIntel GNU/Linux
    • NVidia drivers 256.35
    • X.Org X Server 1.7.6
    • XBMC version: SVN, Dharma branch, 32416
  2. Core2Duo E7400 + GeForce 9500 GT
    • Linux amo 2.6.34-gentoo-r1 #1 SMP PREEMPT Tue Jul 13 10:38:50 CEST 2010 x86_64
    • NVidia drivers 256.35
    • X.Org X Server 1.7.6
    • XBMC version: SVN, Dharma branch, 32449

XBMC configuration

This is my usual XBMC config in regards to video playback, on both systems:
  • rendering method -> GLSL
  • VDPAU enabled
  • sync playback to display -> ON
  • adjust display refresh rate -> ON / audio clock
  • vertical blank sync -> always enabled

Tried the following:

(...and nothing helped)
  • downgrading video driver
  • downgrading libvdpau
  • disabling "sync playback", "adjust refresh rate"
  • messing with rendering methods
  • playing video in 60Hz mode
  • disabling audio (unloading ALSA modules)

If there's anything more I can provide you with to nail this one down - just let me know.

If anyone has any ideas about what more could I check/try - shoot.
Sounds like a bugged sample to be honest if it's only that sample that exhibits it.
elupus Wrote:Sounds like a bugged sample to be honest if it's only that sample that exhibits it.

That was my first guess too, but (despite of me beliving that whoever encoded this did a good job, which is irrelevant here):

1. There is no visible errors in the stream (no malformed/missing frames)
2. Most of all: It plays OK in MPlayer

Also: the sample is a sample cut from a movie. And the whole movie skips the same way.
Elupus, I just did one more test (with the same sample), to verify my observations once more. This time system was Dell Latitude E4300 with integrated Intel graphics. Results, short:

XBMC SVN Dharma 32416: skips
MPlayer SVN-r2976904.3.4: plays fine
If you increase the log level on mplayer (-msglevel all=6) you will see "no picture" where XBMC skips.
Kaistian, thanks for checking this. I followed your footsteps and run mplayer with more verbose output. You're right about "no picture" messages. But as I was able to check, they appear in points other then where xbmc skips. And those "no picture" points look "clean" in both mplayer and xbmc. Could you double check (mplayer vs. xbmc)?

Also, can you confirm, that this sample plays smoothly with MPlayer, while not with XBMC?

I also watched those "skippy" parts frame-by-frame in mplayer - it doesn't look like any frame is missing in video stream.

What I see at those "skippy" points, on the other hand (with MPlayer), is A-V delay instability. Take a look at this graph: http://spin.ict.pwr.wroc.pl/amo/av_delay.png - those "peaks" in fact match skips in XBMC.

Still, this plays OK in MPlayer. I can't see any drops, although I really, really try.
I suppose mplayer handles borked audio timestamps a little better.
Okay, that was the last test for today, I promise:
Same DELL Latitude E4300, but with XBMC 9.11 (sync playback to display on, adjust refresh rate on, GLSL shaders).

Sample plays just fine.
vpiotr Wrote:But as I was able to check, they appear in points other then where xbmc skips. And those "no picture" points look "clean" in both mplayer and xbmc. Could you double check (mplayer vs. xbmc)?
I get the no picture right before the skip, so I just assumed a connection. But some skips doesn't produce no picture message.

Mplayer does play it well, but vlc does not and it's even worse than XBMC, so the encoding isn't good.

Some of the messages in vlc:
[0x22254b8] main audio output warning: audio drift is too big (128035), dropping buffer
[0x22254b8] main audio output warning: buffer is 96035 late, triggering upsampling
[0x22254b8] main audio output warning: audio drift is too big (-120319), clearing out
[0x22254b8] main audio output warning: timing screwed, stopping resampling
[0x22254b8] main audio output warning: mixer start isn't output start (-161311)
[0x22254b8] main audio output warning: audio drift is too big (192167), dropping buffer
[0x22254b8] main audio output warning: audio drift is too big (160167), dropping buffer
[0x22254b8] main audio output warning: audio drift is too big (128167), dropping buffer
[0x22254b8] main audio output warning: buffer is 96167 late, triggering upsampling
[0x22254b8] main audio output warning: audio drift is too big (-120063), clearing out
[0x22254b8] main audio output warning: timing screwed, stopping resampling
[0x22254b8] main audio output warning: mixer start isn't output start (-156672)
[0x22254b8] main audio output warning: audio drift is too big (224167), dropping buffer
[0x22254b8] main audio output warning: audio drift is too big (192167), dropping buffer
[0x22254b8] main audio output warning: audio drift is too big (160167), dropping buffer
[0x22254b8] main audio output warning: audio drift is too big (128167), dropping buffer
[0x22254b8] main audio output warning: buffer is 96167 late, triggering upsampling
[0x22254b8] main audio output warning: audio drift is too big (-128917), clearing out
[0x22254b8] main audio output warning: timing screwed, stopping resampling
Oh, I forgot about vlc!
It has one advantage over the other players - it says that something is wrong with the stream, clearly. :-) Just out of curiosity, I played the sample with VLC - I would say mine plays as good as mplayer, but this may be just the version.

Okay, thanks guys for your time. Bottom line is that elupus was right and the encode looks messed up. But anyway, I hope we didn't waste our time. Short summary in my oppinion should be:

1. Dharma's ability to handle "messed up" streams is considerably worse than 9.11
2. Other players can handle this better, too.

I understand that this is the price we now pay for _perfect_ video quality in all other cases, when encode is correct, and that doing something about it won't be a main goal for XBMC team in the near future.

I personally would consider it a candidate for enhancement at least. Should I open a trac ticket?
bobo1on1 Wrote:I suppose mplayer handles borked audio timestamps a little better.

I can reproduce this issue on any number of movies in my collection (200+).