On Tue, Feb 28, 2012 at 12:30 AM, Vladimir Pantelic <[email protected]> wrote: > On 02/27/2012 11:25 PM, Felipe Contreras wrote: >> >> On Tue, Feb 28, 2012 at 12:18 AM, Vladimir Pantelic<[email protected]> >> wrote: >>> >>> On 02/27/2012 10:12 PM, Felipe Contreras wrote: >>>> >>>> >>>> Hi, >>>> >>>> On Mon, Feb 27, 2012 at 10:46 PM, Felipe Contreras >>>> <[email protected]> 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.
The bridge interface is a dumb pipe, it doesn't know what user-space and the DSP socket-node are communicating; it just passes messages around. If the codec supports it, there's a way to do it. > 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. I don't see any way in which a hwaccel codec can change the planes in s->current_picture. Shall I just replace it with a custom frame? > 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. -- Felipe Contreras _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
