If cmd_pos is broken, this would just keep accumulating packets in the
reassembly buffer, until it fails and flushes the buffer on overflow.
Since packets are usually rather small, this will take a lot of subtitle
packets. The perceived effect is that subtitles are not displayed
anymore after the faulty packet was passed to the decoder.
I'm not terribly sure about this, but on the other hand this code is
active only when fragmented packets need to be reassembled.
Fixes sample file in trac issue #4872.
Assuming the first and second packets are partial, this would append the
reassembly buffer (ctx->buf) to itself with the second
append_to_cached_buf() call, because buf is set to ctx->buf.
I do not know a valid sample file which triggers this, and do not know
if packets can be split into more than 2 sub-packets, but it triggered
with a (differently) broken sample file in trac issue #4872.
Broken by commit ba12ba859a. This only
happens with HLS streams which use encryption and require preserving
cookies sent by the server.
Fixes trac issue #4846.
Some .idx files actually contain duplicate subtitle events:
timestamp: 00:07:52:600, filepos: 00004e800
timestamp: 00:07:52:600, filepos: 00004f800
The second will be dropped, because it has same pts, duration, and text
(the text is just a dummy empty string; the real data is retrieved when
actually reading vobsub subtitle packets).
Dropping this is probably not intended/safe, so avoid it.
See trac issue #4872 for a sample. This patch doesn't fix decoding of
the sample, though.
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>
This also drops setting the frame->pts field. This is usually not set by
decoders, so this would be an inconsistency that's at worst a danger to
the API user.
It appears the buffer->dts field is normally not set by the MMAL
decoder, so don't use it. If it's ever going to be set by MMAL, we
don't know whether the value will be what we want.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The generic code in utils.c sets the AVFrame.pkt_dts field from the
packet it was supposedly decoded. This does not have to be true for a
fully asynchronous decoder like mmaldec. It could be overwritten with an
incorrect value. Even if the decoder doesn't determine the DTS (but sets
it to AV_NOPTS_VALUE), it's impossible to determine a correct value in
utils.c.
Decoders can now be marked with FF_CODEC_CAP_SETS_PKT_DTS, in which case
utils.c won't overwrite the field. The decoders are expected to set this
field (even if they only set it to AV_NOPTS_VALUE).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This MMAL feature fills in missing timestamps from the framerate set on
the input port. This is generally unwanted, since libavcodec decoders
merely pass through timestamps without ever "fixing" them. The framerate
is also unknown, and even the timebase doesn't have to be set.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Don't try to do a blocking wait for MMAL output if we haven't even sent
a single real packet, but only flush packets. Obviously we can't expect
to get anything back.
Additionally, don't send a flush packet to MMAL in the same case. It
appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
(called from ffmmal_close_decoder()), waiting for a reply from the GPU
which never arrives. Either MMAL disallows sending flush packets without
preceding real data, or it's a MMAL bug.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
I can't come up with a nice way to handle this. It's hard to keep the
lock-stepped input/output in this case. You can't predict whether the
MMAL decoder will output a picture (because it's asynchronous), so
you have to assume in general that any packet could produce 0 or 1
frames. You can't continue to write input packets to the decoder,
because then you might get too many output frames, which you can't
get rid of because the lavc decoding API does not allow the decoder
to return an output frame without consuming an input frame (except
when flushing).
The ideal fix is a M:N decoding API (preferably asynchronous), which
would make this code potentially much cleaner. For now, this hack
will do.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Don't try to do a blocking wait for MMAL output if we haven't even sent
a single real packet, but only flush packets. Obviously we can't expect
to get anything back.
Additionally, don't send a flush packet to MMAL in the same case. It
appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
(called from ffmmal_close_decoder()), waiting for a reply from the GPU
which never arrives. Either MMAL disallows sending flush packets without
preceding real data, or it's a MMAL bug.
I can't come up with a nice way to handle this. It's hard to keep the
lock-stepped input/output in this case. You can't predict whether the
MMAL decoder will output a picture (because it's asynchronous), so
you have to assume in general that any packet could produce 0 or 1
frames. You can't continue to write input packets to the decoder,
because then you might get too many output frames, which you can't
get rid of because the lavc decoding API does not allow the decoder
to return an output frame without consuming an input frame (except
when flushing).
The ideal fix is a M:N decoding API (preferably asynchronous), which
would make this code potentially much cleaner. For now, this hack
will do.
At least the new videotoolbox decoder does not actually set a frame if
end_frame fails. This causes the API to return success and signals that
a picture was decoded, even though AVFrame->data[0] is NULL.
Fix this by propagating end_frame errors.
There can be other headers than "Content-Type:" (in this case, a
"Content-Length:" header was following), so checking for a trailing
newline is wrong.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This returns something like "v12_dev0-1332-g333a27c". This is much more
useful than the individual library versions, of which there are too
many, and which are very hard to map back to releases or git commits.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
This returns something like "N-73264-gb54ac84". This is much more useful
than the individual library versions, of which there are too much and
which are very hard to map back to releases or git commits.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The APIC description must be unique, and some ID3v2 tag writers add
spaces to write several APIC entries with the same description. The
trailing spaces simply serve as a way to disambiguate the description.
Do this so that API users do not have to special-case mp3 to fix this
cosmetic issue.
Requested-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Calling ffio_ensure_seekback() if ffio_init_checksum() has been called
on the same context can lead to out of bounds memory accesses and
crashes. The reason is that ffio_ensure_seekback() does not update
checksum_ptr after reallocating the buffer, resulting in a dangling
pointer.
This effectively fixes potential crashes when opening mp3 files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GNUTLS_SHUT_RDWR means GnuTLS will keep waiting for the server's
termination reply. But since we don't shutdown the TCP connection at
this point yet, GnuTLS will just keep skipping actual data from the
server, which basically is perceived as hang.
Use GNUTLS_SHUT_WR instead, which doesn't have this problem.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GNUTLS_SHUT_RDWR means GnuTLS will keep waiting for the server's
termination reply. But since we don't shutdown the TCP connection at
this point yet, GnuTLS will just keep skipping actual data from the
server, which basically is perceived as hang.
Use GNUTLS_SHUT_WR instead, which doesn't have this problem.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some files have SeekHead elements with broken IDs. They mismatch with
the ID of the destination element. These files are written by
"IDMmkvlib0.1" (as identified by the MuxingApp and WritingApp elements),
and the SeekHead IDs are actually endian-swapped.
This confuses the SeekHead logic of the demuxer. It will read some
elements twice, because the SeekHead ID is used to identify and remember
already read elements. With the file at hand, the stream list was
duplicated by reading the Tracks element twice.
Fix this by rejecting invalid EBML IDs in SeekHead entries. (This fix is
relatively specific to the broken file at hand, and doesn't protect
against some other cases of broken SeekHead, such as valid but
mismatching target element IDs.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
OSX does not know MSG_NOSIGNAL. BSD (which OSX is based on) has got
the socket option SO_NOSIGPIPE (even if modern BSDs also support
MSG_NOSIGNAL).
Signed-off-by: Martin Storsjö <martin@martin.st>
OSX does not know MSG_NOSIGNAL, and provides its own non-standard
mechanism instead. I guess Apple hates standards.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This was probably broken some time ago. The breakage is now part of the
ABI. For example, we have:
AV_PIX_FMT_XYZ12BE
AV_PIX_FMT_NV16
AV_PIX_FMT_NV20LE
AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian
format it should be even. This must have been quite obvious when these
formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but
nobody cared or knew about this.
The future libavutil major bump will also break this additionally,
because disabling FF_API_VDPAU will remove an odd number of entries from
the middle of the enum.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Otherwise it will never be reset, and remain "stuck" in this state
forever. Can happen when seeking: the decoder will receive fragments
from different file positions, which triggers the condition easily.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Move the OpenSSL and GnuTLS implementations to their own files. Other
than the connection code (including options) and some boilerplate, no
code is actually shared.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Apparently it can happen that a mp3 file has junk data between id3 tag
and actual mp3 data. Skip this to avoid outputting nonsense timestamps.
(Two packets had the same timestamps, because the mp3 parser failed to
compute a frame duration.)
In this case, the junk consisted of 1044 bytes of zero, which
incidentally is the same size as normal mp3 frames in this stream. I
suspect the mp3 was edited with some tool which wiped the Xing/LAME
headers. Data near the end of the file suggests it was encoded with
"LAME3.97", but the normal Xing/LAME headers are missing. So this could
be "normal". mpg123 also attempts to skip at least 64KB of junk data by
scanning for headers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Move the OpenSSL and GnuTLS implementations to their own files. Other
than the connection code (including options) and some boilerplate, no
code is actually shared.
Signed-off-by: Martin Storsjö <martin@martin.st>
Personally, I need the decoder to back out if get_format() returns no
usable pixel format. This didn't work because the error code was not
propagated down the call chain. This in turn happened because the
variable declaration removed in this patch shadowed the variable, whose
value is returned at the end of the function. Consequently, failures of
decode_nal_unit() were ignored in this place.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Personally, I need the decoder to back out if get_format() returns no
usable pixel format. This didn't work because the error code was not
propagated down the call chain. This in turn happened because the
variable declaration removed in this patch shadowed the variable, whose
value is returned at the end of the function. Consequently, failures of
decode_nal_unit() were ignored in this place.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
APIC tags always have a description. Tag writers obviously leave it
empty if there is no description. In this case, libavformat would export
"" as title. Do not set the title instead.
APIC tags always have a description. Tag writers obviously leave it
empty if there is no description. In this case, libavformat would export
"" as title. Do not set the title instead.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
AV_PIX_FMT_GRAY8/16 are considered YUV formats, and the color_range is
not set - so the API user will have to assume limitted range. (Unless
the API user adds a special-case for the PNG decoder.)
Just export the correct range - full range.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the file size is much larger than what is indicated in the XING
header, the demuxer assumes it's a concatenated file, and throws away
the (presumably) incorrect duration information. Unfortunately, this
also triggers if the id3 tags are very large (embedded pictures and
such). Then the half-baked heuristic not only breaks the duration
display, but also gapless audio.
Fix it by subtracting the size of the headers (the check is off by some
bytes, but that doesn't matter at all). Note that there could be an
arbitrary amount of tags _after_ the mp3 data, but hopefully these are
not too large to trigger the heuristic in practice.
Also add a warning when this happens.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While I'm not sure why exactly sure why the old code could end up in the
wrong position, using the generic index code is much simpler and is
known to work correctly.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These could be kept, but they are not overly useful. The only thing they
had over the remaining mp3 gapless test was seeking, which was incorrect
in the toc test, and only by chance correct in the notoc test.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It's the most useful mode, because it seeks accurately, and does not
break features like gapless audio.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
"-usetoc 2" now invokes the generic seek and indexing mode. This mode
skips data until the seek target is reached, and this is exact. It also
makes gapless audio actually work if a seek past the start of the file
is involved.
Change the fate-gapless-mp3 test to use the new mode, and move the old
one to fate-gapless-mp3-toc (since the test forces use of the Xing TOC).
The new mode has a different result for the seek - this result is
actually correct.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The mp2 seek test results change. Whether to skip samples if the file
had no LAME gapless tags was inconsistent. When seeking to the start
of the file, 529 samples were skipped, but when playing from start,
nothing was skipped. This commit changes the behavior on seek to skip
nothing.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Seeking to a negative time did not have the desired effect of seeking to
the next valid position (the file start). On the other hand, just
"-ss 0" will normally seek to a position higher than 0, because it adds
the start time of the file. (The start time is not 0 because the gapless
code skips a few samples from the start.)
Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do
what you'd expect it would do.
Also put the -ss option at the right place, before -i. This actually
makes it seek, instead of something completely else. The ".out-3" test
is no different in the -usetoc 0/1 cases, because the seeking is
inaccurate (in both cases).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Apparently, some live streams can delete segments too early, maybe
because the client is too far behind. In this case, it's better to skip
the segment, instead of returning EOF. (Yes, the HLS demuxer actually
returns AVERROR_EOF if opening the segment returns a 404 HTTP error.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Removing a bunch of questionable hacks makes it work. These hacks
apparently try to make concatenated mp3s with Lame headers seekable,
which doesn't make too much sense anyway. The main change is that we
trust the Xing header file size field now (the same field is used for
seeking with Xing TOC). Note that a mp3 might contain an unknown number
of unsupported additional tags, so we can't reliably compute this size
manually.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
They seem to sometimes trigger with old AVI files. They are just
confusing, do not help anyone, and use sloppy language.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This is optional, but ensures that linking with -Wl,--as-needed does not
drop the library containing the MMAL VC driver. The driver normally
"registers" itself in the library constructor, but since no symbols are
explicitly referenced, the linker could remove it with --as-needed
enabled.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
YCgCo decoding works just fine. It depends on the API user what is done
with the output. Some API users might support it, some not. Some users
might support it under certain circumstances only.
It is not the job of the decoder to print this message. If the API user
supports it, this message is extremely unhelpful.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
MicroDVD has a "hack" for specifying the video framerate the subtitle
was authored against. The demuxer reads this hint correctly, but didn't
skip it correctly.
This was not noticed, because the exported packet has its duration set
to 0, making it invisible (depending on the API user's rendering logic).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.
Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.
Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.
Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.
Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.
Fixes trac #4423.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Just because the user requested the seek index to be ignored, we can't
just skip essential headers. At least tags are often located at the end
of the file, and the old code simply ignored the seekhead for all
elements, not just the cue index. Also, it looks like it used the index
even if IGNIDX was set if the cue index was located in the beginning of
the file.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In particular, this reads chained seekheads. This makes seeking faster
in files which have the index indirectly linked through 2 seekheads.
As a side-effect, this warns when reading level-1 (toplevel) elements
multiple times (other than seekheads, clusters, and void/crc). Such
elements are not valid and likely break everything.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Doing this check in avutil_version() is not appropriate. Also, this code
is by default disabled (--assert-level is by default 0). A FATE run with
defaults will never execute the checks.
Move it to the pixelutils test program. Whatever reason there was in
avutil_version() not to run this test by default, it should be fine in
this test program. This means FATE will run the test by default. (Yes,
pixelutils is not strictly the best place for it either, but it's
better.)
(pixdesc.c also has a small test program, but it's never run by FATE.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Matroska is an extensible format - unknown elements must be expected. It
shouldn't complain about such elements to the user either; it'll just
generate noise. The "error_recognition & AV_EF_EXPLODE" is completely,
wrong why would it explode on valid files?
It's still useful for debugging, so the message is left in place with a
higher log level.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Nothing uses it, and it provides no public API.
Archeological finds:
Commit 101036adb9 added the API.
Commit a8dd8dc6e9 made mpegts.c use it.
Commit af8aae3fa3 disabled it by default in mpegts.c.
Commit ae2bb52cd2 removed all uses of this from mpegts.c.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
All the webm/vp9 files I have seen so far can have packets that contain
1 invisible and 1 visible frame. The vp9 parser separates them. Since
the invisible frame is always (?) the first sub-packet, the new packet
is assigned the PTS of the original packet, while the packet containing
the visible frame has no PTS.
This patch essentially reassigns the PTS from the invisible to the
visible frame.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This could overflow and crash at least on 32 bit systems.
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This can lead to an endless loop by seeking back a few bytes after each
attempted chunk read. Assuming negative sizes are always invalid, this
is easy to fix. Other code in this demuxer treats negative sizes as
invalid as well.
Fixes ticket #4262.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
av_add_index_entry() can fail, for example because the parameters are
invalid, or because memory allocation fails. Check this; it can actually
happen with corrupted files.
The second hunk is just for robustness. Just in case functions like
ff_reduce_index() remove entries. (Not sure if this can actually
happen.)
Fixes ticket #4294.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This leaked a frame on each avcodec_flush_buffers() call, if frame
threading was enabled. It caused severe memory usage in player if you
were seeking a lot.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If refdata was NULL, the memcpy() ended up copying the same memory
block onto itself, which is not only pointless, but also undefined
behavior.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With a certain fuzzed file, the parser will always return 0 consumed
bytes, which makes calling code call the parser infinitely. Return the
full packet size on error instead. (Here it would be nice if parsers
could return errors at all.)
Additionally, _if_ there's some data left, return that too, which might
help with somewhat broken but still somehow playable files.
Fixes ticket #4242.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
AVInputFormat.read_close is not called if AVInputFormat.read_header
fails, so this needs to be handled separately.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The parser must always set the out_size and out_data pointers. The API
seems to require it, and the common code in parser.c also relies on it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
dvdsub_decode() can call append_to_cached_buf() 2 times, the second time
with ctx->buf as argument. If the second append_to_cached_buf() reallocs
ctx->buf, the argument will be a pointer to the previous, freed block.
This can cause invalid reads at least with some fuzzed files - and
possibly with valid files.
Since packets can apparently not be larger than 64K (even if packets are
combined), just use a fixed size buffer. It will be allocated as part of
the DVDSubContext, and although some memory is "wasted", it's relatively
minimal by modern standards and should be acceptable.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
wm4
