Bug 753022 - Stuttering and choppy video in fullscreen only for totem
Summary: Stuttering and choppy video in fullscreen only for totem
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: totem
Version: 17
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-11 03:49 UTC by Stephen So
Modified: 2019-10-02 17:04 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-31 20:23:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Stephen So 2011-11-11 03:49:12 UTC
Description of problem:

When playing video in fullscreen on totem, the video is slow, stutters and choppy. However, it is normal when in window mode.

Version-Release number of selected component (if applicable):

totem.i686 3.2.1-2.fc16

How reproducible:

Always

Steps to Reproduce:
1.  Play a video in totem
2.  Switch to full screen
  
Actual results:

The video gets choppy in fullscreen mode but not in window mode

Expected results:

The video should be smooth in fullscreen mode

Additional info:

I've downgraded to totem 3.0.1 and the problem goes away. That is, when watching video in fullscreen, the video is much smoother.

Note that this was independently observed in this thread as well:

https://bbs.archlinux.org/viewtopic.php?id=129151

Comment 1 Stephen So 2011-12-04 03:08:56 UTC
I've further noticed that the problem does not occur when using an nvidia card. Therefore the problems observed in this bug report are from an Intel integrated card (Intel 945G).

Comment 2 Stephen So 2011-12-05 11:09:51 UTC
Just verified the problem does not occur in fallback mode.

Comment 3 Stephen So 2012-01-21 05:41:26 UTC
I think the problem is with clutter-gst. When using mplayer or vlc (using Xv), fullscreen playback is smooth.  The new totem is using clutter-gst while the old (3.0.1) version uses Xv.

Comment 4 Amazed 2012-01-31 17:05:59 UTC
My experience matches that of Steve.

Comment 5 Stephen So 2012-03-10 05:59:26 UTC
I think I may have found a workaround that reduces the problem

Place the following two lines in /etc/environment

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True

I got this from this forum post

https://bbs.archlinux.org/viewtopic.php?pid=1018579#p1018579

Comment 6 Stephen So 2012-03-11 06:34:45 UTC
After a day of testing, it seems that "fix" I mentioned before does not make any difference :(

Comment 7 Deleted Account 2012-04-03 21:39:18 UTC
Nope, that environment settings did nothing for me either. I confirm I have this issue on an Intel 945GMA (OpenGL 1.4) too. Surprisingly, the jumpy playback only happens when I switch to fullscreen totem AND have aspect 16:9 (whole real screen area), default aspect (square I believe, that does not fill the real screen) seems to not be jumpy, though it doesn't take profit of all the real screen area. As a note kaffeine kde multimedia player, can handle whole fullscreen 16:9 area without being jumpy.

 That and epiphany gtk+3 flash, are my top priority GNOME troubles.

 Hope to be usefull, have a nice bug hunting.

Comment 8 Stephen So 2012-04-04 00:25:12 UTC
Kaffeine does not suffer from this problem because it uses xv (as does vlc and mplayer), while the new totem uses clutter-gst. Unfortunately there is no way to force totem to use xv, unless we run gnome3 in fallback mode.

An option in the preferences to switch from clutter-gst to xv would be a good feature, which would be similar to what other players offer.

Comment 9 Martin Kho 2012-05-27 11:06:40 UTC
Hi,

In comment #1 it was said that it not happens with a nvidia card. I'm using a nvdia card (GF7600GS, NV4B) and see the slowness/choppyness too in full screen. It seems to be caused by a very high cpu-usage (nearly 100%). The Dragon player (default video player in KDE) uses in full screen only 10% to 15% cpu.

This issue also manifests it self in Fedora 17.

Martin Kho

Comment 10 Stephen So 2012-06-02 00:22:31 UTC
I'm starting to see very high CPU usage as well in totem 3.4 (in Fedora 17). I've posted it in this new bug report

https://bugzilla.redhat.com/show_bug.cgi?id=827415

I really believe an option to choose the video output method would be a good start.

Comment 11 Deleted Account 2012-06-14 13:01:42 UTC
(In reply to comment #8)
> Kaffeine does not suffer from this problem because it uses xv (as does vlc
> and mplayer), while the new totem uses clutter-gst. Unfortunately there is
> no way to force totem to use xv, unless we run gnome3 in fallback mode.
> 
> An option in the preferences to switch from clutter-gst to xv would be a
> good feature, which would be similar to what other players offer.

So is this request piped upstream by the fedora maintainer? It's not like i'm gonna change my hardware cause software issue. Not supporting xv should be an upstream bug. Note to gnome devs, first add a feature, then remove the older, i.e. if you want clutter playing first get the xv quality, then make it, don't remove first at start and leave it incomplete.

Regression.

The fact that it was reported for 16 and it is happening on f17 is near unacceptable. This discriminates people in a unneeded way.

XV back.

Comment 12 Stephen So 2012-06-15 23:35:47 UTC
Just confirming that this problem of stuttering and choppy video still exists in totem in Fedora 17.

Comment 13 Tsu Jan 2012-08-26 16:41:54 UTC
This behavior of Totem isn't specific to Fedora. As a Debian user, I also saw it in v3.4.2. However, fortunately, the Debian maintainers have put this version only in the Experimental repository, the default Totem being still v3.0.1, which works without any problem.

Comment 14 Fedora End Of Life 2013-07-03 20:26:27 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Fedora End Of Life 2013-07-31 20:23:25 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.