[FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24
Carl Eugen Hoyos
ceffmpeg at gmail.com
Tue Feb 5 01:56:03 EET 2019
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:
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:
> (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):
> 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
Reasons and reasons for not adding the external dependency imo...
More information about the ffmpeg-devel