- 20 Jun, 2024 40 commits
-
-
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>
-
Andreas Rheinhardt authored
They are no longer used by the MPEG-1/2 decoders except when using lowres. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
There is no reason to use a temporary buffer as destination for the new macroblock before copying it into its proper place. (Originally, this has been added in commit b68ab260 due to concerns about copying from GPU memory.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Broken in 5ecf5b93. More precisely, 3994623d changed the precursor of ff_mpv_reconstruct_mb() to always decode to the first row of macroblocks for B pictures when a draw_horiz_band callback is set and to (they are exported to the caller via said callback and each row overwrites the previously decoded row; this was probably intended as a cache-optimization). This first macroblock row was used as source for the draw_horiz_band callback. This of course means that the ordinary output B-frame was not decoded correctly at all. Therefore the first aforementioned commit removed this special handling of draw_horiz_band; yet it did not remove the special handling for B-frames in ff_draw_horiz_band(), which broke draw_horiz_band for B-frames. This commit fixes this. (Actually, draw_horiz_band was already broken before 5ecf5b93 when using slice-threading: All slice-threads would write to the first row of macroblocks for B-frames, leading to data races. It seems no one has ever complained about this, just as no one has ever complained about the breakage caused by 5ecf5b93. Probably no one uses draw_horiz_band.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The new value will be overwritten in ff_set_qscale() below. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Calling it is the first thing ff_clean_h263_qscales() and ff_clean_mpeg4_qscales() do anyway. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
A MECmpContext is quite big (792B here) and given how ff_update_duplicate_context() works, it is (unfortunately) copied quite frequently when using slice threading. Therefore keep only what is needed from MECmpContext and remove MECmpContext from MpegEncContext. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Not every function will be set, so zero the context to initialize everything. This also allows to remove an initialization in dvenc.c. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This avoids using MpegEncContext.mecc; it already allows to avoid touching the latter for snowenc and svq1enc. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Several of the potential choices of comparison functions need an initialized MpegEncContext (initialized for encoding, not only ff_mpv_common_init()) or they crash when called. Modify ff_set_cmp() to check for this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MECmpContext.ildct_cmp is an array of function pointers that are not set by ff_me_cmp_init(), but that are set by users to one of the other arrays via ff_set_cmp(). Remove these pointers from MECmpContext and add pointers for the actually used functions to its users. (The DV encoder already did so.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MECmpContext has several arrays of function pointers that are not set by ff_me_cmp_init(), but that are set by users to one of the other arrays via ff_set_cmp(). One of these other users is mpegvideo_enc; it is the only user of MECmpContext.frame_skip_cmp and it only uses one of these function pointers at all. This commit therefore moves this function pointer to MpegEncContext; and removes the array from MECmpContext. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MECmpContext has several arrays of function pointers that are not set by ff_me_cmp_init(), but that are set by users to one of the other arrays via ff_set_cmp(). One of these other users is the motion estimation API. It uses MECmpContext.(me_pre|me|me_sub|mb)_cmp. It is basically the only user of these arrays. This commit therefore moves these arrays to MotionEstContext; this has the additional advantage of making motion_est.c more independent from MpegEncContext. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The majority of the stuff performed in it needs to be done only once; so factor it out into a function of its own to be called in the user's init function. Also avoid using MpegEncContext in it, to separate the two a bit more. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Not every type of comparison function implements every function. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Not all compare functions are implemented for all compare function types. Therefore check for the existence of the used functions. Fixes issue #10245. 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
Possible by using MB_TYPE_CODEC_SPECIFIC for MB_TYPE_ZERO_MV and due to the MB_TYPE_*_MV flags fitting into an int16_t. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Possible now that MB_TYPE_L1 (which does not fit into an int16_t) is no longer used). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MB_TYPE_L[01] is based upon H.264 terminology (it stands for list); yet the mpegvideo based decoders don't have lists of reference frames, they have at most one forward and one backward reference. So use terminology based upon this. This also has a second advantage: MB_TYPE_L[01] is actually an OR of two flags (which are set independently for H.264, but aren't for mpegvideo). Switching to different flags makes the flags fit into an int16_t, which will be useful in future commits. The only downside to this is a very small amount of code in error_resilience.c and mpegutils.c (the only code shared between the H.264 decoder and mpegvideo). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
SVQ3 does not call ff_print_debug_info2(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The "invalid mtype index" here is always -1, because that is the value the VLC api uses for not existent leafs in an incomplete tree. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This is possible now that MB_TYPE_CBP and MB_TYPE_QUANT fit into an int16_t; only MB_TYPE_H261_FIL needs to be remapped to MB_TYPE_CODEC_SPECIFIC. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Do this to make MB_TYPE_{CBP,QUANT} fit into an int16_t, so that can be used in a VLC symbol table. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MB_TYPE_ACPRED is currently reused for MB_TYPE_REF0 by H.264, so that the value fits into an uint16_t. Given that MB_TYPE_ACPRED is not subject to any such restriction (apart from fitting into 32bits), it can be remapped to a hithereto unused bit. The then available bit will be declared to be codec-specific (i.e. unused by generic code), so that H.264 can use it for MB_TYPE_REF0 and so that it can be reused later for e.g. MB_TYPE_H261_FIL. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Obsolete since 3ceffe78. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Everything except dct_unquantize_intra for MPEG-4 need only be set once. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Set them in ff_mpv_idct_init() so that they are already set in ff_mpv_decode_init(). This is in preparation for avoiding to set dct_unquantize in every ff_mpv_frame_start(). 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>
-