[FFmpeg-devel] Supporting DirecTV captioning.

[Joseph Van Riper]

I would like to provide a patch to ffmpeg that would help it support
writing 608-style captions to DirecTV HD mp4 streams.  The a53 sei header
used by ff_alloc_a53_sei does not match the header required by DirecTV.
I've written a function (ff_alloc_directv_sei) that will write the correct
header, but I need to incorporate it with the rest of the library, and
cause it to be used when requested.

(Note that I haven't investigated reading streams with this header.  I
don't know how often one might want to do this, but it might not be
difficult to support, if desired... my interest at the moment is more on
encoding compatible streams than decoding).

Examining the code further, I see that libx264.c, qsvenc_h264.c, and
videotoolboxenc.c all have a reference to a53_cc, treating this integer as
a bool, and reacting to a an 'a53cc' option to set it.  I wonder if I might
try:

1. Retaining a53cc as the option one would set with its current meaning.
2. Creating directvcc as a new option one may set.
3. Changing the a53_cc variable name to to eia_cc.
4. Treating eia_cc as an int instead of a bool.
5. Call neither ff_alloc_a53_sei nor ff_alloc_directv_sei when eia_cc is
set to 0.
6. Call ff_alloc_a53_sei appropriately when eia_cc is set to 1.
7. Call ff_alloc_directv_sei appropriately when eia_cc is set to 2.

I do not want to move forward with a change like this and risk having this
submission rejected... I'd rather work with the team to find what works
best.  To save time on discussion, though, I'll explain my reasoning for
these points:

1. I think it's wise to retain backwards compatibility with those who
depend upon the current setting.
2. The header difference is unique to DirecTV, so the name should stand out.
3. 'EIA-608' and 'EIA-708' captioning appears to be the standard of closed
captioning both of these headers wrap.  If we kept 'a53_cc', it might
confuse someone reading the code later.  And, obviously, it makes not sense
to call it 'directv_cc'.  I've tried to recommend a name that both
approaches have in common.  Perhaps you have a better idea for a variable
name.
4. It can't really be a bool at this point, as we need to support a choice
of neither, a52, or directv.  Three choices can't be jammed into a bool,
heh.
5. C treats 0 as false, so this helps dovetail into existing code rather
cleanly.
6. I opted for '1' because a53 was supported first, and is frankly the
dominant standard.  Perhaps you may choose something else.
7. I opted for '2' because directv will be your second standard supported
by this.  Perhaps you'd prefer a different value.

I would normally not want to request of an open source team a fast response
to something like this, but I sense some urgency to resolving this issue
for the folks who have asked me to look into it.  I will feel compelled to
move forward with something by sometime next week... I just would prefer it
fit in with your recommendations to avoid wasting effort.

Also, I do not entirely know if the function I have written is spot-on with
the header... I am lacking documentation that would clarify one of the
variables that I'm setting.  However, I am working with a team that will be
able to validate that I'm writing the correct values here, so while I may
not necessarily have the right code right now, I will as soon as possible.
Alternatively, if someone on this list happens to already know this value,
I'm all ears... it's the 'user_data_code_length' value from the DirecTV
standard, unique to their header.  I do not know if this should be set to
side_data-size, or some calculated thing.

Many thanks in advance for your attention.

- Trey