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

[Jan Ekström]

On Wed, Feb 6, 2019, 13:38 Carl Eugen Hoyos <ceffmpeg at gmail.com wrote:

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

I do not think you have ever explicitly written that. Which can make things
much less easy to try and interpret - at least for me.

I wrote those things down about the alternatives to be honest. I had looked
into them, and unfortunately it seemed like with my current amount of free
time and being a selfish person wanting to see something work within a
graspable time frame led me to try and utilize the same library as vlc (At
this stage! As I could see features in the anonymous thing that are not
mentioned in libaribb24 I was interested in trying to see how it looks in
more detail afterwards - when there would be a reference).

Also, one thing about bringing in libaribb24: it would mean that all
relevant pieces of it would have to go through style-wise changes and full
on code review. Personally while lgplv3 is "acceptable" as I said, I also
must say that I would not be interested in going through the review process
with it just to end up with something that doesn't get enabled with the
default configure parameters.



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

It would be used from both libavcodec and libavformat. I already have
patches in my wip tree that probe for ARIB broadcast signs, and convert the
channel name to utf-8 (currently via libaribb24).

My plan was to post the probing and setting broadcast standard options to
mpegts.c next, and then see if the text conversion stuff could be pulled in
after the base arib caption demuxing and such got in.

Also just by implementing positioning with this wrapper I uncovered bugs in
both FFmpeg's subtitle encoding as well as client applications when a
single AVSubtitle has multiple ASS lines in it. Thus having a clear finale
to this patch set one way or another would be nice.


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

Unfortunately this format has so many things in it... But yes. That is the
initial mvp. Which I would start moving towards after this patch set at the
very least gets through partially (as I really would not like to get stuck
without the avcodecid and demuxing parts).

Jan


>