Re: [Cellar] Matroska Elements to support frame side data

[Tobias Rapp <[e-mail]>]

On 04.11.2018 00:43, Dave Rice wrote:
> 
>> On Nov 2, 2018, at 5:31 AM, Tobias Rapp <[e-mail]> wrote:
>>
>> [...]
>>
>> while I think that frame side data can be useful for the DPX scenario mentioned later, I see problems with storing timecode information that way. Shall timecode be attached to the video or audio track? Shall there be some sub-classification for VITC/LTC/other timecode sources?
>>
>> Also I would prefer the timecode value to be stored as a number instead of a string representation, for the same reason that the Cluster Timestamp element uses a numerical representation: It makes processing a lot easier.
> 
> If the structure is sufficient then perhaps is better discussed in how to define the MetadataName values. For instance, we could define:
> MetadataName=“timecode.s314m”
> where MetadataBinary is set to a binary value as defined by SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)”.

I should clarify: Storing the timecode value as a _single_ number makes 
processing a lot easier. For example when you export a sub-range of your 
archived video file and have to shift timecode offset in the output 
file. Or when you change the video frame-rate for some reason.

Both, the "01:23:45;12" timecode string and its binary representation 
are using some display-oriented format with mixed timebases 
(hours/minutes/seconds use a fixed timebase, framecount uses another 
timebase depending on the media). In our ingest system we use a separate 
XML file to store VITC/LTC values and first tried to store the SMPTE TC 
string but then switched to storing a microseconds number together with 
some hint for presentation "these values shall be rendered at 29.97 fps 
with drop-frame counting".

> In other thoughts on this suggestion, I think it could make it difficult to easily understand if a file has a particular type of side data. For instance if only a few Clusters somewhere in the Segment contain a certain type of side data, it would require parsing every Cluster to know what types of side data are available. This uncertainly wouldn’t be the same issue if the side data was itself a Track.

I would agree here.

Best regards,
Tobias