View Single Post
Old 6th April 2010, 17:31   #1507  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
They don't modify any header value, they just modify the timestamps of each packet.
Actually they do both. It changes "Track: DefaultDuration" which shouldn't be done for such purposes. Because for audio you have fixed frame duration according to codec used. Also, after muxing you can't easily detect if --sync was used.
Quote:
Originally Posted by Mosu View Post
Because not every player supports that element (unfortunately).
Current method works (in different ways) with Gabest and Haali splitter and with ffplay. It doesn't work with mplayer and VLC.

Actually, it works with VLC just as it should. VLC respects timecodecs and tries to add silence/cut audio respectively (I haven't looked at sources, so it's just a guess from user point). Other splitters detect difference between "Track: DefaultDuration" and real audio frame duration and modify timecodes. But it's the way, how TrackTimeCodeScale should work:
Quote:
It would also be possible to adjust the video to match the audio's speed. However, for playback, the only thing that should be counted on is the selected track(s) timecodes being adjusted if they need to be scaled.
I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).
Abradoks is offline