Fixes Ticket5478
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b21f674876badefc68e4deecdb4a1d46de10b67c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is allocated before, this cannot work
Fixes Ticket5613
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 24f513619680b5bef40b02db6ca07a8a009c2ece)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x86 is maintained entirely by others these days
ML, mostly too
remove myself from a few spots that have other maintainers and where i
just dont know the code that well anyway to do an ideal job
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit bb5bc08ba6f88af2a4a2e00ea03261b142f79f8f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No testcase known
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c36fc857b5a8f8bdf2bcc54ce72bbf817902edcf)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The maximum number of bits int the prefix code for
p(0) is 4. By setting it as 3, we were missing the
last 0 bit.
This fixes bug #4715 present on the trac.
Signed-off-by: Umair Khan <omerjerk@gmail.com>
Reviewed-by: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 5d64ba9d18294a305f4f46c9a64e592dc5d34aa9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5528
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 153ab83bd37cbbcc79d8303cc6efbf81089b8123)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 43a4276c6964a2ec57e08c3c622bb94d35c0441f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of ticket 5598
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 37005e65eb17b1480d9e1755eeba3f50ee3b9555)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of ticket 5598
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 250b620d296adba7bd3a3104a9c30e820fb0bc36)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of ticket 5598
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit bfe945ac3a0c328371dc4b4cc3409b7da5784cb8)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5326
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit abc957e896beb3ce33c5691b9b3701993a381852)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When multiple threads tries to call av_register_all(), the first thread sets
initialized to 1 and do the register process. At the same time, other thread might
also call av_register_all(), which returns immediately because initialized is set to 1
(even when it has not completed registering codecs). We can avoid this problem
if we set initialised to 1 while exiting from function.
Github: Closes#196
(cherry picked from commit b092ee701f4d0ef2b8a4171cd38101d1ee9a1034)
Conflicts:
libavformat/allformats.c
Fixes regression with mplayers direct rendering and reduces buffer count
pressure in some cases
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 39c0b22df42088cf4fb1ceb2447291c224a5c7ed)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5598
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d0388bd32e1c84a9ef87ba6c448c7fffb6a9f259)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: usan_granule_overflow
constant type fix by commiter
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1a82d2cf8fb6a7e854e7548dfcf73c3d046b34ac)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
See: [FFmpeg-devel] [Vote] Code of Conduct
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 89e9393022373bf97d528e6e9f2601ad0b3d0fc1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5498
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d08f2c172fd2baab022f0118f49e5b2852a2d463)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes division by 0 in fate-acodec-ra144
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 635b2ec5f20d6cdef1adf4907ca28f8f09abcecc)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Avoids unexpected occurance and dependency on NaN behavior and divisions by 0
Testcase: fate-lavf-fate-avi_cram
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6085d6b2aeef28671614f625601a23cfc922d282)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2f76157eb05bf63725f96167feda6b2e07501c7e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes the sum of the integer coefficients ending up summing to a value
larger than the value representing unity.
This issue occurs with qN0.dts when converting to stereo
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7fe81bc4f8ba684626fa08f7bef46da3e8abe373)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Leaking this private structure opens up the possibility that it may
be re-used when parsing later packets in the stream. This is
problematic if the later packets are not the same codec type (e.g.
private allocated during Vorbis parsing, but later packets are Opus
and the private is assumed to be the oggopus_private type in
opus_header()).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 542f725964e52201000ec34e2f23229cf534ad3a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Larger values would imply file durations of astronomic proportions and cause
overflows
Fixes integer overflow
Fixes: usan_int64_overflow
Found-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8efaee3710baa87af40556a622bf2d96a27c6425)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: IMG-20160418-WA0002.jpg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit deaf58abf236e09fc9b97db29f1edd064e4b5ad4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5443
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 11db7eee9b001d6992c34b65ee7b0d64f6f5c758)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This decreases the MV related encoding table sizes
This should have little effect on real world video encoding performance
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d7c75a5db0cf3674e1a5c3e51ac024ef2ef6f09f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.
Fixes#4637
(cherry picked from commit 9779b6262471d553c1ed811ff7312564e39d8adf)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5319
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9ac154d1facd4756db6918f866dccf3e3ffb698c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(cherry picked from commit 38797a8033d061ade58b30b8ac86da222fe42a84)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(cherry picked from commit 9149e9c0baaec122bc3da925d6068dffa60b5427)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: mozilla bug 1266129
Found-by: Tyson Smith
Tested-by: Tyson Smith
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9f36ea57ae6eefb42432220feab0350494f4144c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sometimes video fails to decode if H.264 configuration changes mid stream.
The reason is that configuration parser assumes that nal_ref_idc is equal to 11b
while actually some codecs but 01b there. The H.264 spec is somewhat
vague about this but it looks like it allows any non-zero nal_ref_idc for sps/pps.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3a727606c474d3d0b9efa3c900294a84bdb5e331)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, if the movie source filter is used and a seek_point is
specified on a file that has a negative start time, ffmpeg will fail.
An easy way to reproduce this is as follows:
$ ffmpeg -vsync passthrough -filter_complex 'color=d=10,setpts=PTS-1/TB' test.mp4
$ ffmpeg -filter_complex 'movie=filename=test.mp4:seek_point=2' -f null -
The problem is caused by checking for int64_t overflow the wrong way.
In general, to check whether a + b overflows, it is not enough to do:
a > INT64_MAX - b
because b might be negative; the correct way is:
b > 0 && > a > INT64_MAX - b
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1f9734f977f59bc0034096afbe8e43e40d93a5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: maintainer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 0cd9ff4e3aa23318a855c21d60b1c9035b2b99d2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Original mail and my own followup on ffmpeg-user earlier today:
I have a device sending out a MJPEG/RTP stream on a low quality setting.
Decoding and displaying the video with libavformat results in a washed
out, low contrast, greyish image. Playing the same stream with VLC results
in proper color representation.
Screenshots for comparison:
http://zevv.nl/div/libav/shot-ffplay.jpghttp://zevv.nl/div/libav/shot-vlc.jpg
A pcap capture of a few seconds of video and SDP file for playing the
stream are available at
http://zevv.nl/div/libav/mjpeg.pcaphttp://zevv.nl/div/libav/mjpeg.sdp
I believe the problem might be in the calculation of the quantization
tables in the function create_default_qtables(), the attached patch
solves the issue for me.
The problem is that the argument 'q' is of the type uint8_t. According to the
JPEG standard, if 1 <= q <= 50, the scale factor 'S' should be 5000 / Q.
Because the create_default_qtables() reuses the variable 'q' to store the
result of this calculation, for small values of q < 19, q wil subsequently
overflow and give wrong results in the calculated quantization tables. The
patch below uses a new variable 'S' (same name as in RFC2435) with the proper
range to store the result of the division.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e3e6a2cff4af9542455d416faec4584d5e823d5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5244
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 068026b0f7845e0f1850094d974f60d181480d64)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
