DVB-PAL is unsing a resolution of 720x576 points. The transmission itself can be done with different resolutions, but the DVB-card scales them up to the same resolution. Also there is no difference between 16:9 content or 4:3. It's still the same resolution. The only thing what changes, is the size of the pixels.
In 4:3 mode a pixel is 768/720 times more wider than high. In 16:9 mode the pixel is 1024/720 times more wider than high.
In df-gp I'm currently using a screen resolution of 768x576. The pixels are quadratic. This means one should view df-gp's output on a computer screen.
I've also tested a 1024x576 resolution. This is ideal for output on 16:9 TV-screens. While using this resolution, we can use the screen with normal fonts etc. This is ideal for presenting web content, where we don't want to scale by ourself.
For best picture quality on TV-out the resolution should be 720x576. Then no additional scaling/filtering is done and therefore the bits stay like they are. Practical this isn't working. I think due to a bug in the DVB-driver, it's not possible to use 720x576. The picture gets distorted.
Important: The y resolution still have to be 576. This is needed because we use interlaced content. With this content it is needed to have a 1:1 relation between the input lines to the output lines.
mode "768x576-73"
# D: 36.058 MHz, H: 45.993 kHz, V: 73.120 Hz
geometry 768 576 768 576 32
timings 27733 18 0 34 10 46 4
#timings 40557 18 0 34 10 46 4
bcast true
accel true
#rgba 8/16,8/8,8/0,8/24
endmode
mode "1024x576-73"
# D: 36.058 MHz, H: 45.993 kHz, V: 73.120 Hz
geometry 1024 576 1024 576 32
timings 27733 18 0 34 10 46 4
#timings 40557 18 0 34 10 46 4
bcast true
accel true
#rgba 8/16,8/8,8/0,8/24
endmode
VDR is using the DVB-card for showing its OSD. Because we have the VGA-screen now, it's of course better to have the OSD also on VGA.
For this reason I derived a class dfbosd from the dvbosd class. Only one member function and the constructor/destructor have to be implemented.
The impotant member function is the Cmd member. This member funtion is responsible for sending information to the DVB-card. In dfbosd this funtion is changed that it sends the information into a pipe.
When df-gp starts VDR it creates a pipe at first. The file descriptor number is put as an environment variable into the environment space. Then VDR is started.
Inside VDR the dfbosd class attaches itself onto this file descriptor number. All OSD related information are send to this pipe.
Because the signature of Cmd is not changed, all the other methods don't have to be changed.
On df-gp's side. The data are decoded and corresponding actions are performed.
Because the OSD lifes in a 720x576 non quadratic pixel world it has to be scaled into the resolution used by df-gp. This is done by using DirectFb's StretchBlit function.
Every window gets it's screen window and a corresponding rawSurface. The bitmap from vdr is painted into the rawSurface, which has the size of the window as it was created by VDR. This rawSurface is then StretchBlited into the screen surface, which may have a completely different resolution.
The mplayer integration is really simple done right now. MPlayer must use the mga driver to output its picture. Because df-gp isn't using the BES layer this works, i.e. mplayer is writing directly to the BES layer, which superseedes the primary layer of the matrox graphics card. When mplayer stops it frees the BES layer and we can see again the primary layer which is used by df-gp.
This also means that while mplayer is running you'll never see df-gp windows.
Controlling mplayer is done via lirc. In the future I'll change that.
Synchronisation of video sources is the biggest issue to get a good video quality. In the gp-vdr plugin the video source and the video output on TV must be somehow synchronized. The normal way to do that is to take a frame from input and display it when the output signals a frame change (WAITFORSYNC). The problem is that both units are running freely, i.e. one of both will still be faster than the other. The possibility that both run exactly at the same speed is very low. When they run at slightly different speeds it will happen that you have to skip a frame when the synchronisation points are running over. If the clock has some jitter than it may be that the overrun happens not only one but multiple times when both points are near to each other.
The solution to that problem is very old. Because the input clock can't be changed and the input and the output clock have a fix relation (1:1) the phase must be locked. Normally this can be done by genlock devices. In our case we have full control over TV-out and for TV-out it doesn't matter if we run 50Hz or 50.0001Hz or 49.999Hz. That means we could varying the speed of the output to stay in phase with the input. Therefore we would never have an overrun effect.
Practical I was not able to fine control the output timings. The only thing I was able to implement yet is a RESYNC ioctl. This ioctl restarts the TV-out timers, i.e. after issuing this ioctl a new full frame sequence is started.
Because the input is PAL and the output is PAL to, the difference is not that much. The easiest thing would be now, to restart the TV-out every time a new frame is ready. A new frame is ready every 40ms and to output the frame will take 40ms. The result would be perfect, but the restart of the TV-out chip can be seen. That means if we resync every frame, the picture looks very bad.
The current solution is, to RESYNC every some hundred frames. This results in a noticable flicker every some seconds. But in the meantime the picture quality is excellent.