GStreamer-devel

Use of own buffer_alloc function

Classic

List

Threaded

8 messages Options

Daniel Laird

Use of own buffer_alloc function

All,

I am have real difficulty in getting a buffer_alloc function in my sink class that extends GstVideoSink to work.
At the moment it does not even appear to be being called!

I have registered with the base sink i.e
basesink->buffer_alloc = GST_DEBUG_FUNCPTR(my_buffer_alloc);

Yet in my sink it seems that the function is not getting called.
However render is getting called and doing as expected

The graph I have created is something like this:
filesrc -> demux -> switch -> queue -> my_audio_sink
-> switch -> queue -> my_video_sink

The Audio and video sink in my case act as end of line as they are in fact input to my on board embedded decoders etc. I want to be able to give the demux a buffer so that I can then DMA it into my decoder. Is this possible? It certainly appeared so in the docs.

Any help much appreciated.
Daniel Laird

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Edward Hervey

Re: Use of own buffer_alloc function

Administrator

On Wed, 2009-03-11 at 13:27 +0100, Daniel James Laird wrote:

> All,
>
> I am have real difficulty in getting a buffer_alloc function in my sink
> class that extends GstVideoSink to work. At the moment it does not
> even appear to be being called!
>
> I have registered with the base sink i.e
> basesink->buffer_alloc = GST_DEBUG_FUNCPTR(my_buffer_alloc);
>
> Yet in my sink it seems that the function is not getting called.
> However render is getting called and doing as expected
>
> The graph I have created is something like this:
> filesrc -> demux -> switch -> queue -> my_audio_sink
> -> switch -> queue -> my_video_sink
>
> The Audio and video sink in my case act as end of line as they are in
> fact input to my on board embedded decoders etc. I want to be able to
> give the demux a buffer so that I can then DMA it into my decoder.
> Is this possible? It certainly appeared so in the docs.

That's because demuxers don't do downstream buffer_alloc (they don't
need to since the data is already allocated in filesrc).

Since you're a decoder AND a sink you don't need to implement
bufferalloc.

Edward

>
> Any help much appreciated.
> Daniel Laird
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Daniel Laird

Re: Use of own buffer_alloc function

Okay, many thanks for the reply.

So if I understand this correctly the filesrc supplies the buffer to the demux
The demux then 'demuxes' this data and passes it to the downstream component. I.E a decoder.

The demux does not ask the sink for a buffer to output the 'demuxed' data into.

Is there anyway that I can get DMA to work then?
Because if the demux is not going to ask for buffers then I cannot provide a buffer from a memory region that can be dma'd,.

I really would like to be able to get the demux to directly demux data into memory buffers that I provide and then can be dma'd to my decoder.

As this is all new I am probably not quite getting it!
Many thanks for the help so far.
Daniel Laird

-----Original Message-----
From: Edward Hervey [mailto:[hidden email]]
Sent: 2009 Mar 11 12:56
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Use of own buffer_alloc function

On Wed, 2009-03-11 at 13:27 +0100, Daniel James Laird wrote:

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Felipe Contreras

Re: Use of own buffer_alloc function

On Wed, Mar 11, 2009 at 3:18 PM, Daniel James Laird
<[hidden email]> wrote:

> Okay, many thanks for the reply.
>
> So if I understand this correctly the filesrc supplies the buffer to the demux
> The demux then 'demuxes' this data and passes it to the downstream component. I.E a decoder.
>
> The demux does not ask the sink for a buffer to output the 'demuxed' data into.
>
> Is there anyway that I can get DMA to work then?
> Because if the demux is not going to ask for buffers then I cannot provide a buffer from a memory region that can be dma'd,.
>
> I really would like to be able to get the demux to directly demux data into memory buffers that I provide and then can be dma'd to my decoder.
>
> As this is all new I am probably not quite getting it!

Some demuxers do pad_alloc, but probably they are not properly designed.

The filesrc is probably accessing the file with mmap, and doing
pad_alloc on the demuxer. AFAIK you can't use both the mmap of a file
and DMA of the sink at the same time.

--
Felipe Contreras

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tim-Philipp Müller-2

Re: Use of own buffer_alloc function

On Thu, 2009-03-12 at 09:29 +0200, Felipe Contreras wrote:

> The filesrc is probably accessing the file with mmap,

FWIW, filesrc does not use mmap by default, you have to enable that
manually by setting the right properties (this is mostly for error
handling reasons).

> and doing pad_alloc on the demuxer.

Not sure what you mean by that, but I doubt filesrc ever does a
gst_pad_alloc_buffer() downstream, since this doesn't really make much
sense afaics.

Cheers
-Tim

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Felipe Contreras

Re: Use of own buffer_alloc function

On Thu, Mar 12, 2009 at 11:12 AM, Tim-Philipp Müller <[hidden email]> wrote:

> On Thu, 2009-03-12 at 09:29 +0200, Felipe Contreras wrote:
>
>> The filesrc is probably accessing the file with mmap,
>
> FWIW, filesrc does not use mmap by default, you have to enable that
> manually by setting the right properties (this is mostly for error
> handling reasons).
>
>> and doing pad_alloc on the demuxer.
>
> Not sure what you mean by that, but I doubt filesrc ever does a
> gst_pad_alloc_buffer() downstream, since this doesn't really make much
> sense afaics.

Right, I was contradicting myself.

Still the point remains: the memory domains of filesrc and a dma sink
are separate, so a memcpy/mmap is unavoidable.

--
Felipe Contreras

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

TK, Pratheesh Gangadhar

Re: Use of own buffer_alloc function

> -----Original Message-----
> From: Felipe Contreras [mailto:[hidden email]]
> Sent: Thursday, March 12, 2009 3:00 PM
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] Use of own buffer_alloc function
>
> On Thu, Mar 12, 2009 at 11:12 AM, Tim-Philipp Müller <[hidden email]>
> wrote:
> > On Thu, 2009-03-12 at 09:29 +0200, Felipe Contreras wrote:
> >
> >> The filesrc is probably accessing the file with mmap,
> >
> > FWIW, filesrc does not use mmap by default, you have to enable that
> > manually by setting the right properties (this is mostly for error
> > handling reasons).
> >
> >> and doing pad_alloc on the demuxer.
> >
> > Not sure what you mean by that, but I doubt filesrc ever does a
> > gst_pad_alloc_buffer() downstream, since this doesn't really make much
> > sense afaics.
>
> Right, I was contradicting myself.
>
> Still the point remains: the memory domains of filesrc and a dma sink
> are separate, so a memcpy/mmap is unavoidable.
>

This can be quite a bit of an overhead for camera capture use cases in embedded devices - V4L2 driver allocates buffers and resizes before sending to encoder. We resize to a pad_alloc buffer from encoder_input_pad for contiguous buffer. We have patched v42src for doing this and don’t understand why this can’t work. Memcpy at encoder input for raw video frames is a significant overhead.

Regards,
Pratheesh

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Felipe Contreras

Re: Use of own buffer_alloc function

On Thu, Mar 12, 2009 at 1:02 PM, TK, Pratheesh Gangadhar
<[hidden email]> wrote:

>
>
>> -----Original Message-----
>> From: Felipe Contreras [mailto:[hidden email]]
>> Sent: Thursday, March 12, 2009 3:00 PM
>> To: Discussion of the development of GStreamer
>> Subject: Re: [gst-devel] Use of own buffer_alloc function
>>
>> On Thu, Mar 12, 2009 at 11:12 AM, Tim-Philipp Müller <[hidden email]>
>> wrote:
>> > On Thu, 2009-03-12 at 09:29 +0200, Felipe Contreras wrote:
>> >
>> >> The filesrc is probably accessing the file with mmap,
>> >
>> > FWIW, filesrc does not use mmap by default, you have to enable that
>> > manually by setting the right properties (this is mostly for error
>> > handling reasons).
>> >
>> >> and doing pad_alloc on the demuxer.
>> >
>> > Not sure what you mean by that, but I doubt filesrc ever does a
>> > gst_pad_alloc_buffer() downstream, since this doesn't really make much
>> > sense afaics.
>>
>> Right, I was contradicting myself.
>>
>> Still the point remains: the memory domains of filesrc and a dma sink
>> are separate, so a memcpy/mmap is unavoidable.
>>
>
> This can be quite a bit of an overhead for camera capture use cases in embedded devices - V4L2 driver allocates buffers and resizes before sending to encoder. We resize to a pad_alloc buffer from encoder_input_pad for contiguous buffer. We have patched v42src for doing this and don’t understand why this can’t work. Memcpy at encoder input for raw video frames is a significant overhead.

This is an entirely different use case.

In video capturing you want the raw frames coming from the src
(mmaped) to be used directly as they are by the encoder (no memcpy).
If it's a software encoder there's obviously no need to memcpy because
the memory is already available trough the mmap. In the case of
hardware encoder all you need is another mmap to the encoder device
(running on the DSP).

I don't understand why you had to patch v4l2src to avoid memcpy.

--
Felipe Contreras

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel