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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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".
