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

[Tobias Rapp <[e-mail]>]

On 05.11.2018 12:10, Jerome Martinez wrote:
> On 05/11/2018 10:07, Tobias Rapp wrote:
>> I should clarify: Storing the timecode value as a _single_ number 
>> makes processing a lot easier. [...]
> 
> It adds another complexity: you need to transport somewhere else the 
> configuration of this time code value (DP/NDP, frame rate).

I would say that the complexity is just shifted from read to write side. 
It depends on the assumed balance of write and read (archive vs. reuse, 
ingest vs. outgest) whether to see this as adding or removing complexity.

> which is not always available, if I do e.g. realtime transcoding from 
> SDI and catch SMPTE ST 12, I don't have immediately the frame rate (I 
> need to wait for frame number going back to 0) so I would have to wait 
> up to 1 second before writing the Matroska header if frame rate info is 
> in track header.

You could reserve some space in the header to write the frame-rate 
information later.

> For reference MP4/MOV or MXF time codes use numbered values, SMPTE ST 
> 12, SDTI in MXF or GXF use a format which is more like a string time 
> code. strict conversion between time code format (especially keeping the 
> user bytes) is not always doable.
> 
> In my opinion we should not debate here of the best time code format (it 
> would be in a metadata format registry, and both string time code and 
> numbered time code may exist), just permit any of them so I like the 
> proposal from Moritz, especially because I would use it too for 
> RAWcooked the same way as with time code configuration in the track 
> header for DP/NDP and frame rate info (if I store some RAWcooked 
> configuration in the track header, I can improve a lot the comrpession 
> of RAWcooked metadata).
> 
Indeed the timecode format is of second interest (even though 
implementation of multiple formats also adds complexity).

The idea of adding general metadata for each frame is nice, and storing 
DPX tags into it is fine. But I wouldn't store timecode that way, 
regardless of the serialization format. When you want to seek to a 
specific timecode position you have to read all frame metadata in 
advance. If timecode is stored separately, possibly as an own track, it 
allows you to do the mapping from timecode to timestamp first and then 
use the cue table to perform the locate operation efficiently.

Regards,
Tobias