Commit graph

13 commits

Author SHA1 Message Date
Edward Hervey
ce65017d03 decodebin3/urisourcebin: Switch to actual EOS events internally
Use the intended sequence for re-using elements:
* EOS
* STREAM_START if element is to be re-used

This avoids having elements (such as queue/multiqueue/queue2) not
properly resetting themselves.

When delaying EOS propagation (because we want to wait until all
streams of a group are done for example), we re-trigger them by
first sending the cached STREAM_START and then EOS (which will
cause elements to re-set themselves if needed and accept new
buffers/events).

https://bugzilla.gnome.org/show_bug.cgi?id=785951
2017-08-11 11:23:29 +03:00
Seungha Yang
bf32c0b3b0 decodebin3: Remove FIXME and do remove_input_stream() only for the corresponding parsebin
Do not remove other parsebin's input streams. It will cause unexpected
removal of any input streams in multi-parsebin use case.

Basically, the purpose of blocking buffers is similar to checking
no-more-pads of chain/group. That is, it gives hint to know the timing
to remove old (EOSed) streams of the parsebin and to add/reuse slots
for new input streams. But, that doesn't mean that we need to remove
other parsebin's EOSed stream. Each parsebin has most likely its
own streaming thread and therefore EOSed time can be much different.
(i.e., much early EOS of subtitle only parsebin)

https://bugzilla.gnome.org/show_bug.cgi?id=785120
2017-07-19 17:13:20 +02:00
Edward Hervey
651a0fe312 decodebin3: use lock macro where applicable 2017-07-18 13:05:06 +02:00
Thibault Saunier
4b3798fedc decodebin3: Protect fields related to streams handling with the SELECTION_LOCK
Fields related to stream handling (input_streams,
output_streams, slots, guint slot_id) where used totally unprotected
until know.

This lead to several races, especially playing back RTSP streams.

To protect those fields, the OBJECT_LOCK can not be used as we sometimes
need to be able to post message on the bus while holding it.

decodebin3 already has a lock to manage stream selection, and in the end
it makes sense to protect all the stream management fields with the same
lock which is why we reuse the SELECTION_LOCK here.

https://bugzilla.gnome.org/show_bug.cgi?id=784012
2017-07-18 13:05:06 +02:00
Sebastian Dröge
f41198db9d decodebin3: Handle stream-start events without group id correctly
CID 1363327
2017-02-28 15:13:49 +02:00
Seungha Yang
6b5617c2a7 decodebin3: Fix crash caused by slot double freeing
Probe for MultiQueue source pad might receive EOS twice,
the first is fake-eos and the other is actual EOS.
And the slot can be freed with fake-eos/EOS if the slot has no input.

Since slot freeing is async, double free can be possible.
So, decodebin3 needs to remove the probe also with slot freeing.

https://bugzilla.gnome.org/show_bug.cgi?id=777530
2017-01-31 17:16:16 +01:00
Seungha Yang
49653b058a decodebin3: Remove unused variable
https://bugzilla.gnome.org/show_bug.cgi?id=773341
2016-12-08 16:59:07 +01:00
Seungha Yang
582c7cef18 decodebin3: More cleanup DecodebinOutputStream and MultiQueueSlot
When removing DecodebinInputStream, cleanup DecodebinOutputStream and
MultiQueueSlot also if they were drained.

https://bugzilla.gnome.org/show_bug.cgi?id=773341
2016-12-08 16:59:07 +01:00
Seungha Yang
4fcbcf4e48 decodebin3: Send custom-eos event to notify drained state
Likewise how urisourcebin is doing, use custom event if other streams
are still alive.

https://bugzilla.gnome.org/show_bug.cgi?id=773341
2016-12-08 16:59:07 +01:00
Seungha Yang
364a45267e decodebin3: Clear saw_eos flag of DecodebinInputStream by FLUSH event
Likewise how GstPad is doing, saw_eos flag of DecodebinInputStream
must be cleared by FLUSH event.

https://bugzilla.gnome.org/show_bug.cgi?id=774343
2016-11-15 21:38:27 +11:00
Seungha Yang
5f2c0c8ea7 decodebin3: More SELECTION_LOCK when linking to slot
Since there can be multiple parsebin in a decodebin3,
linking parsebin with MultiQueueSlot should be protected also.

https://bugzilla.gnome.org/show_bug.cgi?id=772855
2016-10-14 08:29:46 +02:00
Guillaume Desmottes
c1db195ba5 decodebin3: fix stream leaks
MultiQueueSlot owns a ref on the active stream so it should release it
when being freed.

DecodebinInputStream owns ref on the active and pending stream so they
should be dropped when being freed.

https://bugzilla.gnome.org/show_bug.cgi?id=768811
2016-07-18 13:57:44 +01:00
Edward Hervey
d514e79bee playback: New elements
With contributions from Jan Schmidt <jan@centricular.com>

* decodebin3 and playbin3 have the same purpose as the decodebin and
playbin elements, except make usage of more 1.x features and the new
GstStream API. This allows them to be more memory/cpu efficient.

* parsebin is a new element that demuxers/depayloads/parses an incoming
stream and exposes elementary streams. It is used by decodebin3.
It also automatically creates GstStream and GstStreamCollection for
elements that don't natively create them and sends the corresponding
events and messages

* Any application using playbin can use playbin3 by setting the env
variable USE_PLAYBIN3=1 without reconfiguration/recompilation.
2016-06-30 14:15:47 +02:00