made with persistent connections to prevent incorrect reset of
offset when demuxing HLS+FMP4
Signed-off-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: vectronic <hello.vectronic@gmail.com>
add ff_http_do_new_request2() which supports options to be applied to
HTTPContext after initialisation with the new uri
Signed-off-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: vectronic <hello.vectronic@gmail.com>
Put an AVIOContext whose lifetime doesn't extend beyond the function
where it is allocated on the stack instead of allocating and freeing it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Put an AVIOContext whose lifetime doesn't extend beyond the function where
it is allocated on the stack instead of allocating and freeing it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The structure of a ProRes frame in mov/mp4 is that of a typical atom:
First a 32 bit BE size field, then a tag detailling the content. Said
size field includes the eight bytes of the atom header.
This header is actually redundant, as the size of the atom is already
known from the containing atom. It is therefore stripped away when muxed
into Matroska and so the Matroska demuxer has to recreate upon demuxing.
But it did not account for the fact that the size field includes the
size of the header and this can lead to problems when a decoder uses the
in-band size field.
Fixes ticket #8210.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The check "if (!pb->seekable & AVIO_SEEKABLE_NORMAL)" is wrong, because
! has higher precendence than &. But it is also redundant, because this
part of the code is only ever reached when the AVIO_SEEKABLE_NORMAL flag
is set for pb. So simply remove the check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, aiffenc didn't rely on the standard functions for adding
an element to a linked list and freeing the list, but instead
reimplemented them. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Assertion failure
Fixes: 17770/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5700606668308480
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
add new function duration_estimate_name to dump duration estimate
method, it's will help to debug some duration issue.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add logging context to log, it's will help debuging.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
change the log level to warning if can't get duration, it's will help
to debug some duration issue
Signed-off-by: vacingfang <vacingfang@tencent.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Up until now, read_frame_internal always initialized the packet it
received. But since the recent changes to ff_read_packet, this is no
longer needed: If the parsing queue is initially empty upon entering
read_frame_internal, the packet will now either contain content upon
success or be blank upon failure of ff_read_packet. If the parsing
queue is initially not empty, the packet will be overwritten with the
oldest one from the parsing queue.
Similarly, it is unnecessary to initialize ret in read_frame_internal.
In parse_packet, it is easily possible to only initialize the packet
used as temporary storage for the output if said packet is used at all;
furthermore, this packet doesn't need to be zero-initialized, because
av_init_packet will initialize every field except size and data and
those fields will be set by av_parser_parse2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, parse_packet() used a stack packet in case the stream is
flushed. But using such a packet is unnecessary as there is an AVPacket
readily available, it just needs to be used. Whether flushing is intended
or not will now be signalled by an explicit parameter rather than by
whether the packet parameter is NULL. This removes a few checks in
parse_packet(), gets rid of the initialization of the stack packet and
also reduces usage of sizeof(AVPacket) in libavformat.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of the spare packet (that at this point contains a freshly read packet)
is simply copied into the output packet (via simple assignment, not
av_packet_move_ref, thereby confusing ownership).
2. If the packet needs parsing, the spare packet will be reset after
parsing and any packets resulting from the packet read will be put into
a packet list; the output packet is not used here at all.
3. If the stream should be discarded, the spare packet will be
unreferenced; the output packet is not used here at all either.
Therefore the spare packet and the copies can be removed in principle.
In practice, one more thing needs to be taken care of: If ff_read_packet
failed, the output packet was not affected, now it is. But given that
ff_read_packet returns a blank (as if reset via av_packet_unref) packet
on failure, there is no problem from this side either.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When AVFMT_FLAG_GENPTS is set, av_read_frame would put a reference to a
packet in the packet list (via av_packet_ref) and then immediately
thereafter unreference the original packet. This has been changed to
move the reference instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, avformat_find_stream_info had a potential for memleaks:
When everything was fine, it read packets and (depending upon whether
AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
them when they were no longer needed. But upon failure, said packets
would leak if they were not already on the packet list. This patch fixes
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since the recent changes to ff_packet_list_put, the source packet will
be automatically reset when the reference is moved to the packet list,
so that it is unnecessary to reinitialize the packet in the loops in
parse_packet and ff_read_packet; initializing once at the beginning is
enough.
This also fixes a potential, but currently unexisting problem: If the
raw packet buffer was initially not empty and probe_codec() failed,
then the packet returned would not be initialized. But given that
probe_codec() currently can't fail (always returns 0) this was not an
acute danger.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is done so that its data is really owned by the packet.
This was already true for the current callers.
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been done because some callers of this function were not
compatible with resetting the packet.
This commit changes these callers and fixes this flaw. In order to
indicate that the ownership of the packet has moved to the packet list,
pointers to constant AVPackets are used whenever the target of the
pointer might already be owned by the packet list.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ff_read_packet had potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If putting a packet on a packet list fails, it wasn't unreferenced.
Furthermore, read_frame_internal leaked a packet's (side) data if a
context update was required and failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
There is currently an ordinary check for this (which would lead to a
memleak), but given that no demuxer should ever return a packet with an
invalid stream_index it is more appropriate for this to be an assert.
FATE passes with this change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Andreas Rheinhardt
vectronic
Limin Wang
Steven Liu
Michael Niedermayer
James Almer
Paul B Mahol
Carl Eugen Hoyos
Jun Zhao
Ross Nicholson
Jun Li