FS#8268 - Xine-lib produces green artifacts during x264 video playback

Attached to Project: Arch Linux
Opened by (N/A) (wantilles) - Tuesday, 09 October 2007, 16:16 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 10 December 2007, 17:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Paul Mattal (paul)
Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

Xine-lib produces green artifacts in x264 video stream playback.

Additional info:
* package version(s)

xine-lib-1.1.8-1 (and previous versions)

This not distro-specific. It is an upstream bug. I have observed it in Arch and other distros (Debian sid, Gentoo).

It has been happening in all xine-lib versions since last autumn (October or November), in both architectures (x86, amd64).

It has to do with xine-lib itself because it happens both in Totem-xine and KMPlayer with xine backend selected.

If you switch KMPlayer to mplayer backend, the clips play flawlessly - as they do play flawlessly on any other player that uses mplayer as its backend (smplayer, kplayer, mplayer).

* config and/or log files etc.

Any media player with xine selected as its backend will experience this behaviour (Totem-Xine or KMPlayer with xine selected).

Steps to reproduce:

1. Select any media player that uses xine-lib as its backend (Totem-xine, KMPlayer + xine).

2. Open a video file - regardless of container (AVI or Matroska-MKV) - that contains a x264 video stream.

3. Observe the green artifacts on various frames.

I am opening this bug, so that it can be sent upstream to the Xine developers.

This has been happening for a whole year.

It is about time it got fixed.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Monday, 10 December 2007, 17:27 GMT
Reason for closing:  Deferred
Additional comments about closing:  This is an upstream issue. Discussing it in the Archlinux bug tracker is going to get everyone no where - we should move this to the Xine bug tracker
Comment by Aaron Griffin (phrakture) - Monday, 22 October 2007, 17:17 GMT
Do you possibly have a sample (NOT illegal) x264 video for me to test with?
Comment by (N/A) (wantilles) - Monday, 22 October 2007, 19:02 GMT
I do not know what you consider legal or illegal.

However, any short clip (a 2 or 3 minute chapter) from any DVD that I have legally bought and own, when ripped and encoded, will produce these artifacts, no matter whatever settings I use in the x264 encoder, no matter what version of it I use, or whether I do the encoding in Windows or Linux.

Would you like me to send you a link of such a file via e-mail?
Comment by Aaron Griffin (phrakture) - Monday, 22 October 2007, 19:50 GMT
Erm, that seems questionable. I can rip a DVD of mine. Could you give me a step-by-step of how you encoded it, just so I follow the same steps you did?
Comment by (N/A) (wantilles) - Monday, 29 October 2007, 17:58 GMT
Sorry for the delayed response.

Take any x264 version of the last two years.

Encode anything you want with an average video bitrate between 1 and 2 Mbps.

Put it in either an AVI or Matroska container.

Use any preferences ranging between the two following values (from more "conservative" to more "extreme"):

--pass 2 --stats ".stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 1 --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --threads 2 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "" ""

--pass 2 --stats ".stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "" ""
Comment by Aaron Griffin (phrakture) - Friday, 02 November 2007, 00:02 GMT
Ok, I see what you mean. I need to check to see if this problem has been reported upstream - if it hasn't could you report it there?

Comment by (N/A) (wantilles) - Friday, 02 November 2007, 00:22 GMT
So you saw the green blocks-artifacts yourself.

This has been happening with xine-lib since last autumn, in every distro I've laid my hands on.

I do not know whether it has been reported upstream or not.

But I know for sure that it has been reported for sure in the bugzilla of other distributions (ie Gentoo, Debian, Ubuntu etc).
Comment by Skottish (skottish) - Friday, 07 December 2007, 15:23 GMT
I wanted to throw in a little information. Emotion from E17 uses xine-lib as one of, and currently the only functional backend. The videos that I created on my machine using x264 through FFmpeg do not have this problem. I tried a few different videos and could not reproduce the error.

Note: The encoding flags I use are far less sophisticated than the command from above. I usually produce videos for Quicktime compatibility, so I need to stay in the realm of H.264 simple profile (no B-Frames for instance).

Comment by Skottish (skottish) - Saturday, 08 December 2007, 05:58 GMT
Copyright and royalty free test video. This is my own strangeness:

http://www.mediamax.com/skotload/Hosted/xine_test.mp4

Comment by (N/A) (wantilles) - Saturday, 08 December 2007, 06:36 GMT
With all due respect Scottish, I do not see the point of this discussion.

The bug exists, it is there, and has been there in all distributions, so it is from upstream. And this has been happening for over a year now (since October 2006).

So, xine developers should fix this.

Loading...