James Almer (12019-12-14): > I'm not sure if this is a good idea. It takes any AVBufferRef as input, > so it will crash on pretty much every one not created by an AVBufferPool > (unless it checks that buf is not NULL before dereferencing it), or > return something unrelated otherwise.
This is true, but I do not consider it that big of a problem. It makes no sense to access the opaque pointer unless you know precisely where the buffer comes from and what the opaque pointer contains. This is only expanding on this a bit. There are already several places in FFmpeg's API where parameters have a constraint that cannot be expressed with the imperfect type system of the C language. There are in the standard C library too: realloc() vs. free(), pclose() vs. fclose(), etc. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
