Video scaling in totem is unclean

Thanks for your bug. We use upstream software and don't do change that should make a difference like that. What version of Ubuntu do you use? What other distribution did you try? Maybe they were using totem with xine? Do you have that problem using totem-xine?

This is totem 2.16.2 using GStreamer 0.10.10.

I had totem running on Arch Linux (also GStreamer backend) before and the videos never seemed so "pixely". I don't have the possibility to compare that here though, some thousand km from home and my Desktop...

Do you have the same problem if you play with the video with "gst-launch-0.10 playbin uri=file:///path/to/video"?

Looks exactly the same.

gst-inspect-0.10 videoscale contains the following (end of output):

Element Properties:
  name : The name of the object
                        flags: readable, writable
                        String. Default: null Current: "videoscale0"
  qos : handle QoS messages
                        flags: readable, writable
                        Boolean. Default: false Current: true
  method : method
                        flags: readable, writable
                        Enum "GstVideoScaleMethod" Current: 0, "nearest-neighbour"
                           0) nearest-neighbour - Nearest Neighbour
                           1) bilinear - Bilinear

so i guess the default for "method" is on 0 instead of 1.

Indeed:

gst-launch-0.10 filesrc location=/home/hunzikea/Videos/Flower.avi ! avidemux ! xviddec ! ffmpegcolorspace ! videoscale method=1 ! ximagesink

does the trick. compare with videoscale method=0.
make the opened window fullscreen to see the difference. attach the videofile for comparison purposes, but should work w/ any video.

Thank you for the update, reassigning to gstreamer

Not sure if this is a totem or gstreamer bug... ximagesink does no scaling by default at all so totem must add the videoscale element somewhere. xvimagesink OTOH scales via hardware so this can't be changed in any way.

Without having looked at the totem code possible fixes are having bilinear scaling as default in videoscale (instead of nearest-neighbour) or telling totem to set the property correctly when adding the element.
IMHO the latter should be done in any way, with something in totem's preferences to select the algorithm used as bilinear might be far too slow on some machines while nearest-neighbour is still fine.

Ok, playbin is adding videoscale, not totem. And playbin just uses the default mode of videoscale, i.e. nearest neighbour.

So if anywhere it should be changed there. The only problem I see is that bilinear scaling is much more CPU intensive compared to nearest neighbour... and it could make the difference between a smoothly played movie on a slow machine and many frames beeing dropped...

Sebastien, what do you think? The changes required are rather trivial...

And for now if someone wants to use ximagesink with a better scaling algorithm one could set the video output sink in gstreamer-properties to "videoscale method=1 ! ximagesink" for example.

After some discussion with Sebastien we believe that if this should be changed this change should be done upstream. The default does not have the best quality but is faster... so the best would be to take this upstream and file a bug in their bugtracker: http://bugzilla.gnome.org/

I was an Arch Linux user before. I cannot find anything in their build scripts for the gstreamer base-plugins that would change the default behaviour, so i just wonder why ubuntu is different here...?

You probably use xvimagesink on arch linux and ximagesink on Ubuntu for some reason... but this is just a guess.

When you run "gstreamer-properties", which video output is selected? Does it work when you change to "XWindow System (X11/Xshm/Xv)" and click on test?