2019-02-02 15:21 GMT+01:00, Jan Ekström <jee...@gmail.com>: > On Sat, Feb 2, 2019 at 3:55 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> >> 2019-02-02 14:31 GMT+01:00, Jan Ekström <jee...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
