This feature is mostly only used by NLE software, and is
both of dubious value being enabled by default, and a
possible security risk.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This feature is mostly only used by NLE software, and is
both of dubious value being enabled by default, and a
possible security risk.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.
The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.
This commit introduces a parser for the current bitstream produced by
Daala. It currently bears a large similarity with Theora, another
codec produced by Xiph. While likely to change in the future, its basic
format of packet parsing should remain fairly identical with its current
structure.
Once the bitstream freezes, there are a few probable simplifications
that could be made. Also, the current version (major, minor and micro)
is stuck at zero so it's unusable as a way to warn about possible
incompatibilities. This will change once the bitstream freezes,
however until then this file is strictly targeting the current git
master of the reference encoder, libdaala.
This file was developed independently at the same time by both myself
and Vittorio Giovara, who used libav as a starting point. For fairness,
and to prevent confusion and allegations, his name has been added to the
copyright in the license header as well, and vice versa.
* commit '34ed5c2e4d9b7fe5c9b3aae2da5599fabb95c02e':
avformat: Do not use AVFMT_RAWPICTURE
Removal from ffmpeg.c not merged because some parts of avdevice
still use it
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4e649debcf7f71d35c6b38cdb7ee715eba95d64a':
Postpone API-incompatible changes until the next bump
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b08569a23948db107e5e6175cd4c695427d5339d':
lavf: Replace the ASF demuxer
Conflicts:
Changelog
libavformat/asf.h
libavformat/asfdec.c
libavformat/version.h
tests/ref/fate/wmv8-drm-nodec
tests/ref/seek/lavf-asf
The rewritten demuxer is placed in a new file, the current demuxer is
left as default. Carl has tested both and the one working better is
default.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The old one is the result of the reverse engineering and guesswork.
The new one has been written following the now-available specification.
This work is part of Outreach Program for Women Summer 2014 activities
for the Libav project.
The fate references had to be changed because the old demuxer truncates
the last frame in some cases, the new one handles it properly.
The seek-test reference is changed because seeking works differently
in the new demuxer. When seeking, the packet is not read from the stream
directly, but it is rather constructed by the demuxer. That is why
position is -1 now in the reference.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code is simply broken, the read packets are not aligned to
the mp3 frames, the file end or the id3 tag thus this simply
cannot reliably find the ID3v1 tag to remove it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for WebM Live Muxing by adding a new WebM
Chunk muxer. It writes out live WebM Chunks which can be used for
playback using Live DASH Clients.
Please see muxers.texi for sample usage.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a slightly different
position than if the file would have been read sequentially.
This makes implementing certain operations, such as segmenting,
quite hard, and slower than need be.
Therefore, add an option which retains the same packet sequence
after seeking, as when a file is demuxed linearly.
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a slightly different
position than if the file would have been read sequentially.
This makes implementing certain operations, such as segmenting,
quite hard, and slower than need be.
Therefore, add an option which retains the same packet sequence
after seeking, as when a file is demuxed linearly.
* commit '0af3b65880573aa9b3375362eaab4f84140c7dde':
asf: do not export XMP metadata by default
Conflicts:
libavformat/asfdec.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Similarly to what has been done for MOV, display XMP metadata only when
users explicitly require it.
The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of
edits and saves from the project file.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '847bf5988fec1d3e65c1d8cf0cdb8caf0cfd0c1b':
movenc: Add an option for delaying writing the moov with empty_moov
Conflicts:
libavformat/movenc.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.
This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.
For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since this structurally is quite different from normal RTP
(multiple streams are muxed into one single mpegts stream,
which is packetized into one single RTP session), it is kept
as a separate muxer.
Since this structurally also behaves differently than normal
RTP, all of the other muxers that do chained RTP muxing
(rtsp, sap, mp4) would need to be updated similarly to handle
this - in particular, creating one single rtp_mpegts muxer
for the whole presentation instead of one rtp muxer per stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.
As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was suggested by cbsrobot, ubitux and koda
There are files with huge amounts of XMP data, which would otherwise
be displayed in the terminal output of FFmpeg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b704b648f9ecb830874627db958a37e004107d1b':
mov: parse XMP metadata on demand
Conflicts:
libavformat/isom.h
libavformat/version.h
See: 054c506e3d
The default is left unchanged at enabled
We can change the default if people prefer but i do not want to do that
in a merge.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of edits
and saves from the project file. So display XMP metadata only when the
user explicitly requires it.
Based on a patch by Marek Fort <marek.fort@chyronhego.com>.
* commit 'e352b293712ff7cbde67eba3ce3f8510b037de09':
mov: Add an option for exporting all metadata
Conflicts:
libavformat/isom.h
libavformat/mov.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
ffmenc will store recommended encoder configuration if present.
This will allow the user to base on local defaults and
apply only explicitly set options.
If recommended encoder configuration is not present, then
non-default context's options are stored.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
* commit '2ded57371abead879bcee56da5131e5fac0d17ef':
movenc: Add support for writing sidx atoms for DASH segments
Conflicts:
Changelog
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is mostly to serve as a reference example on how to segment
the output from the mp4 muxer, capable of writing the segment
list in four different ways:
- SegmentTemplate with SegmentTimeline
- SegmentTemplate with implicit segments
- SegmentList with individual files
- SegmentList with one single file per track, and byte ranges
The muxer is able to serve live content (with optional windowing)
or create a static segmented MPD.
In advanced cases, users will probably want to do the segmenting
in their own application code.
Signed-off-by: Martin Storsjö <martin@martin.st>
A flag "dash" is added, which enables the necessary flags for
creating DASH compatible fragments.
When this is enabled, one sidx atom is written for each track
before every moof atom.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously we wrote decoding timestamps here, while the specs
say it should be presentation timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled manually, or can be enabled
in muxers which only need it in certain conditions.
Also allow using the same mechanism to force streams to start
at 0.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'cf589faa5b7aed3bb38e08dcd00bd951e69686d1':
movenc: Add a flag for using default-base-is-moof in tfhd atoms
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Similarly to the omit_tfhd_offset flag added in e7bf085b, this
avoids writing absolute byte positions to the file, making them
more easily streamable.
This is a new feature from 14496-12:2012, so application support
isn't necessarily too widespread yet (support for it in libav was
added in 20f95f21f in July 2014).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '7ae9791b641d1183910b6e7faca23f7ae08f8579':
avformat: bump version after mime_type change
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The -hls_allow_cache parameter enables explicitly setting the
EXT-X-ALLOW-CACHE tag in the manifest file. That tag indicates
whether the client MAY or MUST NOT cache downloaded media
segments for later replay.
Valid values are 1 (=YES) or 0 (=NO) and the EXT-X-ALLOW-CACHE
will not show in the manifest for other values (or if
-hls_allow_cache is not used.
Signed-off-by: Martin Storsjö <martin@martin.st>
After this the order from the original file is stored through readorder
when doing ffmpeg -i input.ass -c copy output.mkv.
And now that the ASS muxer honors the ReadOrder, extracting the ass back
(without transcoding) restores the original order.
* commit 'b263f8ffe7599d9cd27ec477a12700da8eb2790d':
lavf: add AVFormatContext.max_ts_probe
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/utils.c
libavformat/version.h
lavf-fate/mp3 changes as the estimated input bitrate changes and that is
copied to the output
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '051aadeed104ecbe8ee4850ec2d7e5394f5e1ccd':
ogg: Provide aliases for Speex, Opus and audio-only ogg
Conflicts:
Changelog
libavformat/oggenc.c
libavformat/version.h
See: 2ccc6ff03a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'afbd4b7e093adf6d7a830b32759ca3ba8500363d':
lavf: add AVFormatContext/AVStream fields for signaling to the user when events happen.
Conflicts:
libavformat/avformat.h
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The only flags, for now, indicate if metadata was updated and are set after each call to
av_read_frame(). This comes with the caveat that, on stream start, it might not be set properly
as packets might be buffered in AVFormatContext.packet_buffer before being given to the user
in av_read_frame().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'f4c444e17d137c786f0ed2da0e5943df505d5f9e':
Postpone API-incompatible changes until the next bump.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It's a public function and should use the avio_ namespace
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The were wrongly being exported and used by libavdevice
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3a19405d574a467c68b48e4b824c76617fd59de0':
avformat: Use the mime type information in input probe
Conflicts:
libavformat/format.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds the ability to generate WebM DASH manifest XML using
ffmpeg. A sample command line would be as follows:
ffmpeg \
-f webm_dash_manifest -i video1.webm \
-f webm_dash_manifest -i video2.webm \
-f webm_dash_manifest -i audio1.webm \
-f webm_dash_manifest -i audio2.webm \
-map 0 -map 1 -map 2 -map 3 \
-c copy \
-f webm_dash_manifest \
-adaptation_sets “id=0,streams=0,1 id=1,streams=2,3” \
manifest.xml
It works by exporting necessary fields as metadata tags in matroskadec
and use those values to write the appropriate XML fields as per the WebM
DASH Specification [1]. Some ideas are adopted from webm-tools project
[2].
[1]
https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/webm-dash-specification
[2]
https://chromium.googlesource.com/webm/webm-tools/+/master/webm_dash_manifest/
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The AVStream.parser field is considered private and its location cannot be
preserved while preserving also ABI compatibility to libav, as libav added fields
before it.
Some tools like ffmpeg.c access this field though
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '194be1f43ea391eb986732707435176e579265aa':
lavf: switch to AVStream.time_base as the hint for the muxer timebase
Conflicts:
doc/APIchanges
libavformat/filmstripenc.c
libavformat/movenc.c
libavformat/mxfenc.c
libavformat/oggenc.c
libavformat/swf.h
libavformat/version.h
tests/ref/lavf/mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
* commit '95b7fa1729b93bbb3f4fb85a5c0cb53cf970c3c7':
oggenc: Support flushing the muxer
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This allows the caller to write all buffered data to disk, allowing
the caller to know at what byte position in the file a certain
packet starts (any packet written after the flush will be located
after that byte position).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '6d212599aa684f30511fb08ca30fe2378405304e':
avformat: Provide a standard compliance flag
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
