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

[Carl Eugen Hoyos]

2019-02-02 15:21 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> On Sat, Feb 2, 2019 at 3:55 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>
>> 2019-02-02 14:31 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
>>
>> > I will proceed to making a FATE test
>>
>> You cannot add fate tests for external libraries.
>>
>
> Ouch. I was asked by Clement to make one which is why I wanted to do
> it. Possibly he didn't understand that a library was being utilized.
>
>> Is there no chance of adding the aribb24 code to FFmpeg?
>> The library looks small although it also contains an mpegts
>> parser iiuc.
>>
>
> As we generally want code to be LGPLv2.1+ when taking it in, we cannot
> internalize libaribb24 as it is right now (LGPLv3 as of git master).

We prefer LGPL2 but I don't think LGPL3 is unreasonable, we
have a configure switch already...

> All of the files do contain LGPLv2.1 license headers, so I did ask the
> author to confirm and/or normalize them if possible, but there has
> been very little activity around the library recently:
> https://github.com/nkoriyama/aribb24/issues/9

That seems like a very strong indication we should not link
against the library.

>
> There are currently two main things which aribb24 provides:
> - Text conversion from the STD-B24 text encoding to UTF-8
> - Decoding of STD-B24 caption regions into region structures while
> converting the text into UTF-8 by utilizing the previous functionality
>
> The first feature one is available in a not-accepted-upstream iconv
> module implemented under LGPLv2.1:
> https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv/arib-std-b24.c
> (it also includes encoding support if we want to later add support for
> writing properly coded metadata into MPEG-TS in ARIB mode)
>
> The second feature I have found in an anonymous fork of FFmpeg (it
> utilizes this custom iconv module for the text conversion):
> https://github.com/0p1pp1/FFmpeg/blob/isdb-4.0/libavcodec/isdbsubdec.c
>
> Now, the problem is that this decoder has been written by a person who
> is not in touch with upstream, and also seems to utilize an awful lot
> of customized things in general with regards to ASS and other parts -
> which is why I initially decided to pick the alternative of using an
> already utilized/packaged open source library, for which the wrapper
> would not be of too large size. Additionally, the output of this
> library could then be compared against what this anonymous decoder
> generates.

Reasons and reasons for not adding the external dependency imo...

Carl Eugen