Totem Fails To Deinterlace

thank you for your bug report. could you try to play the video using gst-launch-0.10 playbin uri=file:///directory/example? Does it have the same issue? Could you also attach an example directly to launchpad?

Hi Sebastien :)

Please find attached the test samples.

I can confirm that using your CLI command does fail to deal with the interlaced footage - interlace artifacts are everywhere in playback.

reassigning to gstreamer since gst-launch has the same issue

Can I please make some comments here:

1. I consider the priority should be high, I could be argued into settling for medium with convincing points. In certain use cases this is a very serious problem. For example, trying to watch interlaced digital TV broadcasts or captures of such footage results in an unwatchable image. As too, trying to play footage show on interlaced cameras. Transcoding for progressive frames is not only a very time consuming idea but also one which may not be feasible in all cases given finite amounts of workstation storage and other reasons.

2. I think the "bug" exists in both gstreamer and totem. Why should totem have a drop down menu setting that does nothing? Isnt that poor UI design to provide apparent functionality to the user which is not actually implemented in the default back end used by Ubuntu?

I'm new to Gstreamer but I'm going to take a look at the Gstreamer bug database to see if it needs to be reported upstream as well.

the priority is low because that's not something the ubuntu team has the ressources to work on, a new feature, and something upstream is not likely to get available this cycle, changing the priority will not do a real difference to any of those

Seabstien why can't we use ffdeinterlace as provided in the ffmpeg gstreamer plugin until upstream come up with another solution?

Moving to confirmed as clearly it is a bug and has been accepted upstream. I have spoken with upstream about using ffdeinterlace as an interim measure and they had a range of concerns about doing so. It should still be possible to setup a custom gstreamer pipe for cases where users must have it - Im currently doing some tests on this.

Sorry, human error there I meant to move the status to In Progress.

I'd like to share my progress with this. Since upstream seem to be somewhat uncooperative on implementing deinterlacing in Totem Ive been doing tests with gstreamer. I'm pleased to report that deinterlacing functionality is working well. Here's a command line for bottom field first interlaced content:

gst-launch filesrc location=/mnt/vault/Film/Tests/aspbff.avi ! decodebin2 ! ffmpegcolorspace ! deinterlace2 tff=2 ! xvimagesink

And for top field first content:

gst-launch filesrc location=/mnt/vault/Film/Tests/asptff.avi ! decodebin2 ! ffmpegcolorspace ! deinterlace2 ! xvimagesink

Note that currently gstreamer cannot auto detect if the content is TFF or BFF and TFF is assumed. All BFF content has to be hard coded to display correctly.

I have totem deinterlacing by changing the default gstreamer video sink from "autovideosink" to "deinterlace ! autovideosink". You can do it using "Alt+F2" and executing "gconf-editor" and the go to "/system/gstreamer/0.10/default" and change "videosrc" value to "deinterlace ! autovideosink"

Nowadays deinterlace2 doesn't exits, only deinterlace. I don't know if gstreamer now can detect different types of deinterlacing.

I think this should be fixed in another way not by chaging the default videosink, but, this is a perfect workarround until someone fix this.

The "tff" property

  "tff" GstDeinterlaceFieldLayout : Read / Write

Deinterlace top field first.

Default value: Auto detection

OK GStreamer seems to have autodetecting of tff since 0.10.17, also there are some methods to choose from:

The "method" property

  "method" GstDeinterlaceMethods : Read / Write

Selects the different deinterlacing algorithms that can be used. These provide different quality and CPU usage.

Some methods provide parameters which can be set by getting the "method" child via the GstChildProxy interface and setting the appropiate properties on it.

    *

      tomsmocomp Motion Adaptive: Motion Search
    *

      greedyh Motion Adaptive: Advanced Detection
    *

      greedyl Motion Adaptive: Simple Detection
    *

      vfir Blur vertical
    *

      linear Linear interpolation
    *

      linearblend Linear interpolation in time domain
    *

      scalerbob Double lines
    *

      weave Weave
    *

      weavetff Progressive: Top Field First
    *

      weavebff Progressive: Bottom Field First

Default value: Motion Adaptive: Advanced Detection

The deinterlace method are ports of the DScale Tvtime ones, but all of the seems to be poor comparing for example with the vlc's blend, that gives more accurated deinterlacing. For example with the Shaggy - Angel song video I have from a .vob from a DVD the inital animations is not properly deinterlaced by any of the gstreamer available methods.

David. There are several issues with deinterlace module:
1. video is unstable, you don't get comb artifacts, instead image shifts by one pixel ocasionally,
2. subtitles are messed up,
3. It takes a lot of CPU!!! (about 20% on my ancient sempron).

There is also ffdeinterlace module which comes from ffmpeg but there is still issue #2 present. Besides this module works somehow unstable. For some videos it produces blank output.

I'm really surprised that there is a marginal effort put into deinterlacing modules by the gstreamer team. There is still lots of interlaced videos out there (DVDs, non-professional or hd video footage etc., which renders totem/gstreamer useless.

I have seen what you say, also deinterlace messes non interlaced videos, at leats in very noticiable with 1080p videos. Thanks for the info.

Actually, there's some work going on upstream to fix this issue. It would be great if this could get backported to Lucid:

http://www.hadess.net/2010/04/deinterlacing-now-in-totem.html
https://bugzilla.gnome.org/show_bug.cgi?id=547603

https://bugzilla.gnome.org/show_bug.cgi?id=547603 has been fixed in GStreamer Base Plug-ins 0.10.30 - see the release notes at http://gstreamer.freedesktop.org/releases/gst-plugins-base/0.10.30.html

It looks like this has been fixed in Ubuntu 10.10 "Maverick Meerkat". From the totem (2.31.6-0ubuntu1) changelog:

  * New upstream version:
    - Add deinterlacing support, automatically used for interlaced content

Given that Maverick also has GStreamer Base Plug-ins 0.10.30-1build1 this should be fixed now.

I'll try and test with the files in comment 2.

Can someone else also test please?

Results of testing:

With default Totem settings both files in comment 2 look good when played back.

Selecting "Edit > Preferences > Display > Disable deinterlacing of interlaced videos" in Totem and then playing the same files shows prominent interlacing artefacts during playback.

Marking as fixed.

This is going to be also in lucid LTS or is one bug more for the list of important bugs but no so important for canonical to be in actual supported releases and only in the actual in development one.

I worry that there will never be any bug fixing in ubutu releases (apart from the gnome x.x.X upstream updates). It's a pity.

I know, even a totally blockers bugs like in hardy impossibility to make working apps with ocaml 64 (if you compile an app with the ocaml included in ubuntu hardy, youru application will crash before running a little time), in canonical is not considered a important bug, and ocaml is not part of gnome, and also upstream the new version to the included in hardy is just the fix to that non important bug.

If you want to use the latest GStreamer packages on Lucid I recommend the GStreamer developers PPA at https://launchpad.net/~gstreamer-developers/+archive/ppa

Getting hold of the new version of Totem for Lucid seems to be trickier, but if you are any good at compiling from source you can get it at https://launchpad.net/ubuntu/+source/totem/2.31.6-0ubuntu1

Although I'm not an Ubuntu package maintainer I think the new version of Totem probably falls outside of the criteria for a Stable Release Update (SRU). I don't know enough about coding or compilation to know if it would be possible to cherry-pick the patch from upstream and apply it to Totem in Lucid, but then you would be looking at a potential user interface change (needed in case someone need to turn _off_ deinterlacing to get their file to play correctly) which would probably be outside of the SRU criteria anyway.

> This is going to be also in lucid LTS or is one bug more for the list of important bugs but no so important for canonical to be in actual supported releases and only in the actual in development one.

Canonical has nothing to do there, any community contributor is welcome to work on a stable update, those changes are new code and non trivial for a stable update though

Someones say one way to go, others another. The real way to go of canonical, at least the one they said in other bugs, is to backport fixes for critical bugs. This is not a critical bug in anyway but you can search for the ocaml hardy lstd bug and tell me if it's critical or not.