v4l2h264dec seems too restrictive when it comes to colorimetry caps
I have a pipeline which is more or less appsrc ! h264parse ! v4l2h264dec ! appsink
. It didn't work with certain h264 streams, and I found out it's due to colorimetry caps.
When I query the v4l2h264dec element's sink pad's caps after setting the pipeline's state to playing, this is what it reports: video/x-h264, width=(int)[ 64, 1920 ], height=(int)[ 64, 1920 ], framerate=(fraction)[ 0/1, 2147483647/1 ], stream-format=(string)byte-stream, alignment=(string)au, level=(string){ 1, 1b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1, 4.2, 5, 5.1 }, profile=(string){ baseline, constrained-baseline, main, high, stereo-high, multiview-high }, colorimetry=(string){ bt601, smpte240m, bt709, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true
.
The relevant part here is the colorimetry: colorimetry=(string){ bt601, smpte240m, bt709, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }
. When playing the problematic h264 streams, the input caps contains colorimetry=(string)2:4:16:3
, which isn't in the list of supported colorimetries, which causes the problem.
There's a couple of related issues here:
- Why does v4l2h264dec constrain the colorimetries at all? Doesn't it just output the color values which were in the h264 stream? Isn't it the responsibility of the consumer of the decoded video frames to handle the colorimetry?
- The colorimetry tuple
2:4:16:3
means range=[16..235], matrix=BT601, transfer=BT601, primaries=BT470BG. From what I can tell, this is identical to bt601. Shouldn't v4l2h264dec therefore also claim to support2:4:16:3
when it claims to support bt601? Alternatively, shouldn't gstreamer treat them as equivalent when checking if pads are compatible?
And for my own sake: currently, I work around this by hard-coding caps=video/x-h264,colorimetry=bt601
in the appsrc. This seems to work, but is it an alright workaround? Or does v4l2h264dec actually care about colorimetry in some way which could make this workaround problematic?