On Tue, Feb 28, 2012 at 1:56 AM, Vladimir Pantelic <[email protected]> wrote: > 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.
width = 840, coded_width = 848, linesize = 896. Check video_get_buffer. > 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. That's not up to the codec. AFAICS, the codec is supposed to use s->current_picture, not any random AVFrame. But it's hard to tell, since apparently this is the first hwaccel that actually returns data. > 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. I can do that from the client, not from the hwaccel. There, s->current_picture is what s->current_picture is. Cheers. -- Felipe Contreras _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
