Keep all the existing data fields as they are (there's lots and
lots of nontrivial calculation and heuristics based on them in
their current form), but derive the duration as the difference
between the pts of the first packet to the maximum pts+duration
(not necessarily the last packet); use this duration in any box
where the actual presentation duration is supposed to be.
Fixes: 8420
Signed-off-by: Martin Storsjö <martin@martin.st>
Converting explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.
The user can control FLUSH_POINT flushing behaviour using the -flush_packets
option, the default typically means to flush unless a non-streamed file output
is used, so this change should have no adverse effect on streaming even if it
is assumed that after an avio_flush() the output buffer is clean so small
seekbacks within the output buffer will work even when the IO context is not
seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>
To make it consistent with other muxers.
The user can still control the generic flushing behaviour after write_header
(same way as after packets) using the -flush_packets option, the default
typically means to flush unless a non-streamed file output is used.
Therefore this change should have no adverse effect on streaming, even if it is
assumed that the first packet has a clean buffer, so small seekbacks within the
output buffer work even when the IO context is not seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>
Implemented according to the specification at https://www.iso.org/standard/69561.html
The 'mhm1' sample entry is registered with MP4RA, which is defined as MHAS encapsulated single stream MPEG-H 3D Audio.
'MHAS' stands for MPEG-H audio stream, which contains encoded audio data and corresponds metadata for decoding.
This patch enables extracting the MHAS bitstream from MP4 and remuxing into MP4.
Signed-off-by: James Almer <jamrial@gmail.com>
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small dynamic buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
write_tmcd allows tmcd track to be created with any mode but in
mov_write_header, index for first tmcd track is only set for modes
MP4 or MOV, causing a crash if tmcd creation is attempted with other
modes.
This makes sure the data is available when writing the moov atom during the
second pass triggered by the faststart movflag.
Fixes ticket #7780
Signed-off-by: James Almer <jamrial@gmail.com>
This fixes avformat_query_codec incorrectly returning 0 for
mov container and mov_text subtitles.
Signed-off-by: Paweł Wegner <pawel.wegner95@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes a problem where a sample entry which cannot be written correctly appears to succeed, but produces an invalid file.
For example, this command:
ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags +empty_moov -frag_duration 5000000 /tmp/foo.mp4
produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3) child, which is invalid according to ETSI TS 102 366.
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.
Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
Since libopus 1.2, packets of sizes 80ms, 100ms and 120ms are allowed.
Fixes assertion failures when trying to mux such streams.
Signed-off-by: James Almer <jamrial@gmail.com>
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>
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>
