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 780189 - video-format: Conversion from I420_10LE/BE, I420_12LE/BE, A420_10LE/BE to BGRA/RGBA creates corrupted output
video-format: Conversion from I420_10LE/BE, I420_12LE/BE, A420_10LE/BE to BGR...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 785013 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-03-17 11:50 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 11:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
I420_10LE hack (2.00 KB, patch)
2017-04-25 16:34 UTC, Vincent Penquerc'h
none Details | Review

Description Sebastian Dröge (slomo) 2017-03-17 11:50:06 UTC
See e.g.

gst-launch-1.0 videotestsrc ! "video/x-raw,format=I420_10LE" ! videoconvert ! "video/x-raw,format=BGRA" ! glimagesink

Same with I420_10BE, I420_12BE/LE. I422_* and Y444_* and their alpha variants work fine. Conversion to AYUV, I420, AYUV64, ARGB64 also works fine.
Comment 1 Vincent Penquerc'h 2017-04-25 12:28:24 UTC
I can't see what's wrong. Then I set all YUV to 0 in the pack/unpack functions, and I still see banded green and darker green, where I'd expect a full solid color. All I can see grepping for I420_10LE in -base looks OK, so I'm out of ideas right now :/
Comment 2 Vincent Penquerc'h 2017-04-25 15:16:55 UTC
In any case, the UV on the first row (maybe two, hard to say) looks correct (and the Y is wholly correct). I can't see relevant differences with I422_10LE (ie, not to do with the extra subsampling). So it looks like some possible stride bug as the first line's OK.
Comment 3 Vincent Penquerc'h 2017-04-25 16:34:29 UTC
Created attachment 350416 [details] [review]
I420_10LE hack

This fixes it. However, it only points to a bug elsewhere which gets "undone" by the patch. It looks like something somewhere assumes the wrong subsampling for those 4 formats.
Comment 4 Vincent Penquerc'h 2017-04-26 13:39:07 UTC
I've reached video_chroma_up_v2_u16, which I think may be incorrect. It's called when using SUB420 but not SUB422 (and I hacked up everywhere to pretend 422 here, and 420 elsewhere to make sure this is the call which breaks). That's an orc function, which it impenetrable. ORC_DEBUG=backup doesn't fix (the backup function is impenetrable too).
Comment 5 Vincent Penquerc'h 2017-04-26 13:43:14 UTC
Oh, actually, I was looking at video_orc_chroma_up_v2_u16 in the C file, but it's generated, which explains the *erf*. The one in the orc file looks very much nicer (though still obscure right now) :)
Comment 6 Vincent Penquerc'h 2017-04-26 16:15:26 UTC
And AFAICT it's the exact match for the u8 version, which seems fine since I420 works. So I'm lost again for now.
Comment 7 Nicolas Dufresne (ndufresne) 2017-07-07 18:24:53 UTC
One thing we notice is that I420_10LE -> I420 works, also I420_10LE -> ARGB64 works too. It's really something from I420_10LE -> ARGB that breaks.
Comment 8 Sebastian Dröge (slomo) 2017-07-17 08:16:33 UTC
*** Bug 785013 has been marked as a duplicate of this bug. ***
Comment 9 GStreamer system administrator 2018-11-03 11:56:19 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/350.