Closed GoogleCodeExporter closed 8 years ago
In the community repository not package. Sorry typo.
Original comment by coolbooks2@gmail.com
on 12 Mar 2010 at 4:28
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
p.s. so I think the problem is gtk+vdpau.
Original comment by guido.io...@gmail.com
on 2 May 2010 at 3:27
We will just agree to disagree then..
Original comment by kdeko...@gmail.com
on 2 May 2010 at 3:29
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
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
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
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
no, the video tears even when control bar is disappeared.
Original comment by guido.io...@gmail.com
on 3 May 2010 at 1:23
Original issue reported on code.google.com by
coolbooks2@gmail.com
on 12 Mar 2010 at 4:24