[FFmpeg-devel] [PATCH v2 1/2] libavformat/mpegts: Extract arib_caption descriptor data into codecpar->extradata

[Jan Ekström]

On Sun, Apr 11, 2021 at 5:51 PM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Sun, Apr 11, 2021 at 4:58 PM Jan Ekström <jeebjp at gmail.com> wrote:
> >
> > On Sun, Apr 11, 2021 at 4:25 PM magic xqq <xqq at xqq.im> wrote:
> > >
> > > I have already tried to use st->stream_identifier directly in mpegtsenc.c
> > > while handling arib_caption stream in mpegts_write_pmt() function.
> > >
> > > But in mpegtsenc.c, st->stream_identifier always provides
> > > an incorrect value of 0, which should be 0x30 for arib_caption A profile.
> > >
> > > st->stream_identifier seems hasn't been copied correctly while remuxing into
> > > another mpegts stream. So I manually copied it.
> > >
> >
> > Yes, AVStream::stream_identifier is not currently handled by ffmpeg.c.
> > Not sure its addition was ever really thought thoroughly, and mostly
> > added so that MPEG-TS reading clients could gain this value when
> > reading data. Not even ffprobe.c is currently poking a stick at it.
> >
> > But quickly looking at things, you can map component_tag and
> > component_id according to the ARIB caption profile, since your
> > possibilities are:
> >
> > FF_PROFILE_ARIB_PROFILE_A => component tag 0x30-0x37, data_component_id = 0x0008
> > FF_PROFILE_ARIB_PROFILE_C => component_tag 0x87, data_component_id = 0x0012
> >
> > The only issue is if you want to keep the exact same component tag,
> > but that can be improved in ffmpeg.c by just passing it during stream
> > copy into the output AVStream if it's nonzero (that is why it's
> > identifier plus 1). Also probably we need an option to force it to
> > something else if needed. In any case, I consider this somewhat
> > separate from the remux case since I don't think you need to have the
> > exact same id for the remux to be workable? Please note if I am
> > mistaken.
> >
> > Then there's the extra info, I'll have to check the specs later today
> > whether that contains anything dynamic.
> >
> > Best regards,
> > Jan
>
> Alright, so that additional data structure is one byte large and
> contains the following things:
>
> additional_arib_caption_info(){
>   DMF       bslbf(4)
>   Reserved  bslbf(2)
>   Timing    bslbf(2)
> }
>
> DMF - (Display mode flag), with b1111 being the most common value "dynamic"
> Timing - async|program sync|real time sync
>
> So I guess at the very least this would make sense to add into the
> extradata. I do find it interesting though that libaribb24 doesn't
> seem to require this data for valid decoding at all :D (although I
> guess mostly the output timing and automated subtitle sub-stream
> selection is affected by these values).

For context, just checked some random sample I had on hand:

ARIB caption info: DMF: 0xa, reserved: 0x3, timing: 0x1

So "both caption streams are selectable/showable when both received
and playing back a recording" (0b1010), reserved bits are nonzero,
timing is PTS based ("program based" seems to mean that).

Jan