Unrecognized streams are not allocated
Fixes: flicker-1.color1.vp91447030769.08.webm
Found-by: Chris Cunningham <chcunningham@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a5034b324cad4c29d47ef285a30b0705e6eb0384)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously only the edit_rate of material_track was checked.
If it's negative, it causes assertion failures in av_rescale_rnd.
Reviewed-by: Tim Nicholson <nichot20-at-yahoo.com@ffmpeg.org>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit 047bf82c181c1220b3087b37f28445f8b87a7a23)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate causes assertion failures in av_rescale_rnd.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit 7b67fe20f6c5ce21ed1cac01fdb1906e515bc87e)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also support disabling them as they seem to cause problems to some
Users. They are also not allowed in IRT D-10 thus the default for
mxf_d10 is not to write them
This also decreases the filesize when no user comment are stored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d9726893f311b7bbbc9887db2c3ffbefaad78ca3)
Conflicts:
libavformat/mxfenc.c
The return type of strlen is size_t, i.e. unsigned, so if pd->buf_size
is 3, the right side overflows leading to a wrong result of the
comparison and subsequently a heap buffer overflow.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit db374790c75fa4ef947abcb5019fcf21d0b2de85)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9b6fac11da470274d4b93d46ef66527aa1824179)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Context cookies must be updated when a playlist response return Setcookie header.
See: 770dd105044d00263da041f509a08b316296a78e
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some RTSP servers ("HiIpcam/V100R003 VodServer/1.0.0") respond to
our keepalive GET_PARAMETER request by a truncated RTSP header
(lacking the final empty line to indicate a complete response
header). Prior to 764ec70149, this worked just fine since we
reacted to the $ as interleaved packet indicator anywhere.
Since $ is a valid character within the response header lines,
764ec70149 changed it to be ignored there. But to keep
compatibility with such broken servers, we need to at least
allow reacting to it at the start of lines.
Fixes ticket #4952.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit e02dcdf6bb6835ef4b49986b85a67efcb3495a7f)
Commit 2b3e9bbfb529e6bde238aeb511b55ebe461664c8 caused problems for a
certain API user:
https://code.google.com/p/chromium/issues/detail?id=537725https://code.google.com/p/chromium/issues/detail?id=542032
The problem seems rather arbitrary, because if there's junk, anything
can happen. In this case, the imperfect junk skipping just caused it to
read different junk, from what I can see.
We can improve the accuracy of junk detection by a lot by checking if 2
consecutive frames use the same configuration. While in theory it might
be completely fine for the 1st frame to have a different format than the
2nd frame, it's exceedingly unlikely, and I can't think of a legitimate
use-case.
This is approximately the same mpg123 does for junk skipping. The
set of compared header bits is the same as the libavcodec mp3 parser
uses for similar purposes.
(cherry picked from commit de1b1a7da9e6ddf42447271e519099a88b389e4a)
Fixes ticket #4924.
Found-by: Jaroslav Šnajdr <jsnajdr@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit df239b76195156f179618ddb8b167d5bf1245247)
Without EXT-X-MAP support we miss the first bytes of some streams.
These streams worked by luck before byte-ranged segment support was added in
da7759b3579de3e98deb1ac58e642b861280ba54
Fixes ticket #4797.
(cherry picked from commit 909907948846dedf57a730a4d115d04d1117f9e5)
Conflicts:
libavformat/hls.c
Commit ad701326b43078b90 ("avformat/hls: open playlists immediately when
AVDISCARD_ALL is dropped") inadvertently caused first_packet to never be
cleared, causing select_cur_seq_no() to not use the specific code for
live streams.
In practice this means that when the user selects a different audio
track during live stream (i.e. non-VOD) playback, there may be some
additional delay as the code might select an incorrect segment at first,
and we have to wait for video to catch audio (if too late segment was
selected) or to download more following audio segments (if too early
segment was selected).
Fix that by restoring the zeroing of first_packet.
(cherry picked from commit fd74d45d5158812675105a3b4aeb29c67b82f7e8)
If there is no #EXT-X-BYTERANGE specified, there is no need to seek.
Seeking fails anyway for rtmp, because this protocol does not support
url_seek.
This fixes CNN.m3u from trac ticket 4797 (i.e. Debian bug #798189).
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit f9f0b4c08e7dc2c178ede137af4f64ca84ab2deb)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Broken by commit ba12ba859aabfa7153ba397d869db13acdaba340. This only
happens with HLS streams which use encryption and require preserving
cookies sent by the server.
Fixes trac issue #4846.
(cherry picked from commit 26eb2940079d0ec433cf9b2deae24560707cbcf8)
Fixes regression since 7218352e0228028dfa009a3799ec93fd041065f1: WebVTT
files were matching the SRT probing.
(cherry picked from commit 40d9d6de90c3652f4c468ab14976c7faf5e40c07)
The stream ID is essentially an arbitrary number defined by the .idx
file headers. They have to match the IDs in the .sub stream. The vobsub
demuxer assumed the IDs would just start from 0, increassing by 1 for
each stream. This is not correct. In the sample I had, the IDs were
starting from 1, leading to no subtitles being displayed at all.
Fix this by using the correct stream ID.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a47ad06baf6c0db6d47a5531d6d4ee0511f44eac)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes access to Grandstream cameras, which return 401 to ffmpeg
otherwise.
VLC sends Authorization: header with spaces between parameters, and it
is known to work with Grandstream devices and broad range of other HTTP
and RTSP servers, so author considers switching to such behaviour safe.
Just for record - RFC 2617 (HTTP Auth) does not specify the need in
spaces, so this is not a bug of FFmpeg.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit fdb32838723effb4560a345013387ea37b85ff20)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes ticket#4900
Signed-off-by: DHE <git@dehacked.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 76e3f8242d607ac0394b7894196f83f8d02ce5ca)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Not requiring this can end up producing hilariously broken files
together with -c:s copy (e.g. a webvtt file containing binary subtitle data).
Signed-off-by: Simon Thelen <ffmpeg-dev@c-14.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b84232694ef0c6897e82b52326c9ea4027c69ec4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes CID1322337
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 929451c5cba5f05fa3511bc4cec2a8ebd4a41f5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The assignment had incorrectly placed parentheses which resulted in ret
always being > 0.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes CID1322328
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
