I was debugging a problem with a playback pipeline on am i.MX6,
with Gstreamer 1.14.

I am using v4l2h264dec to decode data and generating debug output,
including DOT files in certain situations. Sometimes the pipeline fails,
e.g. by

onGstMessageError Could not dup device '/dev/video15' for reading and writing., v4l2_calls.c(758): gst_v4l2_dup (): /GstPipeline:Player/v4l2h264dec:v4l2h264dec4:
system error: Bad file descriptor

onGstMessageError Could not initialize supporting library., gstvideodecoder.c(2535): gst_video_decoder_change_state (): /GstPipeline:Player/v4l2h264dec:v4l2h264dec4:
Failed to open decoder

After some debugging I think I know the problem: There are two threads,
accessing the same device (my decoder). One is my normal decoding of the video.
The other seems to be gst_v4l2_object_get_property_helper, case PROP_DEVICE_NAME.

After further trying to narrow the error, I was able to switch on/off the
problem by enabling/disabling DOT files generation. The generation of
DOT files seems to be using gst_v4l2_object_get_property_helper, case PROP_DEVICE_NAME, to get the device name, like CODA960 or imx-ipu-vout.

The code in gst_v4l2_object_get_property_helper, case PROP_DEVICE_NAME
(see here:
https://github.com/GStreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L727 ) seems to check if file is open, if not, opens it,
doing something (getting the name) and closing it. When in parallel
(exactly parallel?) the decoder wants to open the files, or is in process
of opening the file, it seems to be a race condition that decoder cannot
be opening or is closed shortly afterwards by gst_v4l2_close setting video_fd
to -1.

I cannot fix it, sorry, too less knowledge in this environment, 
but the current code seems to be buggy. It also looks like open the device
to read the device name again and again seems to be inefficient.
Can it read only once and caching it? The case PROP_DEVICE in same function
looks easier and different.