mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-05 06:05:53 +00:00
70 lines
3 KiB
Plaintext
70 lines
3 KiB
Plaintext
decoderbin:
|
|
|
|
A bin with a sinkpad that decodes the data into raw formats. It works by sending
|
|
the input data through a typefind element and then recursively autoplugs elements
|
|
from the registry until a raw format is obtained. It will then create a new ghostpad
|
|
on itself to signal the app of the new pad.
|
|
|
|
Decodebin will also remove pads when they are removed from the stream.
|
|
|
|
TODO
|
|
- reuse of decoderbin, cleanup in READY state
|
|
- threading after demuxing?
|
|
- new_media events should be handled.
|
|
- caching of elements.
|
|
|
|
playbasebin:
|
|
|
|
A bin with an uri property. It will find the right source element from the registry
|
|
and connect a decoderbin to it. When going to the PAUSED state, it will iterate the
|
|
decoderbin and listen for new pad signals from it. It will connect a queue to each
|
|
new pad and will iterate the decoderbin until one of the queues is filled. It is
|
|
assumed that by that time all the streams will be found so that when leaving the
|
|
PAUSED state, one can query the number of streams in the media file with the given
|
|
uri.
|
|
|
|
Playbasebin internally groups related streams together in a GstPlayBaseGroup. This
|
|
is particulary important for chained oggs. Initially, a new group is created in
|
|
the 'building' state. All new streams will be added to the building group until
|
|
no-more-pads is signaled or one of the preroll queues overflows. When this happens,
|
|
the group is commited to a list of groups ready for playback. PlaybaseBin will then
|
|
attach a padprobe to each stream to figure out when it finished. It will remove
|
|
the current group and install the next playable group, then.
|
|
|
|
Before going to the PLAYING state, it is possible to connect a custom element to
|
|
each of the streams. To do that, you have to add the element to the bin and then
|
|
connect the pad(s) from the stream(s). You do not have to add the elements in
|
|
a thread, the bin will take care of then when it's needed. You are allowed to use
|
|
threads inside the elements, of course.
|
|
The bin tries to be smart and doesn't add a queue when there is only one possible
|
|
stream.
|
|
|
|
|
|
TODO
|
|
- reuse, cleanup in ready state
|
|
- when the first pad is closed, it's possible that another dynamic element is
|
|
added somewhere so that we need a queue for the first pad as well.
|
|
|
|
playbin:
|
|
|
|
Extends playbasebin, sets up default audiosink and videosink for first audio/video
|
|
stream detected. implements seeking and querying on the configured sinks.
|
|
|
|
It also waits for new notifications from playbasebin about any new groups that are
|
|
becomming active. It then disconnects the sinks and reconnects them to the new
|
|
pads in the group.
|
|
|
|
TODO
|
|
- reuse, refcounting, cleanup in READY state
|
|
- be smarter about replugging the sinks instead of removing them and readding them.
|
|
- Do not crap out when the audio device is in use.
|
|
|
|
general
|
|
|
|
TODO
|
|
- playlist support. maybe use a playlist bin that streams the contents of the
|
|
playlist on a pad, interleaved with new_media events. Also add a tuner
|
|
interface while we're at it.
|
|
- plug the many memleaks.
|
|
|