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>
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>
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>
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>
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>
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>
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.
The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of edits
and saves from the project file. So display XMP metadata only when the
user explicitly requires it.
Based on a patch by Marek Fort <marek.fort@chyronhego.com>.
This introduces a new option to the mov demuxer: -use_mfra_for
(pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
TFRAs are read for fragment start times.
Unfortunately some programs that produce fragmented mp4s use the TFRA
time field for dts and some for pts. There is no realistic way to detect
which is the case, hence the responsibility is punted onto the user.
This also means that no behavioural change is enabled by default - you
must pass either dts or pts for anything to happen.
Without this change, timestamps for some discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
default-base-is-moof shall be set to track fragments compatible with DASH
Media Segments. So, this is a fundamental support for ISOBMFF ver. DASH.
This is meaningful only when base-data-offset-present is absent and two or
more track fragments are present in a movie fragment.
Signed-off-by: Martin Storsjö <martin@martin.st>
This uses STTS and TRUN information to calculate the fps
It seems to work with more files than the previous code
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Generate extradata with SPS/PPS based on container dimensions.
Authors of this commit are: Reimar and Thomas Mundt
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This allows to read a live isml movie and segment it using the
smoothstreaming muxer, which requires the bitrates to be known for each stream.
Signed-off-by: Alexandre Sicard <alexandre.sicard@smartjog.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Frames described by this grouping are the starter of a closed or
an open GOP.
This is useful for open GOP of H.264 stream which is not described
by sync sample atom.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This patch fixes the sample from trac issue #522.
The issue is that the mov demuxer insists on using its
calculated sample_size (which is nonsense for old-style tracks)
instead of the one encoded in the track.
The old raw audio code should be using the value in stsz, because
the size of a single sample never makes sense for the size of
a full audio packet, whereas the new code will multiply the
sample size by the chunk size, so it should use the calculated value.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
If parsing moov+mdat in a non-seekable file, we currently
abort parsing directly after parsing the header of the mdat
atom. If we want to continue parsing later (if looking to
parse later fragments), we need to skip past the content of the
mdat atom, otherwise we end up parsing the content of the mdat
atom as root level atoms.
Signed-off-by: Martin Storsjö <martin@martin.st>
Prefix the functions/tables brktimegm, pcm_read_seek,
dv_offset_reset, voc_get_packet, codec_movaudio_tags,
codec_movvideo_tags.
After this, lavf has no global symbols without the proper prefix.
Signed-off-by: Martin Storsjö <martin@martin.st>
Do not use AVStream's duration for dts generation since it contains in
some cases the duration of the whole file instead of duration of the
samples in the moov. This happens if the mdhd holds the duration of the
whole file but has no entries or a zero duration in its stts.