On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote: > On 12/10/2016 7:01 PM, Michael Niedermayer wrote: > > When we will backport this, it will be inevitably in a different location > > in AVCodecContext in each release and master. 3.0, 3.1, 3.2 and master > > use the same soname though and must have a binary compatible interface. > > It thus can only saftely be accessed through AVOptions > > > > It may be enough to require this only in the releases but that could be > > rather confusing. > > Wouldn't it be better to initially add such new fields inside > AVCodecContext->internal and accessible by AVOptions only so they > may be trivial to backport, then once a major bump occurs they can > be moved to the actual public struct with enabled direct access? > > Not sure how feasible is to have options_table.h options change > values from that internal struct, but it would solve the above > concerns. [...]
If people want we can write something like:
/**
* The number of pixels per image to maximally accept.
*
* - decoding: set by user through AVOptions (NO direct access before
57.67.100)
* - encoding: set by user through AVOptions (NO direct access before
57.67.100)
*/
int64_t max_pixels;
This would allow direct access in the future and require AVOptions in
releases but its quite complex
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
