Hi all,
I am trying to the accelerate the gst-ffmpeg codecs using our soc's h/w decoder -the h/w decoder allocates sme memory dumps the decoded buffer in it. -i would like to use this buffer in the direct rendering using the framebuffer driver. I have explored the features like -xvideo to provide different layers and do compositng. -the fbdevsink feature provided by gstreamer. But the current problem i am facing is how to avoid the 'memcpy' between the decoder and and sink and directly give the buffer to to the xvimagesink. what is the safe and best method provided by gstreamer to do this? regards anand ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Administrator
|
On Sat, 2009-11-07 at 15:31 +0530, anand k n wrote:
> Hi all, > I am trying to the accelerate the gst-ffmpeg codecs using our > soc's h/w decoder > -the h/w decoder allocates sme memory dumps the decoded buffer in it. > -i would like to use this buffer in the direct rendering using the > framebuffer driver. > > I have explored the features like > -xvideo to provide different layers and do compositng. > -the fbdevsink feature provided by gstreamer. > > But the current problem i am facing is how to avoid the 'memcpy' > between the decoder and and sink and directly give the buffer to to > the xvimagesink. > > what is the safe and best method provided by gstreamer to do this? First of all... you could have a more granular control if you wrote your wrapped your decoder directly as a gstreamer element (instead of going through another abstraction layer like (gst-)ffmpeg). If you already have a convenience library to acces your hw (which I hope you have), then it's rather trivial (there's plenty of examples of decoder plugins out there). That being said... in order to have direct rendering, your AVCodec needs to expose the fact that it can (AVCodec->capabilities & CODEC_CAP_DR1). If that is set, then there should be no memcpy, since gstffmpegdec will request a buffer from downstream (your sink) and write straight to it instead of doing an extra copy. Edward > > regards > anand > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |