On 02/27/2012 11:25 PM, Felipe Contreras wrote:
On Tue, Feb 28, 2012 at 12:18 AM, Vladimir Pantelic<vlado...@gmail.com> wrote:
On 02/27/2012 10:12 PM, Felipe Contreras wrote:
Hi,
On Mon, Feb 27, 2012 at 10:46 PM, Felipe Contreras
<felipe.contre...@gmail.com> wrote:
Compared to vaapi and vdpau, this code is much simpler; frames in, frames
out,
and not many parameters are required. It's also worth remembering that
this
interface is asynchronous; buffers are processed in a delayed way, and
polling
is required in order to see if the DSP has finished processing them.
So, I'm going to list the issues I have encounter to make this
performs as well as it can:
1) Agree on an I420 packed format
GStreamer, the DSP codecs, and I guess others ignore strides and
planes, so it would be extremely useful to check if the client (e.g.
GStreamer gst-av) requires this format, to avoid line by line, or even
plane by plane copying.
the TI codecs support planar YUV as well, no? Also, there is the
displayWidth that normally all TI dsp codecs support.
Yes, but it's packed; not split into multiple planes. I'll take a look
into the display_width stuff. I have never tried that.
I am quite sure the OMAP3 codecs support both packed and planar, at
least they do when using them via CE/link. Whether the bridge interface
exposes that I am not sure any more, need to check.
But why should packed be a problem, I think libav API allows for a
codec to return packed YUV data using only one data[]/linesize[]
component.
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.
Regards,
Vladimir
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
