- 13 Apr, 2020 1 commit
-
-
Michael Bradshaw authored
The clli atom is expected to be standardized soon. See http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html We now write the clli atom by default. Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
-
- 01 Apr, 2020 1 commit
-
-
Michael Bradshaw authored
The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as experimental and the clli atom is not written by default. The clli atom is already parsed by FFmpeg in mov.c. Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
-
- 10 Mar, 2020 1 commit
-
-
vectronic authored
If 'write_colr' movflag is set, then movflag 'prefer_icc' can be used to first look for an AV_PKT_DATA_ICC_PROFILE entry to encode. If ICC profile doesn't exist, default behaviour enabled by 'write_colr' occurs. Signed-off-by: vectronic <hello.vectronic@gmail.com>
-
- 16 Jan, 2020 2 commits
-
-
James Almer authored
Sets some required constrains and reports compatability with the relevant compatible brand. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
If not available, set flags to 24 (bits 4 and 5), to signal the wallclock value is read at the time of writing the atom. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 11 Dec, 2018 1 commit
-
-
kjeyapal@akamai.com authored
-
- 21 Jun, 2018 1 commit
-
-
Gyan Doshi authored
Both QTFF and the ISOBMFF standards allow it. Fixes #7262
-
- 29 May, 2018 1 commit
-
-
Vishwanath Dixit authored
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.
-
- 17 Apr, 2018 1 commit
-
-
Timo Teräs authored
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:v: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>
-
- 20 Feb, 2018 1 commit
-
-
Vishwanath Dixit authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 02 Dec, 2017 1 commit
-
-
John Stebbins authored
The sdtp is required by the AppleTV 4K in order to play 2160p60 video. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 28 Sep, 2017 1 commit
-
-
Martin Storsjö authored
This reduces the need for an edit list; streams that start with e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid in mov/mp4) by shifting the dts values of all packets forward. This avoids the need for edit lists for such streams (while they still are needed for audio streams with encoder delay). This eases conformance with the DASH-IF interoperability guidelines. Signed-off-by: Martin Storsjö <martin@martin.st> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 15 May, 2017 1 commit
-
-
Martin Storsjö authored
This reduces the need for an edit list; streams that start with e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid in mov/mp4) by shifting the dts values of all packets forward. This avoids the need for edit lists for such streams (while they still are needed for audio streams with encoder delay). This eases conformance with the DASH-IF interoperability guidelines. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 26 Sep, 2016 1 commit
-
-
Carl Eugen Hoyos authored
Fixes ticket #5492.
-
- 01 Sep, 2016 1 commit
-
-
Erkki Seppälä authored
Sometimes it's useful to be able to define the exact track numbers in the generated track, instead of always beginning at track id 1. Using the option use_stream_ids_as_track_ids now copies the use stream ids to track ids. Dynamically generated tracks (ie. tmcd) have their track numbers defined as continuing from the highest numbered stream id. Signed-off-by: Erkki Seppälä <erkki.seppala.ext@nokia.com> Signed-off-by: OZOPlayer <OZOPL@nokia.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 19 Aug, 2016 1 commit
-
-
Umair Khan authored
Signed-off-by: Umair Khan <omerjerk@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 08 Jul, 2016 1 commit
-
-
Martin Storsjö authored
When writing a fragmented file, we by default write an index pointing to all the fragments at the end of the file. This causes constantly increasing memory usage during the muxing. For live streams, the index might not be useful at all. A similar fragment index is written (but at the start of the file) if the global_sidx flag is set. If ism_lookahead is set, we need to keep data about the last ism_lookahead+1 fragments. If no fragment index is to be written, we don't need to store information about all fragments, avoiding increasing the memory consumption linearly with the muxing runtime. This fixes out of memory situations with long live mp4 streams. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 25 Jun, 2016 1 commit
-
-
David Murmann authored
Add -movflags use_metadata_tags to the mov muxer. This will cause the muxer to write all metadata to the file in the keys and mtda atoms. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 18 May, 2016 1 commit
-
-
Martin Storsjö authored
As long as caller only writes packets using av_interleaved_write_frame with no manual flushing, this should allow us to always have accurate durations at the end of fragments, since there should be at least one queued packet in each stream (except for the stream where the current packet is being written, but if the muxer itself does the cutting of fragments, it also has info about the next packet for that stream). Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 27 Feb, 2016 1 commit
-
-
Mats Peterson authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 23 Feb, 2016 1 commit
-
-
Anton Khirnov authored
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.
-
- 15 Dec, 2015 1 commit
-
-
erankor authored
support writing encrypted mp4 using aes-ctr, conforming to ISO/IEC 23001-7. 3 new parameters were added: - encryption_scheme - allowed values are none (default) and cenc-aes-ctr - encryption_key - 128 bit encryption key (hex) - encryption_kid - 128 bit encryption key identifier (hex) Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 12 Aug, 2015 1 commit
-
-
Martin Storsjö authored
The double meaning of the faststart flag (moving a moov atom to the start of files, making them streamable, for non-fragmented files, vs inserting a global sidx index at the start of files for fragmented files) is confusing - see 40ed1cbf for explanation of its origins. Since the second meaning of the flag hasn't been part of any libav release yet, just rename it to get rid of the confusion without any extra deprecation (which wouldn't get rid of the potential confusion, of users adding -movflags faststart even for fragmented files, where it isn't needed for making them "streamable"). This gets back the old behaviour, where -movflags faststart doesn't have any effect for fragmented files. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 10 Aug, 2015 1 commit
-
-
Martin Storsjö authored
The same field is also used for writing the sidx index header, for fragmented files, when the faststart flag is used. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 18 Jul, 2015 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 19 Mar, 2015 2 commits
-
-
Martin Storsjö authored
For strict CFR, they should be pretty much equal, but if the stream is VFR, there can be a sometimes significant difference. Calculate the pts duration separately, used in sidx atoms and for tfrf/tfxd boxes in smooth streaming ismv files. Also make sure to reduce the duration of sidx entries according to edit lists. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Even if this is a guess, it is way better than writing a zero duration of the last sample in a fragment (because if the duration is zero, the first sample of the next fragment will have the same timestamp as the last sample in the previous one). Since we normally don't require libavformat muxer users to set the duration field in AVPacket, we probably can't strictly require it here either, so don't log this as a strict warning, only as info. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 16 Mar, 2015 1 commit
-
-
Martin Storsjö authored
This is incompatible with the omit_tfhd_offset flag (writing position independent fragments with interleaving requires the default_base_moof flag). This makes the moof atoms slightly bigger, but can be better for playback (improving locality of sample data in the mdat). Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 10 Mar, 2015 2 commits
-
-
Martin Storsjö authored
This way, the caller doesn't need to coordinate setting the option after the moov atom has been written. The downside is that it is no longer possible to use the option for checking whether the moov atom already has been written, but a caller is able to keep track of that by other means anyway. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
The previous use of the mov->fragments field, for determining whether written packets were part of the first fragment or not, didn't work as intended when using the empty_moov flag. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 05 Mar, 2015 1 commit
-
-
Kevin Wheatley authored
As this is depricated it should not be on by default, it is only supported for MOV containers, depends on avpriv_get_gamma_from_trc() Enable by: -movflags +write_gama This will use the color_trc to supply a gamma value, if desired an explicit value may be supplied using the -mov_gamma option supplying a suitable floating point value, values <=1e-6 will not be written. Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 26 Jan, 2015 1 commit
-
-
Kevin Wheatley authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 02 Jan, 2015 2 commits
-
-
Martin Storsjö authored
Use the more generic approach with the delay_moov flag, instead of having a update mechanism specific to this one single atom. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This delays writing the moov until the first fragment is written, or can be flushed by the caller explicitly when wanted. If the first sample in all streams is available at this point, we can write a proper editlist at this point, allowing streams to start at something else than dts=0. For AC3 and DNXHD, a packet is needed in order to write the moov header properly. This isn't added to the normal behaviour for empty_moov, since the behaviour that ftyp+moov is written during avformat_write_header would be changed. Callers that split the output stream into header+segments (either by flushing manually, with the custom_frag flag set, or by just differentiating between data written during avformat_write_header and the rest) will need to be adjusted to take this option into use. For handling streams that start at something else than dts=0, an alternative would be to use different kinds of heuristics for guessing the start dts (using AVCodecContext delay or has_b_frames together with the frame rate), but this is not reliable and doesn't necessarily work well with stream copy, and wouldn't work for getting the right initialization data for AC3 or DNXHD either. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 18 Dec, 2014 1 commit
-
-
Martin Storsjö authored
The pts and the corresponding duration is written in sidx atoms, thus make sure these match up correctly. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 26 Nov, 2014 1 commit
-
-
Martin Storsjö authored
This allows creating a later mp4 fragment without sequentially writing the earlier ones before (when called from a segmenter). Normally when writing a fragmented mp4 file sequentially, the first timestamps of a fragment are adjusted to match the end of the previous fragment, to make sure the timestamp is the same, even if it is calculated as the sum of previous fragment durations. (And for the first packet in a file, the offset of the first packet is written using an edit list.) When writing an individual mp4 fragment discontinuously like this (with potentially writing the earlier fragments separately later), there's a risk of getting a gap in the timeline if the duration field of the last packet in the previous fragment doesn't match up with the start time of the next fragment. Using this requires setting -avoid_negative_ts make_non_negative (or -avoid_negative_ts 0). Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 17 Nov, 2014 3 commits
-
-
Martin Storsjö authored
This is mapped to the faststart flag (which in this case perhaps should be called "shift and write index at the start of the file"), which for fragmented files will write a sidx index at the start. When segmenting DASH into files, there's usually one sidx at the start of each segment (although it's not clear to me whether that actually is necessary). When storing all of it in one file, the MPD doesn't necessarily need to describe the individual segments, but the offsets of the fragments can be fetched from one large sidx atom at the start of the file. This allows creating files for the DASH ISO BMFF on-demand profile. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
A flag "dash" is added, which enables the necessary flags for creating DASH compatible fragments. When this is enabled, one sidx atom is written for each track before every moof atom. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
By calling this after writing the moof the first time (for calculating the moof size), we can avoid intermediate storage of tfrf_offset in MOVTrack. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 07 Nov, 2014 1 commit
-
-
Martin Storsjö authored
In this case, shift tracks to start from zero instead (potentially stretching the first sample in tracks that start later than the first one). Some software does not support edit lists at all, the adobe flash player seems to be one of these. This results in AV sync errors when edit lists are used to adjust AV sync. Some players, such as QuickTime, don't respect the duration for audio packets, so if an audio track starts later than the video track and the first audio sample gets a duration longer than the actual amount of data in it, the result will be out of sync. Based on patches by Michael Niedermayer. Signed-off-by: Martin Storsjö <martin@martin.st>
-