Fixes Ticket5689
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 803c058a6f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will be useful when the amount of streams per subdemuxer is not
known at hls_read_header time in a following commit.
(cherry picked from commit 9884f17e34)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will avoid a large time difference between variants in the most
common case.
(cherry picked from commit 4d85069e5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit 81306fd4bdf ("hls: eliminate ffurl_* usage", merged in d0fc5de3a6)
changed the hls demuxer to use AVIOContext instead of URLContext for its
HTTP requests.
HLS demuxer uses the "offset" option of the http demuxer, requesting
the initial file offset for the I/O (http URLProtocol uses the "Range:"
HTTP header to try to accommodate that).
However, the code in libavformat/aviobuf.c seems to be doing its own
accounting for the current file offset (AVIOContext.pos), with the
assumption that the initial offset is always zero.
HLS demuxer does an explicit seek after open_url to account for cases
where the "offset" was not effective (due to the URL being a local file
or the HTTP server not obeying it), which should be a no-op in case the
file offset is already at that position.
However, since aviobuf.c code thinks the starting offset is 0, this
doesn't work properly.
This breaks retrieval of ranged media segments.
To fix the regression, just drop the seek call from the HLS demuxer when
the HTTP(S) protocol is used.
(cherry picked from commit 9cb30f7a880578e995becbd8bf9ffb69788e09a2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5736
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1bfeda5a3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If negative pts are possible for some codecs in ogg then the code needs to be
changed to use signed values.
Found-by: Thomas Guilbert <tguilbert@google.com>
Fixes: clusterfuzz_usan-2016-08-02
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c5cc3b08e5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: Thomas Guilbert <tguilbert@google.com>
Fixes: clusterfuzz_usan-2016-08-02
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6cd9a8b67a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
10- and 12-bit DNxHR use the same DC coefficient decoding process and
VLC table, just with a different shift value. From SMPTE 2019-1:2016,
8.2.4 DC Coefficient Decoding:
"For 8-bit video sampling, the maximum value of η=11 and for
10-/12-bit video sampling, the maximum value of η=13."
A sample file will be uploaded to show that with this patch, things
decode correctly:
dnxhr_hqx_12bit_1080p_smpte_colorbars_davinci_resolve.mov
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e1be80aa11)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ad14aab3b4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit cd141e71bd)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes crash in avformat_open_input() when accessing
protocol_whitelist field.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e947b75b1c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix const corectness and zero init the struct. This example code would actually crash when initializing string.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 69630f4d30)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 282477bf45)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes use of freed memory
Should fix valgrind failures of fate-h264-skip-nointra
Found-by: logan
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit febc862b53)
Conflicts:
libavcodec/h264_parser.c
H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
converted to NAL units before sending them to MediaCodec.
This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
which makes the resulting NAL units correct.
Fixes codec initialization on Nexus 4 and Nexus 7.
(cherry picked from commit 88d9c30cf5)
This reverts commit cb8646af24.
This change has brough more issues than benefits, between compilation
time failures depending on flags used and code miscompilation causing
runtime crashes.
See the "[PATCH 2/2] configure: Enable GCC vectorization on ≥4.9"
thread in the ffmpeg-devel mailing list for the relevant discussion.
(cherry picked from commit fd6dbc5385)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2a8dadb38f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Based-on: patch by James Almer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 86fec7a7e8)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes part of Ticket5676
This fixes kodi, mpv, chromium and ffplay build against 3.0 and linked to 3.1
This is a similar ABI fix to 1eb43af1a0
Approved-by: BBB
Approved-by: jamrial
Approved-by: BtbN
Approved-by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1c7e0abb0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This ensures the AVStream->codec entry is kept in sync when new streams are
discovered mid-playback or changes to the context occur from other sources.
Fixes trac 5678.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c2e13d2ecd)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes part of Ticket5676
This fixes kodi, mpv, chromium and ffplay build against 3.0 and linked to 3.1
This is a similar ABI fix to 1eb43af1a0
Approved-by: BBB
Approved-by: jamrial
Approved-by: BtbN
Approved-by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 042fb69deb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket #5674
the size of data to process in piz_uncompress, is now calc
using the pixel type of each channel.
the data reorganization, alos take care about the size of
each channel
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d9e1e08133)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Even though this is not part of the public API, some external
applications access fields after it, thus breaking after updating from
ffmpeg 3.0 or earlier.
Since it is not public, it can be freely moved to the end to avoid
that problem in the future.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
P1, P2, and P3 are respectively the text versions of PBM, PGM and PPM
files.
We can not obtain the buffer size using av_imgage_get_buffer_size() as
every pixel in the picture will occupy a random size between 16 and 32
bits ("4 " and "231 " are such example).
Ideally, we could look for the next header (or EOF) in the bytestream,
but this commit is meant to fix a decoding regression introduced by
48ac4532d4.
Fix Ticket #5670
(cherry picked from commit c5566f0a94)
Use c++98 standard instead of c++11.
Signed-off-by: Rick Kern <kernrj@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 729d82abae)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '5264e7ba217b3c0ceae813917134e1ab52573141':
ac3: Check the array bound before dereferencing
See d85ebea3f3
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a86aa16088ad7f22a8918d71adb8c040d6033d84':
vaapi_h264: Add trivial support for low-power encoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>