[deuch]

So if it's a clock problem, do you mean graphic card refresh rate clock problem or internal software clock ?

[deuch]

I've made the extraction of the timecode fot the 2 samples (remuxed and not) :

http://deuch.free.fr/tc-audio.txt
http://deuch.free.fr/tc-audio-remux.txt

I've used this command :

mkvextract timecodes_v2 ultra-sample.mkv 1:tc-audio.txt

i've check that the 1st track was the audio one.

There is some differences between the 2 files but i'm not sure is very relevant.

EDIT : TRy again with my ultra-sample.mkv without subtitles and drop/dude audio :

This is the log : http://pastebin.com/8XFxujEw

Some errors at end

[TheSwissKnife]

Those timecodes are complete rubbish even in remux set - way off and any software that tries to sync to them is going to have problems. What are you remuxing with? I measured 240ms out at worst case (rather than a swing of say 70ms to and thro with a constant average) - the 240ms is I think enough for xbmc to give up even with drop/dupe etc and just immediately adjust the clock, thus screwing the video sync.

My advice is get the latest version of mkvmerge, mkvextract, mkvextractgui etc.

Extract using GUI all tracks. Then drag them into mkvmerge gui (mmg) and set the video stream to forced 24/1001 fps. I am very sure you will get proper timecodes then...and I would think that should solve most of your problems.

BTW all I did was insert the timecodes into excel in column A (without the header line) and in column B use =(ROW()-1)*10.66666666666-A1 pasted all the way down (ie formula into B1 then copy and paste down column). Column B show the fluctation then from zero. You can find the max using max(B1:B11968). Now overall the timestamps seem not to be obviously drifting on a long running average so xbmc could try to improve, at least by not shifting the clock so readily on a large swing in timestamp - at least averaging over a second even when large delta but that is something to discuss with bobo1on1.

[senilio]

I just wanted to say thanks to deuch for properly presenting this problem which I'm also experiencing, but I'm not technically fit to make myself understood

I'm on 10.1 stable on an Asus EEEBox 1501p running Ubuntu Server. Have also tried OpenELEC with the same results. NMT play all my files perfectly. I'll do my best to help out with the troubleshooting, in case it's needed. Just let me know!

//senilio

[deuch]

Those timecodes are complete rubbish even in remux set - way off and any software that tries to sync to them is going to have problems. What are you remuxing with? I measured 240ms out at worst case (rather than a swing of say 70ms to and thro with a constant average) - the 240ms is I think enough for xbmc to give up even with drop/dupe etc and just immediately adjust the clock, thus screwing the video sync.

My advice is get the latest version of mkvmerge, mkvextract, mkvextractgui etc.

Extract using GUI all tracks. Then drag them into mkvmerge gui (mmg) and set the video stream to forced 24/1001 fps. I am very sure you will get proper timecodes then...and I would think that should solve most of your problems.

BTW all I did was insert the timecodes into excel in column A (without the header line) and in column B use =(ROW()-1)*10.66666666666-A1 pasted all the way down (ie formula into B1 then copy and paste down column). Column B show the fluctation then from zero. You can find the max using max(B1:B11968). Now overall the timestamps seem not to be obviously drifting on a long running average so xbmc could try to improve, at least by not shifting the clock so readily on a large swing in timestamp - at least averaging over a second even when large delta but that is something to discuss with bobo1on1.

I've to check the version of my tools but mkvmerge is 4.3.0 (MacOS and Windows) (not the last indeed, i will try with the 4.8)

I've demuxed all the tracks with mkvextract (tracks 1:audio.dts 2:video.h264) and remuxed those with mkvmerge with forced FPS (24/1001) and header compression set to none.

I will try your suggestion and now i know how to check the timestamp thanks

[deuch]

Ok, i've extracted the tracks and remuxed with the last version (4.8.0)

http://deuch.free.fr/audio-tc-remux-4.8.0.txt

So i've tried your tips to evaluate timestamps and i've got this for the first lines :

26 -15,33333334
26 -15,33333334
26 -15,33333334
26 -15,33333334
26 -15,33333334
26 -15,33333334
26 -15,33333334
26 -15,33333334
111 -100,3333333
111 -100,3333333
111 -100,3333333
111 -100,3333333
111 -100,3333333
111 -100,3333333
111 -100,3333333

I'm not sure i've really understand your tips (sorry i'm just a french guy) :-D

[TheSwissKnife]

Your timestamps are slightly better but not much. I don't understand to be honest, why your mkvmerge is so messed up.

You are typing something wrong in excel (Assuming you use that)

Cell B1 should say

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

Cell B2 should be

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

etc

works for me.

I will download and remux myself.

[TheSwissKnife]

http://pastebin.com/MYW3DKEy

Look at those. I demuxed using mkvextractgui 2.2.2.5, then muxed with mkvmerge 4.8.0 (24/1001), then extracted timecodes using mkvextract command line.

The timecodes are now even with decimals which is actually even better (must be enhancement since I last did this).

EDIT : All from your remux sample.

[deuch]

Ok Thanks,

I've downloaded this tools : http://www.bunkus.org/videotools/mkvtoolnix/

Using under windows vista ...


mkvextract tracks ultra-sample.mkv 1:audio.dts 3:video.h264

Remuxed it with mkvmerge 4.8.0

set 24/10001 for specific format for the video, set header compression to none for video and audio

mkvextract timecodes_v2 ultra_sample 1:audio-tc.txt 2:video-tc.txt

Did i do something wrong ? :-( I have rounded numbers ... i do not understand


EDIT : OK i've tried again and it's working now ...

A example :

0 10,66666666
11 -0,33333334
21,666666 -10,99999934
32,333332 -21,66666534
42,999998 -32,33333134
53,666664 -42,99999734
64,33333 -53,66666334
74,999996 -64,33332934
85,666662 -74,99999534
96 -85,33333334
106,666666 -95,99999934
117,333332 -106,6666653
127,999998 -117,3333313
138,666664 -127,9999973
149,33333 -138,6666633
159,999996 -149,3333293
170,666662 -159,9999953

This is the file : http://deuch.free.fr/audio-tc.txt

So with your formula, the delay is often superior to 70ms ...

[TheSwissKnife]

Ok so you must have done something wrong before.

Those timecodes are now good, I don't see any 70ms swing max is 0.3333ms. Try the file on your system.

EDIT sample of the 2 columns from excel

0 0.0000
11 -0.3333
21.666666 -0.3333
32.333332 -0.3333
42.999998 -0.3333
53.666664 -0.3333
64.33333 -0.3333
74.999996 -0.3333
85.666662 -0.3333
96 0.0000
106.666666 0.0000
117.333332 0.0000
127.999998 0.0000
138.666664 0.0000
149.33333 0.0000
159.999996 0.0000
170.666662 0.0000
181 0.3333
191.666666 0.3333
202.333332 0.3333
212.999998 0.3333
223.666664 0.3333
234.33333 0.3333
244.999996 0.3333
255.666662 0.3333
267 -0.3333
277.666666 -0.3333
288.333332 -0.3333


Go to cell B1 and enter exactly the text I gave:

Code:

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

see that the value becomes zero. And check the cell content is entered correctly again in the top bar. Then highlight cell B1 and hit Ctrl-C to copy. THen highlight all the cells in column B you want to paste this too (ok to be the one already entered too, or you can just click on column B header button though that will do more than you might want) - anyway then hit Ctrl-V to paste. Check the content of B2 say the same as B1 with the A1 changed to A2, then the value should be -0.3333.
then

[deuch]

So it's better now ...

0 0,000000
11 -0,333333
21,666666 -0,333333
32,333332 -0,333332
42,999998 -0,333331
53,666664 -0,333331
64,33333 -0,333330
74,999996 -0,333329
85,666662 -0,333329
96 0,000000
106,666666 0,000001
117,333332 0,000001
127,999998 0,000002
138,666664 0,000003
149,33333 0,000003
159,999996 0,000004
170,666662 0,000005
181 0,333333
191,666666 0,333334
202,333332 0,333335
212,999998 0,333335
223,666664 0,333336
234,33333 0,333337
244,999996 0,333337
255,666662 0,333338
267 -0,333333
277,666666 -0,333333

I will try this new file tonight.

[TheSwissKnife]

This will fix most of your problem and possibly all. If any video stutters at all after that then they are most likely due to subtitle render (switch off subtitle to confirm), or to refresh rate mismatch to audio clock, when using sync method audio clock (setting drop/dupe would resolve those).

[deuch]

It's better but not perfect, but farly better

Maybe a patch would resolve this issue ?

[senilio]

How is for instance VLC or Popcorn Hour handling files with bad timing? Since on those the example files play stutter free, even the ones not remuxed. What is the difference from XBMC?

[TheSwissKnife]

@deuch Well I don't know what not perfect means. Given all the questions and scenarios I posed I would hope for a little more thoroughness.

The difference with xbmc is that it is trying to keep audio/video sync but generally speaking the audio is the master, it makes no real attempt to compensate for bad timecodes in the audio (beyond a 1 second averaging with a cap on the amount a single timecode is allowed to be out). All attempts to try to improve this are going to come with issues and could compromise quality on perfectly coded streams. There are patches to filter out the timecode jitter, on trac somewhere but team xbmc appear reluctant to incorporate them - and I think that caution is well justified.