summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* avcodec/hevc_cabac: Pass HEVCLocalContext when slice-threadingAndreas Rheinhardt2022-07-25
| | | | | | | | | | | | | | | | | | | The HEVC decoder has both HEVCContext and HEVCLocalContext structures. The latter is supposed to be the structure containing the per-slicethread state. Yet that is not how it is handled in practice: Each HEVCLocalContext has a unique HEVCContext allocated for it and each of these coincides except in exactly one field: The corresponding HEVCLocalContext. This makes it possible to pass the HEVCContext everywhere where logically a HEVCLocalContext should be used. This commit stops doing this for lavc/hevc_cabac.c; it also constifies everything that is possible in order to ensure that no slice thread accidentally modifies the main HEVCContext state. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevcdec: Add stat_coeffs to HEVCABACStateAndreas Rheinhardt2022-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HEVC decoder has both HEVCContext and HEVCLocalContext structures. The latter is supposed to be the structure containing the per-slicethread state. Yet that is not how it is handled in practice: Each HEVCLocalContext has a unique HEVCContext allocated for it and each of these coincides with the main HEVCContext except in exactly one field: The corresponding HEVCLocalContext. This makes it possible to pass the HEVCContext everywhere where logically a HEVCLocalContext should be used. This led to confusion in the first version of what eventually became commit c8bc0f66a875bc3708d8dc11b757f2198606ffd7: Before said commit, the initialization of the Rice parameter derivation state was incorrect; the fix for single-threaded as well as frame-threaded decoding was to add backup stats to HEVCContext that are used when the cabac state is updated*, see https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/268861.html Yet due to what has been said above, this does not work for slice-threading, because the each HEVCLocalContext has its own HEVCContext, so the Rice parameter state would not be transferred between threads. This is fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7 by a hack: It rederives what the previous thread was and accesses the corresponding HEVCContext. Fix this by treating the Rice parameter state the same way the ordinary CABAC parameters are shared between threads: Make them part of the same struct that is shared between slice threads. This does not cause races, because the parts of the code that access these Rice parameters are a subset of the parts of code that access the CABAC parameters. *: And if the persistent_rice_adaptation_enabled_flag is set. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevc_filter: Pass HEVCLocalContext when slice-threadingAndreas Rheinhardt2022-07-25
| | | | | | | | | | | | | | | | | | | | | | | | The HEVC decoder has both HEVCContext and HEVCLocalContext structures. The latter is supposed to be the structure containing the per-slicethread state. Yet that is not how it is handled in practice: Each HEVCLocalContext has a unique HEVCContext allocated for it and each of these coincides with the main HEVCContext except in exactly one field: The corresponding HEVCLocalContext. This makes it possible to pass the HEVCContext everywhere where logically a HEVCLocalContext should be used. This commit stops doing this for lavc/hevc_filter.c; it also constifies everything that is possible in order to ensure that no slice thread accidentally modifies the main HEVCContext state. There are places where this was not possible, namely with the SAOParams in sao_filter_CTB() or with sao_pixels_buffer_h in copy_CTB_to_hv(). Both of these instances lead to data races, see https://fate.ffmpeg.org/report.cgi?time=20220629145651&slot=x86_64-archlinux-gcc-tsan-slices Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevc_mvs: Pass HEVCLocalContext when slice-threadingAndreas Rheinhardt2022-07-25
| | | | | | | | | | | | | | | | | | | The HEVC decoder has both HEVCContext and HEVCLocalContext structures. The latter is supposed to be the structure containing the per-slicethread state. Yet that is not how it is handled in practice: Each HEVCLocalContext has a unique HEVCContext allocated for it and each of these coincides except in exactly one field: The corresponding HEVCLocalContext. This makes it possible to pass the HEVCContext everywhere where logically a HEVCLocalContext should be used. This commit stops doing this for lavc/hevc_mvs.c; it also constifies everything that is possible in order to ensure that no slice thread accidentally modifies the main HEVCContext state. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevcdec: Add pointers to logctx and parent ctx to HEVCLocalCtxAndreas Rheinhardt2022-07-25
| | | | | | | | | | | | | | | | It is safe for a slice thread to read the main context and therefore it is safe to add a pointer to const HEVCContext (namely the parent context) to each HEVCLocalContext. It is also safe (and actually redundant) to add a pointer to a logcontext to HEVCLocalContext. Doing so allows to pass the HEVCLocalContext as context in the parts of the code that is run slice-threaded when slice-threading is in use (currently these parts of the code use ordinary HEVCContext*). This way one is not tempted to modify the main context from the slice contexts. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevcdec: Don't initialize HEVCContexts twiceAndreas Rheinhardt2022-07-25
| | | | | | | | | | The slicethread contexts need to be initialized for every frame, not only the first one, so one can remove the initialization when allocating these contexts, because the ordinary per-frame initialization will initialize them again just a few lines below. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/hevc: add clip for persistent_rice_adaptation_enabled_flagXu Guangxin2022-07-25
| | | | | | Tests the issue fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7. Signed-off-by: Xu Guangxin <oddstone@gmail.com>
* avcodec/x86/pngdsp: Remove obsolete ff_add_bytes_l2_mmx()Andreas Rheinhardt2022-07-25
| | | | | | | It is overridden by ff_add_bytes_l2_sse2() on any non-ancient CPU. Reviewed-by: Henrik Gramner <henrik@gramner.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/hevcdec: Output MD5-message in one pieceAndreas Rheinhardt2022-07-24
| | | | | | | | | | | | | | | | Otherwise, there is no guarantee that the various av_log-messages are not interrupted by another log statement. The latter may originate from anywhere else, even the HEVC decoder itself, as happens when one uses frame-threading to decode the BUMPING_A_ericsson_1.bit sample from the FATE-suite. Furthermore, the earlier approach suffered from the fact that various parts of the logmsg were output with different loglevels and that checking stopped after having encountered the first plane with MD5 mismatch, although it is probably interesting to know whether other planes are incorrect, too. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* configure: properly require libx264 if enabledMarvin Scholz2022-07-24
| | | | | When libx264 can not be found even though it is enabled, it should error out properly instead of silently disabling it.
* avformat/argo_cvg: expose loop/reverb/checksum via metadataZane van Iperen2022-07-24
| | | | | Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
* avformat/argo_cvg: remove trace loggingZane van Iperen2022-07-24
| | | | | Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
* avformat/argo_cvg: add -loop and -reverb optionsZane van Iperen2022-07-24
| | | | | Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
* avformat/argo_cvg: name unk{1,2} fields correctlyZane van Iperen2022-07-24
| | | | | Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
* fftools/ffmpeg: replace AVFrame.pkt_duration with durationAnton Khirnov2022-07-24
| | | | Mistakenly reintroduced in 4740fea7ddf.
* lavf/dnn: dump OpenVINO model input/output names to OVMdel struct.Ting Fu2022-07-24
| | | | | | | Dump all input/output names to OVModel struct. In case other funcs use them for reporting errors or locating issues. Signed-off-by: Ting Fu <ting.fu@intel.com>
* avcodec/svq1enc: Use unsigned for parameter >= 0 to workaround GCC bugAndreas Rheinhardt2022-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | encode_block() in svq1enc.c looks like the following: static int encode_block(int block[7][256], int level) { int best_score = 0; for (unsigned x = 0; x < level; x++) { int v = block[1][x]; block[level][x] = 0; best_score += v * v; } if (level > 0 && best_score > 64) { int score = 0; score += encode_block(block, level - 1); score += encode_block(block, level - 1); if (score < best_score) { best_score = score; } } return best_score; } When called from outside of encode_block(), it is always called with level == 5. This triggers a bug [1] in GCC: On -O3, it creates eight clones of encode_block with different values of level inlined into it. The clones with negative values are of course useless*, but they also lead to -Warray-bounds warnings, because they access block[-1]. This has been mitigated in GCC 12: It no longer creates clones for parameters that it knows are impossible. Somehow switching levels to unsigned makes GCC know this. Therefore this commit does this. (For GCC 11, this changes the warning to "array subscript 4294967295 is above array bounds" from "array subscript -1 is below array bounds".) [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 *: These clones can actually be discarded when compiling with -ffunction-sections. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264_loopfilter: Fix incorrect function parameter array sizeAndreas Rheinhardt2022-07-23
| | | | | | | | | | | | | | | filter_mb_mbaff_edgev() and filter_mb_mbaff_edgecv() have a function parameter whose expected size depends upon another parameter: It is 2 * bsi + 1 (with bsi always being 1 or 2). This array is declared as const int16_t[7], yet some of the callers with bsi == 1 call it with only an const int16_t[4] available. This leads to -Wstringop-overread warnings from GCC 12.1. This commit fixes these by replacing [7] with [/* 2 * bsi + 1 */], so that the expected range and its dependence on bsi is immediately visible. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/snowenc: Don't pass int[2] as parameter declared as int[3]Andreas Rheinhardt2022-07-23
| | | | | | | | | | | | | | | | | | | | check_block_inter() currently does this when calling check_block(). This leads to a -Wstringop-overflow= warning when compiling with GCC 12.1. Given that the main part of the body of check_block() consists of an "if (intra) { ... } else { ... }" which is true iff check_block() is not called from check_block_inter(), it makes sense to fix this by just inlining check_block() check_block_inter() and turning check_block() into a new check_block_intra() (with the inter parts removed, of course). This should also not make much of a difference for the generated code given that both check_block() as well as check_block_inter() are already marked as av_always_inline, so this commit follows this route to fix the issue. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/asfcrypt: Fix wrong array length in function declarationAndreas Rheinhardt2022-07-23
| | | | | | | | | | | | multiswap_step() and multiswap_inv_step() both only require six keys; in all current callers, these keys are part of an array of twelve keys, yet in some of these callers the keys given to these functions point to the second half of these twelve keys, so that only six keys are available to these functions. This led to -Wstringop-overread warnings when compiling with GCC 12.1. Fix these by adapting the declaration of these functions. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/lrcenc: Avoid reading packet paddingAndreas Rheinhardt2022-07-23
| | | | | | (Everything would be fine if the packet was properly padded.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/ffmpeg: Zero subtitle packet paddingAndreas Rheinhardt2022-07-23
| | | | | | Fixes uninitialized reads in the sub-lrc-remux test. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/objpool: Don't use return with expression when returning voidAndreas Rheinhardt2022-07-23
| | | | | | | | | | | Using tail calls with functions returning void is forbidden (C99/C11 6.8.6.4: "A return statement with an expression shall not appear in a function whose return type is void.") GCC emits a warning because of this when using -pedantic: "ISO C forbids ‘return’ with expression, in function returning void" Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/ffmpeg: move each muxer to a separate threadAnton Khirnov2022-07-23
|
* fftools: add a multistream thread-safe queueAnton Khirnov2022-07-23
| | | | | It is similar to AVThreadMessageQueue, but supports multiple streams, each with its own EOF state.
* fftools/ffmpeg: depend on threadsAnton Khirnov2022-07-23
| | | | | ffmpeg will be switched to a fully threaded architecture, starting with muxers.
* fftools/ffmpeg: stop using av_stream_get_end_pts()Anton Khirnov2022-07-23
| | | | | | | | It retrieves the muxer's internal timestamp with under-defined semantics. Continuing to use this value would also require synchronization once the muxer is moved to a separate thread. Replace the value with last_mux_dts.
* fftools/ffmpeg_mux: do not call exit_program() in print_sdp()Anton Khirnov2022-07-23
| | | | | Return an error instead, as is already done in other places in this function.
* fftools/ffmpeg_mux: return errors from write_packet()Anton Khirnov2022-07-23
| | | | | Do not call exit_program(), as that would conflict with moving this code into a separate thread.
* fftools/ffmpeg_mux: return errors from submit_packet()Anton Khirnov2022-07-23
| | | | | Do not call exit_program(), as that would conflict with moving this code into a separate thread.
* fftools/ffmpeg_mux: return errors from of_submit_packet()Anton Khirnov2022-07-23
| | | | | Do not call exit_program(), as that would conflict with moving this code into a separate thread.
* fftools/ffmpeg: make the muxer AVFormatContext private to ffmpeg_mux.cAnton Khirnov2022-07-23
| | | | | Since the muxer will operate in a separate thread in the future, the muxer context should not be accessed from the outside.
* fftools/ffmpeg: only set OutputStream.frame_number for video encodingAnton Khirnov2022-07-23
| | | | | | | It is unused otherwise. Rename the field to vsync_frame_number to better reflect its current purpose.
* fftools/ffmpeg: stop using OutputStream.frame_number in print_report()Anton Khirnov2022-07-23
| | | | | | | | | | This field means different things when the video is encoded (number of frames emitted to the encoding sync queue/encoder by the video sync code) or copied (number of packets sent to the muxer sync queue). Print the value of packets_written instead, which means the same thing in both cases. It is also more accurate, since packets may be dropped by the sync queue or bitstream filters.
* fftools/ffmpeg: use the sync queues to handle -framesAnton Khirnov2022-07-23
| | | | | | | | | | | | | | | | Same issues apply to it as to -shortest. Changes the results of the following tests: - matroska-flac-extradata-update The test reencodes two input FLAC streams into three output FLAC streams. The last output stream is limited to 8 frames. The current code results in the first two output streams having 12 frames, after this commit all three streams have 8 frames and are the same length. This new result is better, since it is predictable. - mkv-1242 The test streamcopies one video and one audio stream, video is limited to 11 frames. The new result shortens the audio stream so that it is not longer than the video.
* fftools/ffmpeg_mux: reindentAnton Khirnov2022-07-23
|
* fftools/ffmpeg: rework -shortest implementationAnton Khirnov2022-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -shortest option (which finishes the output file at the time the shortest stream ends) is currently implemented by faking the -t option when an output stream ends. This approach is fragile, since it depends on the frames/packets being processed in a specific order. E.g. there are currently some situations in which the output file length will depend unpredictably on unrelated factors like encoder delay. More importantly, the present work aiming at splitting various ffmpeg components into different threads will make this approach completely unworkable, since the frames/packets will arrive in effectively random order. This commit introduces a "sync queue", which is essentially a collection of FIFOs, one per stream. Frames/packets are submitted to these FIFOs and are then released for further processing (encoding or muxing) when it is ensured that the frame in question will not cause its stream to get ahead of the other streams (the logic is similar to libavformat's interleaving queue). These sync queues are then used for encoding and/or muxing when the -shortest option is specified. A new option – -shortest_buf_duration – controls the maximum number of queued packets, to avoid runaway memory usage. This commit changes the results of the following tests: - copy-shortest[12]: the last audio frame is now gone. This is correct, since it actually outlasts the last video frame. - shortest-sub: the video packets following the last subtitle packet are now gone. This is also correct.
* fftools: add an object poolAnton Khirnov2022-07-23
| | | | | Allows to avoid constantly allocating and freeing objects like AVFrame or AVPacket.
* fftools/ffmpeg: use pre-BSF DTS for choosing next outputAnton Khirnov2022-07-23
| | | | | | | | | | The following commits will add a new buffering stage after bitstream filters, which should not be taken into account for choosing next output. OutputStream.last_mux_dts is also used by the muxing code to make up missing DTS values - that field is now moved to the muxer-private MuxStream object.
* fftools/ffmpeg: use last filter output pts to choose next output streamAnton Khirnov2022-07-23
| | | | | This will be needed in following commits that will add new buffering stages after encoding and bitstream filtering.
* fate/ffmpeg: add a test for interleaving video+subsAnton Khirnov2022-07-23
|
* fftools/ffmpeg: do not send spurious EOF for streamcopy when loopingAnton Khirnov2022-07-23
|
* fftools/ffmpeg: use refcounted packets for encoded subtitlesAnton Khirnov2022-07-23
|
* fftools/ffmpeg: move freeing 2pass input stats to a better placeAnton Khirnov2022-07-23
| | | | | | | | The current placement of this free is historical - it used to be followed by avcodec_close(), since removed. The proper place for freeing the stats is currently right before the encoder context itself is freed.
* fftools/ffmpeg: move output file opts into private contextAnton Khirnov2022-07-23
| | | | It is private to the muxer, no reason to access it from outside.
* fftools/ffmpeg_mux: split of_write_packet()Anton Khirnov2022-07-23
| | | | | | | | | | | | | | | | It is currently called from two places: - output_packet() in ffmpeg.c, which submits the newly available output packet to the muxer - from of_check_init() in ffmpeg_mux.c after the header has been written, to flush the muxing queue Some packets will thus be processed by this function twice, so it requires an extra parameter to indicate the place it is called from and avoid modifying some state twice. This is fragile and hard to follow, so split this function into two. Also rename of_write_packet() to of_submit_packet() to better reflect its new purpose.
* fftools/ffmpeg_mux: split queuing packets into a separate functionAnton Khirnov2022-07-23
|
* fftools/ffmpeg: move the mux queue into muxer private dataAnton Khirnov2022-07-23
| | | | | | | | | The muxing queue currently lives in OutputStream, which is a very large struct storing the state for both encoding and muxing. The muxing queue is only used by the code in ffmpeg_mux, so it makes sense to restrict it to that file. This makes the first step towards reducing the scope of OutputStream.
* fftools/ffmpeg: do not log to the muxer contextAnton Khirnov2022-07-23
| | | | All other logging goes to NULL context.
* fftools/ffmpeg: access output file chapters through a wrapperAnton Khirnov2022-07-23
| | | | | Avoid accessing the muxer context directly, as this will become forbidden in future commits.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-02 05:02:31 +0000