In <[EMAIL PROTECTED]>, Ville Syrj�l� wrote:
On Tue, Jan 25, 2005 at 05:19:06PM +0000, Tony Houghton wrote: > I can't get df_xine to work with my TV. Depending on various vt options > in /etc/directfbrc and/or whether I use df_xine -l 2, I either get a > completely black screen or flickering spots and mangled black & white > bits of picture reminiscent of a very knackered VCR.
With primary-layer=2 you need to use df_xine -l 0.
If you don't force the layer df_xine seems to make some bad assumptions about the primary layer.
Also for some reason it doesn't allow YUV formats unless the layer has DLCAPS_SCREEN_LOCATION. Claudio what's the deal with this one?
I'm still getting a blank screen, although it seemed to be more of a dark grey than a black this time. It didn't matter whether I used -l 0 or not. FWIW the pixel format was YV12.
Hi,
let me join this as I have similar problems on the TV-out of a Matrox G400 DH, using DirectFB-0.9.21 now the CVS version is absolutely unusable for me now (requires a reboot after each run of a DirectFB application which leaves the Maven chip un-deinitialized or something).
But I noticed that df_xine for sure must be doing something wrong regarding layers/pixelformats, because only by changing the primary layer and forcing a different layer in df_xine, I get the following:
- if I set "primary-layer=2" in /etc/directfbrc and call df_xine with "-l 0", I get the dirty dark grey / black screen on TV, the video is played (be it MPEG1, DVD, DivX) and the sound is ok, even DD5.1 via SPDIF works ok.
- if I DON'T set the "primary-layer=2" in /etc/directfbrc and call df_xine with "-l 2", I get picture on TV. I thought that's the way, but then I looked at the colours, everything is inverted :-( !!!
So these are two routes from which I would have expected to behave the same, as I'm calling df_xine to output on CRTC2 in both cases...
On the first head (FBDev Primary Layer) the colours seem OK, but I'm not interested in that one (yet, as I only have an ordinary TV with just one SCART-RGB input) and just carry from time to time a refurbished CRT monitor to the living room to check if at least on the primary head there's something going on...
A short test of df_xine has convinced me to stick with mplayer. Having tried just two divx files CPU usage with df_xine is about 57% with both files whereas with mplayer I get about 17% for one and 7% for the other. Quite a difference and it makes me think something is very very wrong with df_xine.
What CPU do you have? df_xine just showed up as 0% here on my 1.2GHz Celeron. I would have thought it would register a few % for the sound even if it wasn't trying to show the picture. I couldn't check whether the sound was playing properly because I'm running it remotely from a different room from the TV ATM.
BTW, Tony, I read in your older post in this thread you where looking for better field parity support in DVB stuff like VDR. Well, I don't know if you follewd closely this list but Stefan Lucke seems to have found the solution for that in softdevice...
Then, the only thing I would miss in both softdevice and df_xine would be the ability to hardware-blend OSD data on the Matrox subpicture layer when using CRTC2 for the video (I think that is certainly reducing CPU usage especially with OSD-intense applications like VDR), just like mplayer -vo dfbmga is doing. Stefan Lucke already has a few Matrox-specific options in his code, that encourages me to hope that such special treating of layers can be implemented even if his DFB output in softdevice is generic.
Cheers, Lucian
