On 03/25/2011 05:23 PM, Edward Hervey wrote:
Yes, with playbin2/decodebin2 you can change the order of codecs/plugins being used. By default it will use the one with the highest rank matching the stream to decode, but you can connect to the 'autoplug-factories' signal and reorder those plugins to have it use the software one or the hardware one.
Thanks!
I was planning to familiarize with this as soon I found some time to do it. At first sight, the elements ranking mechanism in gstreamer seems to need some generalization in common. The auto-select fea might be in shape with some bins but afaik bins aren't using any common APIs for this. Static rank bundled with elements that are distributed in decentralized way does not seem effective.
I asked questions about this a few days ago @#gstreamer and had to back up to think what are the real use cases that could benefit from centralized or even dynamic ranking of elements. I'm not well experienced with gstreamer in general, but have designed & implemented MM middleware for Windows and addressed the same common problems there. So, gstreamer might surprise me eventually, but I want to propose centralized ranking mechanism to be considered and maybe dealt with UMMS effort.
* The amount of meego adaptations that supporting varying devices in public oss will grow. They are all heading to use as much of generic core as they can. Now, these devices will need their specific gstreamer pipelines, elements or just sub-components as omx etc. Atm. there are areas where adaptations need to collaborate on elements selection logic above gstreamer and the hacks will flood eventually if not re-factored. The core packaging can have only single ranking for elements. Instead of collaborating into framework(s) itself, adaptations could just provide a configuration. So far simple, but with the requirement to be expandable the configuration becomes complex and requires suitable language.
* The request is not only in scope of codecs, but the sources and filters as well. Man cannot say the type of content before it gets examined. Depending on content & transport the detection might get heavy or even impossible. In these cases, a specified pipeline for particular use case is a ok solution, but it could be made possible to fixate such without implementing new branches of Meego applications or even worse the framework.
* In terms of dynamic configuration for element ranking, the feature would be a great development tool at first. But I can see scenarios that could benefit from it in terms of framework generalization - but I'm afraid it would mean creating just-another-bin.
I would propose an API that splits the complexity out of the exported functions and gathers the complexity into the configuration hold in tree hierachy of use cases. Well, regardless of the defined API, I ponder that the above ranking configuration could be somehow solved with UMMS in general and be part of the configuration needed in other sense as well.
So, lets consider a sequence where custom gstreamer pipeline gets created. Source is a bit specific, so lets skip it. In next step the mimetype should be known and the content may contain uncompressed content so the list of suitable elements is long. The decisions that categorizes this list currently with gstreamer is about selecting the suitable GstBin for the use case. Instead of this Application, Qt backend, or UMMS wrapper could pick up an interface and fetch the info about elements that can be connected. This info can base on external configuration which contain the categories describing the complete tree hierarchy of use cases. E.g. XML is suitable and expandable for this. When the code continues initiating new elements to pipeline, the available configuration for next step focuses on hierarchy and provide the available options for each step. This approach allows backend(s) developer to think 80/20, fixate only on things that are the most common and transparently provide the support of options shown with the UI.
Let's consider some of todays use cases with the camera application. Application is not interested in source and just initiates the API that falls into its defaults with gstreamer/camerabin logic. Viewfinder gets created and the formats for image and video to be captured are somewhat seen with settings dialog. User browses the web, downloads and installs new support for Meego to encode some specific format, then he goes to the camera applications setting dialog again and sees that the format is now available to use. This is the rest 20 that users want to control and the device adaptation could provides the 80 so that users can be ignorant. However, elements with high ranks can get installed similarly or as part of other applications without a notice and the application falling in automation gets unreliable. External configuration could be used to blacklist the elements that aren't shown to user or used as part of the automation. All the support that the above description will need should be provided as a common feature of Meego mm-framework(s), regardless of the use case and application.
Those aware of the mechanism within MS Directshow know that the ability to manipulate ranking by user configuration does make things even worse. Generic and fool-proof automation doesn't fit in the same world, but with agreed policies and commonly defined use cases such thing would really lease the complexity of multimedia stack in Meego and lease the need to collaborate on core frameworks themselves to carry out adaptation tasks.
BR, -Teemu _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
