From caa608e5c0c5829f67a4fbe82e0abc28b24aa150 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Tim-Philipp=20M=C3=BCller?= Date: Sun, 16 May 2021 02:10:55 +0100 Subject: [PATCH] docs: random: clean up outdated documents Most of these are only of historical interest, and for that it's fine if they're maintained in the git history. They're confusing for anyone stumbling across them expecting documentation relating to current versions of GStreamer. Part-of: --- docs/random/API | 2 - docs/random/LICENSE | 18 - docs/random/TODO-pre-0.9 | 170 --- docs/random/autoplug1 | 206 --- docs/random/autoplug2 | 289 ----- docs/random/bbb/streamselection | 85 -- docs/random/bbb/subtitles | 105 -- docs/random/buffers | 19 - docs/random/caps | 209 --- docs/random/caps.dia | 1132 ----------------- docs/random/caps2 | 231 ---- docs/random/classes.dia | Bin 5601 -> 0 bytes docs/random/ds/0.9-planning | 165 --- docs/random/ds/buffer_locking | 30 - docs/random/ds/bufferpools | 57 - docs/random/ds/categories | 50 - docs/random/ds/element-checklist | 43 - docs/random/ds/registry | 15 - docs/random/ds/roadmap | 79 -- docs/random/ensonic/audiobaseclasses.txt | 18 - docs/random/ensonic/dparams.txt | 14 - .../ensonic/draft-registry-change-hooks.txt | 56 - docs/random/ensonic/dynlink.txt | 89 -- docs/random/ensonic/interfaces.txt | 85 -- docs/random/ensonic/lazycaps.txt | 72 -- docs/random/ensonic/logging.txt | 56 - docs/random/ensonic/media-device-daemon.txt | 42 - docs/random/ensonic/plugindocs.txt | 51 - docs/random/ensonic/receipies.txt | 37 - docs/random/eos | 209 --- docs/random/error | 59 - docs/random/example | 108 -- docs/random/hierarchy | 153 --- docs/random/interfaces | 337 ----- docs/random/metadata | 80 -- docs/random/mutability | 30 - docs/random/negotiation | 286 ----- docs/random/omega/EOS/chain-walkthrough | 19 - docs/random/omega/IDEAS | 21 - docs/random/omega/TODO-0.1.0 | 54 - docs/random/omega/TYPE_FOURCC | 3 - docs/random/omega/build/TODO | 7 - docs/random/omega/caps2 | 320 ----- docs/random/omega/caps3 | 20 - docs/random/omega/debug-commit | 30 - docs/random/omega/eos.old | 52 - docs/random/omega/filterfactory | 3 - docs/random/omega/output_policies | 61 - docs/random/omega/pad-negotiation | 40 - docs/random/omega/padtemplates | 46 - docs/random/omega/plan-generation | 87 -- docs/random/omega/sched-case | 20 - docs/random/omega/sched-commit1 | 103 -- docs/random/omega/sched/chains | 89 -- docs/random/omega/sched/walkthrough-72 | 39 - docs/random/omega/sched2 | 13 - docs/random/omega/scheduling | 66 - docs/random/omega/testing/Makefile | 3 - docs/random/omega/testing/framework | 144 --- docs/random/omega/testing/gstobject.c | 314 ----- docs/random/omega/testing/gstobject.txt | 95 -- docs/random/omega/type-properties | 77 -- docs/random/phonon-gst | 269 ---- docs/random/plugins | 93 -- docs/random/plugins.dia | 941 -------------- docs/random/porting-to-0.11.txt | 5 - docs/random/queue | 38 - docs/random/richardb/syncmail | 3 - docs/random/rtp | 44 - docs/random/signal | 12 - docs/random/sources | 324 ----- docs/random/status-0.11-14-jun-2011.txt | 192 --- docs/random/styleguide | 18 - docs/random/testing/syntax | 37 - docs/random/thaytan/opengl | 20 - docs/random/thaytan/video-overlays | 28 - docs/random/thomasvs/0.10 | 121 -- docs/random/thomasvs/0.4.0 | 108 -- docs/random/thomasvs/TODO | 3 - docs/random/thomasvs/docreview | 37 - docs/random/thomasvs/features | 15 - docs/random/thomasvs/guadec-4 | 16 - docs/random/thomasvs/pthread | 75 -- docs/random/thomasvs/pwg | 39 - docs/random/thomasvs/registry | 36 - docs/random/types | 33 - docs/random/types2 | 282 ---- docs/random/types3 | 177 --- docs/random/use-cases-0.11.txt | 21 - docs/random/usecases | 44 - docs/random/vis-transform | 78 -- docs/random/wingo/porting-plugins-to-0.9 | 32 - docs/random/wingo/threadsafe-properties | 76 -- docs/random/wingo/without-factories | 62 - docs/random/zaheerm/dvb-interface.txt | 26 - 95 files changed, 9718 deletions(-) delete mode 100644 docs/random/API delete mode 100644 docs/random/LICENSE delete mode 100644 docs/random/TODO-pre-0.9 delete mode 100644 docs/random/autoplug1 delete mode 100644 docs/random/autoplug2 delete mode 100644 docs/random/bbb/streamselection delete mode 100644 docs/random/bbb/subtitles delete mode 100644 docs/random/buffers delete mode 100644 docs/random/caps delete mode 100644 docs/random/caps.dia delete mode 100644 docs/random/caps2 delete mode 100644 docs/random/classes.dia delete mode 100644 docs/random/ds/0.9-planning delete mode 100644 docs/random/ds/buffer_locking delete mode 100644 docs/random/ds/bufferpools delete mode 100644 docs/random/ds/categories delete mode 100644 docs/random/ds/element-checklist delete mode 100644 docs/random/ds/registry delete mode 100644 docs/random/ds/roadmap delete mode 100644 docs/random/ensonic/audiobaseclasses.txt delete mode 100644 docs/random/ensonic/dparams.txt delete mode 100644 docs/random/ensonic/draft-registry-change-hooks.txt delete mode 100644 docs/random/ensonic/dynlink.txt delete mode 100644 docs/random/ensonic/interfaces.txt delete mode 100644 docs/random/ensonic/lazycaps.txt delete mode 100644 docs/random/ensonic/logging.txt delete mode 100644 docs/random/ensonic/media-device-daemon.txt delete mode 100644 docs/random/ensonic/plugindocs.txt delete mode 100644 docs/random/ensonic/receipies.txt delete mode 100644 docs/random/eos delete mode 100644 docs/random/error delete mode 100644 docs/random/example delete mode 100644 docs/random/hierarchy delete mode 100644 docs/random/interfaces delete mode 100644 docs/random/metadata delete mode 100644 docs/random/mutability delete mode 100644 docs/random/negotiation delete mode 100644 docs/random/omega/EOS/chain-walkthrough delete mode 100644 docs/random/omega/IDEAS delete mode 100644 docs/random/omega/TODO-0.1.0 delete mode 100644 docs/random/omega/TYPE_FOURCC delete mode 100644 docs/random/omega/build/TODO delete mode 100644 docs/random/omega/caps2 delete mode 100644 docs/random/omega/caps3 delete mode 100644 docs/random/omega/debug-commit delete mode 100644 docs/random/omega/eos.old delete mode 100644 docs/random/omega/filterfactory delete mode 100644 docs/random/omega/output_policies delete mode 100644 docs/random/omega/pad-negotiation delete mode 100644 docs/random/omega/padtemplates delete mode 100644 docs/random/omega/plan-generation delete mode 100644 docs/random/omega/sched-case delete mode 100644 docs/random/omega/sched-commit1 delete mode 100644 docs/random/omega/sched/chains delete mode 100644 docs/random/omega/sched/walkthrough-72 delete mode 100644 docs/random/omega/sched2 delete mode 100644 docs/random/omega/scheduling delete mode 100644 docs/random/omega/testing/Makefile delete mode 100644 docs/random/omega/testing/framework delete mode 100644 docs/random/omega/testing/gstobject.c delete mode 100644 docs/random/omega/testing/gstobject.txt delete mode 100644 docs/random/omega/type-properties delete mode 100644 docs/random/phonon-gst delete mode 100644 docs/random/plugins delete mode 100644 docs/random/plugins.dia delete mode 100644 docs/random/porting-to-0.11.txt delete mode 100644 docs/random/queue delete mode 100644 docs/random/richardb/syncmail delete mode 100644 docs/random/rtp delete mode 100644 docs/random/signal delete mode 100644 docs/random/sources delete mode 100644 docs/random/status-0.11-14-jun-2011.txt delete mode 100644 docs/random/styleguide delete mode 100644 docs/random/testing/syntax delete mode 100644 docs/random/thaytan/opengl delete mode 100644 docs/random/thaytan/video-overlays delete mode 100644 docs/random/thomasvs/0.10 delete mode 100644 docs/random/thomasvs/0.4.0 delete mode 100644 docs/random/thomasvs/TODO delete mode 100644 docs/random/thomasvs/docreview delete mode 100644 docs/random/thomasvs/features delete mode 100644 docs/random/thomasvs/guadec-4 delete mode 100644 docs/random/thomasvs/pthread delete mode 100644 docs/random/thomasvs/pwg delete mode 100644 docs/random/thomasvs/registry delete mode 100644 docs/random/types delete mode 100644 docs/random/types2 delete mode 100644 docs/random/types3 delete mode 100644 docs/random/use-cases-0.11.txt delete mode 100644 docs/random/usecases delete mode 100644 docs/random/vis-transform delete mode 100644 docs/random/wingo/porting-plugins-to-0.9 delete mode 100644 docs/random/wingo/threadsafe-properties delete mode 100644 docs/random/wingo/without-factories delete mode 100644 docs/random/zaheerm/dvb-interface.txt diff --git a/docs/random/API b/docs/random/API deleted file mode 100644 index 4962b3283f..0000000000 --- a/docs/random/API +++ /dev/null @@ -1,2 +0,0 @@ -* signals should use dashes in their names, not underscores, so ::notify - works correctly diff --git a/docs/random/LICENSE b/docs/random/LICENSE deleted file mode 100644 index 696b1c1b22..0000000000 --- a/docs/random/LICENSE +++ /dev/null @@ -1,18 +0,0 @@ -/* GStreamer - * Copyright (C) <1999> Erik Walthinsen - * - * This library is free software; you can redistribute it and/or - * modify it under the terms of the GNU Library General Public - * License as published by the Free Software Foundation; either - * version 2 of the License, or (at your option) any later version. - * - * This library is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Library General Public License for more details. - * - * You should have received a copy of the GNU Library General Public - * License along with this library; if not, write to the - * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, - * Boston, MA 02110-1301, USA. - */ diff --git a/docs/random/TODO-pre-0.9 b/docs/random/TODO-pre-0.9 deleted file mode 100644 index 248024aaa6..0000000000 --- a/docs/random/TODO-pre-0.9 +++ /dev/null @@ -1,170 +0,0 @@ -TODO: ------ - -short term core API stability ------------------------------ - -Changes that probably impact the API, careful discussion (IRC) + design doc is required -before changes are accepted. - -target release ! description - ! - 0.4.1 ! expose and API to query the supported seek formats/flags on - (done) ! pads, something like an extra arg to gst_pad_set_convert_function - ! and gst_pad_set_event_function with some function to query the - ! flags and formats. more ideas in docs/random/wtay/query_events - ! (API: medium difficulty) - ! - 0.4.1 ! add event for segment playback/looping and seeking (docs/random/wtay/segments) - (done) ! (API: medium difficulty, plugins: HARD to very HARD) - ! - ? ! add event to adjust rate (reverse playback, slow motion, frame skipping) - ! (docs/random/wtay/rate_event) - ! (API: medium difficulty, plugins: HARD to very HARD) - ! - ? ! add method in the scheduler to set the entry point (frame stepping?) - ! (docs/random/wtay/scheduler_entry) - ! (API: moderatly EASY, scheduler implementation MEDIUM) - ! - 0.6.0 ! create a design doc for a timecache implementation, - (done) ! (docs/wtay/random/timecache) - ! (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD) - ! (done: implemented using GstIndex base class + subclasses) - ! - ? ! implement a QoS event and a policy for handling the event. - ! (API: kindof EASY, plugins MEDIUM to very HARD) - ! - 0.4.1 ! implement user defined GstFormat values, make a format factory etc.. - (done) ! (API: MEDIUM, plugins MEDIUM) - ! - ? ! strip the API to a bare bones minimal set of functions, leave the automatic - ! stuff to the app instead of forcing a policy in the core. - ! create a library with useful higher level function for people who don't want - ! to deal with the lowlevel stuff. - ! (HARD, need to negotiate with people :)) - ! - ? ! use GMarkup to load/save objects, remove dependency on libxml2 - ! (MEDIUM) breaks API/ABI compatibility - ! - - -shortterm core feature enhancements ------------------------------------ - - 0.4.1 ! Implement PAD_DISABLED. This requires simple checks in the scheduler so that - ! it doesn't try to pull/push data from/to a disabled pad. - ! When an element goes to the PAUSED state, all of its pads should be disabled. - ! This should also work for ghostpads. - ! (API: MEDIUM to moderatly HARD, requires some scheduler understanding) - - -short term usability --------------------- - -Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot -of people, hey! you might even find YOUR book on a shelf in a bookstore!! - - - ? ! plugin writers guide - ! (we have almost nothing, so any start is welcomed) - ! (MEDIUM) - ! - ? ! app writers guide needs to cover common tips and tricks and HOWTOs - ! (MEDIUM) - - -short to midterm policy definition ----------------------------------- - -Policy definition is closely related to a HOWTO but sometimes needs some thinking. - - - ? ! document thread safety guidelines, what stuff needs locking in the app, what - ! is done in the core. - ! most of this stuff is in the heads of various people but needs to be written - ! down so that people get more insights into the design and vision of GStreamer. - ! (MEDIUM, some research and discussion needed) - ! - ? ! a step by step guide to the implementation of various events in a plugin, what can you - ! do, when is data passing forbidden etc.. - ! (MEDIUM, some research needed) - ! - ? ! figure out a policy for the NEW_MEDIA event - ! (MEDIUM to HARD) - ! - ? ! figure out how to better handle clock resync - ! (MEDIUM to HARD) - ! - - -midterm feature enhancement ---------------------------- - - 0.6.0 | Define and implement a syntax in gst_parse to handle filtered pad connections. - (done) | (MEDIUM) - | - ? | Figure out a way to set properties on schedulers (and bins?) from gst_parse. - | (MEDIUM) - | - ? | Make gst-inspect do inspection of plugins, schedulers, autopluggers, types. - | An idea would be to make -inspect output an XML representation of the objects - | and use XSLT to transform this into text, HTML, docbook, ... - | (MEDIUM to EASY) - | - - -midterm (longterm) optimisations --------------------------------- - -These optimisations can be done without changing the existing API. - - - (in progress) ! implement an optimal scheduler that uses chaining when possible - ! (HARD, requires detailed knowledge of element scheduling) - ! - ? ! alternatively optimisations to the current scheduler can be done such - ! as: do nothing when the pipeline structure (or chain) has not changed - ! (MEDIUM) - ! - ? ! GstQueue is a little mess. implement a better queue (lockfree?), refactor - ! queueing policy (max buffer, max time, levels etc..) - ! (MEDIUM to farily EASY) - - -longterm feature enhancements ------------------------------ - -Various features that are not critical yet. - - ? ! factory aliases. map a generic name like "videosink" to and actual - ! user configurable plugin (aasink, sdlsink, xvideosink, ...) - ! (MEDIUM) - ! - ? ! property proxy in compound elements. not sure if it's possible at all. - ! what with elements with the same property? - ! (MEDIUM, needs some thinking) - ! - ? ! Make _pad_select work for muxers - ! (MEDIUM to HARD) - - -needs consensus ---------------- - -Some stuff that needs to be figured out based on a pro/con comparison. - - ? ! can we decide on the fact that downstream events are traveling using the - ! scheduler? do we need to reevaluate that design decision? - ! (MEDIUM, needs pros vs cons document) - - -benchmarks ----------- - -Benchmarks are always good to get acceptance in a wider comunity or to identify performance -problems that need fixing. - - ? ! do a latency comparison with popular other frameworks, document GStreamer - ! overhead. - ! (MEDIUM to somewhat EASY) - ! diff --git a/docs/random/autoplug1 b/docs/random/autoplug1 deleted file mode 100644 index f3f94dfec9..0000000000 --- a/docs/random/autoplug1 +++ /dev/null @@ -1,206 +0,0 @@ -COMPLETELY OUTDATED -------------------- - - -A little explanation of the first autoplugger in GStreamer: - -Autoplugging is implemented in the following places: - - gstpipeline.c : construction of the pipeline - gstautoplug.c : selection of the elementfactories needed for autoplugging - -1) pipeline setup ------------------ - -before any autoplugging will take place, a new GstPipeline has to be created. -The autoplugger needs to have a src element and one or more sink elements. the -autoplugger will try to find the elements needed to connect the src element -to the sinks. - -using: - - gst_pipeline_add_src (GstPipeline *pipeline, GstElement *element); - -a source element is added to the pipeline. only one src element can be added -for now. - -using: - - gst_pipeline_add_sink (GstPipeline *pipeline, GstElement *element); - -a sink element can be added to the pipeline. - -2) starting autoplug --------------------- - -when the pipeline has been set up as above, you will call - - gst_pipeline_autoplug (GstPipeline *pipeline); - -to start the autoplugger. this will be done in four phases - -ex. we are going to autoplug an mpeg1 system stream. - -2a) phase1: figure out the type (GstCaps) of the src element. -------------------------------------------------------------- - -the gsttypefind element is connected to the "src" pad of the source -element. gst_bin_iterate is called in a loop until gsttypefind -signals "have_type". the gst_bin_iterate is stopped and the GstCaps -is retrieved from the gsttypefind element. - -gsttypefind is disconnected from the src element and removed from the -bin. - -the GstCaps of the source element is called src_caps later on. - -ex. all typefind functions are tried and the one in mpeg1types will - return a GstCaps: - - video/mpeg, - "systemstream", GST_PROPS_BOOLEAN (TRUE), - "mpegversion", GST_PROPS_INT (1), - NULL - - -2b) phase2: create lists of factories. ---------------------------------------- - -for each sink: -{ - sinkpad = take the first sinkpad of the sink (HACK) - call - - list[i] = gst_autoplug_caps (src_caps, sinkpad->caps); - - I++; -} - -gst_autoplug_caps will figure out (based on the padtemplates) -which elementfactories are needed to connect src_caps to sinkpad->caps -and will return them in a list. - -ex. we have two sinks with following caps: - - video/raw audio/raw - "...." "...." - - gst_autoplug_caps will figure out that for the first sink the following - elements are needed: - - mpeg1parse, mp1videoparse, mpeg_play - - for the second sink the following is needed: - - mpeg1parse, mp3parse, mpg123 - - We now have two lists of elementfactories. - -2c) phase3: collect common elements from the lists. ---------------------------------------------------- - -the rationale is that from the lists we have created in phase2, there -must be some element that is a splitter and that it has to come first (HACK) -We try to find that element by comparing the lists until an element differs. - -we add the common elements to the bin and run gst_pipeline_pads_autoplug. this -function will loop over the pads of the previous element and the one we -just added, and tries to connect src to sink if possible. - -If a connection between the two elements could not be made, a signal "new_pad" -is connected to the element so that pad connection can occur later on when -the pad is actually created. - -ex. when we compare the two lists we see that we have common element: mpeg1parse. - - we add this element to the bin and try to connect it to the previous element in - the bin, the disksrc. - - we see that the src pad of the disksrc and the sinkpad of the mpeg1parse element - can be connected because they are compatible. We have a pipeline like: - - ---------) (-------- - disksrc ! ! mpeg1parse - src --- sink - ---------) (-------- - - -2d) phase4: add remaining elements ----------------------------------- - -now we loop over all the list and try to add the remaining elements - -(HACK) we always use a new thread for the elements when there is a common -element found. - -if a new thread is needed (either bacuase the previous element is a common -element or the object flag of the next element is set to GST_SUGGEST_THREAD) -we add a queue to the bin and we add a new thread. We add the elements to -the bin and connect them using gst_pipeline_pads_autoplug. - -If we add a queue, we have to copy the caps of the sink element of the queue -to the src pad of the queue (else they won't connect) - -we finally arrive at the sink element and we're done. - -ex. - - we have just found our mpeg1parse common element, so we start a thread. - We add a queue to the bin and a new thread, we add the elements - mp1videoparse and mpeg_play to the thread. We arrive at the videosink, we - see that the SUGGEST_THREAD flag is set, we add a queue and a thread and - add the videosink in the thread. - - the same procedure happens for the audio part. We are now left with the - following pipeline: - - We will also have set a signal "new_pad" on the mpeg1parse element because - the element mp1videoparse could not be connected to the element just yet. - - (------------------------------------) (---------- - !thread ! ! thread - ! (-------------) (---------) ! ! (---------) - ! !mp1videoparse! !mpeg_play! ! ! !videosink! - videoqueue--sink src -- sink src -- queue --- sink ! - ---------) (-----------) ! (-------------) (---------) ! ! (---------) - disksrc ! ! mpeg1parse! (------------------------------------) (------------- - src --- sink ! - ---------) (-----------) - queue----- same for audio - - - then we play, create_plan happens, data is flowing and the "new_pad" signal is called - from mpeg1parse, gst_pipeline_pad_autoplug is called and the connection between - mpeg1parse and the videoqueue is made. same for audio. - - voila. smame procedure for mp3/vorbis/avi/qt/mpeg2 etc... - - -Problems: ---------- - -this is obviously a very naive solution. the creation of the elements actually happens -beforehand. MPEG2, for one, fails because there are multiple possibilities to go -from the mpeg demuxer to audio/raw (ac3, mp3) - -Also any intermedia elements like mixers (subtitles) are not possible because we -assume that after the common elements, the streams to not converge anymore. - - - - - - - - - - - - - - - - - - - diff --git a/docs/random/autoplug2 b/docs/random/autoplug2 deleted file mode 100644 index f3374b693f..0000000000 --- a/docs/random/autoplug2 +++ /dev/null @@ -1,289 +0,0 @@ - -1) The Autoplugger API ----------------------- - -We'll first describe how to use the autoplugger. We will provide -a use case: autoplug an mpeg1 system stream for audio/video playback. - - -a) creating an autoplugger --------------------------- - -Before any autoplugging can be done, you'll have to create an -autoplugger object. Autoplugger objects (autopluggers) are -provided by plugins and are created with gst_autoplugfactor_make(). - -GStreamer has provisions for two types of autopluggers: - - - regular autopluggers, which act as a complex element construction - mechanism. They usually don't create threads and operate solely on - GstCaps* for the source and destination. The complex elements - created by regular autopluggers have src and sink pad compatible - with the requested GstCaps*. - - - renderer autopluggers, which are designed to create a complex - object that can be used to playback media. Renderer autoplugged - complex elements have no src pads, only one sink pad. - -We'll create a renderer autoplugger like this: - -! -! GstAutoplug *autoplug; -! -! autoplug = gst_autoplugfactory_make ("staticrender"); -! - - -b) finding out the source media type. -------------------------------------- - -Before we can start the autoplugger, we have to find out the -source media type. This can be done using the typefind functions -provided by various plugins. - -We will create a little pipeline to detect the media type by connecting -a disksrc element to a typefind element. The typefind element will -repeatedly call all registered typefind functions with the buffer it -receives on its sink pad. when a typefind function returns a non NULL -GstCaps*, that caps is set to the sink pad of the typefind element and -a signal is emitted to notify the app. - -Due to caps negotiation, the disksrc will have the detected GstCaps* -set on its src pad. - -We typically use a function like below to detect the type of a media stream -on an element (typically a disksrc). The function accepts a pipeline and the -element inside the pipeline on which the typefind should be performed (passing -a GstPad* is probably a better option FIXME). - -! -! static GstCaps* -! gst_play_typefind (GstBin *bin, GstElement *element) -! { -! GstElement *typefind; -! GstCaps *caps = NULL; -! -! typefind = gst_elementfactory_make ("typefind", "typefind"); -! g_return_val_if_fail (typefind != NULL, FALSE); -! -! gst_pad_connect (gst_element_get_pad (element, "src"), -! gst_element_get_pad (typefind, "sink")); -! -! gst_bin_add (bin, typefind); -! -! gst_element_set_state (GST_ELEMENT (bin), GST_STATE_PLAYING); -! -! // push a buffer... the have_type signal handler will set the found flag -! gst_bin_iterate (bin); -! -! gst_element_set_state (GST_ELEMENT (bin), GST_STATE_NULL); -! -! caps = gst_pad_get_caps (gst_element_get_pad (element, "src")); -! -! gst_pad_disconnect (gst_element_get_pad (element, "src"), -! gst_element_get_pad (typefind, "sink")); -! gst_bin_remove (bin, typefind); -! gst_object_unref (GST_OBJECT (typefind)); -! -! return caps; -! } -! - -Also note that the disksrc was added to the pipeline before calling this -typefind function. - -When the function returns a non-NULL pointer, the media type has been -determined and autoplugging can commence. - -Assume that in our mpeg1 use case the above function returns a GstCaps* -like: - -! -! srccaps = GST_CAPS_NEW ("mpeg1system_typefind", -! "video/mpeg", -! "mpegversion", GST_PROPS_INT (1), -! "systemstream", GST_PROPS_BOOLEAN (TRUE) -! ); -! - - -c) Performing the autoplugging ------------------------------- - -Since we use the renderer API, we have to create the output elements -that are going to be used as the final sink elements. - -! -! osssink = gst_elementfactory_make("osssink", "play_audio"); -! videosink = gst_elementfactory_make("xvideosink", "play_video"); -! - -We then create a complex element using the following code. - -! -! new_element = gst_autoplug_to_renderers (autoplug, -! srccaps, -! videosink, -! osssink, -! NULL); -! -! if (!new_element) { -! g_print ("could not autoplug, no suitable codecs found...\n"); -! exit (-1); -! } -! - -2) Autoplugging internals -------------------------- - -We will now describe the internals of the above gst_autoplug_to_renderers() -function call. This code is implemented in a plugin found in: - - gst/autoplug/gststaticautoplugrender.c - - - -a) phase1: create lists of factories. ---------------------------------------- - -The autoplugger will start with executing the following piece of -code: - -! -! i = 0; -! -! for each sink: -! { -! sinkpad = take the first sinkpad of the sink (HACK) -! -! list[i] = gst_autoplug_caps (srccaps, sinkpad->caps); -! -! i++; -! } -! - -gst_autoplug_caps will figure out (based on the padtemplates) -which elementfactories are needed to connect srccaps to sinkpad->caps -and will return them in a list. - -The element list is created by using a modified shortest path algorithm -by Dijkstra (http://www.orie.cornell.edu/~or115/handouts/handout3/handout3.html). -The nodes of the graph are the elementfactories and the weight of the -arcs is based on the pad compatibility of the padtemplates of the -elementfactory. For incompatible elementfactories, we use a weight of -MAX_COST (999999) and for compatible padtemplates we use 1. - -ex. we have two sinks with following caps: - -! -! video/raw audio/raw -! "...." "...." -! - -gst_autoplug_caps will figure out that for the first sink the following -elements are needed: - -! -! mpeg1parse, mp1videoparse, mpeg_play -! - -for the second sink the following is needed: - -! -! mpeg1parse, mad -! - -Note that for the audio connection the element list "mpeg1parse, mp3parse, -mpg123" would also connect the srccaps to the audiosink caps. Since the -"mpeg1parse, mad" list is shorter, it it always preferred by the autoplugger. - -We now have two lists of elementfactories. - - -b) phase2: collect common elements from the lists and add them to a bin. ------------------------------------------------------------------------- - -The rationale is that from the lists we have created in phase1, there -must be some element that is a splitter and that it has to come first (HACK) -We try to find that element by comparing the lists until an element differs. - -We start by creating a toplevel bin that is going to be our complex element. - -In our use-case we find that mpeg1parse is an element common to both lists, -so we add it to the bin. We then try to find a good ghostpad for the resulting -complex element. This is done by looping over the sink pads of the first common -element and taking the pad that is compatible with the srcaps. - -We end up with a bin like this: -! -! (----------------------) -! ! autoplug_bin ! -! ! ! -! ! (------------) ! -! ! ! mpeg1parse ! ! -! ! - sink ! ! -! ! / (------------) ! -! sink ! -! (----------------------) -! - - -c) phase3: add remaining elements ---------------------------------- - -now we loop over all the list and try to add the remaining elements - -(HACK) we always use a new thread for the elements when there is a common -element found. - -if a new thread is needed (either because the previous element is a common -element or the object flag of the next element is set to GST_SUGGEST_THREAD) -we add a queue to the bin and we add a new thread. We add the elements to -the bin and connect them using gst_pipeline_pads_autoplug. - -we finally arrive at the sink element and we're done. - -ex. - - we have just found our mpeg1parse common element, so we start a thread. - We add a queue to the bin and a new thread, we add the elements - mp1videoparse and mpeg_play to the thread. We arrive at the videosink, we - see that the SUGGEST_THREAD flag is set, we add a queue and a thread and - add the videosink in the thread. - - the same procedure happens for the audio part. We are now left with the - following pipeline: - - We will also have set a signal "new_pad" on the mpeg1parse element because - the element mp1videoparse could not be connected to the element just yet. - - (---------------------------------------------------------------------------------------------) - !autoplug_bin ! - ! ! - ! (----------------------------------------) (------------) ! - ! !thread ! ! thread ! ! - ! (-----) ! (-------------) (---------) (-----) ! ! (---------)! ! - ! !queue! ! !mp1videoparse! !mpeg_play! !queue! ! ! !videosink!! ! - ! sink src-sink src-sink src-sink src-sink !! ! - ! (-----------) (-----) ! (-------------) (---------) (-----) ! ! (---------)! ! - ! ! mpeg1parse! (----------------------------------------) (------------) ! - ! - sink ! ! - ! / (-----------) ! - sink (----------------------------------------) (------------) ! - ! !thread ! ! thread ! ! - ! (-----) ! (-------------) (-----) ! ! (---------)! ! - ! !queue! ! !mad ! !queue! ! ! !videosink!! ! - ! sink src-sink src ------------ sink src-sink !! ! - ! (-----) ! (-------------) (-----) ! ! (---------)! ! - ! (----------------------------------------) (------------) ! - (---------------------------------------------------------------------------------------------) - - The autoplugger will return the autoplug_bin. the app will then connect the - disksrc to the sinkpad of the autoplugged bin. - - Then we play, create_plan happens, data is flowing and the "new_pad" signal is called - from mpeg1parse, gst_pipeline_pad_autoplug is called and the connection between - mpeg1parse and the videoqueue is made. same for audio. - - Et voila. same procedure for mp3/vorbis/avi/qt/mpeg2 etc... - diff --git a/docs/random/bbb/streamselection b/docs/random/bbb/streamselection deleted file mode 100644 index 234782e263..0000000000 --- a/docs/random/bbb/streamselection +++ /dev/null @@ -1,85 +0,0 @@ -Stream selection -= - -1. Problem -URIs (that being either a media stream or a media stream plus subtitle) can -contain multiple streams of a type (audio, subtitle). A user has to be given -the option of selecting one of those streams (or none altogether). - -2. Implementation ideas -Stream selection, in GStreamer, has to be integrated at the player plugging -level, which is (in the case of Totem) playbin. Playbin offers a feature to -'mute' a stream (which means that no processing is done on that stream -altogether, saving the decoding step). Currently, playbin will select the -first occurrence of a stream type and mute all others. A queue is connected -(for pre-roll) to the active stream. What is missing here is a way to change -the active stream. -Playbin interface - one possible interface could simply consist of a bunch of -GObject properties: 'textstream' and 'audiostream', both integer. The number -of available streams can be retrieved using the 'stream-info' GObject property. -Similar to the 'nstreams' property, we could add utility GObject properties -for getting the number of available audio/text streams ('naudiostreams' and -'ntextstreams'). Names of these streams (like language name or so) can be -added as an additional GObject property to streaminfo. Some container -formats contain such names internally. Alternatively, we could allow those -to be user-settable as well (for .sub files). -On a set of either of these properties, playbasebin would mute the old -selected stream (if any), unmute the newly selected stream (if any) and -replug the preroll queue. The queue itself is disabled as well if no new -stream was linked. Alternatively, a switch-like element is used, which -requires no replugging. Pad disabling/enabling is then enough. This also -makes relinking less painful. The switch-like element needs to proxy the -active pads' caps. However, since those caps are (in practice) always the -same across streams, caps setting will (inside the core) immediately -return success. -The switch-like element simply works like this: -= -static void -loop_func (GstElement * element) -{ - GList *inpads; - GstPad *pad; - GstData *data; - - for (inpads = ..; inpads != NULL; inpads = inpads->next) { - pad = inpads->data; - if (!GST_PAD_IS_USABLE (pad)) - continue; - - /* you'd also want some way to synchronize the inputs... */ - data = gst_pad_pull (pad); - if (is_active_pad (pad)) - gst_pad_push (srcpad, data); - else - gst_data_unref (data); - } -} -= -It'd require an active-stream property itself, which (when set) takes -care of doing renegotiation and so on. Using internal pad linkage is -extremely useful here, and requires little code in the switch-like -element itself. Note that there is a slight bit of duplication in the -playbin interface and the switch-like element interface, but that's "just -the way it is". -The implementation of the switch-like element could initially be local to -playbin, until it has been cleaned up and confirmed to be useful to a -wider audience. This allows a lot of experimenting with interfaces because -we won't be forced to maintain a stable interface. -The current 'switch' element (gst-plugins/gst/switch/) already does a few -of those operations, but stream synchronization, re-negotiation on stream -changes, internal pad linkage and some other things are completely missing. -If we're gonna use this element, it'll need a large overhaul. The choice of -writing a new element or using an existing element as basis, and also the -choice of whether or not to make this element local to playbin, should be -based on technical merits and cost/effect analysis and not on personal -pride. - -Notes: -* seamless has the same switch-like element, but it's chain-based. Apart -from scheduler considerations, this is a good idea, but limits its use -(making either good docs and abuse-prevention [see multifilesrc] or -private-to-playbin a prerequisite). -* maybe text-* properties need to be renamed to subtitle-*. - -3. Written by -Ronald S. Bultje - Jan. 2nd, 2005. diff --git a/docs/random/bbb/subtitles b/docs/random/bbb/subtitles deleted file mode 100644 index 6cbe204036..0000000000 --- a/docs/random/bbb/subtitles +++ /dev/null @@ -1,105 +0,0 @@ -Subtitles -========= - -1. Problem -GStreamer currently does not support subtitles. - -2. Proposed solution - - Elements - - Text-overlay - - Autoplugging - - Scheduling - - Stream selection - -The first thing we'll need is subtitle awareness. I'll focus on AVI/MKV/OGM -here, because I know how that works. The same methods apply to DVD subtitles -as well. The matroska demuxer (and Ogg) will need subtitle awareness. For -AVI, this is not needed. Secondly, we'll need subtitle stream parsers (for -all popular subtitle formats), that can deal both with parsed streams (MKV, -OGM) as well as .sub file chunks (AVI). Sample code is available in -gst-sandbox/textoverlay/. - -Secondly, we'll need a textoverlay filter that can take text and video and -blits text on video. We have several such elements (e.g. the cairo-based -element) in gst-plugins already. Those might need some updates to work -exactly as expected. - -Thirdly, playbin will need to handle all that. We expect subtitle streams -to end up as subimages or plain text (or xhtml text). Note that playbin -should also allow access to the unblitted subtitle as text (if available) -for accessibility purposes. - -A problem popping up is that subtitles are no continuous streams. This is -especially noticeable in the MKV/OGM case, because there the input of data -depends on the other streams, so we'll only notice delays inside an element -when we've received the next data chunk. There are two possible solutions: -using timestamped filler events or using decoupled subtitle overlay elements -(bins, probably). The first has as a difficulty that it only works well in -the AVI/.sub case, where we will notice discontinuities before they become -problematic. The second is more difficult to implement, but works for both -cases. -A) fillers -Imagine that two subtitles come after each other, with 10 seconds of no-data -in between. By parsing a .sub file, we would notice immediately and we could -send a filler event (or empty data) with a timestamp and duration in between. -B) decoupled -Imagine this text element: ------------------------------- -video ----- | actual element |out -| / -----------------| -text - - | ------------------------------- -where the text pad is decoupled, like a queue. When no text data is available, -the pad will have received no data, and the element will render no subtitles. -The actual element can be a bin here, containing another subtitle rendering -element. Disadvantage: it requires threading, and the element itself is (in -concept) kinda gross. The element can be embedded in playbin to hide this -fact (i.e. not be available outside the scope of playbin). -Whichever solution we take, it'll require effort from the implementer. -Scheduling (process, not implementation) knowledge is assumed. - -Stream selection is a problem that audio has, too. We'll need a solution for -this at the playback bin level, e.g. playbin. By muting all unused streams -and dynamically unmuting the selected stream, this is easily solved. Note -that synchronization needs to be checked in this case. The solution is not -hard, but someone has to do it. - -3. Written by -Ronald S. Bultje , Dec. 25th, 2004 - - -Appendix A: random IRC addition - intersting question: would it be a good idea to have a "max-buffer-length" property? - that way demuxewrs would now how often they'd need to generate filler events - s/now/know/ - hm... - I don't think it's good to make that variable - dunno - (i'm btw always looking at this from the midi perspective, too) - (because both subtitles and midi are basically the same in this regard) - and do you mean 'after the stream has advanced