On Thu, Jan 14, 2021 at 6:25 AM James Almer <jamr...@gmail.com> wrote:
> On 1/12/2021 11:34 PM, James Almer wrote:
> >> + if (err < 0)
> >> + return err;
> >> + }
> >> + break;
> >> +
> >> + case VVC_TRAIL_NUT:
> >> + case VVC_STSA_NUT:
> >> + case VVC_RADL_NUT:
> >> + case VVC_RASL_NUT:
> >> + case VVC_IDR_W_RADL:
> >> + case VVC_IDR_N_LP:
> >> + case VVC_CRA_NUT:
> >> + case VVC_GDR_NUT:
> >> + {
> >> + H266RawSlice *slice = unit->content;
> >> + int pos, len;
> >> +
> >> + err = cbs_h266_read_slice_header(ctx, &gbc,
> &slice->header);
> >> + if (err < 0)
> >> + return err;
> >
> > Add a call to cbs_h266_replace_ph() here when
> > slice->header.sh_picture_header_in_slice_header_flag is true, and pass a
> > pointer to slice->header.sh_picture_header to it.
>
> Actually no, this wouldn't work as is in the cases where
> ff_cbs_make_unit_refcounted() makes it refcounted. Neither slice or the
> pointer passed to cbs_h266_replace_ph() would be valid.
>
> You'd have ensure the slice variable points the new unit->content after
> a successful call to cbs_h266_replace_ph() (Which you can leave
> untouched), and then make priv->ph point to the H266RawPH struct within
> slice.
>
Yes, It's not workable. The allocation is done by the cbs framework. not by
us.
The cbs_h266_replace_ph just take a reference. it's very cheap.
> _______________________________________________
> 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".
