different display on LCD/HDMI interface

Yes, this is theoretically possible. But then you have to use the Video-for-Linux (V4L) infrastructure to show the video on HDMI. As an example how this is done, you can have a look at our hdmicfg tool, which can be downloaded from this posting for example. hdmicfg uses V4L to show the whole (or part of the) framebuffer that is used for the standard LCD contents.

Some background information:

The S5PV210 processor on the armStoneA8 can drive an LCD display and a TV output. HDMI is part of the TV output. These two devices have different capabilities.

• LCD
  The LCD can use up to five overlay windows. Each window may have its own data, i.e. point to an own framebuffer or directly use some camera input. Each window can be positioned independently on the screen and the content can be alpha blended, i.e. combined with the content below it by setting a transparency value, based on pixel or layer data. The lowest window usually fits the whole screen and is not transparent. Only the four other windows may be smaller and use alpha blending. LCD can have any resolution size up to 1024x768 pixels. In addition, each window can use its own pixel format. E.g window 0 may use 32 bpp in RGBA8888 format, and window 1 may use 1 bpp with only two colors.
  

  
  

• HDMI
  The HDMI output is a combination of up to two windows (backed by a framebuffer), a window with a video source (usually a camera) and a background color generator. The available resolutions are rather restricted, just the common TV resolutions incl. HD will work, i.e. 640x480, 720x576, 1280x720 and 1920x1080. So the windows (2x framebuffer, 1x video) can be positioned and sized freely on this basic resolution. Here the windows can only be blended on a layer basis, not on a pixel basis. Parts that are not occupied by one of the windows show the background color.

The camera sources are not available on the armStoneA8 as we have not made the camera signals available on this board. But the framebuffer sources can be used on all windows.

Our hdmicfg simply defines that one of the windows for the HDMI output should use the same framebuffer as for the LCD. So if the LCD resolution is smaller than the HDMI resolution, you'll only see it as a smaller window and the rest is showing the background color. If the resolution of the LCD is higher than the HDMI resolution, then you'll only see a cropped part of the LCD screen.

However instead of re-using the LCD framebuffer, you can also define your own framebuffer for HDMI. This is currently not supported by our software, but as already said, if you have a look at the hdmicfg sources, it should be clear how to make this. And if you use some video player that already supports V4L, then you might even have the possibility to directly use the HDMI device without any further software. I'm not quite sure right now, but I think GStreamer should support V4L as a backend (video sink). Please deactivate hdmicfg in this case to have free access to the V4L interface of the HDMI driver.

Your F&S Support Team

V4L has a slightly different approach to handling buffers, compared to a standard displaying device like the LCD screen. V4L thinks of a buffer as one frame in a sequence of frames, i.e. in a video. So you usually have a video decoding engine on one side. This engine decodes the video frames and generates a set of buffers, one video frame per buffer. These buffers are queued with V4L. On the other side is the screen or display. The V4L infrastructure then takes one buffer after the other and shows them with a given rate. After showing each buffer for the predefined time, it removes the buffer from the queue and shows the next frame (if a next frame=buffer is available). The removed buffer can then be destroyed or re-used by the video engine.

Let's have an example. A DVD video stream will use an MPEG2 stream with at most 15 frames per GOP (Group of Pictures). So the decoder needs at most 15 buffers to store up to 15 frames of the video. As MPEG2 does also store relative data, i.e. data that only describes the differences between adjacent frames of the video, it sometimes has to reference other frames of the video, apply the differences, and the result is a new frame of the video. So the decoding engine will use these 15 frames and decode one frame after the other. When a frame is decoded, the buffer will be queued in V4L where it will be displayed eventually. In the meantime the decoder will continue to decode the next frames. So these 15 buffers will be used in a round robin manner. The decoding engine fills the buffers with new frames, V4L shows the contents and then returns the (now free) buffer back to the video engine. If the video decoder is faster than the play-back frame rate, then the queue of ready buffers will grow until all 15 buffers are used up. Then the decoder will have to pause until the next buffer will be available again after it is returned from V4L. On the other hand if the decoder is slower than then playback frame rate, then the queue of ready buffers will shrink. In the worst case, there is now new buffer available when V4L will need one, so the video will pause at the currently shown frame until the next buffer is available. The result is a juddering video then.

The S5PV210 will use each of these buffers as base for one of the two possible framebuffer windows. So it depends on the configuration of that window how large it will show up on the display. BUT: the displaying engine of the HDMI output is not capable of doing sophisticated scaling. There is the possibility to do doubling of x and y pixels, but it's only exactly by factor two. And I'm currently not sure whether this doubling is actually supported by the HDMI software driver in Linux. So there is practically no possibility to scale the video in hardware. You either have to provide the video in the desired size already, or you have to do the scaling in the video decoding process, for example as a software scaling filter included in the GStreamer pipeline.

The hdmicfg tool works a little different. It just allocates one V4L buffer (which is actually part of the LCD framebuffer). Then it shows this one buffer indefinitely. As it never provides any further buffers, the current buffer will continue to be shown. So it is actually a video with just one single frame that never stops showing, until you end the hdmicfg tool. So hdmicfg kind of mis-uses the V4L interface by handling only this one buffer to V4L, making it in fact a regular framebuffer like on other displaying devices. This allows for a completely different usage. When using such a single framebuffer, then you can decode your video like to any other framebuffer. So you can do it in the same way as when decoding to the LCD display. And this framebuffer can also be addressed from a Qt program in the same way as on the LCD. However you don't use the advantage of V4L then.

So my idea would be to use a combination of the two: Show the main screen in window 1 of the HDMI output by using some program similar to hdmicfg, providing only one single buffer that can be used as framebuffer. And then you use window 2 by placing it in the correct size (of the video) at the correct position (as required by your application) on the screen, like an overlay. And in this window you use the V4L infrastructure to just show video frames without any decoration.

This would be the best of both worlds. Have Qt draw the main background in window 1 and have V4L efficiently show the video in window 2.

Your F&S Support Team