View Single Post
Old 6th April 2010, 19:37   #1514  |  Link
Abradoks
Registered User
 
Join Date: Mar 2008
Posts: 71
Quote:
Originally Posted by Mosu View Post
True, because I don't want to limit the user in what he can or cannot do.
But it's completely not suitable for audio. Modifying audio frame duration is just wrong and it has nothing to do with the name of the option used for it.
Quote:
Originally Posted by Mosu View Post
Because it wouldn't improve anything. You can use the current --sync method for video and subtitle tracks.
There is already --default-duration for it.
Quote:
Originally Posted by Mosu View Post
You could use TrackTimecodeScale the same way for video and subtitle tracks.
Is there such option in mkvmerge or in mmg?
Quote:
Originally Posted by Mosu View Post
However, using TrackTimecodeScale on audio tracks would result in the same problems that using the current --sync method on audio track has. There's not much (if anything at all) to be gained.
Well, TrackTimecodeScale modifies only specific header parameter and not the whole timecodes. It doesn't require audio resampling. It's easy to recognize if this parameter was used. TrackTimecodeScale was designed for sync, it doesn't produce weird audio tracks and doesn't require to break spec compliance for proper playback. So the only problem is lack of support, which is partially caused by mkvmerge using some hack instead of this parameter.
Quote:
Originally Posted by Mosu View Post
I don't want to spend the time on implementing this in a backwards compatible manner.
What do you mean by "backwards compatible"? Yes, current --sync looks just like an alias for this parameter, and it would be better to change it's behavior. But you can add something like --TrackTimecodeScale instead and leave --sync unchanged.
Quote:
Originally Posted by Mosu View Post
So in order to find out whether or not the track has to be resampled the decoder would have to read a couple of packets, get their timecodes, compare the timecodes to the number of samples in respect to the sampling rate etc etc. This would all be guesswork and not be very precise.
Not at all. If player doesn't want to resample, then it just modifies timecodes of other streams to keep in sync. That's what some splitters do with current method.
Abradoks is offline