- 20 Jun, 2024 40 commits
-
-
James Almer authored
ffprobe is meant to generate parseable output, and if a field is present, it should be printed even if it has a default value. Signed-off-by: James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
These tables are supposed to contain the number of bits needed to encode a given (run, level) pair. Yet the number of bits for pairs needing the escape code was wrong (it only contained the escape code and not the bits needed for run and level). Furthermore, H.261 (a format with explicit end-of-block codes) does not work well together with the RLTable API from rl.c: The EOB code is the first one in ff_h261_rl_tcoeff's VLC table and has a run value of zero. Therefore the result of get_rl_index() is off by one for run == 0 and level values with explicit (run, level) pair. Fixing this necessitated changing the ref files of the vsynth*-h261-trellis tests. Both filesizes as well as PSNR decreased. If one used a qscale value of 11 for this test, one would have received files with about the same size as before this patch (with qscale 12), but with better PSNR. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The RLTable API in rl.c is not well designed for codecs with an explicit end-of-block code. ff_h261_rl_tcoeff's vlc has the EOB code as first element (presumably so that the decoder can check for it via "if (level == 0)") and this implies that the indices returned by get_rl_index() are off by one for run == 0 which is therefore explicitly checked. This commit changes this by adding a simple LUT for the values not requiring escaping. It is easy to directly include the sign bit into this, so this has also been done. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This will allow to avoid the indirection via ff_h261_rl_tcoeff in future commits. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
These must not be modified (even when they are initialized at runtime and therefore modifiable). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
H.261 does not have B-frames. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is a better place for it; no non-h263-based decoder needs these functions any more (both H.261 and the error resilience code recently stopped doing so). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is an MPEG-4-only value; it is always five for the MPEG-4 encoder, so just hardcode this value and move the MpegEncContext field to Mpeg4DecContext. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The RV10 and RV20 decoders use ff_h263_decode_mb() and also the H.263 DSP and VLCs. Despite not calling ff_h263_decode_frame(), it is nevertheless beneficial to call ff_h263_decode_init() to reduce code duplication. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The error resilience code does not make up block coefficients and therefore zeroes them in order to disable the IDCT. But this can be done in a simpler manner, namely by setting block_last_index to a negative value. Doing so also has the advantage that the dct_unquantize functions are never even called for those codecs that do not use ff_mpv_reconstruct_mb() for ordinary decoding (namely RV-30/40 and the VC-1 family). This approach would not work for intra macroblocks (there is always at least one coefficient for them and therefore there is no check for block_last_index for them), but this does not happen at all. Add an assert for this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Just do it once during init. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Don't use a LUT to negate followed by a conditional ordinary negation immediately thereafter. Instead fold the two. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This is beneficial for performance: When concatenating the file from the vsynth1-h261 fate-test 100 times, performance (measured by timing the codec's decode callback) improved by 9.6%. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is unnecessary because ff_mpeg1_dc_scale_table is the default for both dc_scale_tables. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
ff_init_block_index() sets MpegEncContext.dest and MpegEncContext.block_index. The latter is unused by ff_mpv_reconstruct_mb() (which is what this code is preparatory for) and dest is overwritten a few lines below. So don't initialize block_index at all. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
inter_scantable is only used by the dct_unquantize_h263_inter functions, yet this is not used by the MPEG-4 decoder at all (in case H.263 quantization is used, the unquantization already happens in mpeg4_decode_block()). Also move the common initialization of ff_permute_scantable() out of the if. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The WMV2 decoder does not support lowres, so one can optimize the WMV2 specific code away in the lowres version of this function. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
No mpegvideo-based decoder supports lowres > 3, so the FFMIN here are unnecessary. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
There are only two mpegvideo decoders that use another (software) pixel format than YUV420: MPEG-1/2 and the MPEG-4 studio profile. Neither of these use this part of the code, so one can optimize the 422 code away when this code is compiled for the decoder. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
h261_resync() can be completely removed, because h261_decode_gob_header() checks for a GOB header itself if gob_start_code_skipped is zero. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
last_resync_gb is never initialized, causing NULL + 0 in align_get_bits(). In addition to that, the loop is never entered. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It always gets reset at the start of h261_decode_frame(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
All valid values of dc_lum and dc_chrom are in the range 0..9, because they are initialized via tables with 10 elements. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Everything that init_block_index() sets will be overwritten a few lines below again, so don't call it and simply calculate the only thing that is used (namely block_index[0]) manually. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Only the intra scantable is used for studio profile. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Partitioned macroblocks are always 8bit and not studio profile. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The no-output mode (guarded by AV_CODEC_FLAG2_NO_OUTPUT) does not provide a noteworthy speedup; in fact, it even turned out to be slower than the code with the no-output code removed (ordinary encode: 153259721 decicycles, noout encode: 153259721; encode with this patch applied: 152451581 decicycles; timings are for encode_frame callbacks when encoding a 1080p sample to MPEG-4). (Furthermore, this code was broken for most of its existence (since 9207dc3b) and no one noticed, so the no-output mode is probably not used at all.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Possible since 404fe63e. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The earlier code had two problems: 1. For reference frames that are not directly output (happens unless low_delay is set), the mb skip values referred to the next reference frame to be decoded. 2. For non-reference frames, every macroblock was always considered skipped. This makes the output (worse than) useless; that no one ever complained about this shows that this feature is not really used. It is therefore removed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is not a stream property, but a property of an individual picture (in fact, it is only set by the FLV decoder that does not even support frame threading). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is always allocated in ff_mpv_frame_start(), so the only reason to put it into ff_mpeg_update_thread_context() would be for the case that a frame-threaded decoder that supports coded fields implements frame-threading. The only mpegvideo-decoders supporting coded fields are MPEG-1/2 and VC-1. The latter's bitstream requires both coded fields to be part of the same access unit/packet, so that every frame thread will always call ff_mpv_frame_start() itself. The former only "need" the framesize buffers when using lowres. If MPEG-1/2 gains frame-threading, one could either perform framesize allocation in its update_thread_context or when starting a field. (Given that the next packet may trigger a reinitialization due to a frame size change, it was possible for the buffers that were allocated here to be thrown away unused.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-