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.
> 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?
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.
>> + */
>> + 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?
- Derek
_______________________________________________
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".
