Hi Brain,

 

It seems that, you are successful in using ODS0 in 1024x768x16bpp.

 

I am working on DaVinci dm6446 EVM. I am posting this problem here as there
was no reply to my post in other thread. It's a similar problem, so please
help.

 

I am facing a problem of display flickering when cpu gets busy with some
other processing (may be for Ethernet data transfer or while displaying
video).

It seems that the problem is with CPU bandwidth.

 

I am using OSDWIN0 in RGB565 mode. I have selected standard resolution of
NTSC. I understand this means a 720p x 480p resolution.

As per the bandwidth requirement formula, required bandwidth is:

                [(720 * 480) * 2 + 0 ] * 30 = ~20Mbps. Thus this satisfies
the condition for <25Mbps

Still, display flickers whenever there is any heavy processing done over
CPU. Kindly help me out of this.

 

I am using non-interlaced mode. Would this cause any problem? I don't think
so, as I have also checked with interlaced mode. 

Results were the same. But using non-interlaced mode, made the picture more
clear. 

 

Is there any other way by which I can implement this ping-pong logic for
OSDWIN0? 

 

Can you please help me out to get this issue resolved. 

 

BTW what is "panning in the framebuffer driver"? Could this be used to solve
my issue?

 

Awaiting your reply. 

 

Regards,

Suhas Jain

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Carl Renaud
Sent: Wednesday, October 15, 2008 9:16 AM
To: Brian Rhodes
Cc: [email protected]
Subject: Re: DM6446 1024x768 graphics with video overlay

 

Thanks for your response Brian!

 

You say you are able to use OSD0 in 1024x768x16bpp.

 

1) Can you also use OSD1 at the same time as an attribute windows to

let VID0 show through?  E.g. have a D1 30fps video playing over a

1024x768 graphic background?

 

2) When you say "...If you need to do some form of animation on the

OSD window, you'll have to do some work to understand the limitations,

especially if you are using OSD1 as an attribute window for per-pixel

alpha blending... ", what kind of limitation are we talking about?  I

know about the rendering speed limitation of the 297MHz ARM, but other

than that?

 

3) I guess I don't understand the equation in section 4.3.1 of

sprue37c.pdf (Video Window Constraints).  According to the equation,

using OSD0 in 1024x768 at 30 fps seems to exceed the specified limit

of 25 Mbytes/second.

[(1024 * 768) * 2bpp + (720 * 480) * 0.5bpp] * 30 = [1572864 + 172800]

* 30 = ~52 Mbytes/sec

 

What am I missing?

 

Thanks again!

 

 

 On Tue, Oct 14, 2008 at 4:57 PM, Brian Rhodes <[EMAIL PROTECTED]> wrote:

> 

> 

> Carl Renaud wrote:

>> 

>> Hi,

>>  I am seeking advice on the DM6446...

>>  Our product requirements

>> ==================

>> Display a 1024x768 graphic background with a video overlay.  Using the
DM6446, there is no problem doing this is in D1 resolution, using VID0 for
video, OSD0 for graphics and OSD1 for transparency.  For resolutions higher
than D1, there seems to be a few limitations...

>>  Methods

>> ======

>>  1) The first method would be to use VID0 for video, OSD0 for
graphics(RGB565) and OSD1 for transparency.

>>  I read in the VPBE document (section 4.3.1 of sprue37) that the combined
bandwith of the OSDs cannot be more than 25MB/sec.  This is exactly a D1
resolution OSD at 30 fps.  So... this method would not work...  Correct?

>> 

> 

> I am not having trouble drawing 1024x768x16bpp graphics to OSD0.  To
prevent tearing, use the memory you would have for Video 1 window and
implement panning in the framebuffer driver.  Your 'product requirement' has
a full screen graphic background, and for that OSD0 will suffice.  If you
need to do some form of animation on the OSD window, you'll have to do some
work to understand the limitations, especially if you are using OSD1 as an
attribute window for per-pixel alpha blending.

>> 

>> 2) The second method would be to use VID0 for graphics(RGB888) and VID1
for video (as a picture in picture).

>>  In the VPBE document (again section 4.3.1 of sprue37), it is stated that
when doing HD, VID0 should be used and VID1 disabled.  Also, reading through
the mailing list, it seems that there is a silicon problem on the DM6446
that prevents using VID0 and VID1 at the same time.   So... this method
would not work...  Correct?

> 

> You are correct.  You cannot use Video 1 when the resolution of Video 0 is
> 720x576.  The bug in the silicon causes a flicker when both Video 1 and
Video 0 are used at lower resolutions.

> 

>>  3) The third method would be to use VID0 for graphics(RGB888), OSD0 for
video(RGB565) and OSD1 for transparency.

>>  My understanding is that this should be possible if we limit the video
to be a D1 frame within the 1024x768 graphics of VID0.  This would respect
the OSD bandwidth limitation.  However, since OSD0 only takes RGB565 (and
bitmap), I would need to convert the YUV 4:2:2 video to RGB565 on the ARM(or
DSP).  Correct?

>> 

> 

> This would not be possible.  You would not be able to do this colorspace
conversion quick enough.  Codec implementations which do conversions between
4:2:2 and 4:2:0 are simply reassembling the stream of data, throwing some
away in one direction, and duplicating some in the other.  the conversion
from yuv -> rgb is considerably more work.

>> 

>> Is my understanding correct?  Is there any other option on the DM6446 to
meet our requirements?

>>  Thank you!

>>  ------------------------------------------------------------------------

>> 

>> _______________________________________________

>> Davinci-linux-open-source mailing list

>> [email protected]

>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

>> 

 

_______________________________________________

Davinci-linux-open-source mailing list

[email protected]

http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to