[ashlar]

While I do not speak for the team, I think this will probably be put in Eden unless it is thoroughly tested quickly and/or a very simple fix. Dharma is just about to be released, and I am sure the team doesn't want any complications.

I know it's supposedly in feature-freeze. The question was meant to discover whether this was considered a bug or a missing feature. Reading its description it looks like a bug, but I might be wrong.

[danconti]

It's less hackish since the boxee solution would create a remaining lipsync error if some dts samples are corrupt, or the file has been muxed in a fashing where audio timestamps drift over longer periods of time.

It will also mess with MKV's that have been muxed correctly. even if those are rare at the moment they will hopefully become more common.

My change will still trust timestamps from the mkv, it will just lowpass filter the error compared to timestamps as calculated from decoded samples.

Fair that our patch can leave lipsync error since we trust whatever timestamp we land on. It's a trade off. I do worry that your change is susceptible to dropouts still if a seek happens to just before the dropout point and your error calculation hasn't had enough time to figure it out, as you start with the audio clock (based on the resync packet i believe) which is probably inaccurate.

One other thing i noticed. Since you are using the duration calculation in dvdplayeraudio instead of the demuxer duration, i think this will have trouble when doing bitstreaming/passthrough. The reason is the calculation is based on pcm samples instead of encoded data. I think to do this properly you have to at least calculate the accurate frame duration (either by fixing the time scale issues in ffmpeg or by using that part of the change i provided) and using the packet duration when doing passthrough to move the audio clock forward. This is how we handle that part of the problem.

Cheers

[TheSwissKnife]

Can I assume this problem is simply that of strangely fluctuating dts audio timestamps. If so I have always found that demux with mkvextract then remux with mmg (mkvmerge gui) with forced video refresh rate (eg 24000/1001) fixes this. I have seen files for example where timestamp patterns can be out by more than 200ms in places, and when remuxed go back to the max offset of 75ms (and stays within a few ms of 37ms average offset, ie only correct every 8 frames).

[idioteque]

Could the osx version also be affected because I suspect it to be especially after resuming from sleep I see very slight stutter only when playing DTS mkv's

[bobo1on1]

All platforms are affected by this.

[kolja]

It seems I have some MKVs with DTS tracks having bad timestamps. Since Dharma once every few seconds the video freezes for a very short time, looking much like a frame drop, but the dropped frames counter does not increase. The glitch occurs repeatable exactly at the same position in the video, and I always get corresponding log entries like this:

Code:

21:42:43 T:2590002064 M:1333829632 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:454273000.000000, curr:454256000.000000, diff:-17000.000000
21:42:43 T:2590002064 M:1333911552 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:454522000.000000, curr:454512000.000000, diff:-10000.000000
21:42:47 T:2590002064 M:1333800960 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:458518000.000000, curr:458502000.000000, diff:-16000.000000
21:42:49 T:2590002064 M:1333751808 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:460108000.000000, curr:460048000.000000, diff:-60000.000000
21:42:51 T:2590002064 M:1333694464 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:462081000.000000, curr:462054000.000000, diff:-27000.000000
21:42:53 T:2590002064 M:1333796864 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:464086000.000000, curr:464059000.000000, diff:-27000.000000
21:42:54 T:2590002064 M:1333755904 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:466092000.000000, curr:466064000.000000, diff:-28000.000000
21:42:57 T:2590002064 M:1333698560 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:468097000.000000, curr:468070000.000000, diff:-27000.000000
21:42:59 T:2590002064 M:1333665792 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:470102000.000000, curr:470075000.000000, diff:-27000.000000
21:43:00 T:2590002064 M:1333751808 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:471852000.000000, curr:471814000.000000, diff:-38000.000000
21:43:02 T:2590002064 M:1333694464 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:473590000.000000, curr:473542000.000000, diff:-48000.000000
21:43:04 T:2590002064 M:1333764096 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:475318000.000000, curr:475312000.000000, diff:-6000.000000
21:43:08 T:2590002064 M:1333665792 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:479350000.000000, curr:479323000.000000, diff:-27000.000000
21:43:12 T:2590002064 M:1333694464 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:483137000.000000, curr:483078000.000000, diff:-59000.000000
21:43:14 T:2590002064 M:1333653504 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:485110000.000000, curr:485083000.000000, diff:-27000.000000
21:43:16 T:2590002064 M:1333714944 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:487116000.000000, curr:487088000.000000, diff:-28000.000000
21:43:18 T:2590002064 M:1333673984 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:489121000.000000, curr:489083000.000000, diff:-38000.000000
21:43:19 T:2590002064 M:1333751808 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:490774000.000000, curr:490768000.000000, diff:-6000.000000
21:43:21 T:2590002064 M:1333686272 WARNING: CDVDPlayer::CheckContinuity - wrapback of stream:1, prev:492289000.000000, curr:492251000.000000, diff:-38000.000000

Based on TheSwissKnife's suggestion I was able to fix those files by splitting out the DTS track and merge it in again. After that, the video is smooth again and the continuity warnings do not appear anymore.

Does anyone know tools to check timestamps in an MKV file for continuity without playing them back in xbmc? It would be nice if I could run a check over my library ...

[bobo1on1]

You probably have to write your own tool for that, using the ffmpeg libraries.

[m0bbed]

Hi,
I'm happy to have found this thread because I was struggling the last 2 weeks with this "suttering" issue of mkv files. Especially when they are remuxed with a newer Version of mkvmerge. I use version 4.4.0 and some mkv's show this stutter problem with the final Dharma build.

I read this thread and found this patch:
http://trac.xbmc.org/ticket/10891
I downloaded it and have the "DTSinMKV.patch" on my harddrive now.

But I have no idea what to do with the patch. How can I install it? Where do I copy it into?

Please helb me out of my perdition...

thanks
m0bbed

[TheSwissKnife]

Make sure you completely demux the audio out, and then as a separate step remux it with the mkvmerge tool, with the appropriate forced frame rate. I think then the timestamps should be fixed then and no need for this patch.

If you extract the timecodes (again with mkvextract) from the bad file and suck them into ms excel for example you should be able to see any bad timecodes by sticking appropriate formula in next column.

For example a primitive solution assuming you just paste (or insert from text file) the timecodes into excel sheet, column A starting at row 1 with value zero, then stick into cell B1

Code:

=(ROW()-1)*10.66666666666-A1

then copy & paste this all the way down the column and look for larger than normal values (positive or negative) [outside the standard 75ms pattern swing].

[m0bbed]

is this "bad timecodes" problem caused by mkvmerge? Yesterday a new Version of mkvmerge appeared (Version 4.5.0).
I'll try to mux with this version and hope the problem is gone. Otherwise I tend to use an older Version (below Version 4).
All the problems with the "header compression" which is on by default in the new version suck. Also this "bad timecode" issue wasn't there in earlier Versions.

Is there any reason to upgrade from e.g Version 2.9.0 of mkvmerge? With that version I never had any problems.

m0bbed

[TheSwissKnife]

Well I was using 4.3 and the extract followed by remux with forced frame rate seem to always give good files. I cannot say exactly where the original problem was created but I know that certainly some bad ts files has writing application as mkvmerge 4.3 too (so possibly not with using the forced frame rate is the issue or perhaps trying to do it in one step - I don't know). v4.5 seems to at least at the default duration for DTS but not much else in the changelog seems related.