[Gstreamer-openmax] Tunneling in gst-openmax
felipe.contreras at gmail.com
Thu Mar 25 10:53:12 PDT 2010
On Thu, Mar 25, 2010 at 6:37 PM, Rob Clark <rob at ti.com> 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
More information about the Gstreamer-openmax