GNOME Bugzilla – Bug 776446
rawvideoparse internal data stream error with bt2020 colorimetry if resolution is not 4k
Last modified: 2018-11-03 14:02:22 UTC
gst-launch-1.0 filesrc location=/dev/zero blocksize=3110400 num-buffers=1000 ! rawvideoparse width=1920 height=1080 framerate=30 format=nv12 ! "video/x-raw, format=(string)NV12, colorimetry=(string)bt2020" ! fakesink -v ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error. The following works okay: gst-launch-1.0 filesrc location=/dev/zero blocksize=12441600 num-buffers=1000 ! rawvideoparse width=3840 height=2160 framerate=30 format=nv12 ! "video/x-raw, format=(string)NV12, colorimetry=(string)bt2020" ! fakesink -v
Created attachment 348419 [details] [review] fix caps negotiation failing due to default colorimetry
Comment on attachment 348419 [details] [review] fix caps negotiation failing due to default colorimetry It seems completely intentional and expected that this fails. However there should instead be a property on rawvideoparse to set colorimetry and chroma-site for having control over that instead of just always taking the default for the resolution.
These are arbitrary AFAICT. Just set as default without any looking at any data, and just ending up preventing caps intersection for no reason. I'll change it to use properties though. It just seemed nice to work with caps negotiation.
Created attachment 348466 [details] [review] fix assert on large width/height I just noticed I'd uploaded just one of the patches.
Created attachment 348494 [details] [review] fix caps negotiation failing due to default colorimetry The erroring pipeline in the report now works if you add " colorimetry=bt2020" in the properties.
Review of attachment 348494 [details] [review]: It might make sense to have some kind of "none" mode where it is just not added to the caps and the default handling happens ::: gst/rawparse/gstrawvideoparse.c @@ +330,3 @@ + g_object_class_install_property (object_class, + PROP_COLORIMETRY, + g_param_spec_string ("colorimetry", "Colorimetry", "Colorimetry", This is a product of enums, not a string: GstVideoColorRange, GstVideoColorMatrix, GstVideoTransferFunction, GstVideoColorPrimaries @@ +336,3 @@ + PROP_CHROMA_SITE, + g_param_spec_string ("chroma-site", "Chroma site", "Chroma site", + DEFAULT_CHROMA_SITE, G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS) This is an enum: GstVideoChromaSite
How would you want the colorimetry property made ? 4 different properties for each of the subtypes, and error out if 1, 2, or 3 are set ?
Created attachment 348803 [details] [review] fix caps negotiation failing due to default colorimetry Here's the chroma site property made into an enum, I'll do the colorimetry one once you said how you want it done.
Created attachment 348982 [details] [review] fix caps negotiation failing due to default colorimetry Well, I've done it this way then.
-- 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-bad/issues/500.