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>
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>
Manual replacements are done in this commit.
In many cases, the id is some constant made up number (e.g. 0 for video
and 1 for audio), which is then not used in the demuxer for anything.
Those ids are removed.
This patch also introduces CODEC_ID_CELT.
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
this fixes accuracy with normal ogg files while keeping support for ogg files
starting at times different from 0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Specifically crafted samples can reinit ogg->streams[] while
reading samples, and thus we should not cache old pointers since
these may no longer be valid.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>