On Sat, Oct 23, 2021 at 9:16 PM James Almer <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".