[FFmpeg-devel] Question on line 21 data in wtv

[Carlos Fernandez]

I'm resending this from my subscribed email, I apologize for the dirt...

> On Sat, Oct 20, 2012 at 10:47 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>
>> First, while maybe ugly and not fully correct, I believe MPlayer has
>> working code for it in sub/sub_cc.c file, the subcc_process_data
>> function.
>
> I'll check it out :-)
>
>> Also while I never found a proper specification for the DVD format,
>> the DVB one should be quite well documented, search for
>> EIA-608 and EIA-708.
>
> Yes, but .wtv doesn't follow DVB at all, does it? What I did to
> "support" wtv was write (well, someone else did this part) a small
> Win-only program that uses system filters to get the line 21 data and
> exports it to a raw dump. Since my only focus is closed captioning
> this is good enough for me - and has the advantage that I don't have
> to worry about the .wtv format since one of the filter pins gives me
> ready to use (meaning sorted, for example) line 21 data. The problem
> with this data is that its format seems variable (don't know what
> causes the variations though).
>
>> I did not look at your examples in detail, but I believe your problem
>> might be that DVB is actually using a completely new format, EIA-708,
>> but that one does contain a compatibility layer.
>> Now, WTV actually does split the compatibility layer out.
>
> From what I could see (but I'm working with only 6 samples, from 2
> different people), when wtv uses DVD-like GOP based user data for the
> captioning, there's no way EIA-708 can be encoded there. When it uses
> the same encoding as ATSCv53 (I think) then it should work OK. I don't
> know yet when either encoding is used, and more importantly even, if
> there's more than these two ways...
>
>> Unfortunately, if you just look at the concatenated data you will
>> no longer be able to make sense of it.
>
> I was able to get it to work actually. Work meaning that it processes
> OK all my samples, but I still have a couple of variables called
> magic1 and magic2 in my code which is never a good sign :-)
>
>> You absolutely have to look at the size of the packets.
>
> What I get from the pin, is an array of byte of any length (typically
> 90 something bytes). The standard 8 bytes header, then 1 or 3 bytes
> and then the data.
>
> Carlos