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

Jan Ekström jeebjp at gmail.com
Sun Feb 10 03:54:20 EET 2019


On Fri, Feb 8, 2019 at 2:38 AM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Sat, Feb 2, 2019 at 3:31 PM Jan Ekström <jeebjp at gmail.com> wrote:
> >
> > A decoder wrapper for the libaribb24 library found in various
> > distributions and currently utilized by VLC.
> >
> > Requires GPLv3 with the current most recent release, but as the
> > current library master is LGPLv3, any newer releases will require
> > only LGPLv3.
> >
> > If the library is not found in your distribution, it is available at:
> > https://github.com/nkoriyama/aribb24
> >
> > A test sample can be found at:
> > https://kuroko.fushizen.eu/samples/arib_captions_colors_positioning_ruby_subpics.ts
> >
> > An example of how the decoded output currently looks can be found at:
> > https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png
> >
> > I will proceed to making a FATE test as soon as I figure out the simplest
> > way to limit an MPEG-TS stream to some PIDs without doing full remuxing.
> > (I think dvblast has something like this so I might take a look at that)
> >
> > The decoded subtitles might or might not have durations set, so with
> > ffmpeg.c `-fix_sub_duration` is required.
> >
> > Regarding positioning:
> >
> > I have an initial version of positioning implemented, but unfortunately
> > it requires multiple subtitle lines per AVSubtitle, and many applications
> > seem to fail at handling them, including the encoding portions of
> > libavformat/libavcodec (all lines end up concatenated into a single line, even
> > though that is 100% invalid as there is a header included).
> >
> > Thus I have decided to post the first version out now, as when the ruby
> > blocks are not included as a distraction, single-line output seems to be
> > fine and readable/enjoyable.
> >
> > Best regards,
> > Jan
> >
> > Jan Ekström (2):
> >   add libaribb24 ARIB STD-B24 caption decoder
> >   lavf/mpegts: add reading of ARIB data coding descriptor
> >
> >  Changelog               |   1 +
> >  configure               |   7 +
> >  doc/decoders.texi       |  25 +++
> >  libavcodec/Makefile     |   1 +
> >  libavcodec/allcodecs.c  |   1 +
> >  libavcodec/avcodec.h    |   4 +
> >  libavcodec/codec_desc.c |   9 +-
> >  libavcodec/libaribb24.c | 378 ++++++++++++++++++++++++++++++++++++++++
> >  libavcodec/profiles.c   |   6 +
> >  libavcodec/profiles.h   |   1 +
> >  libavcodec/version.h    |   2 +-
> >  libavformat/mpegts.c    |  47 +++++
> >  libavformat/version.h   |   2 +-
> >  13 files changed, 481 insertions(+), 3 deletions(-)
> >  create mode 100644 libavcodec/libaribb24.c
> >
> > --
> > 2.20.1
> >
>
> I really don't like to do this because I really like consensus... But
> now that I know that the disagreement that was had about this patch
> set was not a blocking one, I would like to move forward with my
> ARIB-related work (of which this was part 1). As I have addressed all
> the technical comments that I have received regarding the patches in
> this set, if any more doesn't come within the next 24 or so hours or
> so I would like to start pushing this in as a "reference" decoder for
> this format against which a future internal implementation can be
> compared against.
>

As there have been no further objections, I will be pushing this patch
set and enabling demuxing of ARIB captions with FFmpeg, as well as
decoding with libaribb24 (until an internal decoder is implemented). I
tried to call out for comments to see if anyone had *something* to say
about this patch set during the past two days - but none were
negative.

As another positive sign, the author of this library has recently
re-activated, so while it is likely that the library might move under
the VideoLAN umbrella in the longer term, we should be able to receive
clarification regarding some things.

Thank you,
Jan


More information about the ffmpeg-devel mailing list