Carl Renaud wrote:
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?
Yes, you can. Or you can use the Blending registers which handle the
mixing of the entire layer. You'll find that trying to use the
attribute window to fade in/out large sections of the screen becomes
problematic. If you have a single video window, I would recommend using
a color key and the OSD RGB blend register.
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?
The limitation is (to my understanding) dealing with the memory
bandwidth, so if you are trying to send a series of images to the OSD
window your resolution is limited. In my testing, trying to send too
much data to the OSD window caused tearing which is why I assume that
the limitation is memory bound. However, it could also be limited by
the colorspace conversion and mixing which takes place as well.
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?
How often are you planning on writing data to OSD0? If you are simply
drawing a static background, then you won't have a problem. I suggest
using a double buffering scheme if you have an issue with tearing. To
do that, you just need to write your OSD data to a chunk of contiguous
memory, and then set the start address. If you're not worried about
tearing when displaying your background, or find that it is not an
issue, then just write it directly to your layer (/dev/fb/0). The
formula described in the datasheet calculates the resolution which you
are limited to based on the cumulative bandwidth for the OSD planes.
This would prevent you from being able to play video or animations to
OSD0 at higher resolutions.
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
