This prevents inconsistencies leading to out of array accesses.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd1f05dd18375f2f8e68372edee11436927e43ba8':
ogg: calculate the start position once all the headers are parsed
Conflicts:
libavformat/oggdec.c
libavformat/oggparseskeleton.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7751e4693dd10ec98c20fbd9887233b575034272':
ogg: check that the expected number of headers had been parsed
libx264: change default to closed gop to match x264cli
Use avcodec_free_frame() to free AVFrames.
lavf: use a malloced AVFrame in try_decode_frame().
lavc: add avcodec_free_frame().
lavc: ensure extended_data is set properly on decoding
lavc: initialize AVFrame.extended_data in avcodec_get_frame_defaults()
lavc: use av_mallocz to allocate AVFrames.
lavc: rename the argument of avcodec_alloc_frame/get_frame_defaults
Conflicts:
doc/APIchanges
doc/examples/decoding_encoding.c
libavcodec/utils.c
libavcodec/version.h
libavfilter/src_movie.c
libavformat/oggdec.c
libavformat/oggdec.h
libavformat/oggparsetheora.c
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fix Ticket #1617, revealing a regression I introduced in 8f3eebd.
We need to make sure no stream is added in between Ogg context save and
restore operations (because it would likely lead to a mismatch between
ogg->nstreams and AVFormatContext->nb_streams after the restore op).
This is the reason the ogg->state check is added in ogg_new_stream().
Before this patch, checking for ogg->headers was preventing this:
ogg->headers is always set before any ogg save/restore (though, it was
also preventing from creating the stream when necessary).
The previous method of having to initialize it outside lead
to incorrect code: even if it was initialized, it usually was
only initialized once, thus a packet that could not be matched
to any stream would just be processed with the return values
from the previous call.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also slightly more correct behaviour in case streams_left for
some reason is 0 from the start.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fixes crash based on a uninitialized array index read.
If the read does not crash then out of array writes based
on the same index might have been triggered afterwards.
Found-by: inferno@chromium.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Other cases are not supported and lead to inconsistencies which
can lead to out of array writes.
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The ogg decoder wasn't padding the input buffer with the appropriate
FF_INPUT_BUFFER_PADDING_SIZE bytes. Which led to uninitialized reads in
various pieces of parsing code when they thought they had more data than
they actually did.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
A lot of files do not mark keyframes correctly via
granule, so detect keyframe or not based on data
and complain if it mismatches.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It would never be called when the searched-for position
was already in the index.
In the other cases, the ogg_reset at the end of the
read_timestamp function handled it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
In this case, the pts values will be delayed by one, but
at the same time pts values might only be supplied for e.g.
keyframes.
This results on only the frame after the keyframe having a
pts value.
As a hack, make read_timestamp return the keyframe position
together with the pts from a following frame when seeking
to a keyframe.
Fixes trac issue #438.
However it causes the read_timestamp function to return a
pos value that is actually before the packet with the
indicated pts.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fixes trac issue #438.
Seeking in that sample would cause ogg_read_timestamp to fail
because ogg_packet would go into a state where all packets
of stream 1 would be discarded until the end of the stream.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* qatar/master:
mov: Don't av_malloc(0).
avconv: only allocate 1 AVFrame per input stream
avconv: fix memleaks due to not freeing the AVFrame for audio
h264-fate: remove -strict 1 except where necessary (mr4/5-tandberg).
misc Doxygen markup improvements
doxygen: eliminate Qt-style doxygen syntax
g722: Add a regression test for muxing/demuxing in wav
g722: Change bits per sample to 4
g722dec: Signal skipping the lower bits via AVOptions instead of bits_per_coded_sample
api-example: update to use avcodec_decode_audio4()
avplay: use avcodec_decode_audio4()
avplay: use a separate buffer for playing silence
avformat: use avcodec_decode_audio4() in avformat_find_stream_info()
avconv: use avcodec_decode_audio4() instead of avcodec_decode_audio3()
mov: Allow empty stts atom.
doc: document preferred Doxygen syntax and make patcheck detect it
Conflicts:
avconv.c
ffplay.c
libavcodec/mlpdec.c
libavcodec/version.h
libavformat/mov.c
tests/codec-regression.sh
tests/fate/h264.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
