gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2023-07-13T15:57:46Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1742For DRC (container) streams H264parse is not providing updated caps(width/res...2023-07-13T15:57:46Zkudas-swFor DRC (container) streams H264parse is not providing updated caps(width/resolution)For container streams, H264parse overrides width/height values from upstream as per sink_caps, but for DRC streams it provides old resolutions even after resolution changed (Basically upstream is not updating the value in sink_caps), Due...For container streams, H264parse overrides width/height values from upstream as per sink_caps, but for DRC streams it provides old resolutions even after resolution changed (Basically upstream is not updating the value in sink_caps), Due to that DRC container streams are failing.
Check below code snippet of H264parse:
/* sps should give this but upstream overrides */
if (s && gst_structure_has_field (s, "width"))
gst_structure_get_int (s, "width", &width);
else
width = h264parse->width;
if (s && gst_structure_has_field (s, "height"))
gst_structure_get_int (s, "height", &height);
else
height = h264parse->height;
For DRC elementary streams sink_caps will be NULL, so "if (s && gst_structure_has_field (s, "width"))" and "if (s && gst_structure_has_field (s, "height"))" will be false and H264parse will use SPS parsed resolution and that is why it works.
If I take SPS parsed resolution, then it works fine for both DRC container and elementary streams. Below code works fine for both the cases:
```
#if 0
/* sps should give this but upstream overrides */
if (s && gst_structure_has_field (s, "width"))
gst_structure_get_int (s, "width", &width);
else
width = h264parse->width;
if (s && gst_structure_has_field (s, "height"))
gst_structure_get_int (s, "height", &height);
else
height = h264parse->height;
#else
/* do not override with upstream caps, use sps parsed resolution */
width = h264parse->width;
height = h264parse->height;
#endif
```
I am using GStreamer 1.16.3 on Ubuntu 20.04.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/988DeckLink: Video mode detection not working correctly with 1.162022-11-04T07:15:39ZTim AutinDeckLink: Video mode detection not working correctly with 1.16Hello,
With version 1.8.3 when I enter this command:
```
gst-launch-1.0 -vvv \
decklinkvideosrc device-number=0 ! \
videoconvert ! \
autovideosink
```
It works well, the video mode is detected automatically and quickly. Wit...Hello,
With version 1.8.3 when I enter this command:
```
gst-launch-1.0 -vvv \
decklinkvideosrc device-number=0 ! \
videoconvert ! \
autovideosink
```
It works well, the video mode is detected automatically and quickly. With 1.16, it takes ~ 2 secs to detect the video mode, finds it, but then the video is very shaky, and I have these warnings:
```
WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(3005): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage:
There may be a timestamping problem, or this computer is too slow.
```
If I tell GStreamer what is the mode when starting it, it works fine.