Add/fix spacing, split long lines, align assignments where suitable.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Split long comments, move long comments at the end of lines to
separate lines above, fix vertical alignment, fix up comment style
(unify trailing dots - comments had a mix of 2, 3 or 4 dots, where
it would be just as good without them at all).
Signed-off-by: Martin Storsjö <martin@martin.st>
It is worth keeping instead of removing, in case reading this
bit becomes necessary at some later point.
Signed-off-by: Martin Storsjö <martin@martin.st>
Skip to parse fields for additional independent substreams and its
associated dependent substreams since libavcodec's E-AC-3 decoder does not
support them yet.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
This fixes crashes, where the demuxer could return 0 even
if the returned AVPacket isn't initialized at all. This
could happen if running into EOF or running out of probesize
with non-seekable sources.
Signed-off-by: Martin Storsjö <martin@martin.st>
The new incremental parser doesn't always clear prev_pkt,
however the packet queue is cleared when seeking. Which leads
to a use-after-free.
Verified using Valgrind.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Reduces the amount of upfront data required for cluster parsing
thus decreasing latency on seek and startup.
The change in the seek-lavf_mkv FATE test is due to incremental
parsing no longer reading as much data as the old parser and
thus not having that additional data to generate index entries
based on keyframes. Index entries are added correctly as the
file is parsed.
All FATE tests pass and Chrome has been using this patch for ~6
months without issue.
Currently incremental parsing is not supported for files with
SSA tracks since they require merging packets between clusters.
In this case the code falls back to non-incremental parsing.
Signed-off-by: Aaron Colwell <acolwell@chromium.org>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The mpegts demuxer reads 5 KB at startup just for discovering
the packet size. Since the default avio buffer size is 32 KB,
the seek back to the start will in most cases be within the
avio buffer, and will in most cases succeed even if the actual
protocol isn't seekable.
This makes the demuxer startup faster/with less data when
reading data from a non-seekable input, by not skipping
the first few KB.
If it fails, don't warn if the protocol isn't seekable, making
it behave as before in the failure case.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix this warning:
libavformat/aviobuf.c:663:20: warning: assignment discards qualifiers from pointer target type
Although this is a public header, it should remain source and
binary compatible.
Signed-off-by: Mans Rullgard <mans@mansr.com>
If a video track specifies a zero frame rate (invalid but occurs),
this results in a division by zero and subsequent undefined conversion
to integer. Setting the default duration from the frame rate only
if the latter is greater than zero avoids such problems.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This option is the stream identifier to play or to publish.
Sometimes the URL parser cannot determine the correct
playpath automatically, so it must be given explicitly
using this option (ie. -rtmp_playpath).
Signed-off-by: Martin Storsjö <martin@martin.st>
This option is the name of application to connect on the RTMP server.
Sometimes the URL parser cannot determine the app name automatically,
so it must be given explicitly using this option (ie. -rtmp_app).
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead of allocating over the original, free first. MOVStreamContext
is zero initialized so no double free will occur. Same style as other
fixes for the same problem in this file.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
During error conditions matroska_parse_block may exit without
freeing the memory allocated for laces.
Found via valgrind: http://pastebin.com/E54k8QFU
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>