Fixes: bypassing of checks and assertion failure
Fixes: asan_1003879.mp4
Found-by: Clusterfuzz + asan
Reported-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes memleak and Coverity issue #1439587.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will likely also fix CID 1452574 and 1452565, false positives
resulting from Coverity thinking that av_dict_set() automatically
frees its key and value parameters (even without the
AV_DICT_DONT_STRDUP_* flags).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These functions already free it themselves before they allocate the new
extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allows the creation of the sdtp atom while remuxing MP4 to MP4. This
atom is required by Apple devices (iPhone, Apple TV) in order to accept
2160p medias.
When the mov/mp4 demuxer encounters an error during decrypting a packet,
it returns the error, yet doesn't free the packet, so that the packet
leaks. This has been fixed in this commit.
Fixes the memleaks from ticket #8150.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A value of zero for sample_count in trun box is not
prohibited by 14496-12 section 8.8.8. 4a9d32baca
disallowed this which led the demuxer to error out
when reading the header of valid files.
Empty edits can occur at any position within the edit list except for at
the end. Empty edits in the middle should not impact the reported stream
start_time or the video PTS adjustment, so only include empty edits at
the start of the list in empty_edits_sum_duration.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Binary searching would hang if the fragment items do NOT have timestamp for the
specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box. Then every fragment item
only have the timestamp for one of its tracks.
Example:
ffmpeg -f lavfi -i testsrc -f lavfi -i sine -movflags dash+frag_keyframe+skip_trailer+separate_moof -t 1 out.mp4
ffmpeg -ss 0.5 -i out.mp4 -f null none
Also fixes the hang in ticket #7572, but not the reason for having
AV_NOPTS_VALUE timestamps there.
Signed-off-by: Charles Liu <liuchh83@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count). This ammends the existing check to
include cases where chunk_count == 0. It also patches up the case
when stsc refers to unknown chunks, but stts has no samples (so we
can simply ignore stsc).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Detecting missing tfhd avoids re-using tfhd track info from the previous
moof. For files with multiple tracks, this may make a mess of the
avindex and fragindex, which can later trigger av_assert0 in
mov_read_trun().
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This breaks totally valid files that get caught in its heuristic.
This, according to the commit message, is my own doing, having asked
Michael to implement this check and providing a sample that was
"wrong". I am now atoning for my sins, and removing this hack, having
seen the light (aka that this was silly to do in the first place).
Resotores correct behavior on valid files.
This reverts commit 8e5e84c2a2.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When reading frames, we need to use the fragment for the correct
stream. Sometimes the "current" fragment is not the same as the one
the frame is for.
Found by Chromium's ClusterFuzz:
https://crbug.com/906392 and https://crbug.com/915524
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Chromium fuzzing produced a whacky file with extra tkhds. This caused
an AVStream that was already in use to be corrupted by assigning it a
new id, which blows up later in mov_read_trun because the
MOVFragmentStreamInfo.index_entry now points OOB.
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ISOBMFF does not allow AudioSampleEntryV1 in stsd version 0, so
assume the descriptor format is QTFF SoundDescriptionV1. ISOBMFF does
not define a version 2.
This fixes audio decoding for some MP4 files generated with Apple
tools. The additional fields present in SoundDescriptionV1/V2 need to
be read in order to correctly read additional boxes that contain
information required for decoding the stream.
Fixes#7376.
Also see: https://github.com/HandBrake/HandBrake/issues/1555
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Entries are always at least 8 bytes per the parsing code, so if we
see an impossible entry count avoid massive allocations. This is
similar to an existing check in mov_read_stsc().
Since ff_mov_read_stsd_entries() does eof checks, an alternative
approach could be to clamp the entry count to atom.size / 8.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This field is a uint16_t, see docs:
http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there is a saio/saiz in clear content, we shouldn't create the
encryption index if we don't already have one. Otherwise it will
confuse the cenc_filter.
The changed method is also used for senc atoms, but they should not
appear in clear content.
Found by Chromium's ClusterFuzz: https://crbug.com/873432
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will get ISOBMFF and Matroska up to date with the revised AV1 Codec
Configuration Box spec.
For now keep propagating raw OBUs as extradata until all libavcodec modules
are adapted to handle AV1CodecConfigurationRecord formatted extradata.
Tested-by: Thomas Daede <bztdlinux@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes vorbis mp4 audio files, with edit list specified. Since
st->skip_samples is not set in case of vorbis , ffmpeg computes the
start_time as negative.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This exposes encryption info from the container to the app. This
includes key ID, IV, and subsample byte ranges. The info is passed
using the new side-data AV_PKT_DATA_ENCRYPTION_DATA and
AV_PKT_DATA_ENCRYPTION_INIT_DATA.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by Chrome's ClusterFuzz: http://crbug.com/849062.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This validates that the common encryption saio/saiz atoms only appear
when the data is actually encrypted. This also ignores those atoms
in clear content.
Found by Chrome's ClusterFuzz: http://crbug.com/850389
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If start_time is not set, ffmpeg takes the duration from the global
movie instead of the per stream duration.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We already do this for audio, but it should be done for video too.
If we don't, seeking back to the start of the file, for example, can
become quite broken, since the first N packets will have repeating
and nonmonotonic PTS, yet they need to be decoded even if they are
to be discarded.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Found by Chrome's ClusterFuzz: https://crbug.com/847060
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without this some operations might overflow (undefined behavior)
even though the index adding loop would never execute
No testcase known
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.
Technically, we shouldn't be using the stts atom at all for
calculating stream durations.
This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.
The FATE changes are expected, and output is more correct (the
AAC frame is not 1028 samples).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This doesn't support saio atoms with more than one offset.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: crbug 822705
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Multiple cover images are supported by having multiple data atoms
inside the covr atom. AtomicParsley and mutagen amongst others
support and document this construct.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: -9166684017437101870 + -2495066639299164439 cannot be represented in type
Fixes: Chromium bug 791349
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes seek for files with empty edits and files with negative ctts
(dts_shift > 0). Added fate samples and tests.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In this loop, |i| is the "index". And the memory allocated should be at
least the current "count", which is |i + 1|.
BUG=801821
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be represented in type 'int'
Fixes: Chromium bug 817338
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mov_read_ctts ignores ctts entries having count <= 0. Generally, the
aggregate of all ctts entries' count fields resulting from mov_read_ctts
can be less than the corresponding sample_count.
mov_build_index attempts to normalize any existing ctts_data counts to
be 1, to make a 1-1 mapping of a ctts_data entry to a sample.
That 1-1 mapping left a tail of uninitialized ctts_data entries when the
aggregate, normalized ctts_count < sample_count.
Even more generally, later usage of ctts_data may depend on the entire
ctts_allocated_size having been initialized.
This change memsets the entire allocation of the normalized ctts_data in
mov_build_index, to prevent use of uninitialized data later.
BUG=816787
Change-Id: I7fd7db255e3aeed076ee32c90cb2df211741c052
Reviewed-on: https://chromium-review.googlesource.com/947110
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))
The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.
However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).
Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.
BUG=812567
Change-Id: Ibe94c7138e5818bfaae76866bfa6619a9b8a2b6b
Reviewed-on: https://chromium-review.googlesource.com/934925
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
An index should never be equal to the count. Hence we must make sure
*ctts_index < ctts_count.
Reviewed-by: Sasi Inguva <isasi@google.com>
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>
An invalid file may cause huge alloc. Delay expansion of ctts entries
until the number of samples is known in mov_build_index.
Fixes: 23
Found-by: zhao dongzhuo, AD-lab of Venustech
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
On some failure paths, the error code is not correctly set.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In function mov_read_custom(), it returns 0 on the path that av_malloc()
returns a NULL pointer. 0 indicates success. An error code should be
assigned to ret.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the event of ff_mov_read_stsd_entries() failure, sc->stsd_count
is not updated, even if the function allocates extradata memory.
Instead update the sc->stsd_count as entries are parsed so that
mov_read_close() can do the right thing.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Potentially fixes:
https://bugs.chromium.org/p/chromium/issues/detail?id=786269#c1
In theory, the crash can be triggered by an invalid stream that has
either tfdt or trun outside of the moof
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should be unconditionally freed at the end of mov_fix_index() in
case it hasn't been used during the fix up.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Sasi Inguva <isasi-at-google.com@ffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After c2a8f0fcbe this can happen on normal edit lists starting on a B-frame.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'defe307fb22beca60a632e976ab97e5edd4aee25':
mov: move stsd finalization to an appropriate place
mov: Do not set stsd_count if mov_read_stsd() fails
mov: log and return early on non-positive stsd entry counts
See 8b43ee4054656feb641d
Merged-by: James Almer <jamrial@gmail.com>
Subtract the calculated dts offset from the requested timestamp before
seeking. This fixes an error "Error while filtering: Operation not
permitted" observed with a short file which contains only one key frame
and starts with negative timestamps.
Then, av_index_search_timestamp() returns a valid negative timestamp,
but mov_seek_stream bails out with AVERROR_INVALIDDATA.
Fixes ticket #6139.
Signed-off-by: Jonas Licht <jonas.licht@fem.tu-ilmenau.de>
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When keyframe intervals of dash segments are not perfectly aligned,
fragments in the stream can overlap in time. The previous sorting by
timestamp causes packets to be read out of decode order and results
in decode errors.
Insert new "trun" index entries into index_entries in the order that
the trun are referenced by the sidx.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sets the correct start padding value when an edit list is present.
A new fate test is added, fate-mov-440hz-10ms, to ensure this is
handled correctly.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Sasi Inguva <isasi-at-google.com@ffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '236577230051ad61ec67fa2d68e817d54232d2a0':
mov: Ignore old spherical metadata when newer version is present
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b446f0e98f85e2e931b476e52b319f1c49244660':
mov: Do not try to parse multiple stsd for the same track
See 8b43ee4054
Merged-by: James Almer <jamrial@gmail.com>
Fixes: Missing EOF check in loop
No testcase
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
MP4 files with fragments might have the first moof box that is mentioned
in a fragment index before the first mdat box. Since it is then already
parsed by mov_read_header, we have to make sure that mov_switch_root
will not parse it again when seeking by setting the headers_read flag in
the index. Parsing it a second time would cause the ctts_data array to
receive a second copy of the information from the trun box, leading to
wrong PTS values for the second and following fragments in presence of
B-frames.
Fixes ticket 6560.
Signed-off-by: Daniel Glöckner <daniel-gl@gmx.net>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ctts data in ffmpeg relies on the index entries array to be 1:1
with samples... yet sc->sample_count can be read directly from
the 'stsz' box and index entries are only generated if a chunk
count has been read from 'stco' box.
Ensure that if sc->sample_count > 0, sc->chunk_count is too as
a basic sanity check. Additionally we need to check that after
the index is built we have the right number of entries, so we
also check in mov_read_trun() that sc->sample_count ==
st->nb_index_entries.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).
If seeks are attempted before all ctts values are known, the old
code would dump ctts entries into the wrong location. These are
then used to compute pts values which leads to out of order and
incorrectly timestamped packets.
This patch fixes ctts processing by always using the index returned
by av_add_index_entry() as the ctts_data index. When the index gains
new entries old values are reshuffled as appropriate.
This approach makes sense since the mov demuxer is already relying
on the mapping of AVIndex entries to samples for correct demuxing.
As a result of this all ctts entries are now 1-count. A followup
change will be submitted to remove support for > 1 count entries
which will simplify seeking.
Notes for future improvement:
Probably there are other boxes (stts, stsc, etc) that are impacted
by this issue... this patch only attempts to fix ctts since it
completely breaks packet timestamping.
This patch continues using an array for the ctts data, which is not
the most ideal given the rearrangement that needs to happen (via
memmove as new entries are read in). Ideally AVIndex and the ctts
data would be set-type structures so addition is always worst case
O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
noticeable during seeks.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed integer overflow is undefined behavior.
Detected with clang and -fsanitize=signed-integer-overflow
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When using streaming input, it may be possible to see frames that appear
before the current_frame. When these frames are inserted into the
index, the current_frame needs to be updated so it is still pointing
at the same frame.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mov_finalize_stsd_codec() parses stream information from the ALAC extradata,
so run it after the extradata processing is completed in mov_read_stsd().
Fixes playback of 96kHz ALAC streams muxed by qaac or the reference alac encoder.
Adapted from an FFmpeg patch by Hendrik Leppkes <h.leppkes@gmail.com>
Bug-Id: 1072
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
....
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
Samples files available from:
https://bugs.chromium.org/p/chromium/issues/detail?id=721451https://bugs.chromium.org/p/chromium/issues/detail?id=723537
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva <isasi@google.com>
Some samples have their metadata track time_scale incorrectly set to 0
and the check introduced by a398f054fd
prevents playback of those samples. Setting the time_scale to 1 fixes
playback.
Adding an MOV format option to turn on/off the editlist supporting code, introduced in ca6cae73db
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more robust in case some change or corner case causes them to be
dereferenced before being set
Fixes CID1396274, CID1396275
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
* commit '4b07ebf1eb13561492f7e3c30a67f34415016b3e':
mov: Update colr values
Mostly noop, see a3cab3d433
Only the use of av_color_{primaries,transfer,space}_name() is merged.
Merged-by: Clément Bœsch <u@pkh.me>
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Based on a patch by Micahel Niedermayer <michael@niedermayer.cc>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Michael Niedermayer