The general demuxing API uses parsers and decoders. Therefore
FFStream contains pointers to AVCodecContexts and
AVCodecParserContext and lavf/internal.h includes lavc/avcodec.h.
Yet actually only a few files files really use these; and it is best
when this number stays small. Therefore this commit uses opaque
structs in lavf/internal.h for these contexts and stops including
avcodec.h.
This also avoids including lavc/codec_desc.h implicitly. All other
headers are implicitly included as now (mostly through codec.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska requires pts to be >= 0 with a slight exception:
It has a mechanism to deal with codec delay, i.e. with
the data added at the beginning that does not correspond
to actual input data and should be discarded by the player.
Only the audio actually intended to be output needs to have
a timestamp >= 0.
In order to avoid unnecessary timestamp shifting, this patch
allows muxers to inform the shifting code about this so that
it can take it into account.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The general demuxing API uses bitstream filters to extract extradata
and the muxing API uses them in order to transform packets into
the format desired by the target format. Therefore FFStream contains
pointers to AVBSFContexts and lavf/internal.h includes lavc/bsf.h.
Yet actually, only a few files files are supposed to use these,
namely avformat.c, demux.c and mux.c. For all the other files,
it should be an opaque type that they should not touch and that
they need not know anything about. This can be achieved by not
including these headers and using the structs instead of the
corresponding typedefs.
This also forces translation units that really use the BSF API
themselves to include lavc/bsf.h directly instead of relying on
indirect inclusions (a few other files also use the BSF API;
they already abided by this).
Of course, it also avoids unnecessary rebuilds when bsf.h changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by demuxers (and it is generally demuxers
who have to translate format-specific IDs to stream indices).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by demuxers (although it is hypothetically
possible that some day e.g. a protocol might need it, but
that is unlikely given that they don't deal with AVCodecParameters).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is demuxer-only: It potentially adds an AVStream and it sets
AVStream.attached_pic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is demuxer-only: Muxers deal only with chapters given to them;
they don't create any of their own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file is both for the various public APIs that are demuxer-only
as well as for the demuxer-only internal functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_get_packet_palette() and ff_reshuffle_raw_rgb() belong together:
E.g. the former takes the return value of the latter as argument.
So move ff_get_packet_palette() to rawutils.c (which consists solely
of ff_reshuffle_raw_rgb()).
Also add a separate header for these two functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by muxers. Given that it is not part of
the core muxing code and given that mux.c is already big enough,
it is moved to a new file for utility functions for muxing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is the appropriate place given that AVStream is about to
become an AVOpt-enabled struct.
Also move av_disposition_(to|from)_string, as these are tied
to the disposition stream option.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This search takes alot of time especially when compared with small packets
46631 decicycles -> 15719 decicycles in read_frame_internal() for amr-nb in 3gp
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
write_packet() has code to shift the packets timestamps
to make them nonnegative or even make them start at ts zero;
this code inspects every packet that is written and if a packet
with negative timestamp (whether this is dts or pts depends upon
another flag; basically: Matroska uses pts, everyone else dts)
is encountered, this is offset to make the timestamp zero.
All further packets will be offset accordingly (with the offset
converted according to the streams' timebases).
This is based around an assumption, namely that the timestamps
are indeed non-decreasing, so that the first packet with negative
timestamps is the first packet with timestamps. This assumption
is often fulfilled given that the default interleavement function
by default interleaves per dts; yet there are scenarios in which
it may not be fulfilled:
a) av_write_frame() instead of av_interleaved_write_frame() is used.
b) The audio_preload option is used.
c) When the timestamps that are made nonnegative/zero are pts
(i.e. with Matroska), because the packet with the smallest dts
is not necessarily the packet with the smallest pts.
d) Possibly with custom interleavement functions.
In these cases the relative sync of the first few packet(s) is offset
relative to the later packets. This contradicts the documentation
("When shifting is enabled, all output timestamps are shifted by
the same amount").
Therefore this commit changes this: As soon as the first packet
with valid timestamps is output, it is checked and recorded whether
the timestamps need to be shifted. Further packets are no longer
checked for needing to be offset; instead they are simply offset.
In the cases above this leads to packets with negative timestamps
(and the appropriate warnings) instead of desync. This will mostly
be fixed in the next commit.
This commit also factors handling the avoid_negative_ts stuff out
of write_packet() in order to be able to return immediately.
Tickets #4536 and #5784 as well as the matroska-avoid-negative-ts-test
are examples of c); as has been said, some timestamps are now negative,
yet the ref file update does not show it because ffmpeg.c sanitizes
the timestamps (-copyts disables it; ffprobe and mkvinfo also show
the original timestamps).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, we had a PacketList structure which is actually
a PacketListEntry; a proper PacketList did not exist
and all the related functions just passed pointers to pointers
to the head and tail elements around. All these pointers were
actually consecutive elements of their containing structs,
i.e. the users already treated them as if they were a struct.
So add a proper PacketList struct and rename the current PacketList
to PacketListEntry; also make the functions use this structure
instead of the pair of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Adds support for concat demuxer to copy the side data information
from the input file to the resulting file. It will behave like the
metadata copy, where the metadata of the first file is kept in the
the output file.
Extract the current code that already performs the stream side_data
copy into a separate method and reuse the method in the concat demuxer.
Signed-off-by: Gerard Sole <g.sole.ca@gmail.com>
Return error codes when constructing a stream config fails, rather than
just disregarding the failure and continuing.
Propagate the error codes from av_sdp_create().
Otherwise there is no way to detect an error returned by avio_close() because
ff_format_io_close cannot get the return value.
Checking the return value of the close function is important in order to check
if all data was successfully written and the underlying close() operation was
successful.
It can also be useful even for read mode because it can return any pending
AVIOContext error, so the user don't have to manually check AVIOContext->error.
In order to still support if the user overrides io_close, the generic code only
uses io_close2 if io_close is either NULL or the default io_close callback.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It avoids branches lateron and will allow to easily avoid the overhead
of the linked list currently in use in case there is only one stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Previously this was hardcoded to 2500000 bytes, so probing of the stream codecs
was always limited by this, and not probesize.
Also keep track of the actual size of packets in raw_packet_buffer and not the
remaining size for simplicity.
Fixes ticket #5860.
Signed-off-by: Marton Balint <cus@passwd.hu>
Currently the interleave_packet functions use a packet for
a new packet to be interleaved (may be NULL if there is none) and
a packet for output; said packet is always a stack packet in
interleaved_write_packet(). But all the interleave_packet functions
in use first move the packet to the packet list and then check whether
a packet can be returned, i.e. the effective lifetime of the new packet
ends before the packet for output is touched.
So one can use one packet both for input and output by adding a new
parameter that indicates whether there is a packet to add to the packet
list; there is just one complication: In case the muxer is flushed,
there is no packet available. This can be solved by reusing one of
the packets from AVFormatInternal. They are currently unused when
flushing in av_interleaved_write_frame().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavformat/utils.c has over 4800 lines and is supposed to contain
"various utility functions for use within FFmpeg". In reality it
contains all that and the whole demuxing core of libavformat.
This is especially bad, because said file includes the FFMPEG_VERSION
(the git commit sha) so that it is rebuilt whenever the commit HEAD
points to changes. Therefore this commit makes it smaller by moving
the demuxing code out to a new file, demux.c (in analogy to mux.c
for the muxing code).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavformat/utils.c has over 5500 lines and is supposed to contain
"various utility functions for use within FFmpeg". In reality it
contains all that and the whole demuxing+seeking core of libavformat.
This is especially bad, because said file includes the FFMPEG_VERSION
(the git commit sha) so that it is rebuilt whenever the commit HEAD
points to changes. Therefore this commit starts making it smaller
by factoring the seeking code out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVStream together with the data that is
currently in AVStreamInternal; or rather: Put AVStream at the
beginning of a new structure called FFStream (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVFormatContext together with the data that is
currently in AVFormatInternal; or rather: Put AVFormatContext at the
beginning of a new structure called FFFormatContext (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVFormatInternal altogether.
The biggest simplifications occured in avformat_alloc_context(), where
one can now simply call avformat_free_context() in case of errors.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, ff_write_chained() copied the packet (manually, not with
av_packet_move_ref()) from a packet given to it to a stack packet whose
timing and stream_index is then modified before being sent to another
muxer via av_(interleaved_)write_frame(). Afterwards it is intended to
sync the fields of the packet relevant to freeing again; yet this only
encompasses buf, side_data and side_data_elems and not the newly added
opaque_ref. The other fields are not synced so that the returned packet
can have a size > 0 and data != NULL despite its buf being NULL (this
always happens in the interleaved codepath; before commit
fe251f77c8 it could also happen in the
noninterleaved one). This leads to double-frees if the interleaved
codepath is used and opaque_ref is set.
This commit therefore changes this by directly reusing the packet
instead of a spare packet. Given that av_write_frame() does not
change the packet given to it, one only needs to restore the timing
information to return it as it was; for the interleaved codepath
it is not possible to do likewise*, because av_interleaved_write_frame()
takes ownership of the packets given to it and returns blank packets.
But precisely because of this users of the interleaved codepath
have no legitimate expectation that their packet will be returned
unchanged. In line with av_interleaved_write_frame() ff_write_chained()
therefore returns blank packets when using the interleaved codepath.
Making the only user of said codepath compatible with this was trivial.
*: Unless one wanted to create a full new reference.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 1c0885334d ff_compute_frame_duration
is only called from within utils.c and only for demuxers. So make it
static and remove the code in it that deals with muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It only uses an AVIOContext and an AVBPrint.
When doing so, it turned out that several non-users of
ff_read_line_to_bprint_overwrite() and ff_bprint_to_codecpar_extradata()
relied on libavformat/internal.h to include bprint.h or avstring.h
for them. In order to avoid a repeat of this and in order to reduce
unnecessary dependencies, a forward declaration of struct AVBPrint is
used instead of including bprint.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt
Pierre-Anthony Lemieux
Michael Niedermayer
Marton Balint
Gerard Sole
Anton Khirnov
Limin Wang