That is, parse each moof in one pass (considering all contained streams'
metadata), and do so incrementally as needed for playback rather than
an initial complete scan of all moof (though all moov sample metadata
is fully parsed at startup).
... as some bogus files may indicate streams of 0 duration in moov,
while indicating the complete movie duration in mvhd (the latter should
be in mehd).
Avoid extra allocation in _parse_trun, add more checks for parsing errors,
add or adjust some debug statement, fix comments, sprinkle some branch
prediction.
The allocation of the samples can be placed out of the loop.
Makes the code clearer.
Also avoid relying on traf information as it is placed on the
end of the file and might not be acessible on push mode.
The fragmented mp4 format stores the tracks and samples information in the
'moof' boxes, which are appended before each fragment (fragment->'moof'+'mdat').
The 'mfra' box stores the offset of each 'moof' box and their presentation
time. The location of this box can be retrieved from the 'mfro' box, which is
located at the end of the file.
The 'mfra' box is parsed to get the offset of each 'moof' box and their
presentation time.
Each 'moof' box can contain information for one or more tracks inside
'tfhd' boxes. For each track in a 'moof', we have a 'trun' box, which
contains information of each sample (offset and duration) used to build
the samples table.
Based on patch by Marc-André Lureau <mlureau@flumotion.com>
https://bugzilla.gnome.org/show_bug.cgi?id=596321
Versions 0 and 1 of mvhd have different sizes of its values
(32bits/64bits). This patch makes it dump them correctly.
Also use the right node in the parameter and not the root node.
https://bugzilla.gnome.org/show_bug.cgi?id=596321
GST_ELEMENT_ERROR must not be called with the object lock held,
since it will call gst_object_get_parent() internally, which
takes the object lock as well.
This fixes the assumption that DecoderSpecificInfo must be 2 bytes long
for AAC files. The specification allows HE-AAC to be explicitly
signalled in a backward compatible way. This is done by means of an
additional information after the regular AAC header. It is expected that
decoders that can play AAC but not HE-AAC will parse the header normally
and ignore extended bits, much as they do for the HE-AAC specific payload
in the actual stream.
https://bugzilla.gnome.org/show_bug.cgi?id=612313
This uses gstpbutils to extract the profile and level from the video
object sequence and adds this to stream caps. This can be used as
metadata and for fine-grained decoder selection.
https://bugzilla.gnome.org/show_bug.cgi?id=616521
This exports the AAC profile and level in caps for use as metadata and
(eventually) for more fine-grained selection of decoders at
caps-negotiation time. (Doesn't work for HE-AAC yet though.)
https://bugzilla.gnome.org/show_bug.cgi?id=612313
Parses uuid atoms in push mode when they are found, they might
contain xmp tags.
Also does a minor refactoring to put the global tags posting
into a single function instead of repeating it in 3 different
places.
Fixes#629839
xmp packet is placed into a top-level uuid atom for
isom/mp4 variants.
This patch makes qtdemux parse all top-level atoms
in pull-mode before starting to push data, making
it able to find those tags.
https://bugzilla.gnome.org/show_bug.cgi?id=629839
Timestamp rounding issues could lead to going backwards 2 keyframe periods
(rather than only 1). While this is not necessarily a problem, it might
potentially place additional (buffering) load on downstream and could be
avoided (because We Can).
Fixes#623629.
There seems to be a bug in libmp4v2 that generates a MPEG4BitRateBox as
(bufferSizeDB, avgBitrate, maxBitrate) instead of (bufferSizeDB,
maxBitrate, avgBitrate), according to the spec. I used the mp4file
output while writing this code, so the order is wrong. This patches
fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=623654
Fix timestamp rounding to allow the correct index to be located.
The issue was that scaling from GStreamer time format to mov time format was
rounding down causing the timestamp of the newsegment event received after a
flushing keyframe seek to find the sample index before the one it should
causing further backward seeking to the keyframe prior until no rounding error
occurred.
Rounding up when scaling to mov format has the desired effect, and it is
not clear whether just the _round () variant would be sufficient.
Fixes bug #619105
