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>
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>
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>
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643952 (senc,saiz portions)
Signed-off-by: Matt Wolenetz <wolenetz@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643952 (udta_string portion)
Signed-off-by: Matt Wolenetz <wolenetz@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643951
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support values beyond INT_MAX
Also the check is moved to a more common place and before integer truncation
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643950
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support larger lengths
Retain the ranges of frame indexes when applying edit list in
mov_fix_index. The index ranges are then used to keep track of the frame
index of the current sample. In case of a discontinuity in frame indexes
due to edit, update the auxiliary info position accordingly.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The string codec name need not be as long as the value we are
comparing it to, so memcmp may make decisions derived from
uninitialised data that valgrind then complains about (though the
overall result of the function will always be the same). Use
strncmp instead, which will stop at the first zero byte and
therefore not encounter this issue.
When the input string is too large, so the second condition in if ()
fails, the code will erroneously execute the else branch, indexing the
mac_to_unicode table with a negative index.
CC: libav-stable@libav.org
Bug-Id: 1000
Found-By: Kamil Frankowicz
This implements Spherical Video V1 and V2, as described in the
spatial-media collection by Google.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This implements Spherical Video V1 and V2, as described in the
spatial-media collection by Google.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This prevented the code from correctly exporting the rotation matrix
which caused a few samples to be displayed wrong.
Introduced in ecd2ec69ce.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes valgrind warning about "Conditional jump or move depends on uninitialised value(s)"
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
fate-aac-al07_96 fails if sample_rate == 0 is rejected in
ff_mov_read_stsd_entries.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
According to spec ISO_IEC_15444_12 "For any media stream for which no segment index is present, referred to as non‐indexed stream, the media stream associated with the first Segment Index box in the segment serves as a reference stream in a sense that it also describes the subsegments for any non‐indexed media stream."
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there are no index entries, e_old = st->index_entries is only one
byte large, since it was created by av_realloc called with size 0.
Thus accessing e_old[0].timestamp causes a heap buffer overflow.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>