GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-16T01:07:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/804ges: `check.gst-editing-services.check_layer_activness_gaps_it` race leading ...2022-11-16T01:07:46ZThibault Sauniertsaunier@igalia.comges: `check.gst-editing-services.check_layer_activness_gaps_it` race leading to wrong source used after commit## Command
``` bash
CK_TIMEOUT_MULTIPLIER='1.0' GST_GL_XINITTHREADS='1' GST_PLUGIN_SCANNER_1_0='/var/home/thiblahute/devel/gstreamer/gstreamer/build/subprojects/gstreamer/libs/gst/helpers/gst-plugin-scanner' GST_VALIDATE_LOGSDIR='/var/...## Command
``` bash
CK_TIMEOUT_MULTIPLIER='1.0' GST_GL_XINITTHREADS='1' GST_PLUGIN_SCANNER_1_0='/var/home/thiblahute/devel/gstreamer/gstreamer/build/subprojects/gstreamer/libs/gst/helpers/gst-plugin-scanner' GST_VALIDATE_LOGSDIR='/var/home/thiblahute/devel/gstreamer/gstreamer/build/subprojects/gst-editing-services/tests/check/check_layer_activness_gaps' GST_REGISTRY='/var/home/thiblahute/devel/gstreamer/gstreamer/build/registry.dat' GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' /var/home/thiblahute/devel/gstreamer/gstreamer/build/subprojects/gst-editing-services/tools/ges-launch-1.0 --no-interactive --set-scenario /var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-editing-services/tests/check/scenarios/check_layer_activness_gaps.scenario
```
## ges-launch-1.0 output
```
**-> Running scenario /var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-editing-services/tests/check/scenarios/check_layer_activness_gaps.scenario on pipeline gespipeline0**
Executing `add-clip` at check_layer_activness_gaps.scenario:8 (
- name=clip
- asset-id="framerate\=30/1"
- layer-priority=0
- type=GESTestClip
- pattern=blue
- duration=5000
)
⇨ Action `add-clip` at check_layer_activness_gaps.scenario:8 done 'OK' (duration: 0:00:00.005577927)
Executing `set-layer-active` at check_layer_activness_gaps.scenario:9 (
- tracks={ (string)gesvideotrack0 }
- active=false
- layer-priority=0
)
⇨ Action `set-layer-active` at check_layer_activness_gaps.scenario:9 done 'OK' (duration: 0:00:00.000018555)
Executing `pause` at check_layer_activness_gaps.scenario:11 ( )
⇨ Action `pause` at check_layer_activness_gaps.scenario:11 done 'ASYNC' (duration: 0:00:00.079797039)
Executing `check-property` at check_layer_activness_gaps.scenario:14 (
- target-element-factory-name=videotestsrc
- property-name=pattern
- property-value="100\%\ Black"
)
⇨ Action `check-property` at check_layer_activness_gaps.scenario:14 done 'OK' (duration: 0:00:00.000055063)
Executing `check-property` at check_layer_activness_gaps.scenario:15 (
- target-element-factory-name=audiotestsrc
- property-name=wave
- property-value=Sine
)
⇨ Action `check-property` at check_layer_activness_gaps.scenario:15 done 'OK' (duration: 0:00:00.000026289)
Executing `set-layer-active` at check_layer_activness_gaps.scenario:17 (
- tracks={ (string)gesvideotrack0 }
- active=true
- layer-priority=0
)
⇨ Action `set-layer-active` at check_layer_activness_gaps.scenario:17 done 'OK' (duration: 0:00:00.000057798)
Executing `set-layer-active` at check_layer_activness_gaps.scenario:18 (
- tracks={ (string)gesaudiotrack0 }
- active=false
- layer-priority=0
)
⇨ Action `set-layer-active` at check_layer_activness_gaps.scenario:18 done 'OK' (duration: 0:00:00.000016211)
Executing `commit` at check_layer_activness_gaps.scenario:19 ( )
⇨ Action `commit` at check_layer_activness_gaps.scenario:19 done 'ASYNC' (duration: 0:00:00.019953054)
Executing `check-property` at check_layer_activness_gaps.scenario:22 (
- target-element-factory-name=videotestsrc
- property-name=pattern
- property-value=Blue
)
0:00:00.329193173 �[34m2255451�[00m 0x1c0ee30 �[31;01mERROR �[00m �[00m validate gst-validate-reporter.c:198:gst_validate_report_valist:�[00m <check_layer_activness_gaps.scenario> 3068 (critical) : scenario: The execution of an action did not properly happen :
> check_layer_activness_gaps.scenario:22
22 | check-property, target-element-factory-name=videotestsrc, property-name=pattern, property-value="Blue"
>
> <src>::pattern expected value: '(gchararray)Blue' different than observed: '(gchararray)"100\%\ Black"'
> Error:
(null)> > check_layer_activness_gaps.scenario:22
(null)> 22 | check-property, target-element-factory-name=videotestsrc, property-name=pattern, property-value="Blue"
(null)> >
(null)> > <src>::pattern expected value: '(gchararray)Blue' different than observed: '(gchararray)"100\%\ Black"'
⇨ Action `check-property` at check_layer_activness_gaps.scenario:22 done 'ERROR(reported)' (duration: 0:00:00.011187863)
Executing `check-property` at check_layer_activness_gaps.scenario:23 (
- target-element-factory-name=audiotestsrc
- property-name=wave
- property-value=Silence
)
⇨ Action `check-property` at check_layer_activness_gaps.scenario:23 done 'OK' (duration: 0:00:00.000038071)
Executing `stop` at check_layer_activness_gaps.scenario:25 ( )
⇨ Action `stop` at check_layer_activness_gaps.scenario:25 done 'OK' (duration: 0:00:00.000013796)
check_layer_activness_gaps.scenario --> State change request NULL, quitting application
warning : Buffer didn't have expected DISCONT flag
Detected on <nlesource8:src>
Description : Buffers after SEGMENT and FLUSH must have a DISCONT flag
issue : FLUSH_START events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <nlesource5:src>
Detected on <video_nlecomposition0:src>
Detected on <GESAudioTestSource:nlesource3:src>
Detected on <audio_nlecomposition1:src>
Detected on <nlesource8:src>
Detected on <GESVideoTestSource:nlesource2:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
warning : received an unexpected flush stop event
Detected on <GESAudioTestSource:nlesource3:src>
Detected on <nlesource5:src>
Detected on <nlesource8:src>
Detected on <GESVideoTestSource:nlesource2:src>
issue : SEGMENT events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <audio_nlecomposition1:src>
Detected on <audio_restriction_capsfilter2:sink, audio_restriction_capsfilter2:src>
Detected on <gesaudiotrack0:src>
Detected on <gestimeline0:track_0x220c440_src>
Detected on <tee1:sink, tee1:src_0, internal-sinks:audio_sink>
Detected on <audiotee:sink, audiotee:src_0, streamsynchronizer0:sink_1, streamsynchronizer0:src_1, abin:sink>
Detected on <aqueue:sink, aqueue:src, aconv:sink>
Detected on <conv:sink, conv:src, resample:sink, resample:src, volume:sink, volume:src>
Detected on <aconv:src>
Detected on <fakeaudiosink0:sink>
Detected on <sink:sink>
Detected on <video_nlecomposition0:src>
Detected on <video_restriction_capsfilter0:sink, video_restriction_capsfilter0:src>
Detected on <gesvideotrack0:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
critical : The execution of an action did not properly happen
Detected on <check_layer_activness_gaps.scenario>
Details :
> check_layer_activness_gaps.scenario:22
22 | check-property, target-element-factory-name=videotestsrc, property-name=pattern, property-value="Blue"
>
> <src>::pattern expected value: '(gchararray)Blue' different than observed: '(gchararray)"100\%\ Black"'
dotfile : /var/home/thiblahute/devel/gstreamer/gstreamer/build/subprojects/gst-integration-testsuites/logs/9/check/gst-editing-services/check_layer_activness_gaps_it9.pipelines_dot_files/0:00:00.159441881-validate-report-critical-on-check_layer_activness_gaps.scenario-scenario::execution-error.dot
**Got criticals. Return value set to 18**:
* critical error
> check_layer_activness_gaps.scenario:22
22 | check-property, target-element-factory-name=videotestsrc, property-name=pattern, property-value="Blue"
>
> <src>::pattern expected value: '(gchararray)Blue' different than observed: '(gchararray)"100\%\ Black"'
Issues found: 5
```
**You can mark the issues as 'known' by adding the following lines to the list of known issues**
``` python
"FIXME 'check.gst-editing-services.check_layer_activness_gaps_it9' issues [REPORT A BUG in https://gitlab.freedesktop.org/gstreamer/ or use a proper bug description]": {
"tests": [
"check.gst-editing-services.check_layer_activness_gaps_it9"
],
"issues": [
{
'returncode': 18,
'sometimes': True,
},
{
"issue-id": "scenario::execution-error",
"summary": "The execution of an action did not properly happen",
"level": "critical",
"detected-on": "check_layer_activness_gaps.scenario",
# "details": "\n> check_layer_activness_gaps.scenario:22\n 22 | check-property, target-element-factory-name=videotestsrc, property-name=pattern, property-value="Blue"\n >\n > <src>::pattern expected value: '(gchararray)Blue' different than observed: '(gchararray)"100\%\ Black"'",
},
],
},
```
**Duration**: 0.41796231269836426https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1535vah264dec + videoconvert is slow2022-11-15T13:35:00ZEric Knappvah264dec + videoconvert is slowConverting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline wi...Converting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline with vaapih264dec or vapostproc is much faster. I tried converting to multiple formats and they were all slow when vah264dec was paired with videoconvert. Logs do not show any issues.
#### Setup
- **Operating System:** Ubuntu 20.04.5
- **CPU:** i7-6700
- **GStreamer Version:** Main branch
SLOW:
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vaapih264dec):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vaapih264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vapostproc):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! vapostproc ! 'video/x-raw,format=UYVY' ! fakesink`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1572gstreamer1.0-plugins-bad gstwebrtcbin rtprtxsend using "max-size-time" instea...2022-11-15T12:43:12ZKanstantsin Shabalouskigstreamer1.0-plugins-bad gstwebrtcbin rtprtxsend using "max-size-time" instead of "max-size-packets" causes problemsVersion gstreamer: 1.20.3
When try to change in file: `ext/webrtc/gstwebrtcbin.c`
from
` g_object_set (rtx, "max-size-packets", 500, NULL);`
to
` g_object_set (rtx, "max-size-time", 500, NULL);`
I see a lot of messages like:...Version gstreamer: 1.20.3
When try to change in file: `ext/webrtc/gstwebrtcbin.c`
from
` g_object_set (rtx, "max-size-packets", 500, NULL);`
to
` g_object_set (rtx, "max-size-time", 500, NULL);`
I see a lot of messages like:
`GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion `denom > 0' failed`
As I've found it is related to that:
In gstreamer1.0-plugins-good in the file `gst/rtpmanager/gstrtprtxsend.c `
when call code:
```
while (gst_rtp_rtx_send_get_ts_diff (data) > rtx->max_size_time)
g_sequence_remove (g_sequence_get_begin_iter (data->queue));
```
when we try to get time with `gst_rtp_rtx_send_get_ts_diff` the value **data->clock_rate equal** to 0. which leads to the message:
`GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion `denom > 0' failed`https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/239Internationalization support is broken in Windows2022-11-14T10:22:40ZAndoni Morales AlastrueyInternationalization support is broken in WindowsAt some point we switched from gettext to proxy-libintl as the recipe to build libintl-8.dll, providing the implementation for all gettext functions. proxy-libintl tries to proxy itself by dynamically loading libintl-8.dll (itself) to lo...At some point we switched from gettext to proxy-libintl as the recipe to build libintl-8.dll, providing the implementation for all gettext functions. proxy-libintl tries to proxy itself by dynamically loading libintl-8.dll (itself) to look for the gettext implementation. This ends up using the dummy implementation and no text strings are translated. We should go back to build gettext.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1556kmssink: typo in list of well-known non-square-pixel ratios2022-11-14T09:58:38ZMatthijs Kooijmankmssink: typo in list of well-known non-square-pixel ratios### Describe your issue
The [`gst_video_calculate_device_ratio`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmsutils.c#L230) function calculates the non-square-pixel ratio for an...### Describe your issue
The [`gst_video_calculate_device_ratio`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmsutils.c#L230) function calculates the non-square-pixel ratio for an output, and then rounds it to the nearest ratio from a list of well-known ratios. This list contains common ratios for things like using a 4:3 resolution on a 16:9 (physical size) screen.
One of the items in this list seems to have the wrong value based on the comment, probably incorrectly calculated.
Here's the list:
```c
static const gint device_par_map[][2] = {
{1, 1}, /* regular screen */
{16, 15}, /* PAL TV */
{11, 10}, /* 525 line Rec.601 video */
{54, 59}, /* 625 line Rec.601 video */
{64, 45}, /* 1280x1024 on 16:9 display */
{5, 3}, /* 1280x1024 on 4:3 display */
{4, 3} /* 800x600 on 16:9 display */
};
```
According to the implementation, these ratios are calculated as "the "physical" w/h divided by the w/h in pixels of the display" or `(dev_width_mm * dev_height) / (dev_height_mm * dev_width)` but since everything is ratios, we can just substitute the ratios instead of the actual pixels and mm sizes.
Looking at "1280x1024 on 16:9 display", the resolution is 5:4, so the resulting ratio is (16×4) : (9×5) = 64:45, as shown in the list.
Looking at "800x600 on 16:9 display", the resolution is 4:3, so the resulting ratio is (16×3) : (9×4) = 48:36 = 4:3 as shown in the list.
But looking at "1280x1024 on 4:3 display", the resolution is 5:4 so the resulting ratio is (4×4) : (3×5) = 16:15, not 5:3 as shown in the list. I suspect that the value shown was calculated with the 5 and 4 swapped: (4×5) : (3×4) = 20:12 = 5:3.
I believe this is a trivial fix:
```diff
- {5, 3}, /* 1280x1024 on 4:3 display */
+ {16, 15}, /* 1280x1024 on 4:3 display */
```
I would submit a MR, but I do not have a development setup here to actually test, nor do I really know what this code impacts and how I should test it (also note that the kmssink code that processes the result of this function to compensate for non-square pixels seems broken, see #1555, also for some way to force resolutions which might be helpful to test this).
Looking at the commit history, it seems that this code was already (broken?) like this when it was first introduced in [commit 1aee6cd](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/1aee6cdc25572d856ca414940689194f54fd9054) by @vjaquez.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1568gst-transcoder-1.0 hangs at the start2022-11-13T20:26:03ZAlexandru Băluțgst-transcoder-1.0 hangs at the startThe following command hangs while it works just fine with other source files:
```
$ gst-transcoder-1.0 sample-2001.05.15_04-58-01.dv x999.mov jpeg-raw-in-qt.gep
```
Using a recent build of GStreamer main.
[sample-2001.05.15_04-58-01....The following command hangs while it works just fine with other source files:
```
$ gst-transcoder-1.0 sample-2001.05.15_04-58-01.dv x999.mov jpeg-raw-in-qt.gep
```
Using a recent build of GStreamer main.
[sample-2001.05.15_04-58-01.dv](/uploads/622cfb497a895b20edef3feb8ebc6045/sample-2001.05.15_04-58-01.dv)
https://gitlab.gnome.org/GNOME/pitivi/-/blob/1db8f83fa73a399ab05c4a4d4b0ab7665869acbd/data/gstpresets/jpeg-raw-in-qt.gephttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1566low FPS on certain interfaces (Ethernet vs. WiFi) and certain WiFi routers wh...2022-11-11T18:48:41ZMax Krieglederlow FPS on certain interfaces (Ethernet vs. WiFi) and certain WiFi routers when streaming video via UDPI am trying to stream video from a raspberry pi 4 employing a raspberry pi camera module 2 to a laptop and I am encountering difficulties depending on the interface (ethernet or WiFi) but also the router I am using.
On the raspberry pi ...I am trying to stream video from a raspberry pi 4 employing a raspberry pi camera module 2 to a laptop and I am encountering difficulties depending on the interface (ethernet or WiFi) but also the router I am using.
On the raspberry pi 4 (bullseye, gstreamer 1.18.4) I am running following command
`gst-launch-1.0 libcamerasrc ! video/x-raw, width=1280, height=720 ! videoconvert ! jpegenc ! rtpjpegpay ! udpsink host=192.168.0.100 port=5200`
On the laptop (bullseye, gstreamer 1.18.4) I am accessing the stream as follows
`gst-launch-1.0 -v udpsrc port=5200 ! application/x-rtp, media=video, clock-rate=90000, payload=96 ! rtpjpegdepay ! jpegdec ! videoconvert ! queue ! fpsdisplaysink`
When both devices are connected over WiFi to an access point, which supports WiFi 5 (TP-Link Archer MR600), I get very smooth video on the laptop with 30 FPS and almost no dropped frames. However, when connecting both devices over WiFi 6 (TP-Link Archer AX50) there are still no dropped frames but the frame rate is 1-3 FPS. Manually lowering the WiFi standard on this router doesn't solve the problem. Also, when connecting both devices over Ethernet the frame rate is again in the range 1-3 FPS, but only connecting the laptop over Ethernet and the raspberry over WiFi seems to work with 30 FPS.
When streaming I have collected the incoming packets with tcpdump
`sudo tcpdump -i wlp0s20f3 -s 0 -w dump.pcap host 192.168.0.201 and udp`
and then played them back with
`gst-launch-1.0 filesrc location=dump.pcap ! pcapparse ! application/x-rtp, media=video, clock-rate=90000, payload=96 ! rtpjpegdepay ! jpegdec ! videoconvert ! queue ! fpsdisplaysink`
showing the original stream in either of the above described cases perfectly as expected. I simply noticed that for the WiFi 6 case and Ethernet case there are slightly more rendered frames for the same time period compared to the WiFi 5 case.
To me it looks like that the video stream is sent correctly, but for some reason cannot be rendered by gstreamer live but only after capturing it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1564Failed to import rtmp library file in Android environment2022-11-11T06:50:58ZhncllyyFailed to import rtmp library file in Android environmentI have introduced the flv library file in the project and it can run well, but when I import the rtmp library file, the following error message appears!
librtmp.a(rtmp.o):rtmp.c:function RTMP_TLS_Init: error: undefined reference to 'OPE...I have introduced the flv library file in the project and it can run well, but when I import the rtmp library file, the following error message appears!
librtmp.a(rtmp.o):rtmp.c:function RTMP_TLS_Init: error: undefined reference to 'OPENSSL_init_ssl'
librtmp.a(rtmp.o):rtmp.c:function RTMP_TLS_Init: error: undefined reference to 'OPENSSL_init_crypto'
....
gstreamer version contains 1.18.5, 1.20.4
who can help me, thanks!!!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1119macos: gst-inspect is very slow for the first time2022-11-10T19:39:19ZStéphane Cerveauscerveau@igalia.commacos: gst-inspect is very slow for the first time### Describe your issue
In the devenv, after a build, gst-inspect-1.0 is very slow (about 30 seconds) on a M1 with SSD.
#### Expected Behavior
To be as fast as a desktop linux such as i7/SSD
#### Observed Behavior
it spents a lot of ti...### Describe your issue
In the devenv, after a build, gst-inspect-1.0 is very slow (about 30 seconds) on a M1 with SSD.
#### Expected Behavior
To be as fast as a desktop linux such as i7/SSD
#### Observed Behavior
it spents a lot of time scanning
#### Setup
- **Operating System:** MacOs Monterey
- **Device:** Computer
- **GStreamer Version:** 1.21
- **Command line:** gst-inspect-1.0
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. make a clean build
2. gst-inspect-1.0
### How reproducible is the bug?
Difficult to tell but the gap is big between a macbook and a linux laptop
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
Removing the registry.dat does not help to reproduce the bug alwayshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1560Update duration and seekable for hls stream?2022-11-10T11:33:42ZNhật Nguyễn TrọngUpdate duration and seekable for hls stream?Hi, I'm trying to play an hls stream using gstreamer. First, I had an m3u8 link available and used the command:\
gst-launch-1.0 -v playbin uri="m3u8-link" \
as in the document to play it. Everything worked fine, now I want to add rewind ...Hi, I'm trying to play an hls stream using gstreamer. First, I had an m3u8 link available and used the command:\
gst-launch-1.0 -v playbin uri="m3u8-link" \
as in the document to play it. Everything worked fine, now I want to add rewind functionality on this hls stream, so I use the example "Basic tutorial 4: Time management" to implement it. But the problem is that the program returns "Could not query current duration" and "Seeking is DISABLED for this stream" results because the query gst_element_query_duration is false. After researching, I found this happens when in the content of m3u8-link there is no #EXT-X-ENDLIST tag, which means my stream is still running and updating. If the stream ends, the #EXT-X-ENDLIST tag will be added to the end of the m3u8 file, and everything will work normally again. My question is is there a way to continuously update the duration in case the stream is still running (without the #EXT-X-ENDLIST tag) so that rewind can still be performed on the hls stream? Thank!\
P/s: I can do this on the web thanks to hls.js, I want to do the same with gstreamer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1414ttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (net...2022-11-10T09:21:15ZJuergen Sachsttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (network source)### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the ...### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the command "`export GST_TTML_AUTOPLUG=1 && gst-play-1.0 http://192.168.0.252/media/.../1280x720-h264-ttml-de.mp4`"
- subtitles are visible
- Use "right"-Key to jump 10s foreward
- subtitles disappear -> error
Reproduced with GStreamer 1.16, 1.20.3 (Ubuntu 22.04.1 LTS) (and with other local GStreamer installation)
### Additional Info:
1. The problem occurs
- with TTML subtitles from network source.
- with playbin2 and playbin3 (`gst-play-1.0 --use-playbin3 ...`)
2. The problem does **not** occur
- MP4 container with **SRT** subtitles (1280x720-h264-srt-de.mp4)
- MP4 container with TTML subtitles from **local** file source (`gst-play-1.0 file://.../1280x720-h264-ttml-de.mp4`)
Attachments:
- test streams:
- [1280x720-h264-ttml-de](/uploads/893367b5cabd76f7e370da26bc6499fa/1280x720-h264-ttml-de.mp4)
- [1280x720-h264-srt-de](/uploads/813c9b4844258454cec083d03dbcb99d/1280x720-h264-srt-de.mp4)
- pipelines:
- [ttml-http](/uploads/fae3e6b997f86aa9bf4ab511b325623e/ttml-http.png)
- [ttmp-file](/uploads/09a4274ab8b069878cfe65618f67cecf/ttmp-file.png)
- [srt-http](/uploads/b34da057322059d20018449b6b95e4ec/srt-http.png)
-----
I'm not sure if this is really a TTML problem. The difference between http an file is also pull- vs push-mode in upstream parts of pipeline (source -> qtdemux). So also may be typefinder or qtdemux is involved.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1412decodebin2 sometimes deadlocks on EOS from an HLS stream2022-11-10T09:21:15ZAlexander Slobodeniukdecodebin2 sometimes deadlocks on EOS from an HLS stream**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&a...**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&ad.cust_params=vdm%3Dlive%26chan%3Dabcnews%26plt%3Dott%26refDomain%3Dhttps%3A%2F%2Fabcnews.go.com%26vps%3D640x480%26ppid%3DVENUE_ID%26beacTyp%3Dssai%26sp%3Dvdms%26ait%3Dssai%26var%3D16x9&ad.correlator=TIMESTAMP&ad.ppid=VENUE_ID&ad.cmsid=2494279&ad.networkID=21783347309&ad.vast3=1&ad=abcnews_live&ad.vid=CHANNEL_ID&ad.description_url=https%3A%2F%2Fabcnews.go.com&ad.idtype=rida&ad.adUnit=/abc-news/rockbot/ott&ad.us_privacy=0"`
2. it may require to wait for a while, around 30 minutes. An error occurs after the advertisement finishes playing (but not always). Playback just stops and doesn't recover anymore.
---
**Error analysis**
connecting with gdb shows next deadlock:
Thread 18 is waiting for a "cleanup thread to finish", and blocks the pad 0x7f05c0017a00 (frame 27,28)
```
Thread 18 (Thread 0x7f063d7fa700 (LWP 2045419)):
#0 __pthread_clockjoin_ex (threadid=139662538569472, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
#1 0x00007f06489fd54b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f06489d9faf in g_thread_join () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f0647788a4a in gst_decode_chain_start_free_hidden_groups_thread (chain=0x7f0640005690) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3743
#4 0x00007f064778a7bd in drain_and_switch_chains (chain=0x7f0640005690, drainpad=0x0, last_group=0x7f063d7f8420, drained=0x7f063d7f8428, switched=0x7f063d7f8424) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4223
#5 0x00007f064778c9b5 in gst_decode_bin_expose (dbin=0x7f0638040090) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4730
--Type <RET> for more, q to quit, c to continue without paging--
#6 0x00007f064778aceb in gst_decode_pad_handle_eos (pad=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4298
#7 0x00007f064778dc0a in source_pad_event_probe (pad=0x7f0638040350, info=0x7f063d7f8770, user_data=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:5034
#8 0x00007f0648c4b3f8 in probe_hook_marshal (hook=0x7f0600025ac0, data=0x7f063d7f8640) at ../subprojects/gstreamer/gst/gstpad.c:3664
#9 0x00007f064899f996 in g_hook_list_marshal () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f0648c4bb23 in do_probe_callbacks (pad=0x7f0638040350, info=0x7f063d7f8770, defaultval=GST_FLOW_OK) at ../subprojects/gstreamer/gst/gstpad.c:3848
#11 0x00007f0648c5252a in gst_pad_push_event_unchecked (pad=0x7f0638040350, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5509
#12 0x00007f0648c4c545 in push_sticky (pad=0x7f0638040350, ev=0x7f063d7f8860, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#13 0x00007f0648c41a78 in events_foreach (pad=0x7f0638040350, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:608
#14 0x00007f0648c4c90e in check_sticky (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#15 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#16 0x00007f0648c49cc1 in event_forward_func (pad=0x7f0638040350, data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3125
#17 0x00007f0648c49aab in gst_pad_forward (pad=0x7f060c010360, forward=0x7f0648c49b96 <event_forward_func>, user_data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3079
#18 0x00007f0648c49e80 in gst_pad_event_default (pad=0x7f060c010360, parent=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:3176
#19 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f060c010360, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
#20 0x00007f0648c5270e in gst_pad_push_event_unchecked (pad=0x7f05c0017310, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5544
#21 0x00007f0648c4c545 in push_sticky (pad=0x7f05c0017310, ev=0x7f063d7f8ca0, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#22 0x00007f0648c41a78 in events_foreach (pad=0x7f05c0017310, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:608
#23 0x00007f0648c4c90e in check_sticky (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#24 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#25 0x00007f0648d70421 in gst_video_decoder_push_event (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1119
#26 0x00007f0648d723e9 in gst_video_decoder_sink_event_default (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1655
#27 0x00007f0648d725b5 in gst_video_decoder_sink_event (pad=0x7f05c0017a00, parent=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1691
#28 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f05c0017a00, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
```
Meanwhile the cleanup thread is blocked trying to deactivate this pad 0x7f05c0017a00
```
Thread 34 (Thread 0x7f05b7fff700 (LWP 2045448)):
#0 __lll_lock_wait (futex=futex@entry=0x7f0620004140, private=0) at lowlevellock.c:52
#1 0x00007f0648507131 in __GI___pthread_mutex_lock (mutex=0x7f0620004140) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007f0648c42f0f in post_activate (pad=0x7f05c0017a00, new_mode=GST_PAD_MODE_NONE) at ../subprojects/gstreamer/gst/gstpad.c:1045
#3 0x00007f0648c4376e in activate_mode_internal (pad=0x7f05c0017a00, parent=0x7f0620011a00, mode=GST_PAD_MODE_PUSH, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1223
#4 0x00007f0648c432df in gst_pad_set_active (pad=0x7f05c0017a00, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1114
#5 0x00007f0648c1fdb0 in activate_pads (vpad=0x7f05b7ffe960, ret=0x7f05b7ffe9c0, active=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3171
#6 0x00007f0648c3617b in gst_iterator_fold (it=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, ret=0x7f05b7ffe9c0, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstiterator.c:617
#7 0x00007f0648c1fe57 in iterator_activate_fold_with_resync (iter=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3195
#8 0x00007f0648c1ff9d in gst_element_pads_activate (element=0x7f0620011a00, active=0) at ../subprojects/gstreamer/gst/gstelement.c:3240
#9 0x00007f0648c2029c in gst_element_change_state_func (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3305
#10 0x00007f0648d77c04 in gst_video_decoder_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:2878
#11 0x00007f0648c1f8a8 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3083
#12 0x00007f0648c1eddc in gst_element_continue_state (element=0x7f0620011a00, ret=GST_STATE_CHANGE_SUCCESS) at ../subprojects/gstreamer/gst/gstelement.c:2791
#13 0x00007f0648c1fbd2 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../subprojects/gstreamer/gst/gstelement.c:3122
#14 0x00007f0648c1f632 in gst_element_set_state_func (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:3037
#15 0x00007f0648c1f22d in gst_element_set_state (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2938
#16 0x00007f06477881ea in gst_decode_chain_free_internal (chain=0x7f05c036a1b0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3509
#17 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0614002400, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#18 0x00007f0647787aff in gst_decode_chain_free_internal (chain=0x7f06081c46c0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3386
#19 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0600422450, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#20 0x00007f064778894e in gst_decode_group_free (group=0x7f0600422450) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3681
#21 0x00007f06477889a6 in gst_decode_chain_free_hidden_groups (old_groups=0x7f063800f780 = {...}) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3723
#22 0x00007f06489d9ad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007f0648504609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007f06486dc133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
So,
- thread 18 blocks the pad 0x7f05c0017a00 (src pad of avdec_h264) and waits for the thread 34 to finish.
- thread 34 blocks trying to deactivate this pad 0x7f05c0017a00.
**Hipothesis about the root cause**
I was tracing the error and from what I've seen, it seems that handling EOS have walked an unexpected path:
- First **gst_decode_pad_handle_eos**() steps into **drain_and_switch_chains**() that switches the active decoding group to the next one and at this moment things seem to go well, the decoder we are blocking is now a part of an "old grop", that have been hidden and is going to be freed in another thread.
- Then it steps into **gst_decode_bin_expose**(), because it thinks that the new active group has "deadend" chains inside. The chains contain just a tsdemux and parsers inside.
So, **gst_decode_bin_expose**() starts to hide and free the "new"(not anymore) active group too, and at this moment deadlocks: it has to wait for a cleanup thread that it blocks.
So, as I suppose there's unexpected code path:
1. **gst_decode_pad_handle_eos**() --> **drain_and_switch_chains**() , it launches a cleanup thread for the group that was active (and blocks the thread therefore). This part is ok.
2. **gst_decode_pad_handle_eos**() --> **gst_decode_bin_expose**(). Here the code decides to free the next group too. And this can't not to lead to the deadlock, because it has to wait for the cleanup thread first.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1390urisourcebin: Download-buffering trashes on fast network2022-11-10T09:21:15ZBastien Noceraurisourcebin: Download-buffering trashes on fast networkWhen download-buffering is enabled in playbin (through the `download` flag), accessing videos through HTTP will download the video as fast as possible, and write it to a local cache.
Unfortunately that means that it will try to download...When download-buffering is enabled in playbin (through the `download` flag), accessing videos through HTTP will download the video as fast as possible, and write it to a local cache.
Unfortunately that means that it will try to download hundreds of megs of data from local DLNA server, with the local cache being slow enough that this will cause performance problems until the download has finished. Ideally, `urisourcebin`/`downloadbuffer` would know how fast the disk and the network are so it can throttle its own download speed.
See https://gitlab.gnome.org/GNOME/totem/-/issues/496https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1365rtmpsrc bus error on Mac OSX2022-11-10T09:21:15ZScott Fairbairnrtmpsrc bus error on Mac OSX### Describe your issue
On Mac OSX, in both version 18 and 20 of gstreamer, the rtmpsrc element will not process the stream.
Instead, it gives a bus error.
If the same stream is pulled in by ffmpeg, it works.
If the same syntax is used...### Describe your issue
On Mac OSX, in both version 18 and 20 of gstreamer, the rtmpsrc element will not process the stream.
Instead, it gives a bus error.
If the same stream is pulled in by ffmpeg, it works.
If the same syntax is used by gstreamer under Linux, it works.
But under OSX, rtmpsrc always generates a bus error.
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
#### Expected Behavior
<!-- What did you expect to happen -->
I expected it to read the rtmp source and proceed without a bus error.
#### Observed Behavior
<!-- What actually happened -->
```
gst-launch-1.0 rtmpsrc location=rtmp://127.0.0.1:1935/live/whatever ! fakesink
Setting pipeline to PAUSED ...
[1] 5798 bus error gst-launch-1.0 rtmpsrc location=rtmp://127.0.0.1:1935/live/whatever
```
#### Setup
- **Operating System: Mac OSX Monterey **
- **Device:** Computer <!-- Delete as appropriate !-->
- **GStreamer Version: 18 and 20 exhibits the same behavior **
- **Command line:**
The RTMP stream is sourced by an NGINX server, but we've tried pulling from other services, including CDNs, no difference.
Example..
```
gst-launch-1.0 rtmpsrc location=rtmp://192.168.64.9:1935/live/whatever
```
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
Have an RTMP source.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
We've tried every known combination, including live=1 trailing the rtmp uri, no difference.
We've tried versions 18 and 20.
We've uninstalled everything relating to gstreamer from the machine, reinstalled 20 clean from the site, no difference.
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1303Dynamic removing webrtcbin from GstTee cause total pipeline paused2022-11-10T09:21:14ZZhuChaselDynamic removing webrtcbin from GstTee cause total pipeline pausedI use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipelin...I use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipeline.
I even use GST_PAD_PROBE_TYPE_IDLE to unlink teepad using gst_pad_unlink before removing webrtcbin, code like,
gst_pad_add_probe(sink->teepad, GST_PAD_PROBE_TYPE_IDLE, unlink_cb, sink, (GDestroyNotify)g_free);
But I can still produce pipeline block, queue1 paused. I dig into the source code, when peer(chrome) leaves, I find teepad change to GST_FLOW_FLUSHING(-2) state even without removing webrtcbin from pipeline, I think changing to GST_FLOW_FLUSHING state is inevitable. Below is the state related log:
tee gsttee.c:940:gst_tee_handle_data:<videotee:src_4> Starting to push buffer 0000027DC865E000
0:00:03.219030000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4860:gst_pad_push_data:<videotee:src_4> error pushing events, return flushing
0:00:03.219759000 9820 0000027DC5905800 INFO tee gsttee.c:945:gst_tee_handle_data:<videotee:src_4> Pushing item 0000027DC865E000 yielded result flushing pad src_4
0:00:03.220583000 9820 0000027DC5905800 INFO tee gsttee.c:1013:gst_tee_handle_data:<videotee> received error flushing
0:00:03.222496000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4468:gst_pad_chain_data_unchecked:<videotee> chainfunc return2 queue videotee return -2 funcname gst_tee_chain pad sink
0:00:03.223200000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<videotee:sink> called chainfunction &gst_tee_chain with buffer 0000027DC865E000, returned flushing
0:00:03.223904000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<videotee> chainfunc return queue videotee pad sink return -2
0:00:03.227789000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<caps:sink> called chainfunction &gst_base_transform_chain with buffer 0000027DC865E000, returned flushing
0:00:03.228397000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.228885000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4500:gst_pad_chain_data_unchecked:<caps:sink> called chainlistfunction &gst_pad_chain_list_default, returned flushing ret -2
0:00:03.229151000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.229579000 9820 0000027DC5905800 INFO task gsttask.c:733:gst_task_set_state_unlocked:<queuebb:src> Changing task 0000027DC5907290 to state 2
0:00:03.230532000 9820 0000027DC5905800 INFO queue_dataflow gstqueue.c:1660:gst_queue_loop:<queuebb> pause task, reason: flushing
0:00:03.231669000 9820 0000027DC5905800 INFO task gsttask.c:369:gst_task_func:<queuebb:src> Task 0000027DC5907290 going to paused
from function gst_tee_handle_data,
while (pads) {
GstPad *pad;
/* stop pushing more buffers when we have a fatal error */
if (G_UNLIKELY (ret != GST_FLOW_OK && ret != GST_FLOW_NOT_LINKED))
goto error;
pads = g_list_next (pads);
}
if one pad is not OK, then all pads will be affected. How about move goto error out? So, what can I do to dynamically remove webrtcbin from tee without affect other webrtcbin? Please advise.
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1299souphttpsrc unable to parse response2022-11-10T09:21:14ZSzymon Mikuliczsouphttpsrc unable to parse response### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse respo...### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse response"<br>
With proxy OFF: Crash (SIGABRT)
#### Setup
- **Operating System:** Fedora 36
- **Device:** Computer
- **GStreamer Version:** 1.20
### Steps to reproduce the bug
`gst-launch-1.0 -v souphttpsrc method='get' location='https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3' ! decodebin ! audioconvert ! autoaudiosink`
### How reproducible is the bug?
Always
### Additional Information
Logs attached for proxy/noproxy cases
[gst_proxy.log](/uploads/e42233bfc73b4c7190b6bd3aa4544bdc/gst_proxy.log)
[gst_noproxy.log](/uploads/5714bd0016800ac61408fb1f24fc49ab/gst_noproxy.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1274rtph264pay: delta-unit flag set on non-delta frames.2022-11-10T09:21:14ZPatricia Muscalurtph264pay: delta-unit flag set on non-delta frames.Problem:
rtph264pay sets a delta unit flag on non-delta buffers, when config-interval is set. Only SPS is not marked as delta-unit.
The provided unit test exposes the problem:
[rtph264pay-delta-unit-test-check.patch](/uploads/8378fc4cd...Problem:
rtph264pay sets a delta unit flag on non-delta buffers, when config-interval is set. Only SPS is not marked as delta-unit.
The provided unit test exposes the problem:
[rtph264pay-delta-unit-test-check.patch](/uploads/8378fc4cdc6eeaae35b5a03698a85822/rtph264pay-delta-unit-test-check.patch)
Steps to reproduce:
GST_DEBUG=check:5 GST_CHEKS=test_rtph264pay_avc_delta_unit_check meson test -v -C build --suite gst-plugins-good elements_rtph264
Notice, the following debug output from the test:
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=7, delta_unit=0
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=8, delta_unit=1
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=5, delta_unit=1
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=7, delta_unit=0
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=8, delta_unit=1
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=5, delta_unit=1
DEBUG check rtph264.c:1411:test_rtph264pay_avc_delta_unit_check: nal_type=1, delta_unit=1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1273vaapi: VP8 videos played as grayscale and compressed on left when vaapi is in...2022-11-10T09:21:14ZSebastienvaapi: VP8 videos played as grayscale and compressed on left when vaapi is installedThe issue has been reported on https://launchpad.net/bugs/1978153 using gstreamer 1.20.1 stack
Example of video (screencast from GNOME)
https://bugs.launchpad.net/ubuntu/+source/gstreamer-vaapi/+bug/1978153/+attachment/5596047/+files/Sc...The issue has been reported on https://launchpad.net/bugs/1978153 using gstreamer 1.20.1 stack
Example of video (screencast from GNOME)
https://bugs.launchpad.net/ubuntu/+source/gstreamer-vaapi/+bug/1978153/+attachment/5596047/+files/Screencast%20from%2009-06-2022%2020%3A40%3A36.webm
Screenshot showing the issue
https://launchpadlibrarian.net/606292186/Screenshot%20from%202022-06-10%2005-51-07.png
Using
$ gst-play-1.0 --videosink="glsinkbin sink=gtkglsink" video.webm
shows the same issue than totem
The video plays fine if gstreamer1.0-vaapi is uninstalled.
Trying gstreamer1.0-vaapi 1.20.2 doesn't resolve ithttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1260GstGLColorConvert ignores color range, transfer function and primaries2022-11-10T09:21:14ZSebastian WickGstGLColorConvert ignores color range, transfer function and primaries`GstGLColorConvert` only converts from YUV to RGB (or the other way around) and chooses the color model matrix (`GstVideoColorMatrix`) to be either `bt709` or `bt601`. Any color conversion where the in and out colorimetry have different ...`GstGLColorConvert` only converts from YUV to RGB (or the other way around) and chooses the color model matrix (`GstVideoColorMatrix`) to be either `bt709` or `bt601`. Any color conversion where the in and out colorimetry have different color range, transfer function or primaries is broken. Any color conversion which has a color model matrix other than `bt709` and `bt601` is broken.
`GstGLColorConvert` however claims to support all those conversions which is clearly wrong. Constraining the caps however will result in pipelines which worked before (even though with wrong colors) to stop working at all. The only sensible way to fix this is to implement correct and exhaustive color conversions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1239Memory leak in main (1.21), FLAC module suspected2022-11-10T09:21:13ZLászló KárolyiMemory leak in main (1.21), FLAC module suspectedFor the record:
As discussed on IRC, here's a placeholder issue for a memory leak I'm experiencing with gstreamer 1.21, compiled directly from the main branch. Last commit fedb48c68fc432392d7966ea6acaa889482e09a1, on May 14 2022.
I'm u...For the record:
As discussed on IRC, here's a placeholder issue for a memory leak I'm experiencing with gstreamer 1.21, compiled directly from the main branch. Last commit fedb48c68fc432392d7966ea6acaa889482e09a1, on May 14 2022.
I'm using gstreamer in my [IceGStreamer](https://gitea.ksol.io/karolyi/IceGStreamer) project, an icecast source client I created. Up until 1.20.2 there was no significant RES increase when using it for days, ~115MB RES usage was normal. Ever since I started using `main`, memory usage keeps increasing. RES was yesterday (after ~2 days of running) 250MB, and it is 306M now, after ~8hrs. VIRT values are also higher than before, although I wasn't following those closely. It's the first time I changed to `main` compilation, so I can't tell at which point this memleak got introduced.
I suspect that the FLAC module is at fault, as other IceGStreamer instances that don't play (as much) .flac files, don't reflect the same increasingly expanding RES usage, although I see them consuming more over time. I also get weird artifacts in the log when FLAC playback starts:
```
60:49:12.719821448 95818 0x802c07c00 ERROR libav :0:: invalid sync code
60:49:12.719830054 95818 0x802c07c00 ERROR libav :0:: invalid frame header
60:49:12.719832378 95818 0x802c07c00 ERROR libav :0:: decode_frame() failed
60:49:12.720092488 95818 0x802c07c00 ERROR libav :0:: invalid sync code
60:49:12.720096084 95818 0x802c07c00 ERROR libav :0:: invalid frame header
60:49:12.720097678 95818 0x802c07c00 ERROR libav :0:: decode_frame() failed
60:49:12.720103919 95818 0x802c07c00 ERROR libav :0:: invalid sync code
60:49:12.720105823 95818 0x802c07c00 ERROR libav :0:: invalid frame header
60:49:12.720107336 95818 0x802c07c00 ERROR libav :0:: decode_frame() failed
```
Suggestions on how to debug this problem, copied over from IRC, for later reference (mostly for myself when I have time to tend to this):
> perhaps you could run your code through valgrind --leak-check=yes (with the various .supp suppression files from gstreamer repos) or valgrind heaptrack or you could try the GStreamer leak tracer to see if it's GStreamer objects that are being leaked
> or any other C heap allocation tracing tool