[Matroska-devel] Opus in Matroksa Cont.

Frank Galligan 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
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20130524/88b89db7/attachment.html>


More information about the Matroska-devel mailing list