Commit 2b9493b5 broke this in two ways: a) we should only
pass duration queries in TIME format upstream (or at least
not those in DEFAULT or BYTE format), and b) we mustn't
overwrite the default value of 'res' from TRUE to FALSE
and not set it again later. This led to bogus durations
being reported for FLV playback from file, because TIME
queries would fail (as 'res' had been set to FALSE) and
parsers then do a BYTE query as fallback and try to
guesstimate something in return, which of course goes
horribly wrong since the BYTE size returned is for the
muxed file.
When changing the properties to not be in passthrough mode anymore,
we will only accept caps we can process ourselves, potentially causing
a not-negotiated error.
https://bugzilla.gnome.org/show_bug.cgi?id=720345
This makes sense in DASH reverse playback, where the upstream dashdemux
will download DASH segments in reverse order, but push their buffers
forward to qtdemux and mark each segment start as DISCONT. This needs
to be forwarded downstream to the parser/decoder, otherwise it won't work.
https://bugzilla.gnome.org/show_bug.cgi?id=734443
When writing out a trak with an edit list, make sure the
overall file duration is also updated to reflect the
lengthening of the stream.
Add some more debug to qtdemux to warn about streams that
are longer than the file and get truncated.
We only want to unlock if we push an event downstream and
jump to done_unlock label afterwards. We would also unlock
in case of a segment seek and then unlock again later, and
nothing good can come of that.
(This code looks a bit dodgy anyway though, shouldn't it
also bail out with FLOW_EOS here in case of a segment seek
scenario, just without the event?)
gst_matroska_parse_take() would return FLOW_ERROR instead of
FLOW_EOS in case there's less data in the adapter than requested,
because buffer is NULL in that case which triggers the error
code path. This made the unit test fail (occasionally at least,
because of a bug in the unit test there's a race and it would
happen only sporadically).
Decoder complains about "notification: Invalid mode encountered.
The stream is corrupted" though, even if it works, so there's
probably something wrong with the generated codec headers.
Implement 3 different cases for handling the SR:
1) we don't have enough timing information to handle the SR packet and
we need to wait a little for more RTP packets. In that case we keep
the SR packet around and retry when we get an RTP packet in the
chain function.
2) the SR packet has a too old timestamp and should be discarded. It is
labeled invalid and the last_sr is cleared.
3) the SR packet is ok and there is enough timing information, proceed
with processing the SR packet.
Before this patch, case 2) and 1) were handled in the same way,
resulting that SR packets with too old timestamps were checked over and
over again for each RTP packet.
