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>
This can "demux" .vpy files. Autodetection of .vpy scripts is
intentionally not done, because it would be a major security issue. You
need to force the format, for example with "-f vapoursynth" for the
FFmpeg CLI tools.
Some minor code copied from other LGPL parts of FFmpeg.
I did not find a good way to test a few of the more obscure VS features,
like VFR nodes, compat pixel formats, or nodes with dynamic size/format
changes. These can be easily implemented on demand.
There are use cases where average segment duration needs to be configured
and muxer is expected to maintain the average segment duration. So, using
the name 'min_seg_duration' will be misleading. So, changing the parameter
name to 'seg_duration', where it can be minimum segment duration or average
segment duration based on the use-case. The additional updates needed for
this functinality are made the sub-sequent patches of this patch series.
avcodec bump missed in 7e8eba2d87
avformat bump missed in ff46124b0d and
0694d87024
avdevice bump missed in 0fd475704e
Signed-off-by: James Almer <jamrial@gmail.com>
The "timeout" option name inherently clashes with the meaning of the
HTTP libavformat protocol option with the same name. Rename it after a
deprecation period to make it compatible with the HTTP one.
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.
Enables getting access to ID3 PRIV tags from the command-line or metadata API
when demuxing. The PRIV owner is stored as the metadata key prepended with
"id3v2_priv.", and the data is stored as the metadata value. As PRIV tags may
contain arbitrary data, non-printable characters, including NULL bytes, are
escaped as \xXX.
Similarly, any metadata tags that begin with "id3v2_priv." are inserted as ID3
PRIV tags into the output (assuming the format supports ID3). \xXX sequences in
the value are un-escaped to their byte value.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
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.
Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.
Unfortunately the OpenDML v1.02 document is not very specific on what
value to use for start_line when frame data is not coming from a
capturing device, so this is just using 0/1 depending on the field order
as a best-effort guess.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Print a warning to let applicatios fix their use.
After a deprecation period, check with a low-level assert.
Also make the constraint explicit in the doxygen comment.
Signed-off-by: Nicolas George <george@nsup.org>
The fields can be accessed directly, so these are not needed anymore.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.
Fix the issue by writing the "unknown" value (-1) for now until the
feature is implemented correctly.
Previous version reviewed-by: Peter Bubestinger <p.bubestinger@av-rd.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
* commit '07a2b155949eb267cdfc7805f42c7b3375f9c7c5':
Bump major versions of all libraries
A few API deprecated ~2 years ago or more are also postponed here for
varying reasons.
FF_API_LOWRES:
Since this functionality depends on AVStream->codec, i figure the two can
be removed at the same time in the next bump or so.
FF_API_AVCTX_TIMEBASE:
Couldn't get this one to work. Not just libavcodec but apparently also
libavformat and ffmpeg.c expect AVCodecContext->time_base to be set for
decoding. Upon removal some tests report a different generic stream time
base (like 1/25), and others lose packet duration values. I guess it's
somehow tied to the AVStream->codec clusterfuck.
It can be dealt with alongside FF_API_LAVF_AVCTX in the next bump.
FF_API_OLD_FILTER_OPTS_ERROR:
This one is meant to remain after FF_API_OLD_FILTER_OPTS is removed.
Its purpose is displaying the corrected command line using the new syntax
as a suggestion as part of the error message.
Merged-by: James Almer <jamrial@gmail.com>
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Merged from Libav commit 173b56218f.
