3 A bin with a sinkpad that decodes the data into raw formats. It works by sending
4 the input data through a typefind element and then recursively autoplugs elements
5 from the registry until a raw format is obtained. It will then create a new ghostpad
6 on itself to signal the app of the new pad.
8 Decodebin will also remove pads when they are removed from the stream.
11 - reuse of decoderbin, cleanup in READY state
12 - threading after demuxing?
13 - new_media events should be handled.
14 - caching of elements.
15 - abstract more elements, pads (typefind, ...);
17 The autoplugging happens as follows:
19 1) typefind is added internally to the bin.
20 2) the have_type signal is connected to typefind.
21 3) in the have_type callback the close_pad_link function is called
22 4) close_pad_link checks the type on the pad, if it is raw, a ghostpad
23 is created and autoplugging for that pad stops.
24 5) if the type of the pad is not raw, a list of possible elements that
25 can connect to this type is generated in find_compatibles.
26 6) try_to_link_1 with the element list is called. The function will loop
27 over the element list and will try to connect one of the elements to
28 the pad. If the link works, a call is made to close_link.
29 7) close_link loops over all the source pads of the element and
30 recursively calls 4) for any ALWAYS pad. For elements with
31 a SOMETIMES pad, a structure is set up and is passed to the callback
32 of the new_pad signal.
33 8) in the new_pad callback, 4) is called to try to autoplug the
39 A bin with an uri property. It will find the right source element from the registry
40 and connect a decoderbin to it. When going to the PAUSED state, it will iterate the
41 decoderbin and listen for new pad signals from it. It will connect a queue to each
42 new pad and will iterate the decoderbin until one of the queues is filled. It is
43 assumed that by that time all the streams will be found so that when leaving the
44 PAUSED state, one can query the number of streams in the media file with the given
47 Playbasebin internally groups related streams together in a GstPlayBaseGroup. This
48 is particulary important for chained oggs. Initially, a new group is created in
49 the 'building' state. All new streams will be added to the building group until
50 no-more-pads is signaled or one of the preroll queues overflows. When this happens,
51 the group is commited to a list of groups ready for playback. PlaybaseBin will then
52 attach a padprobe to each stream to figure out when it finished. It will remove
53 the current group and install the next playable group, then.
55 Before going to the PLAYING state, it is possible to connect a custom element to
56 each of the streams. To do that, you have to add the element to the bin and then
57 connect the pad(s) from the stream(s). You do not have to add the elements in
58 a thread, the bin will take care of then when it's needed. You are allowed to use
59 threads inside the elements, of course.
60 The bin tries to be smart and doesn't add a queue when there is only one possible
65 - reuse, cleanup in ready state
66 - when the first pad is closed, it's possible that another dynamic element is
67 added somewhere so that we need a queue for the first pad as well.
72 Extends playbasebin, sets up default audiosink and videosink for first audio/video
73 stream detected. implements seeking and querying on the configured sinks.
75 It also waits for new notifications from playbasebin about any new groups that are
76 becomming active. It then disconnects the sinks and reconnects them to the new
80 - reuse, refcounting, cleanup in READY state
81 - be smarter about replugging the sinks instead of removing them and readding them.
82 - Do not crap out when the audio device is in use.
88 - playlist support. maybe use a playlist bin that streams the contents of the
89 playlist on a pad, interleaved with new_media events. Also add a tuner
90 interface while we're at it.
projects / mafwsubrenderer / blob