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

[Jan Ekström]

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

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

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.

After that, time could be taken to integrate the STD-B24 text
decoding/encoding into libavutil (?) and the decoder
reviewed/rewritten into libavcodec. Additionally that repository does
contain DVB text decoding/encoding if we are interested in that.

> I'd really like to avoid the teletext fiasco if somehow possible...
>

Same here. Unfortunately my initial pick was decided by how much time
until results I would have to utilize.

Best regards,
Jan