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

[James Almer]

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

> 
> Or, what we could do is check for the existence of stream side data containing
> the DOVI configuration record, which is needed to use these RPUs, I think.

That sounds ideal, yes.

> 
>>> +         */
>>> +        if (nal->size > 2 && nal->data[0] == 0x7C && nal->data[1] == 0x01) {
>>> +            s->rpu_buf = av_malloc(nal->raw_size - 2);
>>
>> You should use an AVBufferRef for this that you then attach to the frame
>> using av_frame_new_side_data_from_buf().
> 
> Will do.
> 
>> And you need to keep threads in sync by replacing the dst context's
>> rpu_buf with the src context rpu_buf with av_buffer_replace() in
>> hevc_update_thread_context().
> 
> Will do. Interestingly, I haven't run into any issues here with MT at all,
> in months of use. Luck?

I guess it may be because there's one such NALU per AU in this sample, 
so no frame depends on other threads having finished parsing/decoding 
their own frames and syncing the stuff stored in their thread-specific 
contexts.

> 
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>