[Matroska-devel] Opus in Matroksa Cont.
frankgalligan at gmail.com
Fri May 24 21:35:55 CEST 2013
Just so we are on the same page, is what you are saying:
A file with 44100/1 audio and 30000/1001 video would be written:
TimecodeScale: 1000000 (Backwards compatible)
TrackTimestampScaleNominator (video): 30000
TrackTimestampScaleDenominator (video): 1001000
TrackTimestampScaleNominator (audio): 44100
TrackTimestampScaleDenominator (audio): 1000
Then the old players would behave the same and translate everything into
nanoseconds. And newer players can use the new timebase to translate the
absolute timecode to a track specific timebase? E.g.
1000 raw timecode = 1000000000 scaled timecode (Backwards compatible)
1000 raw timecode = 29.97002997 video timebase units
1000 raw timecode = 44100 audio timebase units
On Fri, May 24, 2013 at 8:38 AM, Steve Lhomme <slhomme at matroska.org> wrote:
> It's possible to make this work so that in the end the SimpleBlock is
> unchanged. The same block value *must* give the same timecode (rounding
> excluded) when using either system on the same file.
> Currently we use TimecodeScale * TrackTimecodeScale * (Cluster Timecode
> Count + Block Timecode Count)
> The new system would be the same except the scales are expressed in
> fractions. It's possible to arrange the 2 fractions to match the one in
> float. I just looked at the specs and the only scaled values are all
> depending on tracks. It would be a problem if Chapter timecodes or other
> things would need to be scaled, but it's not the case.
> We may need to de-deprecate the TrackTimecodeScale if we want to really
> have tracks with different clock scales. It was deprecated because never
> used, but not because it didn't make sense. Another reason is because it
> was a float. And forced floating point values on all timecodes. The problem
> we may have is that new files using it may not play correctly on older
> players if the element wasn't used, which is very likely as it was rarely
> written and most likely 1.0f.
> Maybe muxers should only allow a non 1.0f TrackTimecodeScale when a newer
> Matroska version (4) is forced ? And for the EBMLReadVersion to 4 as well.
> By the way, when/if we update the specs, Timecode should be renamed to
> Timestamp on new elements and descriptions...
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel