> I wish to render two video streams in a picture-in-picture style on the > TV o/p (720x576 PAL interlaced).
For video, you really need to use the video overlay, layer 1, as only that layer supports YUV pixel formats and the FIELD_PARITY option that you'll need to display interlaced video correctly full screen via a TV encoder. Is this a VIA EPIA board you're using? Is it MPEG-2 video? > I need to use as many of the gfx chip hw features as possible to > minimise CPU usage and assume it can accept YV12 format directly and do > a stretched blit as the frames need to be resized. The unichrome driver currently supports acceleration of YV12 only for 2D operations. You will not get hardware acceleration for a StretchBlit of YV12. Instead, you can use the overlay layer to do the scaling for you. The overlay layer supports scaling and positioning. However, as soon as you apply a vertical scaling factor, the picture won't look too good because of interlace effects. > With vesafb I had the two pictures resized and displaying with quite low > CPU usage but I think I need the layer support with viafb to do PiP and > the rest of the app's graphics. I am struggling to find a correct > combination of configuration for dfb, layers, screens, and windows to > give a fast and flicker free display. Render directly to layer 1's surface, configured with FIELD_PARITY and BACKVIDEO or TRIPLE buffering. > I have used dfb.GetDisplayLayer() to get layer 01 which seems to be for > video in YV12 format. It supports other pixelformats too but YV12 will be the best option for efficient display of video. > In that layer I have a window for each video > picture. I am copying the incoming video frames to a general purpose > YV12 surface with the same size as the video frames. Then I am > StretchBlit()'ing the GP surface onto the window surface. I suggest you avoid using windows for the video -- for efficiency you want to avoid copying the frames so write to the overlay layer directly. > With the vesafb I had best results with no buffering at all. With viafb > I seem to need to Flip() the window surfaces after blitting and the > window that has enlarged frames is not being updated fast enough which I > think means that the gfx chip is not doing the work. You'll get extremely poor performance if you've got surfaces in video memory and you're using operations that aren't hardware accelerated. If you need to do a YV12 stretch blit, you'll need the surfaces in system memory and it won't be accelerated. > I've looked for examples but all seem to use the video provider > "objects", should I be somehow using one of these? Any help with > dfb/layer/screen/window config and buffering setting would be appreciated. The video provider interface is just a nice interface for things that provide sources of video. If you've already solved the video decoding part of the problem, it won't help you. In all the above, I've just talked about one video window. For your second, you've got fewer options. The CLE266 hardware does support a second video overlay (known as V3) but this is not currently supported by the DirectFB driver (which only supports V1). I did do an experimental version of the driver with support for only V3 and someone with the time could fairly easily add V3 support properly. That would give you two independently scalable video windows. However, note that V3 does not support YV12 directly which opens up another whole issue of the HQV blitter for which, again, there is no support in DirectFB. However, V3 would support YUY2 video. Also note that later VIA chipsets don't have support for V1. Another option for your second video window is to use a window on the primary layer (note you can put the primary layer in front of the video layer if you want and make it transparent except where there is something to display). The primary supports various RGB modes but no YUV modes. However, RGB StretchBlits are supported. BTW, I have hardware accelerated MPEG-2 video decoding using the CLE266's MPEG-2 decoder via a Xine plug-in working now. I don't know if this is of use. It's not 100% error free though. Doesn't help with your picture-in-picture problem either! Regards, Mark _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
