Http://www.doc88.com/p-8985391206739.html
2.1.2. "One target" media Player/Media Library
A typical MPEG player can play MPEG video and audio, and most players implement a complete bottom-up construct to reach their sole goal: play. There is no set of effective mechanisms available to provide filtering and effect processing for audio and video data, or any provision for adding filters or special effects in video or audio data.
If you want to convert the MPEG-2 video stream to an AVI file, your best option is to separate all the MPEG-2 decoding algorithms from the player and copy them into your AVI encoder, because such algorithms cannot be easily shared between applications.
Developers have tried to create a library that can handle a variety of media types, but because of the lack of a common API, how to integrate is important. Because in the process of integration, we need to pay attention to some special media types (AVI files, LIBMPEG2, ...), and the integration of these media type files requires a unified interface. GStreamer allows these libraries to be packaged with common APIs, simplifying integration and reuse.
2.1.3. No unified plug-in management mechanism
A typical player for different media types will have different plug-ins, two media players will implement their own different plug-in mechanism, so the codec is not easy to exchange. Each typical media player's plug-in management system is a requirement for its specific application.
The lack of a unified plug-in mechanism has severely hampered the development of binary codecs because no company wants to port code to different plug-in mechanisms.
GStreamer of course also uses its own plug-in system, which provides plug-in developers with a very rich framework to ensure that these plug-ins can be widely used and can interact seamlessly with other plugins. The framework provided by GStreamer for plug-ins is very flexible enough to meet the needs of most plug-ins.
2.1.4. A poor sense of user
Because of these problems, application developers spend a considerable amount of time on how to deal with the backend, plug-in mechanism, and so on. This delays most of the project time, which often results in half of the backend and user interface, resulting in a poor sense of user.
2.1.5. Lack of internet transparency provisions
There is currently no underlying framework to allow the operation of transparent media on the network. Interestingly, a distributed MPEG encoder can replicate the same algorithm for non-distributed encoders.
There is no provision for the use of GNOME and KDE desktop technologies, as the GNOME and KDE desktop platforms themselves are still being improved and perfected, making it difficult to integrate multimedia properly into many users ' environments. Note that GStreamer also offers a number of methods that provide the integration of Gsreamer with different desktop systems (see the Integration section in the appendix), which are often not network-transparent.
The GStreamer kernel does not use network transparency at the very bottom, just adds it as a local use on the top level, which means that it is easier to create a package of core components. GStreamer allows the pipeline to be detached on the TCP protocol, using TCP plug-ins to implement the GStreamer data protocol, which is included in the Gst-plugins module, directory gst/tcp
2.1.6. There is still a gap between the products and windows™
We want to see the success of Linux desktop system based on reliable media processing.
We must clear the way for commercial codecs and multimedia applications so that Linux can be a choice in the multimedia field.
2.2. Design goals
We will describe the objectives in the development of GStreamer.
2.2.1. Clear and powerful structure
GStreamer provides a clear set of interfaces to some of the following developers:
L want to build a media pipeline for the application staff. Programmers can use a series of powerful tools to create media pipelines without having to write a single line of code, making complex media controls very simple.
L Plugin programmer. GStreamer provides a simple and simple API to plug-in programmers to create self-plugin (self-contained) plug-ins, while also integrating a large number of debugging and tracing mechanisms and tools. GStreamer also provides a series of practical examples.
2.2.2. Object-Oriented programming ideas
GStreamer is attached to the GLib 2.0 object model, programmers familiar with glib or older versions of GTK + will be comfortable with GStreamer.
GStreamer uses the mechanism of signal and object properties.
The properties and functions of all objects can be queried in the run state.
GStreamer is very similar to GTK + programming methods, requires object model, object All (ownership of objects), reference calculation (reference counting) ...
2.2.3. Flexible and scalable performance
All GStreamer objects can be extended using the GObject inheritance method.
All plugins can be dynamically loaded and can be expanded or upgraded independently.
2.2.4. Enabling plugins to be released in binary form
A plug-in that is published as a shared library can be loaded directly in the run state, and all properties of the plug-in can be set by the GObject property without (in fact never) installing the plug-in's header file.
We are more concerned about the plug-in can be independent, when the operation of the need for a lot of plug-in-related factors.
2.2.5. High performance
High performance is mainly reflected in:
L use GLib's g_mem_chunk and non-modular allocation algorithms to minimize memory allocation.
The connection between the plugins is very light (light-weight). Data passing through the pipeline uses minimal consumption, and data passing between the plug-ins in the pipeline only involves pointer abandonment.
L provides a set of mechanisms for direct operation of the target memory. For example, a plug-in can write data directly to the memory space shared by X server, and the buffer can point to any memory, such as the internal hardware buffer of a sound card.
L refcounting and write copies reduce memcpy to a minimum. The child buffers effectively separate the buffers into manageable chunks.
L Use thread Federation (COTHREADS) to reduce thread consumption. Thread Federation (COTHREADS) is a simple and high-speed way to switch subroutines as a measure of the minimum consumption of 600 CPU cycles.
L Use special plug-ins to support hardware acceleration.
L Use the plugin with instructions to register, so that only the actual need to use the plug-in will be loaded.
All the judgment data are not mutually exclusive lock.
2.2.6. Separation of core libraries from plug-ins (core/plugins)
The essence of the GStreamer kernel is media-agnostic, we know only bytes and blocks, as well as the basic components, gstreamer the power of the kernel can even implement the underlying system tools, like CP.
All media processing functions are provided externally to the kernel by plugins and tell the kernel how to handle specific media types.