GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:37:30Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/997vulkansink: support meta:GstVideoOverlayComposition caps2021-09-24T14:37:30ZAaron Boxervulkansink: support meta:GstVideoOverlayComposition capshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/632Unable to play some multicast streams2021-09-24T13:25:10ZondrejjUnable to play some multicast streamsUnable to play some multicast streams with this error:
```
[ondrejj@work ~]$ LANG=C gst-play-1.0 udp://233.10.47.64:1234/
Press 'k' to see a list of keyboard shortcuts.
Now playing udp://233.10.47.64:1234/
Pipeline is live.
Redistribute...Unable to play some multicast streams with this error:
```
[ondrejj@work ~]$ LANG=C gst-play-1.0 udp://233.10.47.64:1234/
Press 'k' to see a list of keyboard shortcuts.
Now playing udp://233.10.47.64:1234/
Pipeline is live.
Redistribute latency...
** (gst-play-1.0:20526): CRITICAL **: 14:43:16.795: gst_audio_decoder_negotiate_
default: assertion 'GST_IS_CAPS (dec->priv->ctx.caps)' failed
** (gst-play-1.0:20526): CRITICAL **: 14:43:16.795: gst_audio_decoder_negotiate_
default: assertion 'GST_IS_CAPS (dec->priv->ctx.caps)' failed
```
Same problem happens after this stream was recorded using udpxrec. File attached for testing.
[stream.rec](/uploads/a7f23bbf83a9ac7d9f238eed5ed34616/stream.rec)https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/163Runtime problem with `qtdemux` for mingw build only2019-08-23T12:43:20ZDavid IngRuntime problem with `qtdemux` for mingw build onlyI have a video file (no audio) which plays nicely in
* VLC
* Windows Media Player on Windows 10
* Whatever application plays videos by default in Windows 10
The video is here: [screencap.mp4](/uploads/36c073f5a045b802d4dc26549c0fac2e/...I have a video file (no audio) which plays nicely in
* VLC
* Windows Media Player on Windows 10
* Whatever application plays videos by default in Windows 10
The video is here: [screencap.mp4](/uploads/36c073f5a045b802d4dc26549c0fac2e/screencap.mp4)
I have analyzed the video with `ffprobe` (in many ways) and I cannot find any problems with it.
The problem is: `qtdemux` doesn't play nicely with the video; and so I cannot use GES with the video (which is my ultimate goal).
The problem exists in the following versions.
* gstreamer 1.14.4-mingw
* gstreamer 1.16.0-mingw
The problem **does not** exist in the following versions.
* gstreamer 1.16.0-msvc
* gstreamer master (1.16.1) on fedora 30 (built using `gst-build`)
The problem is easily reproduced using `gst-launch` commands for the affected versions.
```
$ gst-launch-1.0 filesrc location=screencap.mp4 ! decodebin ! playsink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
qtdemux.c(6073): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
This is related to an [email thread](http://gstreamer-devel.966125.n4.nabble.com/possible-bug-in-qtdemx-element-td4691005.html).https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/630Audio glitches when using external clock2021-09-24T13:25:09ZJerome BergerAudio glitches when using external clockWhen syncing to an external clock (eg. NTP) using the `resample` slave method, there are regular hiccups in the audio.
By digging through the traces, I was able to determine that those hiccups occur each time the NTP clock is sampled to...When syncing to an external clock (eg. NTP) using the `resample` slave method, there are regular hiccups in the audio.
By digging through the traces, I was able to determine that those hiccups occur each time the NTP clock is sampled to update the `GstAudioSinkClock`. In particular, using `GST_DEBUG="audiobasesink:7"` and looking at the traces that show how each buffer is resampled (traces like `gstaudiobasesink.c:2134:gst_audio_base_sink_render:<alsasink0> rendering at 9471 480/480`), I was able to determine that most buffers are stretched by a small amount (eg. between 480 and 490 frames instead of 480) but the first buffer after each sampling of the NTP clock is reduced by a large amount (often to less than 400 frames instead of 480) producing the audible artefact.
In `gstaudiobasesink.c` there is a disabled code block like this near line 1358:
```c
/* FIXME, we can sample and add observations here or use the timeouts on the
* clock. No idea which one is better or more stable. The timeout seems more
* arbitrary but this one seems more demanding and does not work when there is
* no data comming in to the sink. */
#if 0
GstClockTime etime, itime;
gdouble r_squared;
/* sample clocks and figure out clock skew */
etime = gst_clock_get_time (GST_ELEMENT_CLOCK (sink));
itime = gst_audio_clock_get_time (sink->provided_clock);
/* add new observation */
gst_clock_add_observation (sink->provided_clock, itime, etime, &r_squared);
#endif
```
I was able to fix the issue by enabling the above code block and disabling the call to `gst_clock_set_master (sink->provided_clock, clock);` near line 1685. Afterwards, all buffers are resampled to values close to the nominal 480 frames (between 477 and 483) and there are no longer any audible artefacts.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/617v4l2src: reset DV timings when V4L2_EVENT_SOURCE_CHANGE appear2021-09-24T13:33:28ZEugen Klimv4l2src: reset DV timings when V4L2_EVENT_SOURCE_CHANGE appearMany digital capture cards (e.g. SDI) support format autodetection. However, v4l2 standard doesn't allow driver to change format implicitly [1], so the application needs to wait for V4L2_EVENT_SOURCE_CHANGE and then set the DV timings ex...Many digital capture cards (e.g. SDI) support format autodetection. However, v4l2 standard doesn't allow driver to change format implicitly [1], so the application needs to wait for V4L2_EVENT_SOURCE_CHANGE and then set the DV timings explicitly. This is needed for on-the-fly format change, if hardware support format autodetection.
[1] https://www.linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-query-dv-timings.html#descriptionhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/68GstRtspServer accepts Rtsp OPTIONS message, holds the connection open, never ...2021-09-24T11:03:43ZSean HalpinGstRtspServer accepts Rtsp OPTIONS message, holds the connection open, never responds.Given a pipeline served by `gstrtspserver` that will re-stream rtsp like so;
```
"rtspsrc location=rtsp://<ip>/live.sdp ntp-sync=true buffer-mode=synced latency=0 protocols=GST_RTSP_LOWER_TRANS_TCP ! rtph264depay ! rtph264pay pt=96 ! rtp...Given a pipeline served by `gstrtspserver` that will re-stream rtsp like so;
```
"rtspsrc location=rtsp://<ip>/live.sdp ntp-sync=true buffer-mode=synced latency=0 protocols=GST_RTSP_LOWER_TRANS_TCP ! rtph264depay ! rtph264pay pt=96 ! rtptimestamppay name=pay0"
```
When a disconnection occurs between gstreamer and the rtspsrc location while streaming a SHARED media factory, GstRtspServer will stop responding to RTSP requests, sometimes...
Sending an ffprobe to the mounted stream shows that we send an OPTIONS message then the connection hangs indefinitely and there will be no response.
```
-> % ffprobe -hide_banner -loglevel trace rtsp://<ip>/camera
Probing rtsp score:100 size:0
[tcp @ 0x7ff8e1d02a00] No default whitelist set
[tcp @ 0x7ff8e1d02a00] Original list of addresses:
[tcp @ 0x7ff8e1d02a00] Address <ip> port 554
[tcp @ 0x7ff8e1d02a00] Interleaved list of addresses:
[tcp @ 0x7ff8e1d02a00] Address <ip> port 554
[tcp @ 0x7ff8e1d02a00] Starting connection attempt to <ip> port 554
[tcp @ 0x7ff8e1d02a00] Successfully connected to <ip> port 554
[rtsp @ 0x7ff8e2000000] Sending:
OPTIONS rtsp://<ip>:554/camera RTSP/1.0
CSeq: 1
User-Agent: Lavf58.20.100
--
```https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/39Android tutorials errors on Android Studio 3.4.1 ( Windows 10 64 )2021-09-24T16:19:59ZJPMJPMAndroid tutorials errors on Android Studio 3.4.1 ( Windows 10 64 )Hi,
Sync failed with the following errors :
![ScreenShot073](/uploads/8a986498eea732b198d08a4ecbe2890b/ScreenShot073.png)
Any help ?, thanks in advance.Hi,
Sync failed with the following errors :
![ScreenShot073](/uploads/8a986498eea732b198d08a4ecbe2890b/ScreenShot073.png)
Any help ?, thanks in advance.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/38Installation steps for Windows2021-09-24T16:19:59ZGopi JayaramanInstallation steps for WindowsAs per link, I tried to install gstreamer on my windows 10 PC.
Followed these steps.
>>>
Download and install GStreamer binaries
There are 3 sets of files in GStreamer binaries:
The runtime files are needed to run GStreamer applicatio...As per link, I tried to install gstreamer on my windows 10 PC.
Followed these steps.
>>>
Download and install GStreamer binaries
There are 3 sets of files in GStreamer binaries:
The runtime files are needed to run GStreamer applications. You probably want to distribute these files with your application (or the installer below).
The development files are additional files you need to create GStreamer applications.
The Merge Modules files are additional files you can use to deploy GStreamer binaries alongside your application (see Windows deployment).
Get the Runtime and Development files installers appropriate for your architecture from here:
https://gstreamer.freedesktop.org/data/pkg/windows/
Execute the installers and choose an installation folder. The suggested default is usually OK.
<<<<
After a search, under https://gstreamer.freedesktop.org/data/pkg/windows/1.16.0/, I picked up 3 files. (hope these are right)
1. gstreamer-1.0-msvc-x86_64-1.16.0.msi
2. gstreamer-1.0-devel-msvc-x86_64-1.16.0.msi
3. gstreamer-1.0-msvc-x86_64-1.16.0-merge-modules.zip
I installed the first 2. 3rd one is just unzip, don't know what to do with this.
After reboot, I tried to open msvc project as per link. but no tutorials.sln present in the folder structure.
Please help with detailed instructions.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/628typefind: audio/mpeg icecast stream misdetected as h264 video2021-09-24T13:25:08ZThomas Bluemeltypefind: audio/mpeg icecast stream misdetected as h264 videoTrying to play the following web radio station (which uses icecast) fails:
`gst-launch-1.0 -v uridecodebin uri=http://192.99.39.108:7872/stream ! audioconvert ! audioresample ! autoaudiosink`
```
Setting pipeline to PAUSED ...
Pipeline...Trying to play the following web radio station (which uses icecast) fails:
`gst-launch-1.0 -v uridecodebin uri=http://192.99.39.108:7872/stream ! audioconvert ! audioresample ! autoaudiosink`
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0: source = "\(GstSoupHTTPSrc\)\ source"
Got context from element 'source': gst.soup.session=context, session=(SoupSession)NULL, force=(boolean)false;
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: force-caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: sink-caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad1: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstICYDemux:icydemux0.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps = application/x-icy, metadata-interval=(int)8192
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad1: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstICYDemux:icydemux0.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps = application/x-icy, metadata-interval=(int)8192, content-type=(string)audio/mpeg
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0: bitrate = 0
/GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0: Error parsing H.264 stream
Additional debug info:
gsth264parse.c(1307): gst_h264_parse_handle_frame (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstH264Parse:h264parse0:
No H.264 NAL unit found
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
I traced the problem to [`mp3_type_find_at_offset`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/blob/909b59dd55f94a2c442de07b23e100ab6e1c230c/gst/typefind/gsttypefindfunctions.c#L1431). The problem is that the mp3 frame size is 1044 bytes, but `gst_type_find_peek` keeps failing (regardless of `GST_MP3_TYPEFIND_SYNC_SIZE`) until size is reduced to 1024. So it finds the first header, then somehow the second (even though it is at offset 1044), but then because it considers the second as only partial, it reduces `found` to 1. And because `found` is less than `GST_MP3_TYPEFIND_MIN_HEADERS` (which is defined as 2), it never even considers it as a valid mp3 stream.
The logic of how this function walks through the byte stream doesn't make a whole lot of sense to me.
See [typefind.log](/uploads/1dc502c0f41be16eee58ca382735782f/typefind.log) with my added log statements.
Playing the same station with VLC works as expected.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/173Corrupt frames when negotiating memory:DMABuf with gl pipelines2021-09-24T12:23:19ZPieter JordaanCorrupt frames when negotiating memory:DMABuf with gl pipelinesPlatform: Ubuntu 19.04 x86_64 on Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
When negotiating for memory:DMABuf with Intel VA-API I get pure green frames or corrupt frames like [here](https://imgur.com/67aoHtE)
No warnings or errors.
```
...Platform: Ubuntu 19.04 x86_64 on Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
When negotiating for memory:DMABuf with Intel VA-API I get pure green frames or corrupt frames like [here](https://imgur.com/67aoHtE)
No warnings or errors.
```
gst-launch-1.0 videotestsrc ! "video/x-raw,width=400,height=300,framerate=30/1,format=I420" ! videoconvert ! x264enc ! "video/x-h264" ! vaapih264dec ! "video/x-raw(memory:DMABuf),format=I420" ! glupload ! glcolorconvert ! glimagesinkelement
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/990hlssink2 produces discontinuities / duplicates in output stream2021-09-24T14:37:30ZTimothy Pearsonhlssink2 produces discontinuities / duplicates in output streamWhen using hlssink2 with x264 and aac encoders in a live streaming application, VLC reports discontinuities and duplicates in the output stream. These appear on each segment change; since this is a live stream application, the segments ...When using hlssink2 with x264 and aac encoders in a live streaming application, VLC reports discontinuities and duplicates in the output stream. These appear on each segment change; since this is a live stream application, the segments are set to 1 second so the warnings are quite frequent:
```
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 0, expected 8) for PID 32
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 0
[0x7fc808c19078] ts demux error: libdvbpsi (PSI decoder): TS duplicate (received 0, expected 1) for PID 32
```
While the result appears to play OK, I don't know if frames are being duplicated on the 1 second interval, or if this is a VLC decoding issue only. The old "hlssink" sink did not generate these warnings when used with the mpegtsmux element, using an identical input stream on the same hardware.https://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.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/172vaapih264enc produces encoding errors in CBR and VBR mode for white areas at ...2021-09-24T12:23:19ZMichael Olbrichvaapih264enc produces encoding errors in CBR and VBR mode for white areas at the bottomCan be reproduced with this pipeline:
`gst-launch-1.0 videotestsrc ! imagefreeze ! video/x-raw,width=1920,height=1080 ! vaapih264enc rate-control=cbr ! avdec_h264 ! xvimagesink`
The last few rows in the bottom white rectangle blink gre...Can be reproduced with this pipeline:
`gst-launch-1.0 videotestsrc ! imagefreeze ! video/x-raw,width=1920,height=1080 ! vaapih264enc rate-control=cbr ! avdec_h264 ! xvimagesink`
The last few rows in the bottom white rectangle blink grey/white. The same happens in VBR mode, although it takes a bit before it starts.
This happens with GStreamer 1.16.0 and 1.14.x. The avdec / xvimagesink parts can be replaced. I just use those to make sure that the issue is in the encoder, not the decoder.
It seems to happen if the height is a multiple of 8 but not of 16.
Sometimes, depending on the input data and in CBR mode, the bottom 8 rows are always grey instead of white and not blinking.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/405queue2 : async-done error after seek2021-09-24T11:09:10ZDonghyeok Yangqueue2 : async-done error after seekDear All.
I have an issue about GST_ELEMENT_FLOW_ERROR in queue2.
Actually, I use dashdemux to playback for recorded file in our target environment (e.g TV).
the issue recorde file's duration is shrot(17sec) and it has multi audio str...Dear All.
I have an issue about GST_ELEMENT_FLOW_ERROR in queue2.
Actually, I use dashdemux to playback for recorded file in our target environment (e.g TV).
the issue recorde file's duration is shrot(17sec) and it has multi audio stream.
one dashdemux push all audio stream and because each audio streams are encoded as an independent mp4 file, one audio stream has one qtdemux.
it means when push EOS event, all audio path send EOS event.
the issue is when try seek, async-done is not finished.
in this case, queue2 of non selected audio track receive EOS but src pad is not linked.
so queue2 call GST_ELEMENT_FLOW_ERROR and playbin3 cannot change status.
when I remove GST_FLOW_NOT_LINKED condition, issue is not happened.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/620audiobasesink: prerolling late with fixed latency and rtpbin -> unsynchronize...2021-09-24T13:25:08ZThomas Bluemelaudiobasesink: prerolling late with fixed latency and rtpbin -> unsynchronized outputI am having some troubles with synchronized audio output. On the receiving end, this is roughly my setup:
* Pipeline with `gst_pipeline_set_latency`, let's say 2000ms
* `gst_pipeline_use_clock` on sender and receiver is using a network ...I am having some troubles with synchronized audio output. On the receiving end, this is roughly my setup:
* Pipeline with `gst_pipeline_set_latency`, let's say 2000ms
* `gst_pipeline_use_clock` on sender and receiver is using a network clock (synchronized)
* rtpbin/rtpjitterbuffer with `latency` property set to 780ms, `ntp-sync` TRUE and `ntp-time-source` set to `clock-time`.
* alsasink
Let's say I have two different devices:
* Device A has 10 alsa periods 100ms each (total 1000ms)
* Device B has 10 alsa periods 20ms each (total 200ms)
Let's say the sending side is a little delayed and sends out the first buffer (though it doesn't matter whether the delay is massive or almost 0). rtpjitterbuffer waits at least 780ms (its own `latency`) before pushing out the first buffer. Let's say it took 5 seconds for the first buffer to arrive. It's timestamp is now e.g. 00:00:05.940 (rtpjitterbuffer added in it's latency of 780ms). The deadline timer now triggers it to be pushed downstream to alsasink. Since it is the first buffer, alsasink calls `gst_audio_base_sink_sync_latency`, where it waits for the upstream latency (which happens to be rtpjitterbuffer's latency, and starting 1.16 + `processing-deadline`), so 780ms. But because the pipeline was started 5+ seconds ago, it will always be a late preroll.
Shouldn't the preroll not only take the buffer's timestamp into account, but also wait until total latency - upstream latency, so it doesn't start writing way too early? Right now it waits the same amount of time on both devices, and since it's most likely a late preroll, not at all. But it also seems that once `gst_audio_base_sink_sync_latency` returned, on device B it wouldn't wait 800ms longer and write into the ringbuffer at the wrong locations.
The end result is that both devices play totally out of sync initially, but eventually clock skew adjustments bring them in sync again. But when the delta is so big, it's pretty awful quality and countless clock skew corrections.
~~It seems that `gst_audio_base_sink_sync_latency` should not be waiting merely until the upstream latency expired, but rather "fixed latency - upstream latency", and on top of that also account for the timestamp of the first packet? Or does `gst_audio_base_sink_render` lack a wait on the clock if the timestamp is too far out (which would only be hit right after prerolling or after a resync)?~~
I think part of the problem is that the first buffer tends to be tiny (e.g. 1/10) of the total alsa buffer size (all periods), and because the ringbuffer thread is started at preroll it "sucks" in as many periods as possible, but only that first small buffer was written timely enough. Then, when the next buffer comes in, the ringbuffer thread has already inserted a bunch of silence, and this all leads to a bunch of choppy audio, and the clocks are way off.
I haven't had much success getting this to work properly. It feels like audiobasesink doesn't handle this correctly, but I don't know for sure. I'd appreciate any suggestions/ideas/hints.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/619video: Stack overflow in video_orc_pack_I4202021-09-24T13:25:08ZNicolas Dufresnevideo: Stack overflow in video_orc_pack_I420This was reproduced in SabreLite (IMX.6) with kernel 5.2 rc2. It does not reproduce all the time, which made me suspicious that we call pack/unpack ORC accelerators without verifying that the pointer alignment requirement is met or that ...This was reproduced in SabreLite (IMX.6) with kernel 5.2 rc2. It does not reproduce all the time, which made me suspicious that we call pack/unpack ORC accelerators without verifying that the pointer alignment requirement is met or that the stride is large enough for the request operation.
I've seen loads of hack, where we just bump the alignment in buffer allocation, but for memory allocated by the driver, we can't really influence that, hence users having limitation must check that the required alignment is met, and fallback if not.
```
$ gdb --args gst-launch-1.0 videotestsrc ! v4l2h264enc ! fakesink
GNU gdb (GDB) Fedora 8.3-2.fc30
(gdb) r
Définition du pipeline à PAUSED...
Le pipeline est en phase de PREROLL…
Redistribution de latence…
*** stack smashing detected ***: <unknown> terminated
Thread 2 "videotestsrc0:s" received signal SIGABRT, Aborted.
[Switching to Thread 0xb5f86460 (LWP 941)]
0xb6b93200 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb6b93200 in raise () at /lib/libc.so.6
#1 0xb6b7e364 in abort () at /lib/libc.so.6
#2 0xb6bcdec8 in __libc_message () at /lib/libc.so.6
#3 0xb6c50f80 in __fortify_fail_abort () at /lib/libc.so.6
#4 0xb6c50f24 in __stack_chk_fail () at /lib/libc.so.6
#5 0xb62ac0b4 in video_orc_pack_I420
(d1=0xb5769000 <error: Cannot access memory at address 0xb5769000>, d2=0xb6cb507c <__libc_argv> "D\364\377\276\006", d3=0x0, s1=0x0, n=-1251996216) at tmp-orc.c:1259
#6 0xb5606a18 in ()
```
```
(gdb) p *gst_buffer_get_video_meta (res_buf)
$3 = {
meta = {
flags = (GST_META_FLAG_POOLED | GST_META_FLAG_LOCKED),
info = 0xb560fc08
},
buffer = 0x53c5e8 [GstBuffer],
flags = GST_VIDEO_FRAME_FLAG_NONE,
format = GST_VIDEO_FORMAT_I420,
id = 0,
width = 320,
height = 240,
n_planes = 3,
offset = {0, 76800, 96000, 0},
stride = {320, 160, 160, 0},
map = 0xb6285d78 <default_map>,
unmap = 0xb6285d60 <default_unmap>
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/403Integrate sysprof for profiling and data collection2022-11-10T09:20:53ZChristian HergertIntegrate sysprof for profiling and data collectionIn GNOME, we're working on a new initiative for platform profiling. To do this, the Sysprof project now provides a `libsysprof-capture-3.a` static library which can log a number of data types including counters, files, marks, stack trace...In GNOME, we're working on a new initiative for platform profiling. To do this, the Sysprof project now provides a `libsysprof-capture-3.a` static library which can log a number of data types including counters, files, marks, stack traces, and more.
GTK itself checks for `GTK_TRACE_FD=N` which is set by Sysprof when profiling an application. We could do the same for GStreamer using something like `GST_TRACE_FD=N`.
Doing so would allow us to correlate between compositor data, toolkit data, gstreamer pipelines, and application events all within one application.
You can find some more information about the effort in this blog post:
https://blogs.gnome.org/chergert/2019/05/30/sysprof-developments/
Also, the Initiaitve in gitlab:
https://gitlab.gnome.org/GNOME/Initiatives/issues/10https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/167vaapiencode: Rethink when to start, stop and pause the src pad task2021-09-24T12:23:18ZVíctor Manuel Jáquez Lealvaapiencode: Rethink when to start, stop and pause the src pad taskRight now the start/stop/pause of the src pad's task is a bit convoluted and leads to hacks like https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/95 (it is a hack in the sense it doesn't follow the GstVideoEncode A...Right now the start/stop/pause of the src pad's task is a bit convoluted and leads to hacks like https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/95 (it is a hack in the sense it doesn't follow the GstVideoEncode API logic).
My idea is try to mimic the v4l2 encoder strategy.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/617alsasink/audio(base)sink/audioringbuffer: clock skew due to improper accounti...2021-09-24T13:25:07ZThomas Bluemelalsasink/audio(base)sink/audioringbuffer: clock skew due to improper accounting of frames writtenI have tracked down a deficiency that can introduce incorrect clock skew due to a race condition accounting for frames/samples written vs buffered. For devices with large buffers and periods, this can cause clock skew corrections to be t...I have tracked down a deficiency that can introduce incorrect clock skew due to a race condition accounting for frames/samples written vs buffered. For devices with large buffers and periods, this can cause clock skew corrections to be triggered that normally wouldn't be necessary, especially when a period size is close to the clock skew tolerance or even greater.
When this happens, I noticed the following:
Two consecutive calls to `gst_audio_base_sink_get_time` showed in the log statement that the value of `raw` remained unchanged, while `delay` increased, resulting in backwards time. This happens when `gst_audio_sink_ring_buffer_delay` is called when `gst_alsasink_write` completed the call to `snd_pcm_writei` but the ringbuffer thread hasn't called `gst_audio_ring_buffer_advance` yet. The `segdone` field that `gst_audio_ring_buffer_samples_done` reads from isn't advanced until `gst_audio_ring_buffer_advance` is called, but `gst_alsasink_write` has written data already (e.g. a whole period) that should have been accounted for, which results in a window where the call to `gst_audio_ring_buffer_samples_done` returns less data than that actually has been written, yet the call to `gst_audio_ring_buffer_delay` returns the actual data buffered, leading to a backwards time swing. This is possible because the `GST_DELAY_SINK_LOCK` lock is released (on purpose) between these calls, otherwise it could block `gst_audio_base_sink_get_time` for way too long if no space is available to write.
The solution is actually quite simple: Account for the number of frames written immediately when they are written:
1. Add a `guint64` field to `GstAlsaSink` that tracks the number of frames written. Whenever `snd_pcm_writei` is called, while the `GST_DELAY_SINK_LOCK` is being held, add the number of frames written (assuming no error case).
2. Add a `guint64*` argument to `gst_alsasink_delay`, as well as `GstAudioSinkClass`'s `delay` virtual method (and everywhere else that implements it). In `gst_alsasink_delay`, while the `GST_DELAY_SINK_LOCK` is being held, return the last stored value from that new field. This has to be done in the same call, we cannot add a separate method for this because the information must be retrieved at the same time as `snd_pcm_delay` is called.
3. Add the same new argument to `gst_audio_sink_ring_buffer_delay` and `gst_audio_ring_buffer_delay` that end up calling the `delay` virtual method
4. Change `gst_audio_base_sink_get_time` so that it only calls `gst_audio_ring_buffer_samples_done` in the case that `gst_audio_ring_buffer_delay` didn't return a value in the new `guint64*` argument. If it did return a value, use it as `raw` and `samples`, otherwise call `gst_audio_ring_buffer_samples_done` as a fallback.
This dramatically reduces clock skew values, and eliminates many clock skew corrections I've been observing.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/984webrtcbin: "get-transceivers" signal not usable from bindings due to GArray2021-09-24T14:37:27ZSebastian Drögewebrtcbin: "get-transceivers" signal not usable from bindings due to GArraySee title. Bindings have no way of knowing what item type is used for the array.
Alternatives would be `GValueArray` (deprecated), `GST_TYPE_ARRAY` or a `GstStructure`.
CC @ystreetSee title. Bindings have no way of knowing what item type is used for the array.
Alternatives would be `GValueArray` (deprecated), `GST_TYPE_ARRAY` or a `GstStructure`.
CC @ystreet