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

[Rob C. <ro...@ti...>]

On Mar 25, 2010, at 12:53 PM, Felipe Contreras wrote:

> 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.


no, not magic.. just a task that I've seen frequently underestimated ;-)


> 
>> 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.


yeah.  And it would be interesting to see more other gst elements, like demuxers, utilizing pad_alloc()..  then it would be interesting to implement a GstOmxBuffer and implement pad_alloc handler.


BR,
-R


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