Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: vdr-xine-plugin 0.0.2 problem



Hi,

Guido Fiala wrote:

Not any help for you, but I also get the exact behavior.
(xine plugin does not fill the fifo's).

So if you find the solution, I'd be listening ;-)
Yes - indeed i found the problem:
You must not have loaded any dvb-driver !
Without it works, somewhat.
I don't understand that. I use

	./runvdr -Pxine

which first loads the DVB driver and afterwards VDR.

It displayes the video but not smooth - lot's of framedrops.
Well, from time to time, xine doesn't sychronize after switching channels. Maybe it helps to pause playback via xine's GUI for about 1 second.

Also i wonder why my P3-1266 MHz is slower at decoding MPEG2 than
my old P2-450 - the sysload is now almost 100% despite that i could flawlessly watch MPEG fullscreen at the older system.
Both Systems have Xv-support working fine without any cpu-load to display fullscreen.

Another thing is, that the video-size send via the FIFO does change the size of the xine-window instead of simply scaling correctly. @Reinhard: please add this to the README...
I don't modify any of the packets, that VDR hands me over. It's xine's behaviour to act like that (e. g. the same happens, if you play a DVD). I don't think that I can do anything about that.

I bug is also, that the OSD size is incorrectly calculated after such changes - most times the OSD seems to be twice as large as the window, so one can only see the top left of the OSD.
The problem is, that xine blends the OSD into unscaled video and then scales the result according to the stream's aspect ratio. Stations like VIVA send only 480x576 images, but VDR's OSD is perfect on 720x576 resolution.

The real bug is, that xine doesn't clip the too large OSD, but simply wraps it. In my opinion it doesn't make sense to prescale VDR's OSD for perfectly matching the video image, due to the loss of OSD qualtity. A later approach could be to blend the OSD after scaling the video by using two hardware overlays which xine will support later by using the XvMC API.

Image quality itself is great otherwise.

It seems that no SVDRP-control is supported in xine?
Please explain that more detailed. What's SVDRP?

Why use xine anyway? At least at my system mpeg2dec has the lowest cpu-load of all players, then comes mplayer and xine uses the most cpu. Trying that shows, that only xine correctly synchronizes at the FIFO, that other players show only garbage but the video shows up "somewhat"...
Well, I had a look into xine's and mplayer's sources and xine's really look more modular, but I didn't have a look into mpeg2dec so far.

(All players are compiled optimally for my architecture as i'am using Gentoo-Linux.)

Well - Reinhard - if you are listening - maybe you can answer some of the questions...
Well, I'm working (at least thinking) about release 0.0.3 for quite some time now, but after beeing 9 to 12 hours at work, there is no time left for any real progress on the project. Only on Sunday, I find a some hours to work on the plugin.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de




--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index