How is it possible to have MPEG2 HW acceleration? There seems to be a working plugin for xine. Where can I have the details?
Thanks in advance,
Goktug
On Wed, 2006-08-30 at 13:53 +0300, Ville Syrjälä wrote:
On Wed, Aug 30, 2006 at 11:34:16AM +0100, Mark Adams wrote: > > OK, I have that working, although I'm unsure about the interlacing > > options as they seem to make little difference. I currently have the > > layer set as interlaced, set the field parity option. I guess that the > > SetField() fn has to be called to toggle fields between each frame blit? > > It depends what's coming out of your decoder. If it's producing > frames, you'll need to use FIELD_PARITY and synchronise the output of > frames with the output timing (using the DSFLIP_WAITFORSYNC option or > triple buffering and DSFLIP_ONSYNC). If you're creating fields, > you'll get a reasonable picture without the FIELD_PARITY option (the > temporal field ordering will be correct automatically). However, you > may still get the fields in the wrong vertical position. > > I wouldn't use the interlaced or deinterlace options as they're not > used by the unichrome driver. > > > Yes that's the one. But video is decoded from MPEG4 so the hardware > > decode is not useful :-( > > OK -- I'm impressed you can do two MPEG4 decodes in real time with the > processing power you've got! > > > I think the later chipsets can directly decode MPEG4, so with those we > > would make use of the decoder. > > That's true although I'm not sure there's much linux support for the > hardware decode on those chips. > > > As for V3 support, that would be optimal > > if there is an easy transform from YV12 to YUY2 but I suspect not. > > As I hinted, the hardware does have an 'HQV' blitter that can do this > but there is no support for it at present in DirectFB. I'm not sure > how it would be best modelled in DirectFB because it has to be plumbed > in directly to the V1/V3 layer. From what I understand, this would > seem either to require a logical layer restricted to BACKVIDEO that > can only be written to (because the front and back buffers would have > different pixelformats), or a layer that cannot be written to at all > except via a restricted set of blit operations. If anyone has any > thoughts on this, I'd be interested. My first idea would be to have the V1/V3 layer like any other layer and just have a special HQV blit funtion that would be used if possible. I don't know the hardware so this is just a gut feeling.
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
