From: Sidharth R <sv...@ya...> - 2010-03-25 04:12:19
|
Sir, As per the following link : http://github.com/felipec/gst-openmax there has not been any updation on the source code associated with tunneling after 27th April 2009. Is the tunneling branch merged with the master branch of gst-openmax? Is tunneling fully functional in gst-openmax? Kindly reply to the above queries regarding tunneling. Sidharth Varier |
From: Felipe C. <fel...@gm...> - 2010-03-25 10:15:20
|
Hi, On Thu, Mar 25, 2010 at 6:12 AM, Sidharth R <sv...@ya...> wrote: > As per the following link : > http://github.com/felipec/gst-openmax > > there has not been any updation on the source code associated with tunneling after 27th April 2009. Is the tunneling branch merged with the master branch of gst-openmax? Is tunneling fully functional in gst-openmax? > > Kindly reply to the above queries regarding tunneling. 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. Cheers. -- Felipe Contreras |
From: Rob C. <ro...@ti...> - 2010-03-25 16:37:13
|
On Mar 25, 2010, at 5:15 AM, Felipe Contreras wrote: > Hi, > > On Thu, Mar 25, 2010 at 6:12 AM, Sidharth R <sv...@ya...> wrote: >> As per the following link : >> http://github.com/felipec/gst-openmax >> >> there has not been any updation on the source code associated with tunneling after 27th April 2009. Is the tunneling branch merged with the master branch of gst-openmax? Is tunneling fully functional in gst-openmax? >> >> Kindly reply to the above queries regarding tunneling. > > 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. 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. (That said, transcoding and some other edge cases like that, perhaps tunneling could be a good idea.. but then you don't need to replace GStreamer base classes for that.) Just my $0.02 :-) BR, -R |
From: Felipe C. <fel...@gm...> - 2010-03-25 17:53:19
|
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 |
From: Rob C. <ro...@ti...> - 2010-03-25 19:23:54
|
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 |
From: Felipe C. <fel...@gm...> - 2010-03-25 19:57:11
|
On Thu, Mar 25, 2010 at 9:23 PM, Rob Clark <ro...@ti...> wrote: > 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. It doesn't make sense for a demuxer to do pad_alloc(). Imagine an efficient scenario where the filesrc mmaps the entire clip, then demuxer, some way or the other starts parsing the data and finds the interesting frames, then what? There are only two options: 1) pad_alloc() and memcpy 2) create a sub-buffer and push it For obvious reasons demuxers prefer 2), many decoders can operate directly on the data, and others, such as the ones in gst-dsp can mmap the data and make the DSP algo work on the system memory. So no, I don't see any point in demuxers doing pad_alloc(). Cheers. -- Felipe Contreras |