[Matroska-devel] New Matroska field: extra broadcast data
slhomme at matroska.org
Sun Oct 4 17:00:10 CEST 2015
2015-09-24 20:00 GMT+02:00 Jerome Martinez <jerome at mediaarea.net>:
> Le 23/09/2015 18:13, Steve Lhomme a écrit :
>> In addition to close caption, broadcasting often carries data in some
>> non displayed pixels, especially in analog videos. We should be able
>> to store those invisible information in the container as well.
>> The first that comes to might is Teletext in Europe. There might be
> I think to:
> - VBI raw content (dump of non visible part of a video stream, and should
> sometimes not be lossy compressed, so not in the compressed video stream
> directly), which can contain SMPTE ST-12 timecodes (real time codes, not
> timestamps ;-) ), CEA-608 captions...
We definitely don't want lossy visual compression applied to these. We
could store the compressed frame, minus the visual content (blacked
before being compressed) and leave the interpretation to the player.
In that case we just store the kind of source the data are coming
from, hoping the player will be smart enough to handle it.
Otherwise the muxer needs to understand each fake pixel "parts" and
create a (better identified) track for each. This is a rather complex
task, that's why I think a fallback approach as described above is
> - VANC (SMPTE ST-291, we must be careful because there are 10-bit / synchro
> bytes / checksum "options", because MXF uses 8-bit +no synchro bytes + no
> checksum , GXF uses 10-bit + no synchro bytes + checksum, LXF uses 8-bit +
> synchro bytes + checksum, if we define VANC in Matroska we need to say how
> we transport it), which can contain SMPTE ST-12 timecodes, CEA-608 captions,
> CDP, Bar data, Teletext (WST actually), Acquisition Metadata (SMPTE RDD
> - CDP from a serial link (captions only).
> BTW, same issue with "Teletext": Teletext can contain a programs list +
> subtitles in the same track.
>> Given it's in the video frames it should probably be a kind of
>> track(s). We already extract the closed caption. We could extra some
>> others with different "codec" and/or keep the rest of the data raw to
>> be handled by other processes, outside of the scope of Matroska.
> Isn't TrackType = 3 (Complex) enough for that?
> and we try to define C_VBI, C_VANC, C_TELETEXT... codec identifiers.
Yes it is.
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
Matroska association Chairman
More information about the Matroska-devel