add c608 mapping

[dericed]

For discussion, here is a pull request to add storage of EIA-608 data to Matroska. It's defined in a manner similar to (QuickTime)[https://developer.apple.com/documentation/quicktime-file-format/closed_captioning_sample_data/]. The QuickTime version is a bit vague so I added something to the extra data based on DASH to define the name of the caption channel and its language.

[robUx4]

I guess this is one correct/portable way of doing it. As discussed in #375 it may also be good to extract the data into proper subtitle tracks.

Also should we add constraints on what kind of track (video, with specific resolutions) it can be attached to ?

[robUx4]

Are the numbers at the beginning of each line expected in the ABNF description ?

[robUx4]

CC1/CC2/CC3/CC4 are missing a definition

[mbunkus]

I'm strongly against storing CC data in this way. Repeating what I wrote in #375:

Personally I'd vote for "keep it subtitle, let CodecID speak for itself". We already integrate to many different formats under the type "subtitle", some text based, others are images. And closed captions fulfill largely the same role.

I don't consider their traditional way of transportation (embedded in the video track) to be relevant for our decision.

and

Well, what our track type "subtitles" transports can easily fill both roles, and it only depends on the content. Similar to how "audio" tracks can contain the whole dialog or only the director's comments. I don't see any reason to use a separate track type.

Block additions are meant to carry data required to or enhancing decoding the main block data in the same track. This means the video data (think of e.g. HDR information). However, CCs don't have anything to do with decoding video data at all.

There's no advantage to storing CC data alongside video data. All it does is creating new corner cases for software handling it. For example, mkvmerge would suddenly have to expose that data as some kind of virtual track outside of the regular track structure so that MKVToolNix GUI can present the CC data as what it is, continuous data timed to display at certain points = a track. Same for all plackbac programs out there.

My vote goes to storage as regular track with type subtitle & proper codec ID. I'd also be fine with storage as regular track with a new track type closed_captions or whatever.

[dericed]

I'm adding a subtitle track definition for C608 for comment. See 90e7b11. If there's consensus about this approach, then I'll remove the BlockAdditionalMapping version and rebase.

For storing the channel number I wanted to make a recommendation and suggested the LABEL tag, but more appropriate suggestions are welcome. Or perhaps this could just go into the private data.

[JeromeMartinez]

CC1 & CC2 share field 1 and can not be separated.
CC3 & CC4 share field 2 and can not be separated.

IMO it would be better to indicate the field, or even better to say that for frames there should be 4 bytes (2 bytes of field 1 then 2 bytes of field 2) so we avoid a have to manage tags.

[JeromeMartinez]

Actually we have also T1 to T4 and XDS, so the service name ("CC" thing) is really not relevant.

[dericed]

@JeromeMartinez I pushed an update.

[JeromeMartinez]

first channel number of the CEA-608 pair (expressed as either "CC1" or "CC2")

CC1 and CC2 are names of a service in the specs and it is technically possible to use e.g. only CC2 without using CC1 so I prefer just "field number of the CEA-608 pair (expressed as either "1" or "2")".