If this flag is set, the protocol can handle URLs where the
scheme is a nested scheme such as applehttp+file: - the protocol
can handle any URL where the first segment of the nested scheme
belongs to this protocol.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 8f73c06077)
when writing and pressing q during encoding. Instead, check url_interrupt_cb
at the end.
Note that when a protocol is interrupted by url_interrupt_cb, some data may
be silently discarded: the protocol context is not suitable for anything
anymore.
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This is a substitute for the url_fskip function that was deprecated by
commit 0300db8ad7. avio_fskip is provided to
improve demuxer code readability. It distinguishes the act of skipping over
unknown or irrelevant bytes from the standard avio_seek operation.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
If this flag is set, the protocol can handle URLs where the
scheme is a nested scheme such as applehttp+file: - the protocol
can handle any URL where the first segment of the nested scheme
belongs to this protocol.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This removes a fixme issue, by allowing the av_pkt_dump functions
to use the correct time base.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 863c471638)
In most cases, s->buf_ptr will be equal to s->buf_end when
fill_buffer is called, but this may not always be the case, if
we're seeking forward by reading (permitted by the short seek
threshold).
If fill_buffer is writing to s->buf_ptr instead of s->buf_end (when
they aren't equal and s->buf_ptr is ahead of s->buffer), the data
between s->buf_ptr and s->buf_end is overwritten, leading to
inconsistent buffer content. This could return incorrect data if
later seeking back into the area before the current s->buf_ptr.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit e360ada2d1)
In most cases, s->buf_ptr will be equal to s->buf_end when
fill_buffer is called, but this may not always be the case, if
we're seeking forward by reading (permitted by the short seek
threshold).
If fill_buffer is writing to s->buf_ptr instead of s->buf_end (when
they aren't equal and s->buf_ptr is ahead of s->buffer), the data
between s->buf_ptr and s->buf_end is overwritten, leading to
inconsistent buffer content. This could return incorrect data if
later seeking back into the area before the current s->buf_ptr.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Martin Storsjö
Carl Eugen Hoyos
Anton Khirnov
Anssi Hannula
Baptiste Coudurier
Hendrik Leppkes
Peter Ross
Michael Niedermayer
Reimar Döffinger
Ronald S. Bultje