Re: [Gstreamer-openmax] Tunneling in gst-openmax

[Felipe C. <fel...@gm...>]

On Thu, Mar 25, 2010 at 6:37 PM, Rob Clark <ro...@ti...> wrote:
> On Mar 25, 2010, at 5:15 AM, Felipe Contreras wrote:
>> There has been some progress regarding tunneling, however, it was
>> found that GStreamer's base classes are not going to work for this
>> feature. More work will be needed before this feature lands in master.
>> My personal opinion is that we should stop trying to use GStreamer's
>> base classes and implement the sources/sinks from scratch that fit
>> omx. However, I do not have time to play with this idea right now.
>
> note that not using GStreamer's base classes for src/sink elements also means not using GStreamer's A/V sync, etc.

Not really. GStreamer's base classes achieve A/V sync with code, not
magic, and gst-omx base classes can do the same thing. I don't think
it would be _that_ difficult, but we would have to wait and see.

> On the other hand, it seems that khronos is on the verge of approving a change to allow "non-pre-announced" buffers (essentially officially allowing IL client to do pBuffer pointer copies instead of memcpy's) which in most cases is just as good as tunneling without all the drawbacks.
>
> So IMO, most use-cases where you think tunneling is a good idea, it is probably not.

Completely agree. Perhaps there are some very advanced use-cases where
tunneling might provide a marginal advantage, but I don't think
tunneling is worth the trouble at this point in time. Even now sharing
buffers a la GStreamer's pad_alloc() is far from being exploited
properly, so we should probably start with that.

That being said tunneling is by far the most requested (only?) feature
of gst-omx.

Cheers.

-- 
Felipe Contreras