On Tue, Feb 28, 2012 at 1:12 AM, Vladimir Pantelic <[email protected]> wrote:
> On 02/28/2012 12:06 AM, Felipe Contreras wrote:
>>
>> On Tue, Feb 28, 2012 at 12:30 AM, Vladimir Pantelic<[email protected]>
>> wrote:
>>>
>>> One of the nice things of bridge vs link is that it actually uses
>>> the DSP MMU to map user space buffers to the DSP, so I don't
>>> understand why you are allocating separate dsp output buffers
>>> (inside libtidsp) and then doing memcpy between the 2 sets of
>>> userspace buffers.
>>
>> Because the data is organized in a completely different way anyway.
>
> meaning?
I already explained this multiple times: multiple data planes, and
linesize != width.
Right now I have to do this:
for (i = 0; i < avctx->height; i++)
memcpy(f->data[0] + i * f->linesize[0], p1 + i * avctx->width,
avctx->width);
for (i = 0; i < avctx->height / 2; i++)
memcpy(f->data[1] + i * f->linesize[1], p2 + i * avctx->width
/ 2, avctx->width / 2);
for (i = 0; i < avctx->height / 2; i++)
memcpy(f->data[2] + i * f->linesize[2], p3 + i * avctx->width
/ 2, avctx->width / 2);
If I could use display_width on the socket-node, I could do:
memcpy(f->data[0], p1, avctx->width * avctx->height);
memcpy(f->data[1], p2, (avctx->width * avctx->height) / 4);
memcpy(f->data[2], p3, (avctx->width * avctx->height) / 4);
But I still need to split the data in 3 data planes. With a single one
I could do:
memcpy(f->data[0], b->data->data, avctx->width * avctx->height * 3 / 2);
And only then, I could map the output buffer instead.
As things stands right now, I can't do that.
Cheers.
--
Felipe Contreras
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
