FFmpeg

Commit Graph

Author	SHA1	Message	Date
Niklas Haas	4524d527bf	avcodec/codec_internal: nuke init_static_data() All hail get_supported_config()	4 months ago
Niklas Haas	3305767560	avcodec: add avcodec_get_supported_config() This replaces the myriad of existing lists in AVCodec by a unified API call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite substantially, while also making this more trivially extensible. In addition to the already covered lists, add two new entries for color space and color range, mirroring the newly added negotiable fields in libavfilter. Once the deprecation period passes for the existing public fields, the rough plan is to move the commonly used fields (such as pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video configuration types, and then implement the rarely used fields with custom callbacks.	4 months ago
Niklas Haas	703288cec6	avcodec/internal: add FFCodec.color_ranges I went through all codecs and put them into five basic categories: 1. JPEG range only 2. MPEG range only 3. Explicitly tagged 4. Broken (codec supports both but encoder ignores tags) 5. N/A (headerless or pseudo-formats) Filters in category 5 remain untouched. The rest gain an explicit assignment of their supported color ranges, with codecs in category 4 being set to MPEG-only for safety. It might be considered redundant to distinguish between 0 (category 5) and MPEG+JPEG (category 3), but in doing so we effectively communicate that we can guarantee that these tags will be encoded, which is distinct from the situation where there are some codecs that simply don't have tagging or implied semantics (e.g. rawvideo). A full list of codecs follows: JPEG range only: - amv - roqvideo MPEG range only: - asv1, asv2 - avui - cfhd - cljr - dnxhd - dvvideo - ffv1 - flv - h261, h263, h263p - {h263,vp8}_v4l2m2m - huffyuv, ffvhuff - jpeg2000 - libopenjpeg - libtheora - libwebp, libwebp_anim - libx262 - libxavs, libxavs2 - libxvid - mpeg1video, mpeg2video - mpeg2_qsv - mpeg2_vaapi - mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2 - mpeg4_omx - prores, prores_aw, prores_ks - rv10, rv20 - snow - speedhq - svq1 - tiff - utvideo Explicitly tagged (MPEG/JPEG): - {av1,h264,hevc}_nvenc - {av1,h264,hevc}_vaapi - {av1,h264,hevc,vp8,vp9,mpeg4}_mediacodec - {av1,h264,hevc,vp9}_qsv - h264_amf - {h264,hevc,prores}_videotoolbox - libaom-av1 - libkvazaar - libopenh264 - librav1e - libsvtav1 - libvpx, libvpx-vp9 - libx264 - libx265 - ljpeg - mjpeg - vc2 Broken (encoder ignores tags): - {av1,hevc}_amf - {h264,hevc,mpeg4}_v4l2m2m - h264_omx - libxeve - magicyuv - {vp8,vp9,mjpeg}_vaapi N/A: - ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless) - pgmyuv (headerless) - rawvideo, bitpacked (headerless) - vnull, wrapped_avframe (pseudocodecs)	4 months ago
Andreas Rheinhardt	2b46ae6407	avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS Before commit `f025b8e110`, every frame-threaded decoder used ThreadFrames, even when they did not have any inter-frame dependencies at all. In order to distinguish those decoders that need the AVBuffer for progress communication from those that do not (to avoid the allocation for the latter), the former decoders were marked with the FF_CODEC_CAP_ALLOCATE_PROGRESS internal codec cap. Yet distinguishing these two can be done in a more natural way: Don't use ThreadFrames when not needed and split ff_thread_get_buffer() into a core function that calls the user's get_buffer2 callback and a wrapper around it that also allocates the progress AVBuffer. This has been done in `02220b88fc` and since that commit the ALLOCATE_PROGRESS cap was nearly redundant. The only exception was WebP and VP8. WebP can contain VP8 and uses the VP8 decoder directly (i.e. they share the same AVCodecContext). Both decoders are frame-threaded and VP8 has inter-frame dependencies (in general, not in valid WebP) and therefore the ALLOCATE_PROGRESS cap. In order to avoid allocating progress in case of a frame-threaded WebP decoder the cap and the check for the cap has been kept in place. Yet now the VP8 decoder has been switched to use ProgressFrames and therefore there is just no reason any more for this check and the cap. This commit therefore removes both. Also change the value of FF_CODEC_CAP_USES_PROGRESSFRAMES to leave no gaps. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	9 months ago
Andreas Rheinhardt	2135a40b1c	avcodec/decode: Add new ProgressFrame API Frame-threaded decoders with inter-frame dependencies use the ThreadFrame API for syncing. It works as follows: During init each thread allocates an AVFrame for every ThreadFrame. Thread A reads the header of its packet and allocates a buffer for an AVFrame with ff_thread_get_ext_buffer() (which also allocates a small structure that is shared with other references to this frame) and sets its fields, including side data. Then said thread calls ff_thread_finish_setup(). From that moment onward it is not allowed to change any of the AVFrame fields at all any more, but it may change fields which are an indirection away, like the content of AVFrame.data or already existing side data. After thread A has called ff_thread_finish_setup(), another thread (the user one) calls the codec's update_thread_context callback which in turn calls ff_thread_ref_frame() which calls av_frame_ref() which reads every field of A's AVFrame; hence the above restriction on modifications of the AVFrame (as any modification of the AVFrame by A after ff_thread_finish_setup() would be a data race). Of course, this av_frame_ref() also incurs allocations and therefore needs to be checked. ff_thread_ref_frame() also references the small structure used for communicating progress. This av_frame_ref() makes it awkward to propagate values that only become known during decoding to later threads (in case of frame reordering or other mechanisms of delayed output (like show-existing-frames) it's not the decoding thread, but a later thread that returns the AVFrame). E.g. for VP9 when exporting video encoding parameters as side data the number of blocks only becomes known during decoding, so one can't allocate the side data before ff_thread_finish_setup(). It is currently being done afterwards and this leads to a data race in the vp9-encparams test when using frame-threading. Returning decode_error_flags is also complicated by this. To perform this exchange a buffer shared between the references is needed (notice that simply giving the later threads a pointer to the original AVFrame does not work, because said AVFrame will be reused lateron when thread A decodes the next packet given to it). One could extend the buffer already used for progress for this or use a new one (requiring yet another allocation), yet both of these approaches have the drawback of being unnatural, ugly and requiring quite a lot of ad-hoc code. E.g. in case of the VP9 side data mentioned above one could not simply use the helper that allocates and adds the side data to an AVFrame in one go. The ProgressFrame API meanwhile offers a different solution to all of this. It is based around the idea that the most natural shared object for sharing information about an AVFrame between decoding threads is the AVFrame itself. To actually implement this the AVFrame needs to be reference counted. This is achieved by putting a (ownership) pointer into a shared (and opaque) structure that is managed by the RefStruct API and which also contains the stuff necessary for progress reporting. The users get a pointer to this AVFrame with the understanding that the owner may set all the fields until it has indicated that it has finished decoding this AVFrame; then the users are allowed to read everything. Every decoder may of course employ a different contract than the one outlined above. Given that there is no underlying av_frame_ref(), creating references to a ProgressFrame can't fail. Only ff_thread_progress_get_buffer() can fail, but given that it will replace calls to ff_thread_get_ext_buffer() it is at places where errors are already expected and properly taken care of. The ProgressFrames are empty (i.e. the AVFrame pointer is NULL and the AVFrames are not allocated during init at all) while not being in use; ff_thread_progress_get_buffer() both sets up the actual ProgressFrame and already calls ff_thread_get_buffer(). So instead of checking for ThreadFrame.f->data[0] or ThreadFrame.f->buf[0] being NULL for "this reference frame is non-existing" one should check for ProgressFrame.f. This also implies that one can only set AVFrame properties after having allocated the buffer. This restriction is not deep: if it becomes onerous for any codec, ff_thread_progress_get_buffer() can be broken up. The user would then have to get a buffer himself. In order to avoid unnecessary allocations, the shared structure is pooled, so that both the structure as well as the AVFrame itself are reused. This means that there won't be lots of unnecessary allocations in case of non-frame-threaded decoding. It might even turn out to have fewer than the current code (the current code allocates AVFrames for every DPB slot, but these are often excessively large and not completely used; the new code allocates them on demand). Pooling relies on the reset function of the RefStruct pool API, it would be impossible to implement with the AVBufferPool API. Finally, ProgressFrames have no notion of owner; they are built on top of the ThreadProgress API which also lacks such a concept. Instead every ThreadProgress and every ProgressFrame contains its own mutex and condition variable, making it completely independent of pthread_frame.c. Just like the ThreadFrame API it is simply presumed that only the actual owner/producer of a frame reports progress on said frame. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	9 months ago
James Almer	65ddc74988	avutil: remove deprecated FF_API_OLD_CHANNEL_LAYOUT Signed-off-by: James Almer <jamrial@gmail.com>	11 months ago
Anton Khirnov	d0c8ca961d	lavc: add a private cap for fake-delay encoders Some encoders (ffv1, flac, adx) are marked with AV_CODEC_CAP_DELAY onky in order to be flushed at the end, otherwise they behave as no-delay encoders. Add a capability to mark these encoders. Use it for setting pts generically.	2 years ago
Andreas Rheinhardt	fdff1b9cbf	avcodec/codec_internal: Avoid deprecation warnings for channel_layouts AVCodec.channel_layouts is deprecated and Clang (unlike GCC) warns when setting this field in a codec definition. Fortunately, Clang (unlike GCC) allows to use FF_DISABLE_DEPRECATION_WARNINGS inside a definition (of an FFCodec), so that one can create simple macros to set AVCodec.channel_layouts that also suppress deprecation warnings for Clang. (Notice that some of the codec definitions were already inside FF_DISABLE/ENABLE_DEPRECATION_WARNINGS (that were not guarded by FF_API_OLD_CHANNEL_LAYOUT); these have been removed. Also notice that setting AVCodec.channel_layouts was not guarded by FF_API_OLD_CHANNEL_LAYOUT either, so testing disabling it it without removing all the codeblocks would not have worked.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Andreas Rheinhardt	73fada029c	avcodec/codec_internal: Add macros for update_thread_context(_for_user) It reduces typing: Before this patch, there were 11 callbacks that exceeded the 80 char line length limit; now there are zero. It also allows to remove ONLY_IF_THREADS_ENABLED() in libavutil/internal.h. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Andreas Rheinhardt	48286d4d98	avcodec/codec_internal: Add macro to set AVCodec.long_name It reduces typing: Before this patch, there were 105 codecs whose long_name-definition exceeded the 80 char line length limit. Now there are only nine of them. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Niklas Haas	61ffa23c2e	avcodec/codec_internal: add cap for ICC profile support Codecs that can read/write ICC profiles deserve a special capability so the common logic in encode.c/decode.c can decide whether or not there needs to be any special handling for ICC profiles. The motivation here is to be able to use it to decide whether or not an ICC profile needs to be generated in the encode path, but it might as well get added to decoders as well for purely informative reasons. It's not entirely clear to me whether the "thp" and "smvjpeg" variants of "mjpeg" should have this capability set or not, given that the code technically supports it but I somehow doubt these files may contain them. In either case, this cap is purely informative for decoders so it doesn't matter too much either way. It's also not entirely clear whether the "amv" encoder should signal ICC profile support, but again erring on the side of caution, we probably shouldn't be generating (and encoding!) ICC profiles for this type of media file. Signed-off-by: Niklas Haas <git@haasn.dev>	3 years ago
Andreas Rheinhardt	21b23ceab3	avcodec: Make init-threadsafety the default and remove FF_CODEC_CAP_INIT_THREADSAFE All our native codecs are already init-threadsafe (only wrappers for external libraries and hwaccels are typically not marked as init-threadsafe yet), so it is only natural for this to also be the default state. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	6aad1204cc	avcodec: Add FF_CODEC_CAP_NOT_INIT_THREADSAFE This is in preparation of switching the default init-thread-safety to a codec being init-thread-safe. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	6ed0d95fa2	avcodec/codec_internal: Constify AVPacket in decode_sub cb No subtitle decoder ever modifies the AVPacket given to it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	4243da4ff4	avcodec/codec_internal: Use union for FFCodec decode/encode callbacks This is possible, because every given FFCodec has to implement exactly one of these. Doing so decreases sizeof(FFCodec) and therefore decreases the size of the binary. Notice that in case of position-independent code the decrease is in .data.rel.ro, so that this translates to decreased memory consumption. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	ce7dbd0481	avcodec/codec_internal: Make FFCodec.decode use AVFrame* This increases type-safety by avoiding conversions from/through void. It also avoids the boilerplate "AVFrame frame = data;" line for non-subtitle decoders. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	fb59a42ef9	avcodec/codec_internal: Add FFCodec.decode_sub This increases type-safety by avoiding conversions from/through void. It also avoids the boilerplate "AVSubtitle sub = data;" line for subtitle decoders. Its only downside is that it increases sizeof(FFCodec), yet this can be more than offset lateron. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	5aabb2596f	avcodec/codec_internal: Rename AVCodecDefault->FFCodecDefault This structure is no longer declared in a public header, so using an FF-prefix is more appropriate. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	20f9727018	avcodec/codec_internal: Add FFCodec, hide internal part of AVCodec Up until now, codec.h contains both public and private parts of AVCodec. This exposes the internals of AVCodec to users and leads them into the temptation of actually using them and forces us to forward-declare structures and types that users can't use at all. This commit changes this by adding a new structure FFCodec to codec_internal.h that extends AVCodec, i.e. contains the public AVCodec as first member; the private fields of AVCodec are moved to this structure, leaving codec.h clean. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	a688f3c13c	avcodec/internal: Move FF_CODEC_CAP_* to a new header codec_internal.h Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault. This reduces the amount of files that have to include internal.h (which comes with quite a lot of indirect inclusions), as e.g. most encoders don't need it. It is furthemore in preparation for moving the private part of AVCodec out of the public codec.h. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago

20 Commits (20f2bf5530472e4e8ef5be3f7d83a0455a1cac42)