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 partially reverts cf70ba37ba, since
it didn't take into account when rotation is 0, but there is another
valid operation (eg. translation) in the matrix.
Found-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>
It's better to steer users at these, since they are both better
and more alive than the mingw.org versions.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
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 goto wasn't necessary originally, but it should have been
added when the write_manifest call was added in 8e276378.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes sending chunked packets (packets larger than the output
chunk size, which often can be e.g. 4096 bytes) with a timestamp delta
(or absolute timstamp, if it's a timestamp step backwards, or the
first packet of the stream) larger than 0xffffffff.
The RTMP spec explicitly says (in section 5.3.1.3.) that packets of
type 3 (continuation packets) should include this field, if the
previous non-continuation packet had it included.
The receiving code handles these packets correctly.
Pointed out by Cheolho Park.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes out of array reads and/or infinite loops.
30 is the maximum number of bits that can be read into
coeff_abs below.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill -> av_image_fill_arrays()
avpicture_layout -> av_image_copy_to_buffer()
The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).
The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).
A redundant check has been dropped from av_image_fill_arrays().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
When the display matrix is not the identity one, but the rotation angle
is zero, there is no need to update the sample aspect ratio.
Otherwise, it is possible to obtain negative values which interferes
with transcoding in later stages. This kind of behaviour is reproducible
on mov files with "major_brand: MSNV".
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Anton Khirnov
Hendrik Leppkes
Andreas Unterweger
Vittorio Giovara
Michael Niedermayer
Martin Storsjö
Derek Buitenhuis
Rodger Combs
Nidhi Makhijani
Paul B Mahol
Stefano Sabatini