When async issues its inner seek via ffurl_seek, it treats failures as
EOF being reached. This is not consistent with the behavior of other
protocols (e.g. http, cache) which continue to tolerate reads after
failed seeks, and therefore does not interact correctly with them.
A common pattern where this manifests itself is where avio_seek is
called with pos to be the end-of-file - the http range-request would
fail here, and async would set io_eof_reached to 1. The background
thread would then refuse to read more bytes, and subsequent reads would
only empty the fifo and end in an error.
Presumably the code may have expected subsequent seeks to unset the
io_eof_reached but this is not guaranteed to be true - a subsequent seek
that lands in the AVIOContext's buffer (the fact that the
previously-failed avio_seek leaves the AVIOContext's buffer intact also
suggests that follow-up reads are expected to be tolerated) would not be
issued to the async_seek function, and when that buffer is drained only
async_read calls would follow, leading to the same error just described.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '8ad5124b7ecf7f727724e270a7b4bb8c7bcbf6a4':
movenc: Automatically flush after writing the initial moov
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Chapter-indexing can be expensive since chapters may be interspersed
throughout the entire file and may require many seeks - especially
costly when consuming a video over a remote protocol like http.
Furthermore it is often unnecessary, especially when only trying to get
video info (e.g. via ffprobe).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
In most other cases when writing fragmented mp4 files, the output
IO context is flushed after each fragment. Also flush it after
writing the initial moov, to have it behave in the same way.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'a0c71a575109f123978e345fa7eb4ac03cd4d3c3':
lavf: initialize cur_dts to AV_NOPTS_VALUE for muxing
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
cache protocol indexes its cache using AVTreeNodes which require a cmp
function for inserting and searching new cache-entries. This cmp
function expects a 32-bit int return value (negative, zero, or positive)
but the cache cmp function returns an int64_t which can overflow the
int, giving negative numbers for when it should be positive, vice versa.
This manifests itself only for very large files (e.g. 4GB+)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.
The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.
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>
This seems not to do anything any more since a long time, and removing
it avoids using uninitialized memory. Also change the error value
forwarding as done everywhere else.
Partly fixes: msan_uninit-mem_7fb7d24780d0_2744_R03T.CAK
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes an issue where an int64_t ffurl_seek return-value was being stored
in an int (32-bit) "r" variable, leading to integer overflow when seeking
into a large file (>2GB), and ultimately a "Failed to perform internal
seek" error mesage.
To test, try running `ffprobe 'cache:http://<something>'` on a file that
is ~3GB large, whose moov atom is at the end of the file
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
FFDIFFSIGN was created explicitly for this purpose, since the common
return a - b idiom is unsafe regarding overflow on signed integers. It
optimizes to branchless code on common compilers.
FFDIFFSIGN also has the subjective benefit of being easier to read due
to lack of ternary operators.
Tested with FATE.
Things not covered by this are unsigned integers, for which overflows
are well defined, and also places where overflow is clearly impossible,
e.g an instance where the a - b was being done on 24 bit values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
I've got some m4a samples that had jpeg cover art marked as png. Since
these files were supposedly written by iTunes, and other software can
read it (e.g. clementine does), this should be worked around.
Since png has a very simple to detect header, while it's apparently a
real pain to detect jpeg in the general case, try to detect png and
assume jpeg otherwise. Not bothering with bmp, as I have no test case.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some codecs use the codec_tag to signal specific information and
picking the first one would lead to a broken file.
Bug-Id: 883
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '00b62968d079e63bf22028f253ac297292436ebe':
os_support: Don't try to return the service name as a string in getnameinfo
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Bryan Huh
Michael Niedermayer
Hendrik Leppkes
Paul B Mahol
Andreas Cadhalpun
Martin Storsjö
Timothy Gu
Anton Khirnov
Michael Niedermayer
Sebastian Dröge
Ganesh Ajjanagadde
wm4
Luca Barbato
Derek Buitenhuis