[Celinux-dev] AudioVideoGraphicsSepc_V2

[Ruud Derwig]

Hi Shaun,

Shaun Savage wrote on 14-08-2006 23:31:45:

> The open source implementation of UHAPI is almost a year old with no
> updates.  Gstreamer is being actively worked upon.   If I was a open
> source developer (Which I am) why would I pick a unmaintained, 
> unused library when I could use a actively developed library, with 
> active mailing list? 

Fair question, let me try and explain some things.

Goal of the AVG Specification is to reduce fragmentation and provide 
direction on interfaces (APIs), not implementation. Given the enormous 
diversity in CE hardware platforms, sharing (optimized) implementations is 
difficult. Probably at most 'infrastructure' components like the GStreamer 
framework are worthwhile to have a "common" open source implementation 
for. But also for GStreamer several alternatives exist, some better suited 
e.g. for an implementation in software on a powerfull CPU, some better 
suited for (controlling) an implementation in hardware.

When defining V2 of the specification, we did consider GStreamer. It is a 
great implementation framework for media processing, but it does not 
define standard interfaces for specific AVG functions. There are some 
'standard' GStreamer components (plug-ins), but certainly the breadth of 
functionality needed for developing e.g. a hybrid analog/digital TV is not 
covered.

The AVG V2 specification and GStreamer serve different purposes, and are 
complementory. GStreamer is referenced in the specification in section 
4.2, part of work in progress (for your convenience copied below).

The UHAPI4Linux project has chosen to build on other open source projects 
for implementing the interfaces. It uses e.g. V4L and Linux DVB. It could 
have chosen to build on top of GStreamer, but it didn't.
As you have seen, the UHAPI4Linux project has not been very active. I 
could think of many reasons for that, one being that UHAPI4Linux is not 
the only way of implementing the AVG specification. A number of companies 
have/are developing own implementations optimized for their specific 
hardware platforms. The UHAPI4Linux project has served as a basis for 
getting started with own implementations.
Though not active, the UHAPI4Linux project is being maintained (did you 
try sending e-mail to the mailing list?).
And at the moment, Denis O. Kropp is working on implementing the 
combination of UHAPI VMixer and DirectFB as described in the AVG spec, so 
you can expect some updates coming month.

Now, coming back to your question, it's not an 'UHAPI4Linux vs. GStreamer' 
choice you have. GStreamer helps you in implementing media processig. 
UHAPI4Linux helps you in 'glueing' a standard API on top of your 
implementation.


Regards,

Ruud - AVGWG chair
-----
4.2     Media Processing Frameworks 
There are several interesting developments in the domain of media 
processing frameworks. The Khronos group is finishing the OpenMax 
specification, and the open source Gstreamer solution is being used in a 
number of CE devices or being investigated. A next version of the AVG 
specification will include a specification for media processing framework. 
For now, we only mention a number of considerations.
Media Processing Frameworks can be used to implement audio and video 
system functionality by creating graphs of audio/video processing 
components, codecs, sources and sinks. A media processing framework 
facilitates connecting components and takes care of communicating and 
buffering of data between components. The main function of media 
processing frameworks is this streaming functionality, also called 
‘sidebar connections’. Codecs, source, sink and filter components have 
also functional control interfaces, e.g. to set the volume level or 
brightness. Since the CELF AVG specification recommends specific 
interfaces for this functional control in the previous sections, a media 
processing framework should match with these interfaces. A framework 
should not define control interfaces itself, or it should define 
lower-level interfaces on top of which the CELF interfaces can be 
realized.
--- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tree.celinuxforum.org/pipermail/celinux-dev/attachments/20060815/8a7eb06c/attachment.html