After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756320 - xvimagesink: color bars around edges with gst-libav decoders
xvimagesink: color bars around edges with gst-libav decoders
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.6.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 737782 788626 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-10-09 21:53 UTC by Jan Lukas
Modified: 2018-11-03 11:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
artifacts with gst-play-1.0 (1014.62 KB, image/png)
2015-10-09 21:53 UTC, Jan Lukas
Details

Description Jan Lukas 2015-10-09 21:53:26 UTC
Created attachment 312987 [details]
artifacts with gst-play-1.0

I'm on Fedora 23 beta with gstreamer 1.6.0.
I use a Radeon HD7850 with the radeonSI drivers.
When I play any video with gst-play-1.0 (tested with 1080p Big Buck Bunny) I get a weird flickering colored bar at the bottom. Also a few lines at the top and at the bottom of the video are missing.

Anything I can do to get some additional information for you guys? :)
Comment 1 Sebastian Dröge (slomo) 2015-10-10 08:41:48 UTC
Does it happen with every video resolution and look the same? Does it work better if you use ximagesink, xvimagesink or glimagesink or are all the same?
Comment 2 Jan Lukas 2015-10-10 09:36:19 UTC
Yes, it happens with different resolutions (even though I haven't tested ALL possible resolutions).
It does not happen with ximagesink and glimagesink, only with xvimagesink and autovideosink ;)
Anything else I can do?
Comment 3 Sebastian Dröge (slomo) 2015-10-10 19:49:28 UTC
Can you provide a debug log with GST_DEBUG=xvimage*:6 ?
Comment 4 Jan Lukas 2015-12-17 04:35:40 UTC
Sorry for the long delay. Here you go:
https://paste.gnome.org/pdc4uuvxj
Comment 5 Tim-Philipp Müller 2016-02-28 18:47:45 UTC
I can reproduce this by playing H264/mkv movies via xvimagesink and maximising the window (so that the garbage in the top, bottom, right and left border is visible properly against the black frames), with 1.6.3 as in debian sid, and the Intel driver.

However, I can't reproduce it anymore with git master as of today. I suspect it was something in gst-libav that fixed it.

Please re-open if you can still reproduce this with 1.7.2 or later, thanks!
Comment 6 Tim-Philipp Müller 2016-02-28 18:53:54 UTC
My bad, this still happens with master if the gst-libav decoders are used (it used gstreamer-vaapi decoders at first when I tested).

Assigning to xvimagesink for now.
Comment 7 Tim-Philipp Müller 2016-02-29 00:09:18 UTC
*** Bug 737782 has been marked as a duplicate of this bug. ***
Comment 8 Nicolas Dufresne (ndufresne) 2017-09-06 20:08:12 UTC
Something I just noticed is that if you make the window smaller (scale down) it disappear, and if you look closely on larger window, it's not solid green, the video leaks through (except maybe for the left edge). This looks like a miss-configuration between the crop and the scaler.
Comment 9 Nicolas Dufresne (ndufresne) 2017-10-07 12:43:23 UTC
*** Bug 788626 has been marked as a duplicate of this bug. ***
Comment 10 Nicolas Dufresne (ndufresne) 2017-10-07 12:47:04 UTC
I wonder if XV isn't rounding the crop somehow to some multiple. I think short term we could simple add some over crop, nobody will really notice if we remove 1 pixel around the image, while clearly adding one is very visible. I also don't expect XV code to be revisited soon.
Comment 11 Tim-Philipp Müller 2017-10-07 13:13:00 UTC
I think that would be fine.
Comment 12 Nicolas Dufresne (ndufresne) 2018-08-22 01:17:49 UTC
I forgot to update, but the regression comes from a mix of glamour (the gl based XV driver) bugs and the fact that glamour alignment requirements is smaller then what we hardcore (presumably what was used in real XV drivers). The xvimagesink code is missing any kind of validation of this and is also missing proper video meta support.
Comment 13 GStreamer system administrator 2018-11-03 11:42:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/232.