[FFmpeg-devel] Supporting DirecTV captioning.

[Joseph Van Riper]

On Thu, Sep 21, 2017 at 6:25 PM, Hendrik Leppkes <h.leppkes at gmail.com>
wrote:
>On Thu, Sep 21, 2017 at 11:54 PM, Joseph Van Riper
><vanriper.trey at gmail.com> wrote:
>>
>> 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.
>>
>
>You should know that some of the ffmpeg developers are at a conference
>this weekend, so reponses will possibly be reduced for the next few
>days.

Ah, I would not have known that.  Thank you!

> Generally (and definitely IMHO), writing non-standard files based on a
> proprietary specification for one specific piece of (apparently bad)
> hardware is not something we really enjoy around here. It often
> results in unmaintained and hard-to-test code, since correctness can
> only be verified with one specific piece of hardware, which may not
> even exist in the future anymore - even more so if its entangled in
> multiple components throughout the codebase.

I cannot speak to the merits of the hardware, only that it is apparently
well-used regardless of its merits (in that this particular issue I seek to
resolve costs someone a lot of money, and that Microsoft resolved this
issue in their filters, which suggests MS felt it worthwhile). DirecTV
supposedly used their own header format because they could not wait
for a standard to be determined, at least from what I've read. But...
eh... I'm just trying to solve a problem.

> Keeping that in mind, the changes should be as self-contained and
> minimal as possible, anything that requires more logic in every caller
> that wants to create CC data seems like a bad idea already, and
> increases the maintenance burden. If there is only minimal differences
> in a header, perhaps the function should just have a flags parameter
> to change how it writes headers, or something like that, so that as
> much code as possible can be shared between alternate variants (within
> reason).

I agree.  I would prefer not to sprinkle changes throughout something
if I can avoid it.  Unfortunately, unless someone with more of a
background in this code can correct me, I don't see a way to avoid
touching (if lightly) several modules.

I view your recommendation to pass another argument to the existing
function as potentially more damaging (if only slightly) than my approach.

I still would need to alter code through several modules to either pass
one argument or another, or to call one function or another.  The logic
in both cases is fairly equivalent.

I can alter the original function, which would make it more difficult to
untangle should one desire to revert to the original (not impossible, just
kind of an annoyance), or have another function, which you could
avoid calling, or stub out (#def?).  In both cases, one is having to touch
code in several places throughout the library to ensure either that the
code is called the right way, or the right function is called.  While I'd
call
this very light touching in either case, I'd still need to sprinkle changes
in
several modules.

If this code were organized in a way where the configuration options
were distributed to the various modules using the same structure, I could
do a variation of what you propose where I'd alter that configuration
structure with another value, and react to that.  I'd wholeheartedly agree
that it's the better approach (as I wouldn't need to touch much code at
all).
The piece that configures things would simply provide the structure, and
the other bits would pass that structure into the function whose signature
wouldn't even have to change.  Then, yes, I wouldn't have to touch much,
just something to inform the preferences structure of the new value, and
the function itself.

Unfortunately, this isn't the case.  Each module seems to use a different
structure, and would require touching in some fashion.  If I'm already
forced to touch a lot of code lightly, I would think it preferable to
minimize
the potential damage to the one function by writing another, than to
both alter a lot of code (if lightly), and modify something we know is
working perfectly well to accommodate this change.

But, I'll approach it any way the team desires.  I'm not as familiar with
the
rest of the code, so maybe my concern about configuring this stuff isn't
well founded.  Ultimately, I just want to solve this problem.

- Trey