[gst-embedded] gstreamer dma buffer & management

[Felipe Contreras]

On Fri, Sep 17, 2010 at 2:49 AM, Feng Ye <fye at broadcom.com> wrote:
> I am working on a video dec plugin (based on hardware dec). I plan to use filesrc to read a raw H264 file and feed to my plugin.
> The buffers from plugin's sink pad are the source data for decoding so they need to be DMA-able. Is there way to control how the buffers are allocated? Since they are allocated in filesrc so that's not possible? Looks like I will need to allocate my own buffer in my plugin and then copy them over?
>
> Also, a video frame may contain less bytes than what's in the buffer, what do I do with the remaining bytes?
> >From the ffmpeg example (they are software based so the first dma question does not exist), they create a sub buffer of the remaining bytes and then does a buffer join. These are time consuming I think. I wonder if there are other faster solution? One thing I think might help is to have another plugin in between, which parse the file and only give one frame size of data to my plugin. But I am not sure if these kind of plugin exists.

As Marco mentioned, you would wan to use h264parse for raw clips, but
it's no actively maintained, so perhaps you would want to use a real
demuxer instead.

As of the question of DMA, we have the same issue in gst-dsp;
currently GStreamer has no good control of DMA, so each buffer has to
be mapped/unmapped constantly. If don't know of you have some sort of
MMU so that you can do the same, but if not a memcpy is unavoidable,
imagining a perfect scenario where filesrc is mmaping the file,
somebody would need to copy that data to your buffer. Unless pull mode
is used, which I don't know if it would work, nor if it makes sense.

Cheers.

-- 
Felipe Contreras