gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2023-07-18T15:57:01Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1775SRT simple loopback test pipeline not working_gstreamer_v_1.16.32023-07-18T15:57:01ZSujin KimSRT simple loopback test pipeline not working_gstreamer_v_1.16.3Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 d...Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 device=/dev/video0 do-timestamp=true ! 'video/x-raw, width=1920, height=1088, framerate=60/1, format=BGRx' ! nvvidconv ! 'video/x-raw(memory:NVMM), ftrate=4000000 ! h265parse ! mpegtsmux ! srtsink uri=srt://:8888
Decode : gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888 ! tsparse ! tsdemux ! h265parse ! nvv4l2decoder ! nvvidconv ! queue ! ximagesink
Can any one give me some advises?
Am I using MPEG-TS MUX/DEMUX wrong?
P.S. Loop back test over UDP using udpsink and udpsrc works finehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1761Caught segmentation fault while loading plugin file:.2023-07-13T17:08:15ZDivya Sampath KumarCaught segmentation fault while loading plugin file:.Hello,
I am using Gstreamer version 1.20.3. I encounter this log line in the issue title, but it does not report any library name. It just prints out ".". I also do not see any errors in the Gstreamer logs (it is set to INFO level). Whe...Hello,
I am using Gstreamer version 1.20.3. I encounter this log line in the issue title, but it does not report any library name. It just prints out ".". I also do not see any errors in the Gstreamer logs (it is set to INFO level). Where does the library loading actually happen? I thought it is when element_factory_make() and gst_init_check() is invoked but I am not so sure. Can somebody help me understand the different APIs of Gstreamer where library loading actually happens?
To include more details, I have a code where gstreamer is written in C++ and is being run on Java threads via JNI. Since multiple threads can invoke gst_element_make at the same time, I added locks around the calls to make sure no 2 threads try to load at the same time.https://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/1717EOS problem in Gstreamer pipeline with webrtcbin2023-05-16T03:55:03Zoto313EOS problem in Gstreamer pipeline with webrtcbinI am using GStreamer 1.18.4 using GstSharp binding. And I am using following pipeline:
`filesrc name=source location=video.raw ! videoparse width=1920 height=1080 framerate=30/1 format=40 ! videoconvert ! openh264enc ! h264parse ! rtph...I am using GStreamer 1.18.4 using GstSharp binding. And I am using following pipeline:
`filesrc name=source location=video.raw ! videoparse width=1920 height=1080 framerate=30/1 format=40 ! videoconvert ! openh264enc ! h264parse ! rtph264pay ! webrtcbin bundle-policy=max-bundle`
I initialize pipeline with code:
```
_pipeline = (Gst.Pipeline)Gst.Parse.Launch("...");
_pipeline.MessageForward = true;
_pipeline.Bus.AddSignalWatch();
_pipeline.Bus.Message += HandleBusMessage;
_pipeline.SetState(Gst.State.Playing);
_loop.Run();
private void HandleBusMessage(object o, Gst.MessageArgs args) {
var msg = args.Message;
_logger.LogInformation($"Received message: {msg.Type}");
}
```
I need to stop the whole pipeline when filesrc read the whole file. I thought that I just need to handle the EOS message and exit the loop, but no EOS is received from the bus.
I never get EOS message type in HandleBusMessage method, when filesrc read whole file. I only get StreamStatus, Tag, StateChanged message types. I tried set the property "message-forward" on pipeline (I also try to set this property on the webrtcbin),but no Element message type is received in the method (https://gstreamer.freedesktop.org/documentation/gstreamer/gstbin.html?gi-language=c#GstBin:message-forward).
I also tried to remove the webrtcbin from the pipeline. Then the method HandleBusMessage is called also with Element and EOS message type. So the problem must be somehow with the webrtcbin element.
How can I get information that filesrc read whole file and generated EOS? Is webrtc handling event wrong?
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1716Exposing more SRT options, enabling changing some of them during runtime2022-04-29T11:04:43Zmoibrahim-devExposing more SRT options, enabling changing some of them during runtimeHello everyone,
For a project, I need to expose more SRT options than the ones exposed by the srtsrc/srtsink options (https://gstreamer.freedesktop.org/documentation/srt/srtsink.html?gi-language=python#properties)
I tried setting optio...Hello everyone,
For a project, I need to expose more SRT options than the ones exposed by the srtsrc/srtsink options (https://gstreamer.freedesktop.org/documentation/srt/srtsink.html?gi-language=python#properties)
I tried setting options other than that using query parameters in the srturi (for example srt://$IP:$PORT?retransmitalgo=1) but I cannot get those properties using the gstreamer API function get_property($PROPERTY)
Now, my first question would be:
- Is that a limitation in the gstreamer API or in the plugin implementation itself?
If it is a limitation in the plugin implementation, I would consider implementing that by my own
I could think of those different options:
- exposing the SRTSOCKET number to be able to access the socket using the SRT API from the "outside"
- Implementing a way to be able to add more SRT options in a configurable way. For example, using a configuration file, using gst command line options ..
I am asking this here because If I would implement it, it would like to contribute it and therefore implement it in a way that will be accepted by the community.
BRhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1708[d3d11videosink] GPU Memory Leak2022-03-07T18:28:34ZStian Berglie[d3d11videosink] GPU Memory LeakFor each call to [action signal "draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#d3d11videosink::draw), the GPU memory is increasing.
I am calling the action
`videoSink.Emit("draw", shared...For each call to [action signal "draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#d3d11videosink::draw), the GPU memory is increasing.
I am calling the action
`videoSink.Emit("draw", sharedHandle, (uint)2, (ulong)0, (ulong)0);`
on every callback from [signal "begin-draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#signals).
When commenting out the Emit action, there is no memory leak.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1705tsdemux: mpegts descriptors are parsed fail2022-02-25T09:19:14ZWenlin Hungtsdemux: mpegts descriptors are parsed failSome bitstream has private descriptor tags with invalid descriptor length bytes.
Should skip descriptor parsing which is invalid descriptor length and keep playing,
instead of returning descriptor parsing fail then stop playback.
What v...Some bitstream has private descriptor tags with invalid descriptor length bytes.
Should skip descriptor parsing which is invalid descriptor length and keep playing,
instead of returning descriptor parsing fail then stop playback.
What version of GStreamer you are using: Gstreamer 1.10.4
What operating system you are using (Windows, macOS, Linux): Embedded linuxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1701avdec_h264 producing sudden PTS jumps in RTSP streams2022-02-14T16:35:14ZArkadiy Kulevavdec_h264 producing sudden PTS jumps in RTSP streamsHello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264dep...Hello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264depay ! h264parse ! identity name=id_parse ! avdec_h264 ! identity name=id_avdec ! watchdog timeout=10000 ! autovideosink`
I've been trying to wrap my head around this problem for quite a while and finally wrote a python script which shows me the PTS offsets in different parts of the pipeline ([gst.py](/uploads/1480a00860f8be0cbef49f409a4e50ce/gst.py) script attached)
`h264parse` produces a small jump in PTS only in the beginning of the playback, but stays more or less at 0.0333 afterwards (which is consistent with 30 FPS).
`avdec_h264`, however, produces jumps every several seconds:
```
[pts= 0.194 ] pts_parse delta from previous PTS not 0.0333 = 0.193780327
[pts= 0.194 ] pts_avdec delta from previous PTS not 0.0333 = 0.193780327
[pts= 4.31 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699949600000021
[pts= 6.509 ] pts_avdec delta from previous PTS not 0.0333 = 0.06690735799999992
[pts= 8.307 ] pts_avdec delta from previous PTS not 0.0333 = 0.06704043799999937
[pts= 12.306 ] pts_avdec delta from previous PTS not 0.0333 = 0.06695861200000053
[pts= 13.705 ] pts_avdec delta from previous PTS not 0.0333 = 0.06703847100000004
[pts= 20.308 ] pts_avdec delta from previous PTS not 0.0333 = 0.06702971500000032
[pts= 20.642 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999486099999899
[pts= 23.275 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699473599999806
[pts= 24.341 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999411300000105
```
Is it a bug? Or I should write a wrapper script which fixes the PTS after `avdec_h264` myself?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1685Video and audio are out of sync when using nvh264dec2022-05-03T16:48:57ZAnton MartynauVideo and audio are out of sync when using nvh264decUbuntu 18.04, GStreamer 1.18.4
I have a problematic source: https://drive.google.com/file/d/1I7G8qHhsedeW9-_hjiqoP4Lh643g_cEP/view
When I work with it I get a lot of warnings:
```
mpegtspacketizer mpegtspacketizer.c:2365:mpegts_packeti...Ubuntu 18.04, GStreamer 1.18.4
I have a problematic source: https://drive.google.com/file/d/1I7G8qHhsedeW9-_hjiqoP4Lh643g_cEP/view
When I work with it I get a lot of warnings:
```
mpegtspacketizer mpegtspacketizer.c:2365:mpegts_packetizer_pts_to_ts: Not enough information to calculate proper timestamp
mpegtspacketizer mpegtspacketizer.c:2363:mpegts_packetizer_pts_to_ts: No groups, can't calculate timestamp
tsdemux tsdemux.c:2295:check_pending_buffers: THIS SHOULD NOT HAPPEN !
basetsmux gstbasetsmux.c:1611:gst_base_ts_mux_clip:<mux:sink_1> ignoring DTS going backward
```
But when I use avdec_h264 with nvh264enc everything is fine:
```
gst-launch-1.0 --gst-debug=3 \
filesrc location="source01.ts" ! queue ! tsdemux name=demux \
demux. ! queue max-size-time=0 ! h264parse ! avdec_h264 ! queue ! videoconvert ! nvh264enc bitrate=4196 ! queue ! h264parse ! queue ! mux. \
demux. ! queue max-size-time=0 ! aacparse ! avdec_aac_latm ! queue ! audioconvert ! faac bitrate=196608 ! queue ! aacparse ! queue ! mux. \
mpegtsmux name=mux ! hlssink playlist-length=10 playlist-location="playlist.m3u8" location="fragment%06d.ts"
```
If I try to use nvh264dec and nvh264enc, then video and audio are out of sync:
```
gst-launch-1.0 --gst-debug=3 \
filesrc location="source01.ts" ! queue ! tsdemux name=demux \
demux. ! queue max-size-time=0 ! h264parse ! nvh264dec ! queue ! videoconvert ! nvh264enc bitrate=4196 ! queue ! h264parse ! queue ! mux. \
demux. ! queue max-size-time=0 ! aacparse ! avdec_aac_latm ! queue ! audioconvert ! faac bitrate=196608 ! queue ! aacparse ! queue ! mux. \
mpegtsmux name=mux ! hlssink playlist-length=10 playlist-location="playlist.m3u8" location="fragment%06d.ts"
```
When I try to play the result with nvh264dec in ffplay, warnings are displayed:
```
DTS 324214713 < 324228227 out of order
```
Is it possible to make nvh264dec to handle the source correctly in the way as avdec_h264 does?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1682mpegtsmux: error: Could not create handler for stream2021-10-27T12:18:29ZMarianna Smidth Buschlempegtsmux: error: Could not create handler for streamI have python app which is dynamically linking video (H264) from an `udpsrc` (RTP) and audio from a local `alsasrc` (converted to AAC) to `mpegtsmux`.
Depending on the order/timing of the linking I'm getting this error message:
`basets...I have python app which is dynamically linking video (H264) from an `udpsrc` (RTP) and audio from a local `alsasrc` (converted to AAC) to `mpegtsmux`.
Depending on the order/timing of the linking I'm getting this error message:
`basetsmux gstbasetsmux.c:811:gst_base_ts_mux_create_pad_stream:<mpegtsmux2> error: Could not create handler for stream`
I have tried asking both on the mailing list and IRC does this error means and what causes it, but nobody has been able to answer me so far...
A simpler gst-launch-1.0 representation of the pipeline works fine:
```
gst-launch-1.0 udpsrc address=224.1.1.1 port=5000 multicast-iface=eth1 ! application/x-rtp,media=video,payload=33,clock-rate=90000,encoding-name=MP2T ! rtpbin ! queue ! decodebin caps="video/x-h264" ! h264parse ! "video/x-h264,stream-format=byte-stream,alignment=au" ! tee name=t ! queue ! "video/x-h264,stream-format=byte-stream,alignment=au" ! multiqueue name=mq ! mpegtsmux name=mux ! rtpmp2tpay ! fakesink audiotestsrc ! "audio/x-raw,format=S32LE,layout=interleaved,rate=44100,channels=2,channel-mask=(bitmask)0x3" ! mq. mq. ! audioconvert ! avenc_aac ! mux. -v --gst-debug=*:3
```
So it must be a matter of order/timing
Raising the debug level to `*tsmux:5` or even `*tsmux:7` doesn't give all that much more clarity:
```
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168211501 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:1676:gst_base_ts_mux_find_best_pad:<mpegtsmux_cam1> Best pad found with 0:00:00.023219954: <mpegtsmux_cam1:sink_1>
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168320898 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:1094:gst_base_ts_mux_aggregate_buffer:<mpegtsmux_cam1> Pads collected
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168373356 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_0> Creating stream with PID 0x0041 for caps video/x-h264, stream-format=(string)byte-stream, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, alignment=(string)au, profile=(string)high, level=(string)4
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168416277 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:780:gst_base_ts_mux_create_pad_stream:<mpegtsmux_cam1:sink_0> Use stream (pid=65) from pad as PCR for program (prog_id = 0)
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168447309 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_1> Creating stream with PID 0x0041 for caps audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, stream-format=(string)raw, framed=(boolean)true, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)1210
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168469731 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:470:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_1> we have additional codec data (2 bytes)
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168483311 75594 0x564857e0f8f0 WARN basetsmux gstbasetsmux.c:811:gst_base_ts_mux_create_pad_stream:<mpegtsmux_cam1> error: Could not create handler for stream
```
And looking at the source I seem to be getting here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/gst/mpegtsmux/gstbasetsmux.c#L727
```
if (ts_pad->stream == NULL) {
ret = gst_base_ts_mux_create_stream (mux, ts_pad);
if (ret != GST_FLOW_OK)
goto no_stream;
}
```
```
no_stream:
{
GST_ELEMENT_ERROR (mux, STREAM, MUX,
("Could not create handler for stream"), (NULL));
return ret;
}
```
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/gst/mpegtsmux/gstbasetsmux.c#L370
```
if (st != TSMUX_ST_RESERVED) {
ts_pad->stream = tsmux_create_stream (mux->tsmux, st, ts_pad->pid,
ts_pad->language);
} else {
GST_DEBUG_OBJECT (pad, "Failed to determine stream type");
}
if (ts_pad->stream != NULL) {
```
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsmux/tsmux/tsmux.c#L682
My best guess:
```
/* Ensure we're not creating a PID collision */
if (tsmux_find_stream (mux, new_pid))
return NULL;
```
Finally if I compare with the output of the working gst-launch:
```
0:00:00.306454146 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mux:sink_0> Creating stream with PID 0x0041 for caps video/x-h264, stream-format=(string)byte-stream, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, alignment=(string)au, profile=(string)high, level=(string)4
0:00:00.306529032 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:780:gst_base_ts_mux_create_pad_stream:<mux:sink_0> Use stream (pid=65) from pad as PCR for program (prog_id = 0)
0:00:00.306580500 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mux:sink_1> Creating stream with PID 0x0042 for caps audio/mpeg, channels=(int)2, rate=(int)44100, mpegversion=(int)4, base-profile=(string)lc, framed=(boolean)true, stream-format=(string)raw, channel-mask=(bitmask)0x0000000000000003, level=(string)2, profile=(string)lc, codec_data=(buffer)121056e500
0:00:00.306609142 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:470:gst_base_ts_mux_create_stream:<mux:sink_1> we have additional codec data (5 bytes)
0:00:00.306659206 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmuxaac.c:106:gst_base_ts_mux_prepare_aac_adts:<mux> Preparing AAC buffer for output
0:00:00.306679775 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmuxaac.c:111:gst_base_ts_mux_prepare_aac_adts:<mux> Rate index 4, channels 2, object type/profile 2
0:00:00.306703159 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1187:gst_base_ts_mux_aggregate_buffer:<mux:sink_1> Chose stream for output (PID: 0x0042)
0:00:00.306724715 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1201:gst_base_ts_mux_aggregate_buffer:<mux> Buffer has PTS 0:00:00.000000000 pts 0
0:00:00.306745826 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1207:gst_base_ts_mux_aggregate_buffer:<mux> Buffer has DTS +0:00:00.000000000 dts 0
0:00:00.306760796 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1229:gst_base_ts_mux_aggregate_buffer:<mux> delta: 1
```
Here it can be seen that the difference is that the audio and video streams both have their own PIDs (0x41 and 0x42) while when I get the error they both got the same PID (0x41)
And that is what must be triggering this:
```
/* Ensure we're not creating a PID collision */
if (tsmux_find_stream (mux, new_pid))
return NULL;
```
Is this expected behavior or a bug / race condition?
If this is expected is it at least possible to add more debug information (pad name, ...) that can give a better indication of what is wrong?
Fx, add an WARNING about PID collision?
And in that case what should I do to avoid collisions?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1669VA: Need to create a property for device's tile selection.2021-10-28T15:50:49ZHe JunyanVA: Need to create a property for device's tile selection.The current vaD128h264dec kind VA plugins can specify the GPU device correctly, but we now have a sub division of each GPU device into multi tiles(It is like the NUMA in GPU side), so we may need to add a "tile" property to each VA eleme...The current vaD128h264dec kind VA plugins can specify the GPU device correctly, but we now have a sub division of each GPU device into multi tiles(It is like the NUMA in GPU side), so we may need to add a "tile" property to each VA element.
We just continue the discussion of:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2230#note_1059967https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1668h264parse: Forwarding SEI timecodes causes qtmux to produce non-playable output2021-09-24T14:39:37ZPaul Feeh264parse: Forwarding SEI timecodes causes qtmux to produce non-playable outputI've encountered a change in behaviour that first occurs with GStreamer 1.15.90. Processing of CCTV video that worked with GStreamer 1.12.5 breaks when I upgrade to GStreamer 1.16.2. I have narrowed down the change to commit 7c425cf3.
...I've encountered a change in behaviour that first occurs with GStreamer 1.15.90. Processing of CCTV video that worked with GStreamer 1.12.5 breaks when I upgrade to GStreamer 1.16.2. I have narrowed down the change to commit 7c425cf3.
[playable.h264](/uploads/a548c809d03a80c31b2b9c46037b39ae/playable.h264)
Attached is a depayed capture of RTP video from an IP CCTV camera. I initially investigated with GStreamer 1.12.5 and 1.16.2 as these were the versions bundled with openSUSE Leap 15.1 and 15.2. However it's commit 7c425cf3 that's of most interest.
The attached file is playable with both GStreamer 1.12.5 and 1.16.2 as follows:
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! decodebin ! autovideosink
```
Note: Ignore that it's a dark noisy image, the camera wasn't pointing at anything useful.
A pipeline including `h264parse` and `qtmux` elements illustrates the change in behaviour.
Output on Leap 15.1, GStreamer 1.12.5 (video plays onscreen, acceptable error as I closed the video playback window early):
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! qtmux fragment-duration=1000 ! filesink location=output.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.017978031
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$ gst-play-1.0 output.mp4
Press 'k' to see a list of keyboard shortcuts.
Now playing /root/output.mp4
Redistribute latency...
Redistribute latency...
ERROR Output window was closed for file:///root/output.mp4
ERROR debug information: xvimagesink.c(554): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Reached end of play list.
```
Output on Leap 15.2, GStreamer 1.16.2 (gst-play fails to display any video):
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! qtmux fragment-duration=1000 ! filesink location=output.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.019327141
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$ gst-play-1.0 output.mp4
Press 'k' to see a list of keyboard shortcuts.
Now playing /root/output.mp4
ERROR This file contains no playable streams. for file:///root/output.mp4
ERROR debug information: qtdemux.c(716): gst_qtdemux_post_no_playable_stream_error (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
no known streams found
Reached end of play list.
```
If I patch gstreamer-plugins-bad to avoid the `gst_buffer_add_video_time_code_meta_full` call, added by 7c425cf3, then I can once again pass the h264 via through `h264parse` and `qtmux` elements and get playback video with GStreamer 1.16.2.
I'm unsure whether:
1. The handling of time codes from SEI NALs is flawed within `h264parse`,
2. the `qtmux` element incorrectly handles the additional `GstVideoTimeCodeMeta` or
3. if the resulting video is valid, but gst-play is at fault (unlikely as other players also fail to handle the output).
Also note, behaviour changes again with GStreamer 1.18 where the `qtmux` fails with `"Buffer has no PTS"`. However that's a separate issue. This bug is only about the SEI time code change introduced in 1.15.90.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1663mss stream playback failed2022-04-28T13:07:10Zrlandjmss stream playback failedgstreamer version:git master
Playbin3 cannot play this mss stream http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest ,but I can play it normally after installing the [Native MPEG-Dash + HLS Playback plugi...gstreamer version:git master
Playbin3 cannot play this mss stream http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest ,but I can play it normally after installing the [Native MPEG-Dash + HLS Playback plugin](https://chrome.google.com/webstore/detail/native-mpeg-dash-%2B-hls-pl/cjfbmleiaobegagekpmlhmaadepdeedn?hl=en) in chrome.
qtdemux/mssdemux complained about many errors. Is there any way for qtdemux/mssdemux to improve compatibility with this stream?
log [gst.zip](/uploads/18188cc9c8c68d41cfd6d316f2f4fbf9/gst.zip)
```shell
$ GST_DEBUG_COLOR_MODE=off GST_DEBUG=5 GST_DEBUG_FILE='/home/luckysk/work/log/gst.log' GST_DEBUG_DUMP_DOT_DIR='/home/luckysk/work/log' gst-launch-1.0 playbin3 uri=http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(SoupSession)NULL, force=(boolean)false;
Redistribute latency...
Redistribute latency...
Redistribute latency...
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux3: This file is invalid and cannot be played.
Additional debug info:
../gst/isomp4/qtdemux.c(7406): gst_qtdemux_process_adapter (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux3:
sample data crosses atom boundary
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0/GstMssDemux:mssdemux0: Internal data stream error.
Additional debug info:
../gst-libs/gst/adaptivedemux/gstadaptivedemux.c(2708): _src_chain (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0/GstMssDemux:mssdemux0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1655`srtpenc`, `dtlsenc`: Log keys to `SSLKEYLOGFILE`2022-05-17T00:01:21ZGerard Ryan`srtpenc`, `dtlsenc`: Log keys to `SSLKEYLOGFILE`Adding [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) logging to `SSLKEYLOGFILE` for `srtpenc` and `dtlsenc` would allow easy diagnosis of network-related issues using Wireshark as it w...Adding [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) logging to `SSLKEYLOGFILE` for `srtpenc` and `dtlsenc` would allow easy diagnosis of network-related issues using Wireshark as it will be able to decrypt the packet captures.
Adding it to these plugins, rather than higher-level plugins like `webrtcbin` would allow a large portion of GStreamer to use this feature.
[NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) is followed by Chrome, Firefox, Curl and Wireshark.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1652Follow-up from "codecs: av1dec: Enable scalable decoding"2021-09-24T14:39:34ZVíctor Manuel Jáquez LealFollow-up from "codecs: av1dec: Enable scalable decoding"The following discussion from !2475 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2475#note_1043529):
> This patch can really solve the multi...The following discussion from !2475 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2475#note_1043529):
> This patch can really solve the multi layer problem, the correctness is OK, but have some performance flaw because of the caps negotiation.
>
> For example, there are 2 spatial layer, 0 with 800x600 res and 1 with 1092x1080 res. According to spec, we should only output the higher layer by default, which is the 1 with 1920x1080 res. But we need to decode both layers(The higher layer needs to reference the lower layer). The coded picture from both layers come in interweave sequence, and in the new_picture(), because the resolution changes, we need to re-negotiate the caps with the downstream element again and again. The is a big waste and have performance problem.
>
> If we want to avoid this, we should notify the sub-class whether this picture will be output or not when call the new_picture(). And the sub-class should maintain a buffer_pool for each non-output layers internally, and allocate the picutre/buffers/surfaces from that internal buffer pool to avoid that re-negotiation.
>
> This may take a big effect(Each internal layer can also change their resolution dynamically). I think this patch can already make us conform to the SPEC and pass all the conformance test about his. This multi layers feature is more or less like the SVC feature of the HEVC, we are not sure whether it will be widely used. And I think we can add a TODO for that, and this patch is already OK for me.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1645msdk: decode and downscale with msdkh264dec and msdkvpp outputfile corrupted2021-09-24T14:39:33Ztengjinchungmsdk: decode and downscale with msdkh264dec and msdkvpp outputfile corruptedtrying to decode and down scale from 4K to 2048x1550 nv12 file, output file have greenline at the top of the stream. Issue is not observed with vaapih264dec and vaapipostproc.
```
platform: TigerLake
vainfo: VA-API version: 1.12 (libva ...trying to decode and down scale from 4K to 2048x1550 nv12 file, output file have greenline at the top of the stream. Issue is not observed with vaapih264dec and vaapipostproc.
```
platform: TigerLake
vainfo: VA-API version: 1.12 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 21.2.3 (2cc1938f)
```
`gst-launch-1.0 filesrc location=/home/test/media-profiling-tool/media-content/H264/Puppies_3840x2160_20mbps_60fps_High_at_L5.2.h264 num-buffers=1500 ! h264parse ! vaapih264dec ! vaapipostproc ! "video/x-raw,format=NV12,width=2048,height=1550" ! filesink location=2048x1550-nv12.yuv`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1638SRT stats send-duration-us duplicated2021-09-24T14:39:33ZSektor van SkijlenSRT stats send-duration-us duplicatedThe `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is send...The `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is sending data (idle time exclusive) */
"send-duration-us", G_TYPE_INT64, stats.usSndDuration,
...
/* busy sending time (i.e., idle time exclusive) */
"send-duration-us", G_TYPE_UINT64, stats.usSndDuration,
"negotiated-latency-ms", G_TYPE_INT, stats.msSndTsbPdDelay, NULL);
```
Another minor problem is `*bytes += stats.byteSent;` for `is_sender` section, but `stats.byteRecvTotal` for else section. As you don't request clearing the stats in the `srt_bstats` call it shouldn't make a difference, but formally it's wrong.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1635codecs: h264decoder: decoding performance regression in latest git2023-01-29T18:09:21ZRafał Dzięgielcodecs: h264decoder: decoding performance regression in latest gitWhile using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This ...While using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This does not happen if I use 1.19.1 or compile gst-plugins-bad from before !2373
Bisect indicated that f1df1207 and b4e38874 were the first 2 bad commits that introduced this bug.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1631Hanging in shmsink2023-06-28T15:18:11ZandrejlevkovitchHanging in shmsinkSometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, ...Sometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, because shmsink can't allocate new memory and blocks of shared memory (as GstBuffer-s) reuses by gstreamer. So producer freezes here:
https://github.com/GStreamer/gst-plugins-bad/blob/f9d7b708e12e5560759c585b44cfa3e523b61526/sys/shm/gstshmsink.c#L730-L742
I see this problem with gstreamer version 1.4 and 1.6
Looks like if we will ignore "need_new_memory" condition (just return from function and skip current frame) it fixes the problem. [Here](https://github.com/andrejlevkovitch/gst-shm-hanging-fix) you can find minimal example for bug reproducing and small fix that resolves the problem.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1630dvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()2021-09-24T14:39:31ZHarald Jennydvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This resul...Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This results in the error message "dvbsrc gstdvbsrc.c:2235:gst_dvbsrc_output_frontend_stats:<dvbsrc0> There were errors getting frontend status information: 'Unknown error 524'" (which means ENOTSUPP). Would it be possible to modify gst_dvbsrc_output_frontend_stats() to do the stats collection in a v5 compatible way like it is done for example in https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/dvbchannel.cpp?
Kind regards
Harald Jenny