[Matroska-devel] Opus in Matroksa Cont.

Steve Lhomme slhomme at matroska.org
Sat May 25 08:19:21 CEST 2013


You need the float version of the TrackTimecodeScale for the timestamp of
the block to make sense on both.

Also if an audio codec always pack 512 frames you probably want to put that
in the numerator.
On May 24, 2013 9:36 PM, "Frank Galligan" <frankgalligan at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20130525/0273c8f0/attachment-0001.html>


More information about the Matroska-devel mailing list