Improve parsing of the samplerate.
Parse the framelen so that we can calculate timestamps.
When interpollate the incomming timestamp on outgoing buffers when there are
multiple subframes.
fixes#625825
It was an arbitrary limit from the start, meant as a basic sanity check,
so may just as well increase it a little. Would be good to provide
progress reporting while completing the block in any case..
https://bugzilla.gnome.org/show_bug.cgi?id=637060
Use g_ascii_dtostr() and g_ascii_strtod() to serialise/deserialise
floating point numbers, instead of ugly hacks that switch locale
before and after calling libc functions (which is not a good idea
in a multi-threaded application).
atof() converts strings according to the current locale, but the
framerate string will likely always use a dot as floating point
separator, so use g_ascii_strtod() instead (but also canonicalise
the string before, so we can handle both formats as input).
Include all possible stats of a source in the stats structure because we might
be interested in what happened in the past.
Document the stats property and the fields.
Using this in a demuxer will cause deadlocks if there's
a pad with a pending pad-block downstream, no matter if
there is a queue between the pad or not. Queues pass
bufferalloc downstream from the same thread and only
act as a thread boundary for events and buffers.
When the jitterbuffer contains -1 timestamps, make sure we still calculate the
buffer fill level by skipping the -1 buffers.
Try to be more resilient to weird input timestamps.
since we are using the clock for sync, we need to also provide a clock for good
measure. The reason is that even if downstream elements provide a clock, we
don't want to have that clock selected because it might not be running yet.
... thereby (partially) deprecating properties currently controlling whether
or not byte-stream output or NAL/AU alignment (though properties still determine
fallback if nothing specified in caps).
Fixes#606662.
Extra info can't hurt. Field names aren't necessarily consistent with
what's used elsewhere though (e.g. avidemux), but then neither are the
caps.
https://bugzilla.gnome.org/show_bug.cgi?id=623178
In particular, when streaming interleaved, this arranges for setting a new
timestamp on outgoing buffer so downstream can appropriate reset
to a change in (rtp)time.
Use 3 adapters, one to accumulate paketization units, another on to accumulate
tiles and a last one to accumulate the final frame.
Don't just blindly flush the adapter on DISCONT but only discard the current
packetization unit.
When we dropped jpeg2000 packets between SOP markers, adjust the SOT header with
the new lenght.
In particular, accept unknown stream in track fragment, and only error out
if that raises problems later on with respect to offset tracking.
Fixes#620283.
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
