The following keys will now be interpreted by navseek:
'f' means fast forward: the stream gets played at rate 2.0
'r' means rewind: the stream gets played at rate -2.0
'n' means normal: the stream gets played at rate 1.0
Fixes#631516.
On the one hand, it insufficiently checks whether it only updates a dummy
segment. On the other hand, only doing this at the time the last sampled is
prepared (and sent downstream) is too little too late.
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
The DTS typefinder may return a lower probability for frames that start
at non-zero offsets and where there's no second frame sync in the first
buffer. It's fairly unlikely that we'll acidentally identify PCM data
as DTS, so we don't do additional checks for now.
https://bugzilla.gnome.org/show_bug.cgi?id=636234
