On 18/02/2021 15:20, Nuo Mi wrote:
+ return AVERROR(ENOMEM);
+ }
+ h266->ph = (H266RawPH*)h266->ph_ref->data;
+ memcpy(h266->ph, ¤t->sh_picture_header,
sizeof(H266RawPH));
This memcpy() is naughty - if that was a ref to a previous picture header
then you've just overwritten the reference while the other unit still holds
it.
If the slice is unit->content then unit->content_ref is a reference to a
superstructure of the picture header, avoiding the copy, but I'm not sure
it's the right way to do it.
Is it right that the two possible options here are:
* Store a ref, which might be to a newly-allocated buffer or might be to
a previous unit.
* Store the whole structure in the private context.
?
If the structure isn't too large, then the second option feels much
simpler.
If it is large such that holding references and avoiding copies is
beneficial (which is quite large, every ref entails a malloc/free
call-pair), then we probably want that ref to always be to the unit?
If we store the whole structure, it's hard to detect the picture header
missing case.
Also, if we use this as start point of the native decoder, the native
decoder may need ref the picture header for multi-thread decoding.
I think it would be reffing all of the units of the picture, which would
include the picture header.
- Mark
_______________________________________________
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".
