Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
This struct is for internal use of avformat_find_stream_info(), so it
should not be exposed in public headers. Keep a stub pointer in its
place to avoid changing AVStream layout, since e.g. ffmpeg.c accesses
some fields located after it (even though they are marked as private).
And replace the flags parameter with a function callback that can be used to
copy the contents of the packet (e.g, av_packet_ref and av_packet_copy_props).
Signed-off-by: James Almer <jamrial@gmail.com>
Document that it also sets the size in case the desired side data is
absent (if the pointer has been supplied).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
AVStream.request_probe as well as AVStream.mux_ts_offset are below the
separator of public and private fields, so that a further "NOT PART OF
PUBLIC API" is redundant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet(); it is of course nonsense and
has been replaced by an accurate description.
2. The description of av_write_uncoded_frame() suggested
av_interleaved_write_frame() as a replacement if the input is not
already correctly interleaved; it also referred to said function for
details. Given that said function can't write AVFrames and that the
specifics of writing uncoded frames are explained in the description
of av_interleaved_write_uncoded_frame(), both references have been fixed.
3. Removed an outdated comment about avformat_seek_file().
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit updates the documentation of av_read_frame() to match its
actual behaviour in several ways:
1. On success, av_read_frame() always returns refcounted packets.
2. It can handle uninitialized packets.
3. On error, it always returns blank packets.
This will allow callers to not initialize or unref unnecessarily.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since bae8844e35, the packet is automatically unreferenced in
ff_read_packet() when an error is returned; but the documentation of
this of AVInputFormat.read_packet has not been updated accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allows user to set maximum number of buffered packets when
probing a codec. It was a hard-coded parameter before this commit.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVFMT_NOTIMESTAMPS may be using in AVInputFormat.flags for demuxing
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
A generic lavf flag for AAC LATM packetization for the RTP muxer was
added in ef409645f0 and then made inert 20 days later in 0832122880
when a private muxer option was added and the generic flag no longer
read.
These fields will allow the mpegts demuxer to expose details about
the PMT/program which created the AVProgram and its AVStreams.
In mpegts, a PMT which advertises streams has a version number
which can be incremented at any time. When the version changes,
the pids which correspond to each of it's streams can also change.
Since ffmpeg creates a new AVStream per pid by default, an API user
needs the ability to (a) detect when the PMT changed, and (b) tell
which AVStream were added to replace earlier streams.
This has been a long-standing issue with ffmpeg's handling of mpegts
streams with PMT changes, and I found two related patches in the wild
that attempt to solve the same problem:
The first is in MythTV's ffmpeg fork, where they added a
void (*streams_changed)(void*); to AVFormatContext and call it from
their fork of the mpegts demuxer whenever the PMT changes.
The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html,
where they created a new AVMEDIA_TYPE_DATA stream with id=0 and
attempted to send packets to it whenever the PMT changed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Parses the video_stream_descriptor (H.222 2.6.2) to look
for the still_picture_flag. This is exposed to the user
via a new AV_DISPOSITION_STILL_IMAGE.
See for example https://tmm1.s3.amazonaws.com/music-choice.ts,
whose video stream only updates every ~6 seconds.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For seekable mpegts streams, duration is calculated from
pts by seeking to the end of the file for a pts and subtracting
the initial pts to compute a duration.
This can be expensive in terms of added latency during
probe, especially when streaming over a network. This new
option lets you skip the duration calculation, which is useful
when you don't care about the value and want to save some overhead.
This patch is particularly useful when dealing with live mpegts
streams. Normally such streams are not seekable, so durations
are not calculated. However in my case I am dealing with a seekable
live mpegts stream (networked access to a .ts file which is still
being appended to).
Signed-off-by: Aman Gupta <aman@tmm1.net>
This will replace the 1024 character limited filename field. Compatiblity for
output contexts are provided by copying filename field to URL if URL is unset
and by providing an internal function for muxers to set both url and filename
at once.
Signed-off-by: Marton Balint <cus@passwd.hu>
The seek function can just return an error if seeking is unavailable,
but often this is too late. Add a flag that signals that the stream is
unseekable, and use it in HLS.
It was sort of optional before - if you didn't call it, networking was
initialized on demand, and an ugly warning was logged. Also, the doxygen
comments threatened that it would be made strictly required one day.
Make it explicitly optional. I would prefer to deprecate it fully, but
there might still be legitimate reasons to use this. But the average
user won't need it.
This is needed only for two reasons: to initialize TLS libraries like
OpenSSL and GnuTLS, and winsock.
OpenSSL and GnuTLS were already silently initialized on demand if the
global network init function was not called. They also have various
thread-safety acrobatics, which make concurrent initialization within
libavformat safe. In addition, the libraries are moving towards making
their global init functions safe, which removes all need for central
global init. In particular, GnuTLS 3.5.16 and OpenSSL 1.1.0g have been
found to have safe init functions. In all cases, they use internal
reference counters to avoid that the global uninit functions interfere
with concurrent uses of the library by other API users who called global
init.
winsock should be thread-safe as well, and maintains an internal
reference counter as well.
Since we still support ancient TLS libraries, which do not have this
fixed, and since it's unknown whether winsock and GnuTLS
reinitialization is costly in any way, don't deprecate the libavformat
functions yet.
Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.
Signed-off-by: James Almer <jamrial@gmail.com>
Anton Khirnov
James Almer
Andreas Rheinhardt
Andriy Gelman
Jun Zhao
Steven Liu
Carl Eugen Hoyos
Gyan Doshi
Aman Gupta
Josh de Kock
Marton Balint
wm4
Michael Niedermayer