DirectFB - Home of the pragmatist Roadmap


[directfb-dev] CLE266 MPEG video surface
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] CLE266 MPEG video surface



Hi,

I've been looking through the code that Andreas posted to the VIA Linux
Arena forum - his prototype DirectFB mpeg decoder for the CLE266 and have a
couple of questions:

I believe that the MPEG framebuffers allocated are simply YUV420 surfaces.
Believing that this was the case I attempted to set the V1 framebuffer
address (V1_STARTADDR_Y0, V1_STARTADDR_CB0, V1_STARTADDR_CR0) to point to to
the just decoded MPEG framebuffer address.

I then set V_COMPOSE_MODE register to equal V1_COMMAND_FIRE_LOAD_VBI which I
believe causes the change to take effect. I set V1_STRIDE to the same value
in hwdec_set_fb_stride.

I believe that this would have two advantages:

- Remove the overhead of the Blit call
- Force the change to occur during vsync, therefore removing the image
tearing.

However, I get garbage on the screen when I do this. It is rapidly changing
garbage, admittedly, which I guess means that I am at least setting the
framebuffer address!

Before I debug this I'd appreciate it if anyone could answer the following
questions:

- Is this possible? I notice that the ddmpeg stuff uses the HQV video
registers.
- The register definitions mention HW_FLIP. What does this do?

The HQV_CONTROL register has bits 'HQV_FLIP_EVEN' and 'HQV_FLIP_ODD'. Does
this mean that the HQV surface is needed to display interlaced, field
pictures?

Thanks very much for any help,

Colin










-- 
Info:  To unsubscribe send a mail to ecartis@directfb.org with 
"unsubscribe directfb-dev" as subject.



Home | Main Index | Thread Index


directfb.org / Development / Old Archives