It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.
Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.
Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.
This should behave similar to x264 and other encoders, as it handles a
gop_size of 0 as Intra-Only, while it's still possible to control how
many B-Frames it inserts.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Before
2843 decicycles in ff_sbr_autocorrelate_sse3, 262086 runs, 58 skips
After
2693 decicycles in ff_sbr_autocorrelate_sse3, 262117 runs, 27 skips
Signed-off-by: James Almer <jamrial@gmail.com>
if the openjpeg parameter tcp_rates is not 0 ( using the ffmpeg compression_level option )
every 2nd image per thread is badly encoded. By moving the opj_setup_encoder function from
libopenjpeg_encode_init to libopenjpeg_encode_frame this can be prevented.
This fixes ticket #3754.
Signed-off-by: Jean First <jeanfirst@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This improves motion estimation and avoids using uninitialized data
for resolutions that aren't a multiple of 16.
Prior to d2a25c40, the edges used to be initialized so that encoding
was deterministic, but after that commit it started using uninitialized
data (for non multiple of 16 resolutions).
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This like the previous attempt does not fully correctly decode this
type of non standard H.264, but it now works fully automatic
requiring no manual filters or flags to be used
See Ticket2254
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The vec_ste calls were mistakenly changed to vec_vsx_st in c5ca76a, which
caused stack smashing.
Changing them back fixes crashes on ppc64el, when configured with
--toolchain=hardened.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '440119b18836887d98c9e337c5911563bb43588c':
libopenh264enc: Move a declaration of a variable into an ifdef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bba02479260d0e7dec8c530a7e75a1c7aa53c06e':
libopenh264enc: Remove a workaround for silencing warnings about unused variables in the OpenH264 header
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The 1.3 release branch of OpenH264 (as well as the master branch)
have been updated so that GCC no longer warns about this variable
as being unused.
Signed-off-by: Martin Storsjö <martin@martin.st>
This leaked a frame on each avcodec_flush_buffers() call, if frame
threading was enabled. It caused severe memory usage in player if you
were seeking a lot.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
