[FFmpeg-devel] [PATCH 1/2] lavc: add CEA-708 codec id.

[Reimar Döffinger]

On Wed, Mar 26, 2014 at 07:54:51PM +0100, Nicolas George wrote:
> Le septidi 27 ventôse, an CCXXII, Reimar Döffinger a écrit :
> > It was kind of my idea that we would just have all under a single ID for
> > the moment since filtering out the part you want isn't hard, but that was
> > in large part due to laziness...
> > I believe most if not all wtv samples we have include combined 608 and 708
> > data, but I can't test right now (and don't even know they are on the
> > sample server).
> 
> I have made a small survey of the samles that were pointed in this thread:
> 
> http://samples.ffmpeg.org/MPEG2/subcc/HK_DVB_sample.ts
> http://samples.ffmpeg.org/MPEG2/subcc/HK_DVB_w_subtitle.ts
> http://samples.ffmpeg.org/MPEG2/subcc/HigashiNoEden8CCs.ts
> http://samples.ffmpeg.org/MPEG2/subcc/arib-captions.ts
> http://samples.ffmpeg.org/MPEG2/subcc/DVR-ClosedCaption/
> 
> seem to contain nothing exploitable: either dvb_sub, or nothing visible
> (possibly subcc inside H.264 like inside mpeg2video: is it possible? the
> decoder does not export it).

Should be possible, but I have not checked it yet.

> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1482/NCIS.wtv
> 
> contains a stream flagged "eia_608" with packets that look like that:
> 
> 00000000: 8527 7320 6f6e 2074 0300                 .'s on t..
> 
> Reimar's commit message says it should 

Did you intend to write something more?
That packet should be a CEA-708 message.
The CEA-608 messages are in the same stream but only 2 byte large
packets.
Plays for me in MPlayer with -subcc 1 -sid 0

> http://archive.org/download/FfmpegTest/BCSPA039_pre.mov
> http://samples.ffmpeg.org/MPEG2/subcc/Test%20for%20Quicktime%20608%20CC%20file.mov
> 
> contain a stream flagged "eia_608" with packets that look like that:
> 
> 00000000: 0000 000a 6364 6174 8080 0000 000a 6364  ....cdat......cd
> 00000010: 7432 8080                                t2..
> 
> That looks very different from the WTV packet format, there may be something
> wrong.

No, nothing wrong, just a different way of wrapping it, see
mov_cc_signature_1 in sub/sub_cc.c in MPlayer.
subcc_process_data in that file for code that autodetects these three
formats.

> Regarding the issue of this thread, I now believe that CEA-708 really
> deserves a different codec-id. I will try to get something working with the
> samples I have and MPlayer's code.

As you can also see from that code, a CEA-608 decoder should generally
be able to figure out the CEA-608 part of it if you just throw a
complete CEA-708 stream at it.
So I'd kind of suggest to delay that decision until you have enough
code to decide if you actually need it to be separate.