[FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24

[Carl Eugen Hoyos]

2019-02-05 18:22 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:

> My initial idea was to get a reference going with libaribb24 which had
> a defined interface and thus I didn't have to look too much into the
> "how the sausage is done" part of it. After that I would have started
> looking into these two things in order to see if it made sense to
> bring them in in some way, without the functionality missing
> altogether from FFmpeg for now.
>
> To be honest, what I most disliked about your reply is that you do not
> hint at all with regards to which way would you like for this to move
> on towards. I am left in the air guessing what is acceptable for you.

I am sorry, it is exactly as you write:
I am not happy about adding this dependency, I read your mails
as if you would agree or at least you point out many reasons
not to add it and there is precedence that you cannot "bring them
in" at a later point after adding the dependency.
But at no point I wanted to "block" the dependency and I
honestly hope I never wrote that.

> But OK, let's give this a thought if libaribb24 is not considered to
> be acceptable to link against. We want as much as possible bite-sized
> changes to go in so that it is simpler for both the author as well as
> the reviewer. Thus, even if we skip the decoder part from this patch
> set, the following parts could already be reviewed and merged:
> 1. AVCodecIDs/descriptors and profiles in lavc (I used to have these
> in a separate patch, but I was requested to merge them into the
> decoder patch for review).
> 2. MPEG-TS Demuxing in lavf (It is not like this one is going to
> change compared to when the decoder is finished).
>
> This gets us one step forward, and not all of the code has to be
> reviewed at the point where the following bigger dump of code will be
> posted.
>
> Then, for the following steps:
> 1. Text decoding.
>
> The ARIB STD-B24 gconv module is indeed LGPLv2.1+ so we can start
> taking it in. Thus the question would more become... where should it
> go? libavutil?

(While this is a detail imo that you should decide)
Is there any problem putting it in the library where it gets used?
Or is it used in several FFmpeg libraries?

> Or should we spin up a new library called
> libbroadcasttext if we plan on taking in the DVB text format as well
> (in the future)? Or is there a common way in the different (supported
> by us) iconv systems to register new decoding and encoding functions?
> FATE tests can then be made against this, and any differences to
> libaribb24 verified and either kept or fixed on our side. The review
> of this component should be done separate compared to the subtitle
> decoding, as while one depends on the other, they are indeed separate
> things.

> 2. Subtitle decoding.
>
> The anonymous decoder needs to be taken into its barebones and
> possibly partially rewritten. I would probably not include more
> features than this initial version of this libaribb24 wrapper in the
> initial version. And in one way, I would probably just put being able
> to extract the textual data as a prime requirement for the first stage
> of the decoder.

Which I believe is almost as good as a perfect subtitle decoder.

Carl Eugen