GNOME Bugzilla – Bug 766382
v4l2videodec: use visible size, not coded size, for downstream negotiation filter
Last modified: 2016-06-07 21:20:52 UTC
Created attachment 327800 [details] [review] v4l2videodec: use visible size, not coded size, for downstream negotiation filter gst_v4l2_probe_caps() returns the coded size, not the visible size. Subtract the known padding from probed caps with the coded size before using them as filter for caps negotiation with downstream elements.
Review of attachment 327800 [details] [review]: ::: sys/v4l2/gstv4l2videodec.c @@ +533,3 @@ gst_buffer_unref (codec_data); + /* For decoders G_FMT returns coded size, G_SELECTION returns visible size That's odd, as this isn't the case on S5P MFC. You can have padding in your buffers without exposing the coded size. Do we have a general agreement around developer that this is the way to go ? Do yo have a patch for MFC ?
Sorry, I see, MFC is also this way. This is another regression caused by the negotiation of the format. Thanks for the patch.
You can with multiplane formats. For single-planar YUV420 formats it is not possible to have vertical padding because the chroma planes start right after the luma plane.
Will also go in 1.8. Attachment 327800 [details] pushed as 1f31715 - v4l2videodec: use visible size, not coded size, for downstream negotiation filter
Branch: 1.8 Commit: b957760a6bf80b1974fc08f3ae8ce47a54570f8f