[FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'

[Roger Pack]

On Fri, May 1, 2020 at 12:22 AM Kieran Kunhya <kierank at obe.tv> wrote:
>
> On Fri, 1 May 2020 at 04:59, Roger Pack <rogerdpack2 at gmail.com> wrote:
>
> > On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya <kierank at obe.tv> wrote:
> > >
> > > On Thu, 30 Apr 2020 at 07:22, Roger Pack <rogerdpack2 at gmail.com> wrote:
> > >
> > > > > > c9153590e5f167e41910d867639eb887164e28d2
> > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00
> > 2001
> > > > > > From: rogerdpack <rogerpack2005 at gmail.com>
> > > > > > Date: Tue, 28 Apr 2020 05:15:15 +0000
> > > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a
> > new
> > > > codec
> > > > > >  type of 'raw 608 byte pairs'
> > > >
> > >
> > > How does this content exist? Are you defining your own file format with
> > the
> > > byte pairs?
> >
> > It's transmitted as "raw byte pairs" by analog TV broadcast in the US.
> > https://en.wikipedia.org/wiki/EIA-608 has  details.
> >
> > I believe it transmits  one closed caption character (or control code)
> > per frame (basically a single byte pair on "line 21") so it can do 30
> > closed caption chars/second.  Anyway that's where it's originating
> > from.  Good question :)
> >
>
> Yes, but these byte pairs are usually in a container or exist in an
> analogue waveform.

It's from analogue waveform, it gets pulled out by the analog TV
decoder card into the byte pairs.
The container is basically "which frame" the line 21 data happened to
come in with.  It comes in with two bytes/frame.
It comes in with a timestamp given by (I presume) the timestamp of the
frame it accompanies as a pin in directshow (in windows).

Directshow with the tuner card presents the line 21 data as "VBI
packets" (with a header specifying which portion of the VBI it comes
from, line 21 "odd" or line 21 "even"), and a timestamp.

There is another directshow filter that basically filters out the VBI
data and passes on just the "raw byte pairs" for a given CC stream.
See attached, but only concentrate on the "VBI Codec" filter box.  It
presents  two "CC" pins, the first of which we accept the byte pairs
from (with patch 3/3) [1]

So it's an analog standard, which directshow handles this way, and
it's converted to byte pairs.

> Have you defined your own format of "raw byte pairs"? That doesn't exist in
> the wild as far as I know.

The "format" is normal EIA 608
https://en.wikipedia.org/wiki/EIA-608
The "characters" section.
There was already a codec named "AV_CODEC_ID_EIA_608", but it was
really EIA 608 encapsulated within an EIA 708 stream, so I went with a
new name.  The existing 608 decoder already decoded the "byte pairs"
internally I just needed to be able to access it without the
encapsulation for this particular input.
In the analog stream they "come in" on the line 21 data as EIA byte
pairs.  No 708 encapsulation, hence me calling it "raw"
(AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS).
So it seems standard.

Cheers.

-roger-

[1] If you care about the nitty gritty, here's the media types that
the pins present:

VBI pin:
Media type: MEDIATYPE_VBI {F72A76E1-EB0A-11D0-ACE4-0000C0CC16BA}
Subtype: KSDATAFORMAT_SUBTYPE_RAW8 {CA20D9A0-3E3E-11D1-9BF9-00C04FBBDEBF}
Format type: {F72A76E0-EB0A-11D0-ACE4-0000C0CC16BA}

CC pin:
Media type: MEDIATYPE_AUXLine21Data {670AEA80-3A82-11D0-B79B-00AA003767A7}
Subtype: MEDIASUBTYPE_Line21_BytePair {6E8D4A22-310C-11D0-B79A-00AA003767A7}
Format type: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DirectShowCapture-1.png
Type: image/png
Size: 16667 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200501/fadf6e78/attachment.png>