Re: [st-ericsson] v4l2 vs omx for camera
Locked
12
12
Re: [st-ericsson] v4l2 vs omx for camera
 
|
On Thu, Feb 24, 2011 at 3:27 PM, Laurent Pinchart
<[hidden email]> wrote: >> > Perhaps GStreamer experts would like to comment on the future plans ahead >> > for zero copying/IPC and low power HW use cases? Could Gstreamer adapt >> > some ideas from OMX IL making OMX IL obsolete? >> >> perhaps OMX should adapt some of the ideas from GStreamer ;-) > > I'd very much like to see GStreamer (or something else, maybe lower level, but > community-maintainted) replace OMX. Yes, it would be great to have something that wraps all the hardware acceleration and could have support for software codecs too, all in a standard interface. It would also be great if this interface would be used in the upper layers like GStreamer, VLC, etc. Kind of what OMX was supposed to be, but open [1]. Oh wait, I'm describing FFmpeg :) (supports vl42, VA-API, VDPAU, DirectX, and soon OMAP3 DSP) Cheers. [1] http://freedesktop.org/wiki/GstOpenMAX?action=AttachFile&do=get&target=gst-openmax.png -- Felipe Contreras _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
On Saturday, February 26, 2011 14:38:50 Felipe Contreras wrote:
> On Thu, Feb 24, 2011 at 3:27 PM, Laurent Pinchart > <[hidden email]> wrote: > >> > Perhaps GStreamer experts would like to comment on the future plans ahead > >> > for zero copying/IPC and low power HW use cases? Could Gstreamer adapt > >> > some ideas from OMX IL making OMX IL obsolete? > >> > >> perhaps OMX should adapt some of the ideas from GStreamer ;-) > > > > I'd very much like to see GStreamer (or something else, maybe lower level, but > > community-maintainted) replace OMX. > > Yes, it would be great to have something that wraps all the hardware > acceleration and could have support for software codecs too, all in a > standard interface. It would also be great if this interface would be > used in the upper layers like GStreamer, VLC, etc. Kind of what OMX > was supposed to be, but open [1]. > > Oh wait, I'm describing FFmpeg :) (supports vl42, VA-API, VDPAU, > DirectX, and soon OMAP3 DSP) > > Cheers. > > [1] http://freedesktop.org/wiki/GstOpenMAX?action=AttachFile&do=get&target=gst-openmax.png > > Are there any gstreamer/linaro/etc core developers attending the ELC in San Francisco in April? I think it might be useful to get together before, during or after the conference and see if we can turn this discussion in something more concrete. It seems to me that there is an overall agreement of what should be done, but that we are far from anything concrete. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Linus Walleij
On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij <[hidden email]> wrote:
> 2011/2/24 Edward Hervey <[hidden email]>: > >> What *needs* to be solved is an API for data allocation/passing at the >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that >> userspace (like GStreamer) can pass around, monitor and know about. > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > passing, pinning of buffers and so on. The CMA (Contigous Memory > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > so CMA provides buffers, HWMEM pass them around. > > Johan, when you re-spin the HWMEM patchset, can you include > linaro-dev and linux-media in the CC? I think there is *much* interest > in this mechanism, people just don't know from the name what it > really does. Maybe it should be called mediamem or something > instead... To Marek, Can you also update the CMA status and plan? The important thing is still Russell don't agree the CMA since it's not solve the ARM different memory attribute mapping issue. Of course there's no way to solve the ARM issue. We really need the memory solution for multimedia. Thank you, Kyungmin Park > > Yours, > Linus Walleij > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to [hidden email] > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
Administrator
|
In reply to this post by Hans Verkuil
On Sat, 2011-02-26 at 14:47 +0100, Hans Verkuil wrote:
> On Saturday, February 26, 2011 14:38:50 Felipe Contreras wrote: > > On Thu, Feb 24, 2011 at 3:27 PM, Laurent Pinchart > > <[hidden email]> wrote: > > >> > Perhaps GStreamer experts would like to comment on the future plans ahead > > >> > for zero copying/IPC and low power HW use cases? Could Gstreamer adapt > > >> > some ideas from OMX IL making OMX IL obsolete? > > >> > > >> perhaps OMX should adapt some of the ideas from GStreamer ;-) > > > > > > I'd very much like to see GStreamer (or something else, maybe lower level, but > > > community-maintainted) replace OMX. > > > > Yes, it would be great to have something that wraps all the hardware > > acceleration and could have support for software codecs too, all in a > > standard interface. It would also be great if this interface would be > > used in the upper layers like GStreamer, VLC, etc. Kind of what OMX > > was supposed to be, but open [1]. > > > > Oh wait, I'm describing FFmpeg :) (supports vl42, VA-API, VDPAU, > > DirectX, and soon OMAP3 DSP) > > > > Cheers. > > > > [1] http://freedesktop.org/wiki/GstOpenMAX?action=AttachFile&do=get&target=gst-openmax.png > > > > > > Are there any gstreamer/linaro/etc core developers attending the ELC in San Francisco > in April? I think it might be useful to get together before, during or after the > conference and see if we can turn this discussion in something more concrete. > > It seems to me that there is an overall agreement of what should be done, but > that we are far from anything concrete. > I will be there and this was definitely a topic I intended to talk about. See you there. Edward > Regards, > > Hans > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Kyungmin Park
On Sat, 26 Feb 2011, Kyungmin Park wrote:
> On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij <[hidden email]> wrote: > > 2011/2/24 Edward Hervey <[hidden email]>: > > > >> What *needs* to be solved is an API for data allocation/passing at the > >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > >> userspace (like GStreamer) can pass around, monitor and know about. > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > so CMA provides buffers, HWMEM pass them around. > > > > Johan, when you re-spin the HWMEM patchset, can you include > > linaro-dev and linux-media in the CC? I think there is *much* interest > > in this mechanism, people just don't know from the name what it > > really does. Maybe it should be called mediamem or something > > instead... > > To Marek, > > Can you also update the CMA status and plan? > > The important thing is still Russell don't agree the CMA since it's > not solve the ARM different memory attribute mapping issue. Of course > there's no way to solve the ARM issue. both on the lak mailing list already. 1) Make the direct mapped kernel memory usable by CMA mapped through a page-sized two-level page table mapping which would allow for solving the attributes conflict on a per page basis. 2) Use highmem more aggressively and allow only highmem pages for CMA. This is quite easy to make sure the target page(s) for CMA would have no kernel mappings and therefore no attribute conflict. Furthermore, highmem pages are always relocatable for making physically contiguous segments available. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Edward Hervey
On Saturday 26 February 2011, Edward Hervey wrote:
> > > > Are there any gstreamer/linaro/etc core developers attending the ELC in San Francisco > > in April? I think it might be useful to get together before, during or after the > > conference and see if we can turn this discussion in something more concrete. > > > > It seems to me that there is an overall agreement of what should be done, but > > that we are far from anything concrete. > > > > I will be there and this was definitely a topic I intended to talk > about. > See you there. I'll also be there. Should we organize an official BOF session for this and invite more people? Arnd _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
Hi All,
Linaro is currently collecting requirements for next cycle.If you all agree we can set up a call to discuss what could be interesting things on this topic to work on next cycle and then I can take the ideas generated for approval to Linaro TSC.
Thanks
Sachin
On Mon, Feb 28, 2011 at 1:19 AM, Arnd Bergmann <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Nicolas Pitre
Hello,
On Saturday, February 26, 2011 8:20 PM Nicolas Pitre wrote: > On Sat, 26 Feb 2011, Kyungmin Park wrote: > > > On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij <[hidden email]> wrote: > > > 2011/2/24 Edward Hervey <[hidden email]>: > > > > > >> What *needs* to be solved is an API for data allocation/passing at the > > >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > >> userspace (like GStreamer) can pass around, monitor and know about. > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > > so CMA provides buffers, HWMEM pass them around. > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > linaro-dev and linux-media in the CC? I think there is *much* interest > > > in this mechanism, people just don't know from the name what it > > > really does. Maybe it should be called mediamem or something > > > instead... > > > > To Marek, > > > > Can you also update the CMA status and plan? > > > > The important thing is still Russell don't agree the CMA since it's > > not solve the ARM different memory attribute mapping issue. Of course > > there's no way to solve the ARM issue. > > There are at least two ways to solve that issue, and I have suggested > both on the lak mailing list already. > > 1) Make the direct mapped kernel memory usable by CMA mapped through a > page-sized two-level page table mapping which would allow for solving > the attributes conflict on a per page basis. That's the solution I work on now. I've also suggested this in the last CMA discussion, however there was no response if this is the right way > 2) Use highmem more aggressively and allow only highmem pages for CMA. > This is quite easy to make sure the target page(s) for CMA would have > no kernel mappings and therefore no attribute conflict. Furthermore, > highmem pages are always relocatable for making physically contiguous > segments available. I'm not sure that highmem is the right solution. First, this will force systems with rather small amount of memory (like 256M) to use highmem just to support DMA allocable memory. It also doesn't solve the issue with specific memory requirement for our DMA hardware (multimedia codec needs video memory buffers from 2 physical banks). The relocation issue has been already addressed in the last CMA patch series. Michal managed to create a framework that allowed to relocate on demand any pages from the CMA area. Best regards -- Marek Szyprowski Samsung Poland R&D Center _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Hans Verkuil
On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
> On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > 2011/2/24 Edward Hervey <[hidden email]>: > > > What *needs* to be solved is an API for data allocation/passing at the > > > > > > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > > userspace (like GStreamer) can pass around, monitor and know about. > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > so CMA provides buffers, HWMEM pass them around. > > > > Johan, when you re-spin the HWMEM patchset, can you include > > linaro-dev and linux-media in the CC? > > Yes, please. This sounds promising and we at linux-media would very much > like to take a look at this. I hope that the CMA + HWMEM combination is > exactly what we need. Once again let me restate what I've been telling for some time: CMA must be *optional*. Not all hardware need contiguous memory. I'll have a look at the next HWMEM version. -- Regards, Laurent Pinchart _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Arnd Bergmann
On Sunday, February 27, 2011 20:49:37 Arnd Bergmann wrote:
> On Saturday 26 February 2011, Edward Hervey wrote: > > > > > > Are there any gstreamer/linaro/etc core developers attending the ELC in San Francisco > > > in April? I think it might be useful to get together before, during or after the > > > conference and see if we can turn this discussion in something more concrete. > > > > > > It seems to me that there is an overall agreement of what should be done, but > > > that we are far from anything concrete. > > > > > > > I will be there and this was definitely a topic I intended to talk > > about. > > See you there. > > I'll also be there. Should we organize an official BOF session for this and > invite more people? I think that is an excellent idea. Do you want to organize that? (Always the penalty for suggesting this first :-) ) Regards, Hans _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Arnd Bergmann
On Sunday 27 February 2011 20:49:37 Arnd Bergmann wrote:
> On Saturday 26 February 2011, Edward Hervey wrote: > > > Are there any gstreamer/linaro/etc core developers attending the ELC in > > > San Francisco in April? I think it might be useful to get together > > > before, during or after the conference and see if we can turn this > > > discussion in something more concrete. > > > > > > It seems to me that there is an overall agreement of what should be > > > done, but that we are far from anything concrete. > > > > > I will be there and this was definitely a topic I intended to talk about. > > > > See you there. > > I'll also be there. Should we organize an official BOF session for this and > invite more people? Any chance of an IRC backchannel and a live audio/video stream for those of us who won't be there ? -- Regards, Laurent Pinchart _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
In reply to this post by Laurent Pinchart
On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote:
> On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote: > > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > > 2011/2/24 Edward Hervey <[hidden email]>: > > > > What *needs* to be solved is an API for data allocation/passing at the > > > > > > > > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > > > userspace (like GStreamer) can pass around, monitor and know about. > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > > so CMA provides buffers, HWMEM pass them around. > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > linaro-dev and linux-media in the CC? > > > > Yes, please. This sounds promising and we at linux-media would very much > > like to take a look at this. I hope that the CMA + HWMEM combination is > > exactly what we need. > > Once again let me restate what I've been telling for some time: CMA must be > *optional*. Not all hardware need contiguous memory. I'll have a look at the > next HWMEM version. Yes, it is optional when you look at specific hardware. On a kernel level however it is functionality that is required in order to support all the hardware. There is little point in solving one issue and not the other. Regards, Hans _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
On Monday 28 February 2011 11:21:52 Hans Verkuil wrote:
> On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote: > > On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote: > > > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > > > 2011/2/24 Edward Hervey <[hidden email]>: > > > > > What *needs* to be solved is an API for data allocation/passing at > > > > > the kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and > > > > > that userspace (like GStreamer) can pass around, monitor and know > > > > > about. > > > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > > Allocator) has been slightly modified to fit hand-in-glove with > > > > HWMEM, so CMA provides buffers, HWMEM pass them around. > > > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > > linaro-dev and linux-media in the CC? > > > > > > Yes, please. This sounds promising and we at linux-media would very > > > much like to take a look at this. I hope that the CMA + HWMEM > > > combination is exactly what we need. > > > > Once again let me restate what I've been telling for some time: CMA must > > be *optional*. Not all hardware need contiguous memory. I'll have a look > > at the next HWMEM version. > > Yes, it is optional when you look at specific hardware. On a kernel level > however it is functionality that is required in order to support all the > hardware. There is little point in solving one issue and not the other. I agree. What I meant is that we need to make sure there's no HWMEM -> CMA dependency. -- Regards, Laurent Pinchart _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
On 28 February 2011 11:33, Laurent Pinchart <[hidden email]> wrote:
Yepp..Johan will do that (his mail is fubar at the moment so I will answer instead :-) )
hwmem API has Scattered memory support as well (not implemented yet though)
HWMEM has no CMA dependency, although hwmem is easily adapted ontop of CMA(once the speculative prefetch stuff in ARM arch is resolved) BR /Robert F _______________________________________________ _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: [st-ericsson] v4l2 vs omx for camera
|
Administrator
|
In reply to this post by Marek Szyprowski
On Mon, 2011-02-28 at 09:50 +0100, Marek Szyprowski wrote:
> Hello, [...] > > I'm not sure that highmem is the right solution. First, this will force > systems with rather small amount of memory (like 256M) to use highmem just > to support DMA allocable memory. It also doesn't solve the issue with > specific memory requirement for our DMA hardware (multimedia codec needs > video memory buffers from 2 physical banks). Could you explain why a codec would require memory buffers from 2 physical banks ? Thanks, Edward > > The relocation issue has been already addressed in the last CMA patch series. > Michal managed to create a framework that allowed to relocate on demand any > pages from the CMA area. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: [st-ericsson] v4l2 vs omx for camera
|
|
Hello,
On Tuesday, March 01, 2011 11:26 AM Edward Hervey wrote: > On Mon, 2011-02-28 at 09:50 +0100, Marek Szyprowski wrote: > > Hello, > [...] > > > > I'm not sure that highmem is the right solution. First, this will force > > systems with rather small amount of memory (like 256M) to use highmem just > > to support DMA allocable memory. It also doesn't solve the issue with > > specific memory requirement for our DMA hardware (multimedia codec needs > > video memory buffers from 2 physical banks). > > Could you explain why a codec would require memory buffers from 2 > physical banks ? > Well, this is rather a question to hardware engineer who designed it. I suspect that the buffers has been split into 2 regions and placed in 2 different memory banks to achieve the performance required to decode/encode full hd h264 movie. Video codec has 2 AXI master interfaces and I expect it is able to perform 2 transaction to the memory at once. Best regards -- Marek Szyprowski Samsung Poland R&D Center _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [st-ericsson] v4l2 vs omx for camera
|
|
Hi All,
I have sent an invitation for 3pm UTC Monday 7th March to have a discussion on things that can be explored/worked upon in Linaro related to v4l2 support.The idea is to come out with concrete activities that can be targeted in Linaro MM WG to address this topic.
If any body is unhappy with time please let me know.I tried to take care of US,Europe and India time zones.
Also please forward the invitation to anybody I have missed out on
Thanks
Sachin
On Tue, Mar 1, 2011 at 4:21 PM, Marek Szyprowski <[hidden email]> wrote: Hello, _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |