On 02/28/2012 12:18 AM, Felipe Contreras wrote:
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.
linesize != width, but in fact the next multiple of 16.
and one plane vs 3 does not matter, you are free to have
one buffer where data[0] points to the start and data[1]
and data[2] point to an offset into the same buffer.
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);
as said, the displaywidth on the socket node is width padded up to the
next multiple of 16 and you can make linesize[] in the libav buffer
exactly that.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
