pycousin / gnome-mplayer

Automatically exported from code.google.com/p/gnome-mplayer
GNU General Public License v2.0
0 stars 0 forks source link

video turns to black when switching to fullscreen with VDPAU output #373

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. launch gnome-mplayer
2. select VDPAU video output
3. switch to fullscreen while playing a video

What is the expected output? What do you see instead?
The video should scale to fullscreen. Instead, the screen turns to black
and switching back to windowed mode doesn't restore the correct behaviour :
the video is still all black

What version of the product are you using? On what operating system?
v0.9.8, v0.9.9, v0.9.9.2.

system :
linux kernel 2.6.32.7
xorg 7.1
mplayer SVN-r30531
nvidia binary driver 190.53 (stable) and 195.30 (beta)
GTK+ 2.18.7

Please provide any additional information below.
As i said in "issue 370", it used to work for me, and i have never used any
compositing manager. I updated GTK+ since then, so may be is it GTK related?
Mplayer launched from the command line do work, and correctly switches to
fullscreen and back, though.

Help!!!
thanks, Seb.

Original issue reported on code.google.com by sebastie...@free.fr on 15 Mar 2010 at 3:39

GoogleCodeExporter commented 8 years ago
Try adding 

export GDK_NATIVE_WINDOWS=1 

to the environment and see if it helps. Also you might try enabling compositing.

Original comment by kdeko...@gmail.com on 15 Mar 2010 at 3:41

GoogleCodeExporter commented 8 years ago
similar problem here.
http://http.ruv.straumar.is/static.ruv.is/vefur/innklipp_eldgos.wmv doesn't work
properly. in my case video starts without problems but after ~ 17 sec it gets 
black,
while sound works. there is no possibility to get video back nor restarting 
playback.
so i don't need fullscreen to get this bug. but i think it could be the same 
problem.
(export GDK_NATIVE_WINDOWS=1 didn't help)

distribution: sidux (debian unstable)
KDE 4.3.4 with active composting
iceweasel/firefox 3.5.8-1
MPlayer SVN-r30660-snapshot-4.4.3 with vdpau
gecko-mediaplayer 0.9.9.2-1
gnome-mplayer 0.9.9.2-1

Original comment by sebastia...@googlemail.com on 21 Mar 2010 at 5:54

GoogleCodeExporter commented 8 years ago
Sorry, since I don't have vdpau capable hardware I really can't do much for 
this. I
will take a patch however if you get a fix.

Original comment by kdeko...@gmail.com on 22 Mar 2010 at 2:29

GoogleCodeExporter commented 8 years ago
Suggest you try enabling composite and see if that helps.

Original comment by kdeko...@gmail.com on 22 Mar 2010 at 2:29

GoogleCodeExporter commented 8 years ago
composite is already enabled.

i installed old mplayer (debian unstable 1.0~rc3+svn20090405-1+b1) from repo 
without
vdpau support but nothing changed.

Original comment by sebastia...@googlemail.com on 22 Mar 2010 at 6:08

GoogleCodeExporter commented 8 years ago
Does xv or x11 output work? Like I said if those work, there is really not 
anything I
can do for you since I don't have that hardware.

Original comment by kdeko...@gmail.com on 22 Mar 2010 at 7:13

GoogleCodeExporter commented 8 years ago
because of original debia mplayer i have to use x11 / xv. so it does not work
properly no matter what video output i use. first ~25 sec everything works fine 
but
then video turns black and doesn't return whatever i do.
i already use vlc to see if video is corrupted but everything seems to be ok.

do you a similar behavior with the same link on your machine?

Original comment by sebastia...@googlemail.com on 22 Mar 2010 at 11:52

GoogleCodeExporter commented 8 years ago
I was able to watch the entire 1:30 of the video. Using xv output on an ATI 
r600 card. 

Original comment by kdeko...@gmail.com on 23 Mar 2010 at 3:46

GoogleCodeExporter commented 8 years ago
I have this problem as well with an Nvidia 9500GT and the 195.36.15 driver, 
compositing disabled in xorg.conf.

I think this is related to the way the frame is being drawn (for lack of better 
terms), and not the fault of mplayer or nvidia.  If you noticed, when going to 
fullscreen it goes black, then back to a window it's still black; but then if 
you go 
into the preferences and choose xv, the video comes back.  In other words 
mplayer, 
firefox, the driver, etc, have not crashed in anyway.  smplayer and cli mplayer 
also 
have no problem with fullscreen and back again.

Is there any way to enable some debug logs for gnome-mplayer?  Any other 
environment 
variables I could try?

As an aside, is there any way we can go back to good old cli mplayer like it 
was 
with the mplayerplug-in package?  Why does gnome-mplayer have to be embedded 
into 
the browser, it just adds a layer of complexity such as being reported in this 
bug 
report.  I was happy for a long time with the mplayer window popping up.

Original comment by cpt_mo...@yahoo.com on 16 May 2010 at 11:16

GoogleCodeExporter commented 8 years ago
I understand your frustration, but the fact that it works with x11, xv and gl 
video
outputs points to a problem in the vdpau driver/vdpau support in mplayer. You 
might
want to ensure that you have a current mplayer. I don't have nvidia hardware to 
test
with and everything works fine with my radeon hardware. When the video goes to
fullscreen. The video is moved from the browser window to a new window and then 
that
window goes fullscreen. This is common X window manipulation, and the driver 
should
be able to handle it.

Logs can be enabled with Edit->Preferences [Interface] and check the Verbose 
Debug
Enabled. The output will go to the console or to .xsession-errors

mplayerplug-in still exists, if you prefer it, use it. But I don't do any active
development in it anymore. But if you would like to submit patches, I'll take 
them.
gecko-mediaplayer and gnome-mplayer work great for most people. I actually 
suspect in
a couple of years that gecko-mediaplayer will no longer be needed due to HTML5 
and
the video tag.

Original comment by kdeko...@gmail.com on 17 May 2010 at 1:08

GoogleCodeExporter commented 8 years ago
I use mplayer from SVN, and also tired with mplayer_git; no difference.  I also 
tried
numerous times to compile the CVS of mplayerplug-in but cannot do it.

Thanks for the info about .xsession-errors.  I found out something interesting. 
 I
started a video in youtube (I'm using the greasemonkey script "youtube without 
flash
auto"), then I changed the rendering to vdpau and copied out the mplayer 
command line
from .xsession-errors.  I stopped the playback in Firefox but left the window 
open
and ran the command in a terminal which continues playing the video in Firefox, 
and I
was able to double-click to go fullscreen and back and forth from Firefox!  So
basically everything works properly as long as the mplayer command was run in a
terminal.  This is above my head, but hopefully this rings a bell for someone.  
Here
was the mplayer command for this particular video and session:

mplayer -profile gnome-mplayer -vc ffh264vdpau -quiet -slave -identify -volume 
79
-noconsolecontrols -noidle -osdlevel 0 -nomouseinput -nocache -wid 0x5800046 
-ss 79
-cookies -subfont-text-scale 5 -subfont Sans -channels 2 -lavdopts threads=4
-dvd-device /dev/dvd -af-add export=/tmp/mplayer-af_exportlqhjvu:512
/home/mocha/.cache/gnome-mplayer/plugin/gecko-mediaplayerudssit

I also catch an error like this in .xsession-errors:
VO: [vdpau] 1920x1080 => Window manager warning: Invalid WM_TRANSIENT_FOR window
0x5e00020 specified for 0x5e00320 (GNOME MPla).

As a final note, I noticed you are using -wid in the command, if I remove it 
then
mplayer opens in its own window (like mplayerplug-in) and again everything is 
working
properly.  Is it feasible to patch the source to eliminate the passing of -wid? 
 I
will try it if you can give me some pointers.  Thanks.

Original comment by cpt_mo...@yahoo.com on 18 May 2010 at 5:24

GoogleCodeExporter commented 8 years ago
It is very easy to patch the source. Search for "-wid" in thread.c . However, no
patch that works like that will ever be accepted into gnome-mplayer.

Original comment by kdeko...@gmail.com on 18 May 2010 at 10:42

GoogleCodeExporter commented 8 years ago
Thanks.  It works.  I'm not sure why you simply don't add this as a feature. 
Something like "Play in browser" or "Play in standalone window".  It's nice to 
be
able to move the mplayer window to another screen for example, in my case a
television where I can go fullscreen there and still use the browser.  Anyway, 
it's
your call..

Original comment by cpt_mo...@yahoo.com on 19 May 2010 at 5:34

GoogleCodeExporter commented 8 years ago
Because it makes the controls appear in the browser window and the video appear
somewhere else. Also makes gnome-mplayer work weird so that is why I don't like 
it. I
still consider this a bug in the nvidia drivers.

Original comment by kdeko...@gmail.com on 19 May 2010 at 12:43

GoogleCodeExporter commented 8 years ago
same here, only the audio plays but no video output come out .

Original comment by peLASTIK...@gmail.com on 19 Oct 2010 at 8:50

GoogleCodeExporter commented 8 years ago
same here what? no video when using vdpau? If not does it work with x11 or xv 
output?

What version of gnome-mplayer are you using?
What video card?
What drivers?

Original comment by kdeko...@gmail.com on 19 Oct 2010 at 8:54

GoogleCodeExporter commented 8 years ago
I just wanted to report that i consider this issue resolved fixed :
after sometime using mplayer's CLI, and several NVidia binary drivers updates,
I decided to give gnome-mplayer a new try... And it worked. Currently i use 
NVidia driver v260.19.29, gnome-mplayer 1.0.0, and mplayer SVN-r32717.

Regards, Seb.

Original comment by sebastie...@free.fr on 18 Dec 2010 at 6:53

GoogleCodeExporter commented 8 years ago
i tested it again with nvidia 260.19.21-1, gnome-mplayer 1.0.0, gecko-mplayer 
1.0.0 and mplayer 1.0~rc4~try1.dsfg1-1 but i still get black screens after some 
time. it's really annoying!

Original comment by sebastia...@googlemail.com on 13 Jan 2011 at 9:08

GoogleCodeExporter commented 8 years ago
Sebastian, might try upgrading to the nvidia v260.19.29 driver.

Original comment by kdeko...@gmail.com on 13 Jan 2011 at 9:09

GoogleCodeExporter commented 8 years ago
sadly v260.19.29 is not in debian experimental. last time i made no good 
experiences in installing nvidia-driver by hand. afterwards it was nearly 
impossible to remove it and get a proper working dmakms with nvidia-driver 
again.

but i will give it a try and report the results.

Original comment by sebastia...@googlemail.com on 13 Jan 2011 at 9:32

GoogleCodeExporter commented 8 years ago
Can you try the 1.0.4b1 code and see if that helps any?

Original comment by kdeko...@gmail.com on 6 Jun 2011 at 5:22

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I am experiencing this when using vdpau with version 1.0.4, Nvidia driver 
280.13. Video is only restored by switching vo to Xv and restarting 
gnome-mplayer. This occurs with my Quadro NVS 3100m and Geforce 8400GS under 
Ubuntu 11.04, running either Unity or Compiz. I believe it may also happen 
under Metacity, will make an extended test later.

Original comment by tom.gelinas@gmail.com on 3 Aug 2011 at 9:08

GoogleCodeExporter commented 8 years ago

If a VDPAU accelerated instance of gnome-mplayer outputs only black, and 
another VDPAU accelerated media player is tried, that other media player 
functions properly. Even after having successfully played a VDPAU accelerated 
video with another player, gnome-mplayer still does not properly function.

I have not seen this problem with gmplayer and mplayer. I wonder if it only 
occurs after launching several instances of ANY VDPAU accelerated media player. 
If someone wants narrow the scope of this bug, they should probably use 
gmplayer with vo=VDPAU as their default media player for a while. If gmplayer 
displays only black output, then the problem is probably with VDPAU. Otherwise, 
there is a valid issue with gnome-mplayer.

Original comment by tom.gelinas@gmail.com on 6 Aug 2011 at 4:04

GoogleCodeExporter commented 8 years ago
There is a fix in the current SVN code that may fix this. I was advised to not 
set the background color for the vdpau output as it may cause issues. So I have 
made that change. I have a ATI card that can use VDPAU under gallium and I am 
unable to duplicate the problem with that setup.

Original comment by kdeko...@gmail.com on 9 Aug 2011 at 3:31

GoogleCodeExporter commented 8 years ago
Unfortunately that didn't fix it. The video space is grey and the pillarboxing 
is black.

Original comment by tom.gelinas@gmail.com on 11 Aug 2011 at 9:32

Attachments:

GoogleCodeExporter commented 8 years ago
We are experiencing same issues here. 
Our gnome-mplayer version is 1.0.4b2, mplayer 2:1.0~rc4, from natty repos, and 
we are using an iON based custom device (VDPAU acceleration is fundamental for 
us) 

Since we only need the gecko-mediaplayer -> mplayer connection, and I must 
suppose the problem is in someway related to the GTK+ VDPAU combination, is 
there anyway to get rid of the gtk interface in gnome-mplayer and only exploit 
its dbus interconection with gecko-mediaplayer? Or maybe mplayerplug-in is 
better for us? 

Original comment by jacopo.m...@gmail.com on 24 Aug 2011 at 9:25

GoogleCodeExporter commented 8 years ago
Well since mplayer does not have a dbus interface, you still need gnome-mplayer 
to bridge that connection. The current SVN code might fix your problem, but I 
still feel that the problem is with the nvidia drivers. As I have vdpau 
available on my machine and it works correctly, and others have it working on 
their machines. Recommend trying a newer version of mplayer as well.

Original comment by kdeko...@gmail.com on 24 Aug 2011 at 3:04

GoogleCodeExporter commented 8 years ago
Right, I'm trying to control mplayer through a fifo to avoid dbus at all..
I can only confirm that gnome-mplayer works fine on an older ubuntu 10.04, but 
I cannot provide more information about nvidia driver version (gnome-mplayer 
version is the same)

Original comment by jacopo.m...@gmail.com on 25 Aug 2011 at 11:03

GoogleCodeExporter commented 8 years ago
Closing due to age

Original comment by kdeko...@gmail.com on 22 Oct 2012 at 4:33