pycousin / gnome-mplayer

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

Playing a video in vdpau fullscreen composting enabled works, without compositing fails #370

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Disable compositing in the xorg.conf config file.
2. Restart X.
3. Open gnome-mplayer and make sure output is set to vdpau.
4. Play any video file and then fullscreen.

What is the expected output? What do you see instead?
When you fullscreen the video the video disapears and the screen goes to
black. The video is still playing however and the sound can be heard. When
you return from fullscreen the small video window stays black as well. Only
way to get the view the video again is to reopen the video file. Also
opening menus while the video is playing erases some of the video. The area
the menus go over stays black. 

What version of the product are you using? On what operating system?
I am using version 0.9.9.2 on Archlinux using the package in the community
package. 

Please provide any additional information below.
If you play a video with compositing enabled in X this behaviour doesn't
happen. There is however tearing in the video with composting enabled. 

Original issue reported on code.google.com by coolbooks2@gmail.com on 12 Mar 2010 at 4:24

GoogleCodeExporter commented 8 years ago
In the community repository not package. Sorry typo.

Original comment by coolbooks2@gmail.com on 12 Mar 2010 at 4:28

GoogleCodeExporter commented 8 years ago
If you change the video output option to x11 or xv does this problem go away? 
If so
it sounds like a bug somewhere else. I do not have a vdpau capable device to 
test
with. Did this used to work and is now a regression? 

Original comment by kdeko...@gmail.com on 12 Mar 2010 at 4:48

GoogleCodeExporter commented 8 years ago
I also have this problem. I'm using the same version and is also running 
Archlinux.
If I enable x11 or xv as output the problem goes away, but then vdpau isn't 
used which makes the movie stutter 
heavily on my system.
I have not tried an older version because I have just recently got the vdpau 
capable graphic card. Maybe I could 
downgrade to try, but I'm not sure if that would cause some other problems.

Original comment by mathias....@gmail.com on 13 Mar 2010 at 9:47

GoogleCodeExporter commented 8 years ago
The vdpau option is only available on nvidia video cards and I do not have one. 
So I
cannot do any debugging on this issue. Does the video disappear if you only 
maximize
the window and not fullscreen it?

I'm surprised that xv causes the video to stutter as that normally gives pretty
decent results unless the videos are large. 

Original comment by kdeko...@gmail.com on 13 Mar 2010 at 2:44

GoogleCodeExporter commented 8 years ago
Resizing is also a problem. If I decrease the size of the window the video 
shrinks as expected. But when 
increasing the size the video remains small and the area around gets filled 
with black.
Also any window or menu that happens to move over the video leaves that area 
black as well.

Xv isn't the cause for the stuttering. It's my cpu thats to slow for a smooth 
playback, that being the reason why I 
need vdpau.

Original comment by mathias....@gmail.com on 13 Mar 2010 at 3:01

GoogleCodeExporter commented 8 years ago
What version of mplayer are you using? If you open the video with just mplayer 
do you
have problems when you resize the video?

Original comment by kdeko...@gmail.com on 13 Mar 2010 at 3:04

GoogleCodeExporter commented 8 years ago
Also how fast is your CPU and how much RAM do you have?

Original comment by kdeko...@gmail.com on 13 Mar 2010 at 3:11

GoogleCodeExporter commented 8 years ago
MPlayer SVN-r30526-4.4.3
Resizing with mplayer appears to work fine.

Original comment by mathias....@gmail.com on 13 Mar 2010 at 3:11

GoogleCodeExporter commented 8 years ago
My CPU is an Core2duo @ 1.86ghz
Ram is 4gb but only ~3.07 available due to a limit in my cheap motherboard 
chipset.

Original comment by mathias....@gmail.com on 13 Mar 2010 at 3:18

GoogleCodeExporter commented 8 years ago
Did disabling deinterlacing affect this issue at all? What size of video are you
trying to playback 1080p videos? Because that CPU should be able to play most 
videos
just fine with XV.

It may be possible that vdpau just does not like to be embedded in a window. 
Have you
tried gl or gl2 video outputs and see if they help any?

Also are you sure that the memory is limited by the motherboard and not that 
you are
running in 32bit mode. Because that memory limit is right around where the 
32bit cut
off occurs. Not all core2duos can run in 64bit mode so it may be a CPU limit. 
Might
try a 64bit live CD and see if that allows you to get more RAM.

Original comment by kdeko...@gmail.com on 13 Mar 2010 at 4:50

GoogleCodeExporter commented 8 years ago
Disabling deinterlacing did unfortunately not affect this issue.
Yes it's most 1080p movies and a few high bitrate 720p movies that's a little 
to heavy on the cpu usage and 
causing a problem.
I have attached a log when playing one of the heaviest with xv active. Not sure 
if it shows much though.

Xv, gl and gl2 works correctly but then vdpau isn't used and the playback 
stutters. Lower resolution and bitrate 
movies play fine.

I'm already running a 64bit system. Unfortunately I'm pretty confident it's my 
motherboard chipset thats 
limiting my accessible amount of memory. It's discussed here 
http://www.pcreview.co.uk/forums/thread-
2314894.php and explained more in this document 
http://dlsvr01.asus.com/pub/ASUS/mb/4GB_Rev1.pdf
But thanks for the tips anyway :)

Original comment by mathias....@gmail.com on 13 Mar 2010 at 5:18

Attachments:

GoogleCodeExporter commented 8 years ago
Hello there,

i stumbled upon this thread while looking for a solution to the very same 
issue...
Except i am not running archlinux, nor a compositing manager. :-)
Launching mplayer from the command line works : when switching to fullscreen,
everything is fine.
I tried to downgrade the Nvidia driver from beta to the latest stable, upgraded 
gtk+
to latest (2.18.7), and tried gnome-mplayer v0.9.9.2, 0.9.9., and 0.9.8. They 
all
have the same issue.
But what i can say is that it used to work for me with gnome-mplayer-0.9.8 for 
sure.
My wild guess is that it's either GTK or mplayer related.

just my 2 cents,
Seb.

Original comment by sebastie...@free.fr on 14 Mar 2010 at 7:59

GoogleCodeExporter commented 8 years ago
Just to clarify, I'm not  using compositing. I don't thing the original poster 
does either if you look at his steps for 
reproducing the error. It's just the title of the issue that wrongly states 
thats compositing is enabled.

Original comment by mathias....@gmail.com on 14 Mar 2010 at 8:18

GoogleCodeExporter commented 8 years ago
Back to the original issue, any particular reason compositing is needed to be
disabled? I thought that most DEs were recommending it now?

Original comment by kdeko...@gmail.com on 15 Mar 2010 at 12:54

GoogleCodeExporter commented 8 years ago
I have compositing disabled because I had tearing issues in XBMC. And as far as 
I could tell that was the 
recommended solution. XBMC is the main purpose for this computer so that 
working smooth is the main 
priority. Though after a quick test now it appears that it is Compiz that's 
causing the XBMC tearing issues. So 
I guess I could have compositing enabled.

I have tried Gnome-Mplayer with compositing enabled and then it works better. 
Video doesn't turn black 
neither in fullscreen or behind menus and windows.
Unfortunately this introduces some other problems. Like the original poster I 
get tearing in the video both in 
fullscreen and in window playback.
The tearing might be something else though. It wasn't there before enabling 
compositing. But is now also 
present when using standard Mplayer. If i use Compiz the tearing gets slightly 
better but it's not fully gone.
Also in fullscreen when the control bar disappears the video flickers and 
appears to jump back and fort a few 
frames. Disabling the animation makes it better with only a slight stutter when 
it disappears. The animation 
was really nice though when using xv.

Original comment by mathias....@gmail.com on 15 Mar 2010 at 2:11

GoogleCodeExporter commented 8 years ago
As far as I know video tearing is only really corrected in the OpenSource 
drivers and
then you have to use pretty recent code. I have an ATI R600 card and tearing 
was only
recently fixed for me. Large videos like elephants dream at 1080p still give a 
little
problem because of the decoding of the video takes an entire processor on my 
machine.
2.66GHz Intel Q6600. But I don't see any tearing.

I use also compiz 

BTW, you can turn off the animation in fullscreen, it is a interface preference.

tearing is caused by the video card displaying a buffer that still being drawn. 
There
has to be syncronization between the video driver and the x-server and in some 
cases
the kernel (KMS setups). Perhaps upgrading the x-server will help out. I'm using
1.7.5.901-4

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

GoogleCodeExporter commented 8 years ago
Unfortunately the nvidia open source drivers (Nouveau?) if I understand 
correctly doesn't provide VDPAU yet, 
which I need for those large 1080p videos.

Animation is now turned off, and there is just a slight stutter when the 
control bar disappears, but that's ok.

When playing the same video in XBMC also using VDPAU and compositing enabled, 
there don't appear to be any 
tearing, but maybe XBMC does it some other way.
I'm running version 1.7.5.902-1 of the x-server.

Original comment by mathias....@gmail.com on 15 Mar 2010 at 2:53

GoogleCodeExporter commented 8 years ago
I apologize if i hoped on that thread inappropriately...
It turns out that i was a little of topic, my issue not dealing with 
compositing.
I am going to open a new issue for my specific case.
Sorry for the noise. :-(
Seb.

Original comment by sebastie...@free.fr on 15 Mar 2010 at 3:26

GoogleCodeExporter commented 8 years ago
Might see if this article helps at all

http://blog.mymediasystem.net/my-media-system/tearing-with-nvidia-dirvers-and-mp
layer-with-vo-xv/

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

GoogleCodeExporter commented 8 years ago
That article concerns xv. When I use xv there is not tearing even with 
compositing enabled. It's only VDPAU that 
causes problems and it only tears when composting is enabled.

Thank you for trying to help me/us btw

Original comment by mathias....@gmail.com on 15 Mar 2010 at 3:47

GoogleCodeExporter commented 8 years ago
Marking as done since I don't have vdpau capable hardware. If you find a fix, I 
will
take a patch, but probably the best thing is to enable composite for now.

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

GoogleCodeExporter commented 8 years ago
I have a similar problem: mplayer works fine, but gnome-mplayer have tearing. 
But it
is indenpent by vdpau or xv or x11

Original comment by guido.io...@gmail.com on 29 Apr 2010 at 8:05

GoogleCodeExporter commented 8 years ago
guido.iodice,

What video card? What drivers? What version of GTK and X?

Original comment by kdeko...@gmail.com on 29 Apr 2010 at 9:01

GoogleCodeExporter commented 8 years ago
video card: nvidia 8200
driver: nvidia proprietary driver
X: 1.7.6
GTK: 2.20
gnome-mplayer: 0.9.9.2
mplayer: MPlayer SVN-r29978-4.4.2
OS: Ubuntu 10.04

Original comment by guido.io...@gmail.com on 29 Apr 2010 at 9:09

GoogleCodeExporter commented 8 years ago
nvidia driver likes to tear in fullscreen mode when in a gtk window... 

Original comment by kdeko...@gmail.com on 30 Apr 2010 at 1:00

GoogleCodeExporter commented 8 years ago
but Totem works fine. Mplayer itself uses gtk for its gui and works with no 
tearing.

Original comment by guido.io...@gmail.com on 30 Apr 2010 at 1:04

GoogleCodeExporter commented 8 years ago
I must correct my previous post. 

1. gnome-mplayer + vdpau: tearing
2. gnome-mplayer + xv: no tearing
3. mplayer (nogui) + vdpau: no tearing
4. mplayer gui + vdpau: no tearing

command line for mplayer : mplayer -vo vdpau -vc ffh264vdpau  file.m4v

Original comment by guido.io...@gmail.com on 2 May 2010 at 1:37

GoogleCodeExporter commented 8 years ago
From what I understand vdpau may not always do tearfree video. I thing the 
drivers
just need to upgrade to support new mechanism in kernel and X to do this. 

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

GoogleCodeExporter commented 8 years ago
should be using the same method of Mplayer GUI can solve the issue? but I 
presume
Mplayer GUI doesn't use gtk_window but X... is it so?

Original comment by guido.io...@gmail.com on 2 May 2010 at 1:37

GoogleCodeExporter commented 8 years ago
I actually believe that there probably is tearing in mplayer with a vo of 
vdpau, as
the screen updates are not synchronized with the screen update. I think there 
is more
going on with gnome-mplayer and that is why you happen to see it there and not 
in
mplayer. As far as I know the only output that is tearfree at the moment is the
radeon open source driver (and a VERY recent version of that) with the right 
kernel
and X and perhaps the nouveau drivers as well. None of the other drivers are
integrated with the kernel and X to sync properly. But again only XV or GL is
available on those drivers, so vdpau is out for those options. Tear prevention 
is
really not something that can be done at the application level for the most 
part, at
least in my opinion. 

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

GoogleCodeExporter commented 8 years ago
"Tear prevention is
really not something that can be done at the application level for the most 
part, at
least in my opinion."

yes, but...

"I actually believe that there probably is tearing in mplayer with a vo of 
vdpau"

I think not, because I use mplayer (and mplayer gui) with no tearing and vdpau.

Original comment by guido.io...@gmail.com on 2 May 2010 at 3:26

GoogleCodeExporter commented 8 years ago
p.s. so I think the problem is gtk+vdpau.

Original comment by guido.io...@gmail.com on 2 May 2010 at 3:27

GoogleCodeExporter commented 8 years ago
We will just agree to disagree then..

Original comment by kdeko...@gmail.com on 2 May 2010 at 3:29

GoogleCodeExporter commented 8 years ago
but this is no matter of opinion :)
If, as I suspect, the issue is with gtk window, you could be workaround it 
opening a
Xlib window only for fullscreen. But, I know: this is ugly for streaming and 
file
with unsupported or badly supported seeking.

Original comment by guido.io...@gmail.com on 2 May 2010 at 3:43

GoogleCodeExporter commented 8 years ago
I will not be changing the method of how gnome-mplayer handles the full screen 
mode.
I do have an alternate version of how the control bar is handled in SVN, but 
there
have be issues with it specifically when using the nvidia driver. The new method
works fine on Intel and ATI cards, so that goes back to driver issues again.

Original comment by kdeko...@gmail.com on 2 May 2010 at 5:46

GoogleCodeExporter commented 8 years ago
well, I think this is the better 'solution'. Workarounds like mine might make 
things
worse.

Original comment by guido.io...@gmail.com on 2 May 2010 at 5:54

GoogleCodeExporter commented 8 years ago
Is what you are calling tearing, is that what happens when the control bar 
appears
and disappears?

Original comment by kdeko...@gmail.com on 3 May 2010 at 12:27

GoogleCodeExporter commented 8 years ago
no, the video tears even when control bar is disappeared.

Original comment by guido.io...@gmail.com on 3 May 2010 at 1:23