Skip to content

GitLab

v4l2: Reset transfer in gst_v4l2_object_acquire_format()

Merged Qi Hou requested to merge hq/gstreamer:transfer into main

I met pipeline hang when running one rtp streaming case. Here is the test command:

`Server:

gst-launch-1.0 v4l2src device=/dev/video3 ! "video/x-raw,format=YUY2,width=1920,height=1080" ! v4l2h264enc output-io-mode=dmabuf-import ! h264parse ! rtph264pay ! udpsink host=192.168.101.34

Client:

gst-launch-1.0 -e udpsrc ! application/x-rtp ! rtph264depay ! h264parse ! v4l2h264dec ! queue ! v4l2h264enc ! h264parse ! matroskamux ! filesink location=./001_H264_webcamera.mkv`

Client pipeline hang as decoder chosen caps is always null after negotiation with encoder, and capture setup got dead loop.

Here is the analysis:

  1. First negotiation between decoder and encoder, decoder capture set format with bt601 where info.colorimetry.transfer = GST_VIDEO_TRANSFER_BT601(enum is 16). It makes v4l2object->transfer to be also 16.
  2. driver reports source change event to client. Capture get format with fmt.fmt.pix.colorspace/quantition/ycbcr_enc/xfer_func=3:2:2:1 which is got by parsing the encoded stream from server.
  3. In acquire_format(), fmt.fmt.pix.xfer_func=1 makes cinfo->transfer = v4l2object->transfer = 16 in get_colorspace(). So get_colorspace() map pix colorimetry 3:2:2:1 to gstreamer colorimetry 2:3:16:1. It's not acceptable by encoder sink caps.

Resolution:

Reset v4l2object->transfer in acquire_format() to avoid get_colorspace() use the old transfer.