And monitor no_more_pads.
With live sources such as rtsp, uridecodebin only creates its
child decodebins between PAUSED and PLAYING.
This means that the ASYNC_DONE it posts when getting NO_PREROLL
in its change_state method gets immediately propagated by the
GstBin parent class, as opposed to a situation where a
decodebin has been added to it already, and has posted ASYNC_START.
The proposed solution, instead of simply waiting for ASYNC_DONE,
and finishing prematurely in that case, waits for three conditions
to be true:
* the uridecodebin needs to have emitted no_more_pads
* its current state must be PAUSED if not live, PLAYING otherwise
* There must be no "pending subtitle pads", ie pads where we haven't
received tags yet.
All these conditions are checked in the message handler, as we
post custom messages on it when we get subtitle tags or no_more_pads.
https://bugzilla.gnome.org/show_bug.cgi?id=783257
When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes
which we want to decode/push immediately. Therefore don't queue them.
If upstream didn't send just keyframes (which is the ideal situation), two
different things can happen:
1) Either the subclass checks the segment flags and properly configures
the decoder implementation to only decode/output keyframes,
2) Or the subclass really decodes and outputs everything, in which case
the reverse frames will end up arriving "late" downstream (and will
be dropped). If upstream did properly send GOP in reverse order, we
still end up just showing keyframes (but at the overhead of decoding
everything).
https://bugzilla.gnome.org/show_bug.cgi?id=777094
Always put multiview-caps onto the output caps, assuming
mono if we've got no other information. It's still easy for
downstream elements to override using a capssetter or event
probe if desired.
https://bugzilla.gnome.org/show_bug.cgi?id=776172
Child streams could have more accurate width/height or various other
information added. If they have the same name, they are likely to be the
same streams.
https://bugzilla.gnome.org/show_bug.cgi?id=782697
This is now needed as GstClock does not do that internally anymore,
because that broke bindings.
And mark the function correctly as (transfer full), which it already was
before.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
Performing a gst_sdp_media_get_caps_from_media() would result in
changing fields in the GstSDPMedia violating the const tag in the
function declaration.
Before there would be a line with a=rtpmap:96 VP8/90000
after, that attribute would only contain a=rtpmap:96
Fix by performing modifications on duplicated strings instead of on
the internal values.
Also add a simple test for checking that the representation doesn't
change by a gst_sdp_media_get_caps_from_media()
The GSource for dealing with timeouts in
gst_video_convert_sample_async() might be attached to a non-default
context, so we should not be using g_source_remove() on the returned ID.
The correct thing to do is to keep a reference to the actual GSource and
then call g_source_destroy() on it.
https://bugzilla.gnome.org/show_bug.cgi?id=780297
Track how long it takes to generate the first buffer after a flush
as a simple measure of how efficient the decoder is at skipping /
rushing to get to the first decode.
