The code was buggy, using the wrong variable, also it missed the case
where the packet become smaller due to sidedata/metadata being extracted
which left a few bytes uninitialized
Fixes use of uninitialized memory
Fixed: msan_uninit-mem_7f6abbe44530_6838_mewmew_vorbis_ssa.nut
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The fate test is changed because the reference file depends on the use of
non cleared data at the very
end. Alternatively we could upload a new reference file, though that would
then have to be changed every time the handling of a truncated frame changes
or theres a change to error concealment, each time adding a new file ...
Fixes use of uninitialized memory
Fixed: msan_uninit-mem_7f3c02b81363_2787_RLG2_19.rm
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It stored images wrong in the user provided buffers (that is you would
end up with a wrongly flipped image if you used direct rendering).
Also it used wrong dimensions as noticed by ubitux
Enable the old code unconditionally so flipping works correctly
again.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b0be1ae792ac8bbfb0fc7b9b9cb39eaf0feb489b':
x86: avcodec: Add a bunch of missing #includes for av_cold
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes use of the example with encoders which use tha AVFrame w/h/pix_fmt fields
FFV1 is one of these codecs
We cannot easily workaround the not set fields in common code because the API
has AVFrame constant for the encoders.
Alternatives would be to fix the API or to duplicate the struct and fill in
missing fields. Or as is to require all user apps to set this correctly and
maybe simplify for that case
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
mjpegdec: apply flipping after decoding, not before
Conflicts:
libavcodec/mjpegdec.c
libavcodec/mjpegdec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e588615d938f8581f0d6f3771662d08cadfc00de':
hevc: fix decoding of one PU wide files
Conflicts:
libavcodec/hevc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ca96e337169093979d7c763064ad9dae12b3108c':
vp9: drop support for real (non-emulated) edges
Conflicts:
libavcodec/vp9block.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ef8c93e2f18c624d0c266687e43ab99af7921dd3':
vp8: drop support for real (non-emulated) edges
Conflicts:
tests/fate/vpx.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ebfe622bb1ca57cecb932e42926745cba7161913':
mpegvideo: drop support for real (non-emulated) edges
Conflicts:
libavcodec/mpegvideo.c
libavcodec/mpegvideo_motion.c
libavcodec/wmv2.c
If this is slower on a major platform then it should be investigated
and potentially reverted.
See: 8fc52a5ef9
See: 3969b4b861
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fix PTS set on the frame when encoding, which must be specified in the
encoder timebase or this will confuse the encoder.
When muxing the packet, the PTS/DTS generated by the encoder is then
rescaled to the stream timebase.
They are not measurably faster on x86, they might be somewhat faster on
other platforms due to missing emu edge SIMD, but the gain is not large
enough to justify the added complexity.
They are not measurably faster on x86, they might be somewhat faster on
other platforms due to missing emu edge SIMD, but the gain is not large
enough to justify the added complexity.
Several decoders disable those anyway and they are not measurably faster
on x86. They might be somewhat faster on other platforms due to missing
emu edge SIMD, but the gain is not large enough (and those decoders
relevant enough) to justify the added complexity.
untested (noone tested within about a month) and the change is
quite trivial so should be ok. While the code before this change
is broken.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
