Video overlay - essential for fast video playback

[Piru]

Recently there has been a lot of discussion about overlay, and how it supposedly is obsolete and/or of small priority.

It is neither. Overlay is absolutely critical for low-end systems displaying video. The benefits of overlay are two-fold:

• Offloading the video scaling to hardware.
• Offloading the YCbCr -> RGB conversion to hardware.

The first point is the most critical. It allows the video to be scaled to whatever size requested without requiring the application to perform the frame scaling with the CPU. Even if you choose not to resize the video output at all, much of the video content (such as DVDs) require scaling out of the box to display the video with the correct aspect ratio.

The second point removes the need for the application to convert the YCbCr encoded image information to RGB understood by the graphics system. This leaves more time for actual video and audio decoding.

The practical implications are that if the OS or graphics driver doesn't support overlay, video playback will suffer. This is especially critical with the low-end systems that already spend considerable resources decoding the video and audio in the first place.

So neither is overlay low priority nor obsolete.

PS. It does not matter how the overlay is implemented. It could be dedicated overlay mode supported by the graphics hardware, or it could be implemented via the 3D hardware. The important point is that both OS and the device driver implement it and the APIs providing the overlay to the applications.

PPS. Overlay has other uses as well, such as in emulators where the graphics can be stretched to whatever size needed. Without it you're stuck with the postage stamp on a 1920x1080 display.

[Piru]

Recently there has been a lot of discussion about overlay, and how it supposedly is obsolete and/or of small priority.

It is neither. Overlay is absolutely critical for low-end systems displaying video. The benefits of overlay are two-fold:

1. Offloading the video scaling to hardware.

2. Offloading the YCbCr -> RGB conversion to hardware.

The first step is the most critical. It allows the video to be scaled to whatever size requested without requiring the application to perform the frame scaling with the CPU. Even if you choose not to resize the video output at all, much of the video content (such as DVDs) require scaling out of the box to display the video with the correct aspect ratio.

The second point removes the need for the application to convert the YCbCr encoded image information to RGB format understood by the graphics system.

The practical implications are that if the OS or graphics driver doesn't support overlay, video playback will suffer. This is especially critical with the low-end systems that already spend considerable amount of resources decoding the video and audio in the first place.

So neither is overlay low priority nor obsolete.

PS. It does not matter how the overlay is implemented. It could be dedicated overlay mode supported by the graphics hardware, or it could be implemented via the 3D hardware, as long as it is.

PPS. Overlay has other uses as well, such as in emulators where the graphics can be stretched to whatever size needed. Without it you're stuck with the postage stamp on a 1920x1080 display.


MODS: I think I posted this yesterday as an misc announcement by accident. Please nuke that post.

[Piru]

A discussion about overlay is classed as a news item?

The mistake was mine, I originally posted to a wrong category by accident. This "news item" should be deleted. To quote the actual discussion thread post:

MODS: I think I posted this yesterday as an misc announcement by accident. Please nuke that post.

[Piru]

@ Piru

I respect your work on MOS;however, I'll side with Hans and Karlos's opinions on modern video driver issues.

And by that comment you show your complete ignorance of the matters at hand. I hope it's that, since the alternative is even worse.

[Piru]

Overlay is obsolete.

The "classic" method of implementing video overlay might be obsolete with certain hardware. This does not however make the concept of overlay obsolete. As I point out in my original post:

PS. It does not matter how the overlay is implemented. It could be dedicated overlay mode supported by the graphics hardware, or it could be implemented via the 3D hardware. The important point is that both OS and the device driver implement it and the APIs providing the overlay to the applications.

Hans has been saying that it is unlikely that he will support the old Picasso96 PIP APIs. This is unfortunate as it will lock out textured video from all old applications using the API. In that sense overlay indeed has been obsoleted for OS4.

This also means that in the future if some application wishes to support fast video display on OS4 the application has to have two code paths, one for classic Picasso96 PIP API (for older graphics cards) and second for some yet to be determined new API (for newer graphics cards). Hardly an ideal solution.

Of course, it also means that anyone who is using newer RadeonHD cards in low-end systems will need to wait undetermined time to have proper video playback, or upgrade their system to Radeon 9200 or some other card that is properly supported.

Textured video is a much better way of doing the same thing at the same speed.

It actually is considerably slower to use textured video. There is some setup involved, and you need to wait for the operation to finish (actual performance of course depends on the implementation details). Classic overlay gives the application a frame buffer it can write to, and it will be displayed automagically without any extra calls or waiting needed. It is even possible to completely disable the OS and bang the framebuffer and it will update on screen just fine (this is btw why with Mediator setup you could route amiga display to a video grabbing card, and then display the graphics in an overlay window, and run HW banging games and demos).

If there's a possibility to have both classic overlay and textured video, overlay would be the better choice for the low-end systems. This also means that it likely is a better idea to use a graphics card with true overlay in such low-end systems instead of a card that doesn't have the classic overlay.

Textured video has the benefit of being part of the actual display frame buffer though, and then you can perform other effects on it (such as transparency), and for example take screenshot of the video.

[Piru]

The bottleneck is going to end up being the CPU decode, especially if DMA retrieval of texture data is thrown into the mix.

True. However, the resulting bitmap needs to be blitted to the screen, too, unless if it somehow bypasses the compositing stage (of course possible as well). While this is not going to take much time, it still is yet another step that needs to be performed compared to classic overlay.

If implemented properly there will be little difference in performance. It will be slower than the old style overlay. How much, depends on the implementation (if everything is done correctly there's only minimal performance hit, if it's not; say no PIO texture fetch, extra blit required, then it could make a difference between 720P being usable or not).

This is a distinct advantage for such machines, but I doubt that, other than on actual classic Amiga machines, there'll be much hardware banging going on.

Of course. The example was merely to illustrate how the classic overlay is completely automatic and doesn't require any extra blitting, copying or such (that is it comes as "free" resource-consumption-wise).

Anyhow, it will be some time before we will see how it performs. Meanwhile anyone wanting to play videos on low-end systems such as SAM460 with Radeon HD are out of luck.

[Piru]

Tell it to my BVision :razz:

"Tseh Tseh, BVision, jump into that PCI/PCIe slot!"




Anyway, I heard you've been working on Radeon R100/R2x0 as well. I almost feel sorry for you, such a pain in the behind...