No idea if this a Mesa OMX issue or UVD or gstreamer - GPU is R9 285 Tonga. In theory this should be able to h/w decode 10 bit h264 - and the h/w does seem to process it. The problem is that something is assuming/expecting/indicating that the output is NV12, so the output is corrupted. Here's a snip of a debug output from doing - GST_DEBUG=*:4 gst-launch-1.0 -f filesrc location=A-10bit-h264.mkv ! matroskademux ! h264parse ! omxh264dec ! filesink location=out.yuv 0:00:00.364695565 660 0x22310f0 INFO GST_EVENT gstevent.c:679:gst_event_new_caps: creating caps event video/x-h264, level=(string)4.1, profile=(string)high-10, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, parsed=(boolean)true <snip> gstpad.c:5881:gst_pad_start_task:<omxh264dec-omxh264dec0:src> created task 0x22f85f0 0:00:00.366822661 660 0x2231590 INFO GST_EVENT gstevent.c:679:gst_event_new_caps: creating caps event video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)bt709, framerate=(fraction)30000/1001
Yeah, that's a known issue/unimplemented feature. On pre Tonga hardware UVD can actually decode 10 bit h264, but still outputs NV12. And so far we didn't had the time to actually implement support for 10bit video surfaces used on Tonga so your end result is corrupted. BTW: If somebody wants to get his hands dirty this should be rather easy to hack together, just not top priority for us.
(In reply to Christian König from comment #1) > Yeah, that's a known issue/unimplemented feature. > > On pre Tonga hardware UVD can actually decode 10 bit h264, but still outputs > NV12. So you mean it produces correct output on other h/w like using 10 bit internally and truncating to 8 bit for output? If so why not output nv16 or something else 10 bit? > And so far we didn't had the time to actually implement support for 10bit > video surfaces used on Tonga so your end result is corrupted. OK - I guess it is not exactly a needed feature by anyone I'm just testing. Are there any docs that list the capabilities whether implemented or not of the various UVDs VCEs and VSR (if that is h/w) > BTW: If somebody wants to get his hands dirty this should be rather easy to > hack together, just not top priority for us. Maybe easy for those who know what they are doing :-) Where would someone start to look for inspiration? On a slightly related note what version of bellagio/gstreamer do you use? sf.net version needs a bit of patching to even compile and then seems to install OMX headers that gst-omx doesn't like. I can get there in the end but wondered whether I am missing some new version hiding somewhere. I asked on #gstreamer and the only person that replied thought it was old/broken and not needed - though after looking around he did admit he didn't know about VCE. I am just asking to double check that there really is no other way to use gstreamer and get-omx h/w accel. TIA
(In reply to Andy Furniss from comment #2) > If so why not output nv16 or something else 10 bit? lol at me re-reading this and remembering that nv16 is 8 bit 422.
-- 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/mesa/mesa/issues/912.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.