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.
Fixes gapless decoding. Adjust skip_samples field correctly in case of DISCARDed audio frames.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
av_log() expects its first parameter to be a pointer to a struct whose
first element is a pointer to an AVClass. In what I can only imagine is
a typo, one call to av_log() in the AAX decryption code instead passes
a pointer to an AVSHA struct, which doesn't even contain a pointer as
its first element, much less a pointer to an AVClass. Change the call to
pass the current MOVContext, as surrounding calls do.
The incorrect AVClass was causing mpv to emit the warning "av_log
callback called with bad parameters" when playing an .aax file.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use proper ISO 8601 timestamps which also signal that they are in UTC.
This changes the format of creation_time and modification_date metadata values
from 2016-06-01 22:30:00 to 2016-01-01T22:30:00.000000Z
Fixes ticket #5673.
Signed-off-by: Marton Balint <cus@passwd.hu>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This change relaxes the whitelist on reading color metadata in MOV/BMFF
containers. The whitelist on writing values is still in place.
As a consequence it also fixes an apparent bug in reading 'nclc' values.
The 'nclc' spec [1] is in harmony with ISO 23001-8 for the values it
lists, but the code getting removed was remapping 5->6 and 6->7 for
primaries, which is incorrect, and was remapping 6->5 for color matrix
("colorspace" in the code), which is equivalent but an unnecessary
inconsistency. This logic error doesn't appear in movenc.
Removing the whitelist allows proper conversion when the source codec
relies on the container for proper signaling of newer codepoints, such
as DNxHR and VP9. If converting to a codec or container that has updated
its spec to include the new codepoints, the metadata will be preserved.
If going back to MOV/BMFF, the output whitelist will still kick in, so
this won't result in out-of-spec files being created.
[1] https://developer.apple.com/library/mac/technotes/tn2162/_index.html
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: 13262c363a28da8d6bdcc472aed6e9dc/asan_heap-oob_cfb5e2_3733_31cf3fcc783295c34222eb070a784f84.3gp
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are samples with invalid stsc that may work fine as is and
do not need extradata change. So ignore any out of range index, and
error out only when explode is set.
Found-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '76729970049fe95659346503f7401a5d869f9959':
mov: Implement support for multiple sample description tables
Notes:
* The sc->stsc_data[index].id checks have been moved from the mov_read_stsc
to mov_read_packet before the value is used in mov_change_extradata to
not break playback of samples with broken stsc entries (see sample of
ticket #1918).
* sc->stsc_index is now checked against sc->stsc_count - 1 before it
is incremented so it remains lesser than sc->stsc_count. Fixes a crash
with:
./ffmpeg -i matrixbench_mpeg2.mpg -t 1 -frag_duration 200k test.mov
./ffprobe -show_packets test.mov
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
* commit 'd34826c33d401929b2ff8aee161fd39ad0a73613':
mov: Add a comment referring to the standard that defines the loci box
Merged-by: Clément Bœsch <clement@stupeflix.com>
Implement variable sized big-endian integers, since these are found
in files created by ARRI cameras.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function needs to return false, or data in the additional tables
will be skipped, and the decoder will not be able to decode frames
associated with them.
Store data from each stsd in a separate extradata buffer, keep track of
the stsc index for read and seek operations, switch buffers when the
index differs. Decoder is notified with an AV_PKT_DATA_NEW_EXTRADATA
packet side data.
Since H264 supports this notification, and can be reset midstream, enable
this feature only for multiple avcC's. All other stsd types (such as
hvc1 and hev1) need decoder-side changes, so they are left disabled for
now.
This is implemented only in non-fragmented MOVs.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Previously, we required the minimum number of bytes required for
the full box. Don't strictly require the astronomical body and additional
notes fields, but do require an altitude field (which currently isn't
parsed). This matches the initial length check at the start of the function
(which doesn't know about the variable length place field).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '7e01d48cfd168c3dfc663f03a3b6a98e0ecba328':
mov: Check the entries value when parsing dref boxes
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Samples produced by Omneon (Harmonic) store external references with
paths ending with 0s. Such movs cannot be loaded properly since every
0 is converted to '/', to keep the same parsing code for dref type 2
and type 18: this makes the external reference point to a non-existing
direactory, rather than to the actual referenced file.
Add a brief trimming loop that drops all ending 0s before trying to
parse the external reference path.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This also fixes reading gapless metadata when the entries do not start with the
mean atom. Such samples can be found here:
https://hydrogenaud.io/index.php/topic,93310.0.html
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
This broke packed_maindata.mp3.mp4
Its unknown to me what this commit would have fixed
Reviewed-by: James Almer <jamrial@gmail.com>
This reverts commit 79127dbbef, reversing
changes made to 9fad1ce7c9.
* commit 'b92962436bdcfae478c8598dca397a397762eef8':
mov: Fix the format specifier type for size
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
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.
Some muxer might or might not fit incomplete mp3 frames in
their packets.
Bug-Id: 899
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This commit is a no-op.
* commit '5eb562831b3a9bea8026c413ef1338e06450d005':
mov: Use the correct type for size
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This also deprecates our old duplicated callbacks.
* commit '9f61abc8111c7c43f49ca012e957a108b9cc7610':
lavf: allow custom IO for all files
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The UUID is based on http://www.adobe.com/devnet/xmp.html
The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN
FILES See Table 8
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
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>
Confine the 0x00000000 to 'raw '/'twos' fourcc mapping to old version 0
sound sample descriptions, since they are the only valid sample
descriptions for this type of mapping.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In many older QuickTime files, the audio format, or "fourcc", is
0x00000000. The QuickTime File Format Specification states the following
regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."
MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
support reading encrypted mp4 using aes-ctr, conforming to ISO/IEC
23001-7.
a new parameter was added:
- decryption_key - 128 bit decryption key (hex)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This consists mainly of moving the palette handling from
the mov_parse_stsd_video() function to a new ff_get_qtpalette() function
in the new file qtpalette.c, which will be shared by both matroskadec.c and
mov.c.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
QuickTime metadata can come after trak data. Add indicator for which trak is being parsed (-1 if none) so that global metadata after the trak can be parsed.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is possibly undefined behavior based on sequence point rules, but I
have not studied the spec at that level of detail.
Fixes: CID 1338321.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Some entries might be either empty or contain types we do not parse
(eg. 'url '). In both cases, if an 'alis' is not the first entry,
external references are not loaded, so make sure that the array starts
with an 'alis' dref.
Rather than reading the alternate absolute path version from dref
type 18, make sure that 0s are considered as '/'. These values are
sometimes present in the full path, and are mistakenly interpreted as
line terminators othewise.
With the correct handling of this dref type, parsing type 18 is not
needed any more.
Chapter-indexing can be expensive since chapters may be interspersed
throughout the entire file and may require many seeks - especially
costly when consuming a video over a remote protocol like http.
Furthermore it is often unnecessary, especially when only trying to get
video info (e.g. via ffprobe).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I've got some m4a samples that had jpeg cover art marked as png. Since
these files were supposedly written by iTunes, and other software can
read it (e.g. clementine does), this should be worked around.
Since png has a very simple to detect header, while it's apparently a
real pain to detect jpeg in the general case, try to detect png and
assume jpeg otherwise. Not bothering with bmp, as I have no test case.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The Apple dev specification:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html
Basically the structure is like:
|--meta
|----hdlr
|----keys
|----ilst
1) The handler type in the metadata handler atom is ‘mdta’.
2) The key and value are stored separately for each key-value pair.
The 'keys' atom stores the key table, while 'ilst' atom stores the
values corresponding to the indices in the key table.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
mp3 packets all have the same duration and number of samples
if their duration indicated in the container varies then thats an
indication that they are not 1 mp3 packet each.
If this autodetection fails for some case then please contact us
and provide a testcase.
Fixes Ticket4938
Partially fixes Ticket 4727.
-duration is not a safe expression, since duration can be INT_MIN.
One might ask how it can become INT_MIN.
Although it is true that line 2574 is no longer reached with INT_MIN due
to commit 053e80f6ea (which fixed another
integer overflow issue), mov_update_dts_shift is called on line 3549 as
well, right after a read of untrusted data.
One can do the fix locally there, but that function is already a huge
mess. Changing mov_update_dts_shift is likely better.
This changes duration to INT_MIN + 1 in such cases. This should not make any
practical difference since such streams are anyway fuzzer files.
Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E.
This is useful for DTS-HD formats, some of which cannot be
decoded by dcadec.c or libdcadec.
Signed-off-by: Shawn Singh <shawnsingh@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Note that convergence_duration had another meaning, one which was in
practice never used. The only real use for it was a 64 bit replacement
for the duration field. It's better just to make duration 64 bits, and
to get rid of it.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The previous restriction was partially designed to fix certain
(broken) samples from bug 215. There should be no restriction on the
number of keyframes per fragment or trun.
The spec suggests that all frames lacking MOV_FRAG_SAMPLE_FLAG_IS_NON_SYNC
are key frames, but we require the flag MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES
to be unset as well. This works for (possibly broken) media that never
sets the NON_SYNC flag and should also be correct for any spec-compliant
file.
For files that never set either of the flags, all samples are marked
as keyframes.
Signed-off-by: Martin Storsjö <martin@martin.st>
Commit 0a551cbe introduced "activation_bytes" option, and not specifying
this option (while calling ffmpeg / ffprobe) causes the program to quit
early. Before this commit, ffprobe was capable of processing metadata in
.aax files.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Possibly fixes Ticket4671
the removed check is wrong and insufficient
Based on patch by Maksym Veremeyenko <verem@m1.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 260813283176b57b3c9974fe284eebc3_signal_sigsegv_7ffff713351a_991_xtrem_e2_m64q15_a32sxx.3gp with memlimit of 262144
Found-by: Samuel Groß, Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'a1e2caa93e4f8102666a21222f01b74838b6497f':
mov: Log format rather than fourcc in stsd in trace mode
Conflicts:
libavformat/mov.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2eef75fd7e1ac96ab9ca63bb4523078c908bc9b1':
mov: Adjust variable types to fix format warnings
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6ec688e1bc76dd93151cbca1c340162ae4b10d77':
mp3: enable packed main_data decoding in MP4
Conflicts:
libavcodec/mpegaudiodec_template.c
Only the parts needed to support the available sample are merged
the remaining error checks are left in place
Merged-by: Michael Niedermayer <michaelni@gmx.at>
14496-3 suggests packing main_data of MP3 that is usually scattered
into multiple frames due to bit reservoir.
However, after packing main_data into a access unit, bitrate index
in the MPEG audio frame header doesn't match with actual frame size.
In order to accept this, this patch removes unnecessary frame size
checking on mp3 decoder.
Also, mov demuxer was changed to use MP3 parser only on special cases
(QT MOV with specific sample description) to avoid re-packetizing.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If avio_read fails, the buffer can contain uninitialized data.
This fixes 'Conditional jump or move depends on uninitialised value(s)'
valgrind warnings, and addresses a few memleaks.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
In this case the mov demuxer can return a large number of empty packets.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A negative sample duration is invalid according to the spec, but there
are samples that use it for the DTS calculation, e.g.:
http://files.1f0.de/samples/mp4-negative-stts-problem.mp4
These currently get out of A/V sync.
Also change the logging type to AV_LOG_WARNING, because decoding the
sample can continue.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
In this case the mov demuxer can return a large number of empty packets.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
If avio_read fails, the buffer can contain uninitialized data.
This fixes 'Conditional jump or move depends on uninitialised value(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Using the PRIu8 format specifier to print an enum value causes a
compiler warning, so use %d instead.
Fixes ticket #4467.
Signed-off-by: Chris Watkins <watk@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9286de045968ad456d4e752651eec22de5e89060':
mov: Double-check that alias path is not an absolute path
Conflicts:
libavformat/mov.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
nlvl_to and nlvl_from can be set to 1 if both alias and target files
are in the same directory, so actually check the first character of the
string. We can do this because MacOS filepaths (alis type 2) are always
converted to UNIX filepaths (alis type 18).
Absolute paths can be stored in alis type 2 and 18 according to my research:
the first is the canonical MacOS filepath, with path level separated by
colons, and the volume name within the filepath, while the second should be the
absolute filesystem path from the mount point.
* commit 'be089af38f65dc8b1fe3564f98020fc815577edb':
mov: Rely on box type rather than file type for colr atom
Conflicts:
libavformat/mov.c
See: 0276b95242
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Although it's not allowed to use only allows 'nclc' in ISOM files, there
are samples that do not always respect this rule. This change prevents
atom overread and a spurious color range initialization.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes ticket #4387.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Note, Vittorio Giovara had submitted a very similar fix to me privately
a few hours before this, iam applying Jochens because it comes with a
commit message too and i had not yet applied Vittorios, but For sake
of credit, Vittorio independently solved this first
* commit 'e4fe535d12f4f30df2dd672e30304af112a5a827':
mov: Write the display matrix in order
Conflicts:
libavformat/mov.c
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This will allow to copy the matrix as is and it is just cleaner to keep
the matrix in the same order specified by the mov standard (which is
also explicitly described in the documentation).
In order to preserve compatibility, flip the angle sign in the display API
av_display_rotation_set() and av_display_rotation_get(), and improve the
documentation mentioning the rotation direction.
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.
Set this field to TRUE if the audio component is to operate on
little-endian data, and FALSE otherwise.
However TRUE and FALSE are not defined. Since this flag is just a boolean,
interpret all values except for 0 as little endian.
Sample-Id: 64bit_FLOAT_Little_Endian.mov
as this kind of allows to circumvent it to some extend.
We also could add a separate parameter or value to choose this
Found-by: ramiro
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Next commit will revert the PTS seeking so this is not needed anymore
This reverts commit 38e641a060.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4abfa387b8.
This commit broke playback of fragmented mp4 files with b-frames.
While investigating this, it turned out that the general framework
isn't ready for a PTS-based index yet. Revert this change until
a better thought out solution is in place.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes out of array read
Fixes: asan_heap-oob_ae74b5_3610_cov_1739568095_test.3g2
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
On input ACLR will be used to set colour range no matter which codec
it is associated with.
No change for when it will be output.
Rework mov_read_extradata function to allow detection of truncated
atom reads by callers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new mov code uses a temporally non sorted index since 4abfa387b8
and can thus no longer be filled with av_add_index_entry() which expects the index to be sorted.
Reverting 4abfa387b8 and this commit would be
a alternative fix as would be various other options.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
CTS-based seek is reasonable since player requests frames in output order
not coded order.
This change fixes seek to a keyframe within consecutive keyframes.
Let's say P[0|-1] and P[1|0], here x and y inside [x|y] are PTS and DTS
respectively, and both two frames are a keyframe. If you try to seek on
PTS=0, i.e. P[0|-1], you'll get P[1|0] if the demuxer is DTS based. This
is obviously undesirable.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'e3528d2a7bf29ba148d7ac1678552ce0089cd14f':
mov: Implement parsing of the "HandlerName" from the MP4 HDLR atom
Conflicts:
libavformat/mov.c
See: b76bc01034
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This atom typically is used for a track title. The handler name is stored
as a Pascal string in the QT specs (first byte is the length of the string),
so do not export it.
A second length check based on the first character is added to avoid
overwriting an already specified handler_name (it happens with YouTube
videos for instance, the handler_name get masked), or specifying an
empty string metadata.
The Pascal string fix and the second length check are written
by Clément Bœsch <clement.boesch@smartjog.com>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This partially reverts cf70ba37ba, since
it didn't take into account when rotation is 0, but there is another
valid operation (eg. translation) in the matrix.
Found-by: Michael Niedermayer <michaelni@gmx.at>
When the timecode value is in counter mode then it is important to use
the timescale and frameduration to calculate the timecode fps.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The original code was intended purely for rotation == 0
In cf70ba37ba the condition was
changed to use it only for rotation != 0
which broke the cases for which it was intended to be used
as well as breaking cases for which it was not intended to be
used.
This changes the code so it could work for the more general
case and fixes the regressions
If you have sample files that are not handled correctly
please open tickets or mail me!
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cf70ba37ba74089a18295b29e77dead0a3222c9e':
mov: Check angle rather than full matrix when updating SAR
Merged-by: Michael Niedermayer <michaelni@gmx.at>
