The version 1 needs the channel count and would divide by 0
Fixes: division by 0
Fixes: fpe_movenc.c_1108_1.ogg
Fixes: fpe_movenc.c_1108_2.ogg
Fixes: fpe_movenc.c_1108_3.wav
Found-by: #CHEN HONGXU# <HCHEN017@e.ntu.edu.sg>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: ffmpeg_crash_8.avi
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: ffmpeg_bof_1.avi
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
da9cc22d5b allowed the MOV muxer to relay a custom stream handler name,
whether populated from the input stream or user-set. However, the entry
key didn't match the key set by the MOV demuxer, so it wasn't
effective. Fixed.
Due to the change, four FATE refs have to be updated. Verified that the
target payload of the tests hasn't changed in terms of CRC.
For chapter images, the mov demux produces streams with disposition set
to attached_pic+timed_thumbnails. This patch fixes to properly recognize
streams that should be encoded as cover image (ones with only and only
attached_pic disposition set).
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Find codec tag for attached images using appropriate list of
supported image formats.
This fixes writing the cover image to m4v/m4a and other container
formats that do not allow these codecs as a track.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The producer reference time box supplies relative wall-clock times
at which movie fragments, or files containing movie fragments
(such as segments) were produced.
The box is mainly useful in live streaming use cases. A media player
can parse the box and utilize the time fields to measure and improve
the latency during real time playout.
Fixes https://trac.ffmpeg.org/ticket/2798
This makes movenc handle AV_DISPOSITION_ATTACHED_PIC and write
the associated pictures in iTunes cover atom. This corresponds
to how 'mov' demuxer parses and exposes the cover images when
reading.
Most of the existing track handling loops properly ignore
these 'virtual streams' as MOVTrack->entry is never incremented
for them. However, additional tests are added as needed to ignore
them.
Tested to produce valid output with:
ffmpeg -i movie.mp4 -i thumb.jpg -disposition✌️1 attached_pic \
-map 0 -map 1 -c copy movie-with-cover.mp4
The cover image is also copied correctly with:
ffmpeg -i movie-with-cover.mp4 -map 0 -c copy out.mp4
AtomicParseley says that the attached_pic stream is properly
not visible in the main tracks of the file.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
This prevents creating potentially broken files, as both the AV1 and
the AV1 in ISOMBFF specs are unfinished.
Signed-off-by: James Almer <jamrial@gmail.com>
Support for writing copyright metadata was added in commit bed4fc54c9
for 3GP, MOV and iTunes metadata. 3GP and MOV cases are formally
specified. However, iTunes format does not have specification, and
it seems to have been assumed that it would use the same atom as
MOV (both being Apple formats).
However, Apple uses 'cprt' atom for iTunes metadata (do note that
the iTunes 'cprt' encoding is generic iTunes ItemList atom, not
the 3GP 'cprt' encoding. These are also inside different parent
atoms).
Most references trying to document iTunes atoms mention only
the 'cprt' tag. See:
- http://atomicparsley.sourceforge.net/mpeg-4files.html
- http://mutagen.readthedocs.io/en/latest/api/mp4.html
Same applies to other software supporting this tag. Most of them
encode and decode only the 'cprt' atom.
ffmpeg mov demuxer supports both atoms in this context. There are
few pieces of other software that support similarly both 'cprt' and
the incorrect '\251cpy' atom in this context. I believe they do it in
order to read the ffmpeg encoded incorrect copyright atom.
In light of the above this changes the copyright atom to 'cprt' as
it seems to be supported univerally and is the correct atom to use.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is shared test and this simplifies code a bit. Follow up
commit will have additional tests for this function.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Demuxing only. Muxing is disabled as altref frame handling is not
defined in the spec, and there's no way to know the presence of
such frames during stream initialization.
Based on a patch by Steven Liu.
Fixes ticket #7000
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
With FCPX 10.4, Apple has expanded the set of colorspace, primaries,
and trc flags officially supported in QuickTime files. The expanded set
matches the codepoints used in ffmpeg and many other specs.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The avc3 sample entry type is useful for adaptive streaming. It permits
parameter sets to be written inline in the video stream.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes sizeof(AC3HeaderInfo) from the ABI.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
m4b is commonly used as extension for m4a audiobook files.
The format is exactly the same. The only thing that differs
is the extension.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '50a1c66cf6ab7eb683daaa9e2da3869fa3a54609':
ac3_parser: add a public function for parsing the data required by the demuxer
avpriv_ac3_parse_header() is left in place but without the
GetBitContext parameter, as the mov muxer requires a lot more fields
than just bitstream_id and frame_size from the AC3HeaderInfo struct.
Merged-by: James Almer <jamrial@gmail.com>
This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.
I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).
This eases conformance with the DASH-IF interoperability guidelines.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If AVCodecParameters.codec_tag is 'hvc1' use it instead of 'hev1' for
h.265 streams. QuickTime (and other Apple software) requires 'hvc1'.
(cherry picked from commit 84ab1cc437)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
mux.c init_muxer() already sets codec_tag correctly in the cases
simplified here.
This also adds the capability to support alternative tags for the
same codec_id.
(cherry picked from commit f6f86f432f)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
ff_mp4_obj_type contains the wrong type of tags for
AVOutputFormat.codec_tag. AVOutputFormat.codec_tag is used to
validate AVCodecParameters.codec_tag so needs to be the same
type of tag.
Creates new tag lists for mp4 and ismv. New tag lists support
same list of codecs found in ff_mp4_obj_type. psp uses the same
tag list as mp4 since these both use mp4_get_codec_tag to look up tags.
(cherry picked from commit 713efb2c0d)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
instead of deciding whether to encrypt based on the encryption scheme,
decide according to whether cenc was initialized or not.
mov_create_timecode_track calls ff_mov_write_packet with a track that
doesn't have cenc initialized.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't just look at zero sized packets, and also check for AAC extradata
updates, in preparation for the following patches.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This brings our generation of the vpcC box up to date to version 1.0
of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
find_fps attempts to infer framerate from AVCodec's timebase. When this
results in a frame rate that isn't explicitly marked as supported in
av_timecode_check_frame_rate, find_fps returns the AVStream's
avg_frame_rate, which, per avformat.h, _may_ be set (or not).
mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and
find_compressor attempt to call av_q2d on the return value of find_fps,
which in the above case, may result in division by zero and therefore,
an undefined frame rate when NaN is converted to int.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Based on the draft spec at http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
'-strict -2' is required to create files in this format.
Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track with the same attributes
differs from another one.
Reviewed-by: Martin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Based on the draft spec at https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
'-strict experimental' is required to create files in this format.
Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes division by 0
This is similar to how avg_frame_rate is checked elsewhere
Fixes: 6d24add0455f41b1b45b7ba615cd46f3/asan_generic_dc34c3_5480_0a2ef411cae999b9871ed71a2e481b71.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '4f7723cb3b913c577842a5bb088c804ddacac8df':
movenc: Add an option for skipping writing the mfra/tfra/mfro trailer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '785c25443b56adb6dbbb78d68cccbd9bd4a42e05':
movenc: Apply offsets on timestamps when peeking into interleaving queues
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Using the stream timebase simply overflows
Fix integer overflow in psp framerate computation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is supposed to be a flag. The only currently defined value is
AVIO_SEEKABLE_NORMAL, but other ones may be added in the future.
However all the current lavf code treats this field as a bool (mainly
for historical reasons).
Change all those cases to properly check for AVIO_SEEKABLE_NORMAL.
Streaming servers appear to ignore all other language metadata.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>
This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sometimes it's useful to be able to define the exact track numbers in
the generated track, instead of always beginning at track id 1. Using
the option use_stream_ids_as_track_ids now copies the use stream ids
to track ids. Dynamically generated tracks (ie. tmcd) have their track
numbers defined as continuing from the highest numbered stream id.
Signed-off-by: Erkki Seppälä <erkki.seppala.ext@nokia.com>
Signed-off-by: OZOPlayer <OZOPL@nokia.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's a small and simple function that can be inlined.
This removes one private symbol and should reduce object dependencies with the next
major bump
Signed-off-by: James Almer <jamrial@gmail.com>
When writing a fragmented file, we by default write an index pointing
to all the fragments at the end of the file. This causes constantly
increasing memory usage during the muxing. For live streams, the
index might not be useful at all.
A similar fragment index is written (but at the start of the file) if
the global_sidx flag is set. If ism_lookahead is set, we need to keep
data about the last ism_lookahead+1 fragments.
If no fragment index is to be written, we don't need to store information
about all fragments, avoiding increasing the memory consumption
linearly with the muxing runtime.
This fixes out of memory situations with long live mp4 streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add -movflags use_metadata_tags to the mov muxer. This will cause
the muxer to write all metadata to the file in the keys and mtda
atoms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'f12a705ee570e16ca692c66b62821a2dbdf82566':
movenc: Factorize a function for finding a metadata entry and the associated language
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit 'e1eb0fc960163402bbb4e630185790488f7d28ed':
movenc: Use packets in interleaving queues for the duration at the end of fragments
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
The second one is not explicitly needed, as res is not reset, but it is there
for consistency.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
This was missed in e1eb0fc960, when ff_interleaved_peek was
changed to include const during the evolution of the patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
As long as caller only writes packets using av_interleaved_write_frame
with no manual flushing, this should allow us to always have accurate
durations at the end of fragments, since there should be at least
one queued packet in each stream (except for the stream where the
current packet is being written, but if the muxer itself does the
cutting of fragments, it also has info about the next packet for that
stream).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '0abb07bad7026a945a31ba4047e6583c8b3fa3da':
movenc: Update a comment to reflect how the code actually behaves
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This codepath isn't quite as bad as it used to sound, if fragments
are cut automatically at video packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
https://developer.apple.com/library/mac/technotes/tn2174/_index.html
- Enabled creation of timecode tracks for MP4 in the same way as MOV.
- Used nmhd as media information header of timecode track of MP4 instead
of gmhd used in MOV, thus avoiding tcmi also, as recommended above.
- Bypassed adding source reference field for MP4, as suggested above.
Issue: https://trac.ffmpeg.org/ticket/4704
Signed-off-by: Syed Andaleeb Roomy <andaleebcse@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
This also deprecates our old duplicated callbacks.
* commit '9f61abc8111c7c43f49ca012e957a108b9cc7610':
lavf: allow custom IO for all files
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Some (de)muxers open additional files beyond the main IO context.
Currently, they call avio_open() directly, which prevents the caller
from using custom IO for such streams.
This commit adds callbacks to AVFormatContext that default to
avio_open2()/avio_close(), but can be overridden by the caller. All
muxers and demuxers using AVIO are switched to using those callbacks
instead of calling avio_open()/avio_close() directly.
(de)muxers that use the URLProtocol layer directly instead of AVIO
remain unconverted for now. This should be fixed in later commits.
support writing encrypted mp4 using aes-ctr, conforming to ISO/IEC
23001-7.
3 new parameters were added:
- encryption_scheme - allowed values are none (default) and cenc-aes-ctr
- encryption_key - 128 bit encryption key (hex)
- encryption_kid - 128 bit encryption key identifier (hex)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This feature allows making associations between audio tracks
that apple players recognize. E.g. when an ac3 track has a
tref that points to an aac track, devices that don't support
ac3 will automatically fall back to the aac track.
Apple used to *guess* these associations, but new products
(AppleTV 4) no longer guess and this association can only
be made explicitly now using the "fall" tref.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
By writing a zero-sized packet, the caller can communicate the
start_dts/start_cts for the stream without actually writing
the first packet.
This allows doing random-access writing of fragments when the
start dts of the stream isn't zero, so that the edit list in the moov
is written based on timestamps from the nominal start time signaled
via the zero-sized packet, while the first proper packet written
corresponds to a later fragment.
To avoid potential unexpected behaviour, empty packets only set
start_dts if the frag_discont flag is set.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows producing fragments discontinously where the video
stream has b-frames (but starts at pts=0), but doesn't work for the
cases with audio with preroll.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '8ad5124b7ecf7f727724e270a7b4bb8c7bcbf6a4':
movenc: Automatically flush after writing the initial moov
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
In most other cases when writing fragmented mp4 files, the output
IO context is flushed after each fragment. Also flush it after
writing the initial moov, to have it behave in the same way.
Signed-off-by: Martin Storsjö <martin@martin.st>
