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 791876 - vaapipostproc not allowing overriding colorimetry (bt601/709) by downstream caps
vaapipostproc not allowing overriding colorimetry (bt601/709) by downstream caps
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-22 16:27 UTC by Florent Thiéry
Modified: 2018-11-03 15:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florent Thiéry 2017-12-22 16:27:02 UTC
I am decoding with vaapidecodebin (autoplugged through decodebin), which scales automagically. However i need bt709 support to avoid an additional conversion between bt601 and bt709, or the following will crash:

$ gst-launch-1.0 videotestsrc num-buffers=1 ! x264enc ! h264parse ! vaapidecodebin ! "video/x-raw, format=(string)NV12, width=(int)960, height=(int)540, framerate=(fraction)30, colorimetry=(string)bt709, pixel-aspect-ratio=1/1" ! fakesink

Works:

$ gst-launch-1.0 videotestsrc num-buffers=1 ! x264enc ! h264parse ! vaapidecodebin ! videoconvert ! "video/x-raw, format=(string)NV12, width=(int)960, height=(int)540, framerate=(fraction)30, colorimetry=(string)bt709, pixel-aspect-ratio=1/1" ! fakesink

Is it possible to support bt709 ?
Comment 1 Florent Thiéry 2018-01-10 16:01:49 UTC
Actually, vaapipostproc will define bt709 if the resolution is 1080p, but bt601 below (which fits the specifications).

Basically what is missing is the possibility to override the choice made internally by vaapipostproc. I'm editing the ticket title to reflect this.
Comment 2 Florent Thiéry 2018-01-10 16:08:42 UTC
My use case is about compositing video from NV12 as a 1080p canvas with compositor; i am feeding compositor with video from vaapidecodebin, and scaling is handled by vaapipostproc. 

Feeding multiple 1080p inputs into a single 1080p canvas results in sub-1080p resolutions, which results in vaapipostproc fixating colorimetry to bt601, but the downstream compositor will work in bt709 since the final output is 1080p.

What i'm trying to avoid is to let compositor handle all the colorimetry conversion work (which is software only and single-threaded).

This fails:
gst-build]$ gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)30/1, format=(string)I420"  ! x264enc ! vaapidecodebin ! "video/x-raw, format=(string)NV12, width=(int)960, height=(int)540, framerate=(fraction)30, colorimetry=(string)bt709, pixel-aspect-ratio=1/1" ! fakesink

This works:
gst-build]$ gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)30/1, format=(string)I420"  ! x264enc ! vaapidecodebin ! "video/x-raw, format=(string)NV12, width=(int)960, height=(int)540, framerate=(fraction)30, colorimetry=(string)bt601, pixel-aspect-ratio=1/1" ! fakesink

Inversely, this works:
gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)30/1, format=(string)I420"  ! x264enc ! vaapidecodebin ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, colorimetry=(string)bt709, pixel-aspect-ratio=1/1" ! fakesink -v

This fails:
gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)30/1, format=(string)I420"  ! x264enc ! vaapidecodebin ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, colorimetry=(string)bt601, pixel-aspect-ratio=1/1" ! fakesink
Comment 3 GStreamer system administrator 2018-11-03 15:52:38 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/gstreamer-vaapi/issues/80.