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.
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>
When the display matrix is not the identity one, but the rotation angle
is zero, there is no need to update the sample aspect ratio.
Otherwise, it is possible to obtain negative values which interferes
with transcoding in later stages. This kind of behaviour is reproducible
on mov files with "major_brand: MSNV".
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The previous code assumed if an atom was marked with a 64-bit
size extension, it actually had that data available. The new
code verfies there's enough data in the atom for this to be
done.
Failure to verify causes total_size > atom.size which will
result in negative size calculations later on.
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Under abnormal conditions the item_count may exceed the max
allocation size on 32-bit systems, this causes the allocated
size to overflow and become too small for the given count.
Additionally, if av_reallocp() fails its allocation, the
fragment_index_count is not correctly decremented.
Ensuring further havoc may be wrought, the error code for
read_tfra() is not checked upon return.
Found-by: Paul Mehta <paul@paulmehta.com>
positive return code and use of _array functions by commiter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since 3cec81f4d4, a zero-length metadata value would try to
allocate 2*0 bytes, where av_malloc() returns NULL.
Always add one to the allocated length, to allow space for
a null terminator in the zero-length case.
Incidentally, this fixes fate-alac on RVCT 4.0, where a compiler
bug seems to mess up the mov muxer to the point that it writes
the wrong sort of metadata. Previously this bug was undetected,
but since 3cec81f4d4 such mov files started returning
AVERROR(ENOMEM) in the mov demuxer.
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>
