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

[Reimar Döffinger]

On 20 Oct 2012, at 16:46, Carlos Fernandez <cfs at nova.es> wrote:
> 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).

WTV uses a pre-processed format for storage, so it is already reordered, and it is only the data bytes (not the ones that indicate the CC stream) and it has one subtitle stream per CC channel (well, must have, I do not have a sample for that unfortunately).

>>> 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...

WTV uses only one single format as far as I can tell, your mistake is looking at the raw video data instead of the pre-processed subtitle data the WTV files contain.

>>> 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.

As I wrote in my other mail I don't think there is anything standard at all about that 8 byte header, it seems like a DirectShow-internal-only thing to me.