[FFmpeg-devel] [PATCH 2/3] avcodec/hevcdec: Export Dolby Vision RPUs as side data

[Jan Ekström]

On Sat, Oct 23, 2021 at 9:16 PM James Almer <jamrial at gmail.com> wrote:
>
> On 10/23/2021 2:52 PM, Derek Buitenhuis wrote:
> > On 10/23/2021 3:18 PM, James Almer wrote:
> >> 0x7c01 is just the NAL header that signals type 62, nuh_layer_id 0 and
> >> nuh_temporal_id 0.
> >>
> >> forbidden_zero_bit    =      0
> >> nal_unit_type         = 111110
> >> nuh_layer_id          = 000000
> >> nuh_temporal_id_plus1 =    001
> >>
> >> So the last two checks can be changed to !pkt->nals[pkt->nb_nals -
> >> 1].nuh_layer_id && !pkt->nals[pkt->nb_nals - 1].temporal_id
> >
> > Do'h, will fix.
>
> That being said, would Dolby RPU NALUs like this using other values for
> temporal and layer id be valid? Or can we just assume that's never
> happening?
>
> >
> >> This is horrible, but i guess there's no alternative without
> >> autoinserting a bsf.
> >
> > Yeah, I couldn't think of one - and the BSF option seemed even worse.
> >
> >> What i said above. It's nothing Dolby specific. Any NAL type 62 could be
> >> like that. If there's no spec we could use to actually parse the
> >> bitstream after the NAL header, then we will end up propagating pretty
> >> much anything using NAL type 62 as Dolby RPU.
> >
> > Indeed, there is no spec. As far as I know, nothing else uses UNSPEC62,
> > though, and this is consistent with what e.g. Dolby's open source muxer
> > and mkvtoolnix do.
> >
> > What do you suggest? Rename the side data to _UNSPEC62 maybe and leave it
> > to the caller to handle it?
>
> No, i prefer having the side data be about Dolby Vision RPU. Who knows,
> maybe in the future Dolby realizes they had the Unregistered and even
> Registered User Data SEI readily available for this kind of proprietary
> information and start using that instead...
>

They already utilize something like this for their ST.2094-10
brightness metadata (which is actually specified through ETSI etc
[1]), which hilariously is also called "DoVi" in their marketing.

Since effectively D has taken over NAL unit 62 for this stuff, just
call it RPU_BUFFER or so, and take in everything NAL unit 62?

Jan

[1] https://www.etsi.org/deliver/etsi_ts/103500_103599/103572/01.03.01_60/ts_103572v010301p.pdf