Hello,
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
On 8 November 2010 13:59, lucian orasanu o_lucian@yahoo.com wrote:
Hello,
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
My personal experience with mplayer is that it lacks proper aspect ratio detection or guessing based on source that does not contain the correct info. xine-lib seems to handle this much better. Also automatic cropping is a nice feature that works quite well in the vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem to mind that the output is stretched or squeezed incorrectly, but I do. I prefer it that a circle appears to be that and not in the elliptical form.
Theunis
On 08/11/10 12:50, Theunis Potgieter wrote:
On 8 November 2010 13:59, lucian orasanuo_lucian@yahoo.com wrote:
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
My personal experience with mplayer is that it lacks proper aspect ratio detection or guessing based on source that does not contain the correct info. xine-lib seems to handle this much better. Also automatic cropping is a nice feature that works quite well in the vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem to mind that the output is stretched or squeezed incorrectly, but I do. I prefer it that a circle appears to be that and not in the elliptical form.
What??! You can tell mplayer the exact ratio of your monitor and the exact ratio of the video on the command line and it correctly calculates how to display it. vdr-sxfe and vdr-fbfe have an equivalent of -monitoraspect but xine-ui and gxine don't, or didn't last time I looked. Instead they query the display's dimensions from the X server, which often gives bogus information, or xine doesn't use the information correctly. For example, X thinks my Sony TV (1366x768 physically, but uses a 1360x768 native resolution, connected by HDMI), measures 16m x 9m (yes, metres!) so I override it with:
Section "Monitor" Identifier "32in TV" #DisplaySize 708 398 # real size DisplaySize 320 180 # lie to avoid tiny fonts Option "UseEdiDpi" "false" Option "DPI" "96 x 96" Option "DPMS" "false" EndSection
But when I tried xine it was OK windowed, while in full-screen mode it scaled and applied letterboxing as if for a 4:3 display for some reason :-(.
With xine you can override the aspect ratio of the video stream too. It has the advantage over mplayer that you can do it on the fly, but the disadvantage that it only has a few presets with names that don't indicate what the aspect ratio actually is in numbers.
On 8 November 2010 17:02, Tony Houghton h@realh.co.uk wrote:
On 08/11/10 12:50, Theunis Potgieter wrote:
On 8 November 2010 13:59, lucian orasanuo_lucian@yahoo.com wrote:
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
My personal experience with mplayer is that it lacks proper aspect ratio detection or guessing based on source that does not contain the correct info. xine-lib seems to handle this much better. Also automatic cropping is a nice feature that works quite well in the vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem to mind that the output is stretched or squeezed incorrectly, but I do. I prefer it that a circle appears to be that and not in the elliptical form.
What??! You can tell mplayer the exact ratio of your monitor and the exact ratio of the video on the command line and it correctly calculates how to display it. vdr-sxfe and vdr-fbfe have an equivalent of -monitoraspect but xine-ui and gxine don't, or didn't last time I looked. Instead they query the display's dimensions from the X server, which often gives bogus information, or xine doesn't use the information correctly. For example, X thinks my Sony TV (1366x768 physically, but uses a 1360x768 native resolution, connected by HDMI), measures 16m x 9m (yes, metres!) so I override it with:
I was referring to the source and not to my output display.
Section "Monitor" Identifier "32in TV" #DisplaySize 708 398 # real size DisplaySize 320 180 # lie to avoid tiny fonts Option "UseEdiDpi" "false" Option "DPI" "96 x 96" Option "DPMS" "false" EndSection
But when I tried xine it was OK windowed, while in full-screen mode it scaled and applied letterboxing as if for a 4:3 display for some reason :-(.
With xine you can override the aspect ratio of the video stream too. It has the advantage over mplayer that you can do it on the fly, but the disadvantage that it only has a few presets with names that don't indicate what the aspect ratio actually is in numbers.
-- TH * http://www.realh.co.uk
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I demand that Tony Houghton may or may not have written...
On 08/11/10 12:50, Theunis Potgieter wrote:
[snip]
You can tell mplayer the exact ratio of your monitor and the exact ratio of the video on the command line and it correctly calculates how to display it. vdr-sxfe and vdr-fbfe have an equivalent of -monitoraspect but xine-ui and gxine don't, or didn't last time I looked.
gxine has video.display_width and video.display_height. I should move them to xine-lib one day...
[snip]
I demand that lucian orasanu may or may not have written...
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
Feel free to help out, by all means...
On Wed, Nov 10, 2010 at 12:52 PM, Darren Salt linux@youmustbejoking.demon.co.uk wrote:
I demand that lucian orasanu may or may not have written...
how about moving to mplayer instead of xine-lib, is not maintained very well any more?
Would be good, I returned to xinelibout / xine-lib with yavdr recently after using a reel eHD for awhile to find that the same old sync problems exist which is a real shame otherwise it would be pretty good. I especially see sync issues on channels with Dolby Digital 2.0, Stereo PCM doesn't seem too bad.
-
Darren Salt -
lucian orasanu -
Morfsta -
Theunis Potgieter -
Tony Houghton