[totem-gstreamer] Totem video output doesn't use xv

Bug #80820 reported by Emmanuel Pacaud on 2007-01-21
18
Affects Status Importance Assigned to Milestone
totem (Ubuntu)
High
Ubuntu Desktop Bugs

Bug Description

Binary package hint: totem

Totem in feisty doesn't use xv for its video output. It used too. That means higher cpu usage and bad scaling quality.

Mplayer does work correctly on my system.

Envel (envel) wrote :

The bug exist also in totem-xine. Even xine-ui works fine. I have ATI video card. I've used both fglrx and ati driver. The problem exists in both cases.

gstreamer-properties uses xv though

Changed in totem:
status: Unconfirmed → Confirmed
Young-Ho Cha (ganadist-gmail) wrote :

I build totem from gnome svn and it works correctly.

Sebastien Bacher (seb128) wrote :

Do you try to open a small video format? Does that depend of the video you are playing?

From the upstream changelog:

" * src/backend/bacon-video-widget-common.h:
 * src/backend/bacon-video-widget-gst-0.10.c:
 (bacon_video_widget_new):
 * src/backend/bacon-video-widget-xine.c: (load_video_out_driver):
 When the requested video widget is smaller than 200x120, use the
 non-Xv video output, useful so that small QuickTime "image" streams
 don't hog the Xv port

 (Closes: #364572)"

Changed in totem:
assignee: nobody → desktop-bugs
status: Confirmed → Needs Info
Envel (envel) wrote :

All my video files are greater or equal to 320x240. Totem works identically not depending on file type.

I noticed that video thumbnails in Nautilus are bluish with artifacts when they are generated by totem 2.17.5.
I downgraded to totem 2.16.4 (from edgy repository). The problem is disappeared after thumbnails cache was cleaned.

Michael R. Head (burner) wrote :

I'm seeing this with large videos (well, I believe that the cause of the poor visual quality is that xv isn't being used). I have an ATI 7500 in a T30 using the opensource drivers. The same videos worked fine in Edgy yesterday before I upgraded to feisty. The videos I've got are, for example, AVIs @ 640x272.

Daniel Robitaille mentioned the problem on the sounder list: https://lists.ubuntu.com/archives/sounder/2007-February/009841.html

Michael R. Head (burner) wrote :

Daniel Robitaille determined that this is due to the fact that totem is now defaulting to Xshm rather than Xv visuals. This may be due to incompatibilities between Xv and Xcomposite with the radeon driver, but I don't have confirmation on this point.

https://lists.ubuntu.com/archives/sounder/2007-February/009855.html
https://lists.ubuntu.com/archives/sounder/2007-February/009856.html
https://lists.ubuntu.com/archives/sounder/2007-February/009857.html

Conn O Griofa (psyke83) wrote :

I can confirm this bug on two systems running latest Feisty, (using nvidia and i810 drivers respectively). Switching between totem-gstreamer and totem-xine makes no difference; gstreamer-properties will show Xv output correctly in test output, but totem never respects the videosink selected, and editing ~/.gnome2/totem_config to use "video.driver=xv" doesn't help with the xine backend either.

Every movie I've tried (all >320x240 resolution) exhibits this behaviour in totem, and other players such as VLC can use the Xv video extension without any difficulty.

I don't think logs are necessary, but if anyone needs some I'll be happy to post later.

Sebastien Bacher (seb128) wrote :

What videocard and videodriver people having that problem are using? How do you know if totem is using Xv or not?

I'm using the free ATI drivers and a readeon rv100 board.

High CPU utilization and the fact the image' follow' the totem window when I move it is a good indication totem is not using xv.

You can check whether totem is using xvimagesink, by using this command.

$ totem --gst-debug=xvimagesink:4

If totem is not using xvimagesink, there is no gst debugging message.

2007/2/6, Sebastien Bacher <email address hidden>:
> What videocard and videodriver people having that problem are using? How
> do you know if totem is using Xv or not?
>
> --
> [totem-gstreamer] Totem video output doesn't use xv
> https://launchpad.net/bugs/80820
>

Matthew Garrett (mjg59) wrote :

This is fixed upstream

Changed in totem:
status: Needs Info → Fix Committed
Changed in totem:
importance: Undecided → High
Sebastien Bacher (seb128) wrote :

This upload fixes the problem:

 totem (2.17.91-0ubuntu1) feisty; urgency=low
 .
   * New upstream version:
     - Fix crasher when getting the listed of subtitles/languages
     - Handle the icyx:// protocol
     - Add video/x-theora+ogg, application/ram, video/x-matroska,
       audio/x-matroska and audio/x-wavpack to the supported mime-types
     - Solaris compilation fixes
     - Fix vanity compilation
     - Fix using the playlist parser from Python
     - Have "Audio files" and "Video files" filters in the Open dialogues
     - Browser plugin:
       - Add stubs of Javascript support for the GMP (Windows Media compatible)
         browser plugin
     - GStreamer backend:
       - More robust code to check for stream metadata
       - Fix title streaming in internet radios (Ubuntu: #83117)
     - xine-lib backend:
       - Fix blue-ish pictures created by the thumbnailer (Ubuntu: #80629)
     - fix totem-video-indexer crasher (Ubuntu: #80801)
     - fix xv not being used (Ubuntu: #80820)
   * 2.17.90:
     - Fix build with older GCCs, older Mozillas, "-j2", and Solaris
     - Add support for the new "Media Player keys" infrastructure in GNOME 2.18
     - Append "#X" number to duplicate languages in the menu entries
       (Ubuntu: #59815)
     - Add "TrueAudio" as a supported file type
     - Add an uninstalled pkgconfig file for the playlist parser
     - Fix launching Totem remotely (broken by GOption work earlier in 2.17.x)
       (Ubuntu: #81089, #81922)
     - Make GTK+-only version compile again
     - Fix disabling the browser plugin using configure
     - Playlist parser:
       - Only export public symbols from the library
       - Avoid crashing when an MP3 that we can't get info about is being parsed
         (Ubuntu: #81511)
     - Browser plugin:
       - Add stubs of Javascript support for the NarrowSpace (Quicktime-
         compatible) and Complex (Real/Helix-compatible) plugins
       - Only set the "hand" cursor when we're ready to be clicked
       - Only stop using video acceleration when the video size is given
     - Thumbnailer:
       - Avoid crashes with newer version of GLib
       - Add a --verbose output
     - GStreamer:
       - Make mouse events work properly while playing
       - When reaching the end of a file while seeking, go to the next
         item in the list, instead of getting closer and closer to the end
       - Show an error when we're missing the video decoder for a file
       - Avoid reentrancy errors by handling errors asynchronously (avoids
         bad state when clicking too fast)
   * debian/patches/03_autoconf.dpatch:
     - updated
   * debian/patches/06_specify_bash_shell_fix_build.dpatch:
     - use bash and not sh for the shell, fix build problem
   * debian/patches/80_from_svn_fix_extre_codec_error_dialog.dpatch,
     debian/patches/90_from_svn_fix_click_action_for_gstreamer.dpatch,
     debian/patches/91_from_svn_fix_thumbnailer_thread_init_call.dpatch:
     - dropped, fixed with the new version

Changed in totem:
status: Fix Committed → Fix Released
Michael R. Head (burner) wrote :

Sweet. Thanks seb and upstream!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers