GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2020-02-11T18:50:02Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1208Typo in Security Advisory 2019-0001 (CVE-2019-9928)2020-02-11T18:50:02ZMichael CatanzaroTypo in Security Advisory 2019-0001 (CVE-2019-9928)There's a typo in [Security Advisory 2019-0001 (CVE-2019-9928)](https://gstreamer.freedesktop.org/security/sa-2019-0001.html). Under CVE database entries, "CVE-2016-9445" should be replaced with "CVE-2019-9928".There's a typo in [Security Advisory 2019-0001 (CVE-2019-9928)](https://gstreamer.freedesktop.org/security/sa-2019-0001.html). Under CVE database entries, "CVE-2016-9445" should be replaced with "CVE-2019-9928".https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/98RTP time stamps should not be scaled when Speed header is used2020-05-15T17:20:47ZBranko SubasicRTP time stamps should not be scaled when Speed header is usedThe current implementation of the RTSP Speed header scales the RTP time stamps according to the value of the Speed header.
For example, for a 30 fps video stream played at normal speed (Speed=1.0) the RTP time stamps will increase with a...The current implementation of the RTSP Speed header scales the RTP time stamps according to the value of the Speed header.
For example, for a 30 fps video stream played at normal speed (Speed=1.0) the RTP time stamps will increase with approximately 3000 between frames. However, if Speed=2.0 then in our current implementation they will increase with approximately 1500, i.e. the time stamps are scaled with the Speed.
That behavior is wrong. The value of the Speed header is supposed to determine the speed at which the data is sent, but it's not supposed to change the playback time. The primary use case is client scaling of the media.
RFC 7826, section 251, defines the Speed as follows:
"Speed: The ratio of playback time delivered per unit of wallclock time."
It's further explained as:
"Speed (Section 18.50) affects how much of the playback timeline is delivered in a given wallclock period.
The default is Speed = 1 which means to deliver at the same rate the media is consumed. Speed > 1 means
that the receiver will get content faster than it regularly would consume it."
In essence, Speed controls the delivery speed, not the playback speed. Thus the time stamps should not be scaled.
For more information please see http://ietf.10.n7.nabble.com/RTSP-Speed-and-Scale-overview-text-td191370.html.
One possible to this is to instrument the the RTP payloader (through a property?).https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/231Build issue with gstvaapifilter on gst-build2020-02-11T12:02:19ZPieter JordaanBuild issue with gstvaapifilter on gst-buildAs shown in my comment here:
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/commit/1c7e820805b49a89357de7ef6df975b4a5b42c72#note_407453
Build fails due to fields not available in the structure `VAProcColorProperties`.
More sp...As shown in my comment here:
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/commit/1c7e820805b49a89357de7ef6df975b4a5b42c72#note_407453
Build fails due to fields not available in the structure `VAProcColorProperties`.
More specifically:
- `colour_primaries`
- `transfer_characteristics`
- `matrix_coefficients`https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/230[TGL] vaapih265enc error while doing encode2020-02-20T08:03:26ZVUNNYSODHI[TGL] vaapih265enc error while doing encodeENV:
* Gstreamer: commit 20301a882008dc849abec33d5d29d86441d86cae
* gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
* gst-plugins-good: commit 8445685a21b7c912595827646ef2900ebc84a100
* gstreamer-vaapi: commit 5fe553f...ENV:
* Gstreamer: commit 20301a882008dc849abec33d5d29d86441d86cae
* gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
* gst-plugins-good: commit 8445685a21b7c912595827646ef2900ebc84a100
* gstreamer-vaapi: commit 5fe553f4c707003899c0bc17e3deb33edd89cb68
Below error on running command TigerLake platform:
#**gst-launch-1.0 filesrc location=sunflower_1080p_NV12.yuv ! videoparse width=1920 format=nv12 framerate=30 height=1080 ! vaapih265enc tune=low-power ! video/x-h265, profile=main ! h265parse ! matroskamux ! filesink location=/tmp/low_sgst_h265.mkv**
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapiencodeh265-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
**0:00:12.902268902 15942 0x7f004c0040f0 ERROR vaapiencode gstvaapiencode.c:196:gst_vaapiencode_default_alloc_buffer: invalid GstVaapiCodedBuffer size (0 bytes)
**
0:00:12.902356346 15942 0x7f004c0040f0 ERROR vaapiencode gstvaapiencode.c:303:gst_vaapiencode_push_frame: failed to allocate encoded buffer in system memory
0:00:19.332532224 15942 0x7f004c0040f0 ERROR vaapiencode gstvaapiencode.c:196:gst_vaapiencode_default_alloc_buffer: invalid GstVaapiCodedBuffer size (0 bytes)
0:00:19.332702523 15942 0x7f004c0040f0 ERROR vaapiencode gstvaapiencode.c:303:gst_vaapiencode_push_frame: failed to allocate encoded buffer in system memory
In dmesg:
[58620.698034] i915 0000:00:02.0: Resetting vcs1 for preemption time out
[58620.698082] i915 0000:00:02.0: inner_rawvideop[15943] context reset due to GPU hang
[58620.700277] i915 0000:00:02.0: GPU HANG: ecode 12:10:28ffff7d, in inner_rawvideop [15943]
However, if I remove tune=low-power I see different error as below:
#**gst-launch-1.0 filesrc location=sunflower_1080p_NV12.yuv ! videoparse width=1920 format=nv12 framerate=30 height=1080 ! vaapih265enc ! video/x-h265, profile=main ! h265parse ! matroskamux ! filesink location=/tmp/sgst_h265.mkv**
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapiencodeh265-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
**
**ERROR:../gst-libs/gst/vaapi/gstvaapiencoder_h265.c:2188:reset_properties: assertion failed: (ret)**
Aborted (core dumped)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/509Video freezes when switching between cameras using input-selector on iOS iPad2021-09-24T11:08:54ZJawad BraickVideo freezes when switching between cameras using input-selector on iOS iPadI'm having trouble switching back and forth between the front-facing camera and the back-facing camera on an iOS iPad Pro. I'm using the `input-selector` element to switch between camera sources. When it switches from the first camera so...I'm having trouble switching back and forth between the front-facing camera and the back-facing camera on an iOS iPad Pro. I'm using the `input-selector` element to switch between camera sources. When it switches from the first camera source to the second camera source, the video freezes on the camera, and then unfreezes when it switches to the original camera source. I'm on iOS 12.3 and gstreamer 1.16.1. This is my pipeline.
<pre><code>
pipeline = gst_parse_launch("avfvideosrc device-index=1 name=back_camera_src ! videoconvert ! identity name=sink0_sync sync=TRUE ! input-selector name=input_selector ! identity name=identity_segment silent=TRUE ! autovideosink name=video_sink sync=FALSE
avfvideosrc device-index=0 name=front_camera_src ! videoflip video-direction=180 ! identity name=sink1_sync sync=TRUE ! input_selector.
autoaudiosrc ! audioconvert ! audioresample ! audioconvert ! autoaudiosink", &error); <code></pre>
When I change the second source to the test source as in this second pipeline switching works fine.
<pre><code>
pipeline = gst_parse_launch("avfvideosrc device-index=1 name=back_camera_src ! videoconvert ! identity name=sink0_sync sync=TRUE ! input-selector name=input_selector ! identity name=identity_segment silent=TRUE ! autovideosink name=video_sink sync=FALSE
videotestsrc is-live=true pattern=ball ! videoflip video-direction=180 ! identity name=sink1_sync sync=TRUE ! input_selector.
autoaudiosrc ! audioconvert ! audioresample ! audioconvert ! autoaudiosink", &error);<code></pre>
This is my code to switch sources with the input selector
<pre><code>
-(void) switchVideoSrc
{
GstElement *inputSelector = self->inputSelector;
gint nb_sources;
GstPad *active_pad, *new_pad;
gchar *active_name;
g_message ("switching");
g_object_get (G_OBJECT (inputSelector), "n-pads", &nb_sources, nil);
g_object_get (G_OBJECT (inputSelector), "active-pad", &active_pad, nil);
active_name = gst_pad_get_name (active_pad);
g_message(active_name);
if (strcmp (active_name, "sink_0") == 0) {
new_pad = gst_element_get_static_pad (inputSelector, "sink_1");
} else {
new_pad = gst_element_get_static_pad (inputSelector, "sink_0");
}
g_object_set (G_OBJECT (inputSelector), "active-pad", new_pad, NULL);
g_free (active_name);
gst_object_unref (new_pad);
}
</code></pre>
I looked at the logs up until GST_DEBUG level 4 and didn't find anything unusual. Any ideas what could be the problem or how to go about debugging this?https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/241Capssetter negotiation failure2020-02-10T14:27:32ZEdward HerveyCapssetter negotiation failureExample pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming...Example pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming caps values). Theoretically `videoconvert` should end up negotiating to `UYVY`.... but it doesn't (it ends up doing passthrough).
The problem is that the caps transformation function of `capssetter` only works in one direction (converting upstream caps to downstream ones). When converting caps from downstream to upstream it either returns the query filter caps or ANY.
Ideally it *should* do something smarter to allow passing some of the downstream information (i.e. negotiated caps) upstream if at least the caps name is the same.
Further example: `capssetter caps="video/x-raw,pixel-aspect-ratio=8/9` if you wanted to override the PAR. In this case , when converting caps in reverse, capssetter could detect that the field will be overriden and therefore just return the downstream caps with the `pixel-aspect-ratio` field removed (it will replace it anyway).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/697capssetter: negotiation failure2021-09-24T13:33:43ZEdward Herveycapssetter: negotiation failureExample pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming...Example pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming caps values). Theoretically `videoconvert` should end up negotiating to `UYVY`.... but it doesn't (it ends up doing passthrough).
The problem is that the caps transformation function of `capssetter` only works in one direction (converting upstream caps to downstream ones). When converting caps from downstream to upstream it either returns the query filter caps or ANY.
Ideally it *should* do something smarter to allow passing some of the downstream information (i.e. negotiated caps) upstream if at least the caps name is the same.
Further example: `capssetter caps="video/x-raw,pixel-aspect-ratio=8/9` if you wanted to override the PAR. In this case , when converting caps in reverse, capssetter could detect that the field will be overriden and therefore just return the downstream caps with the `pixel-aspect-ratio` field removed (it will replace it anyway).https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/55help on how to run tut code2020-03-25T18:21:54Zcarlylouhelp on how to run tut codeBased on the content in link : https://gstreamer.freedesktop.org/documentation/installing/on-mac-osx.html?gi-language=c, I can not know how to run tut code on mac.
My question is I can not find content under path: /Library/Frameworks/G...Based on the content in link : https://gstreamer.freedesktop.org/documentation/installing/on-mac-osx.html?gi-language=c, I can not know how to run tut code on mac.
My question is I can not find content under path: /Library/Frameworks/GStreamer.framework/Current/share/gst-sdk/tutorials so that I can not follow the instructions "To start building the tutorials, create a new folder in your Documents directory and copy the folder /Library/Frameworks/GStreamer.framework/Current/share/gst-sdk/tutorials."
Can anyone give me help on this? I really need to know how to configure the development environment.
Thanks in advance.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/229Vaapivp9enc negotiation error for 4k yuv stream2020-02-13T03:49:50ZVUNNYSODHIVaapivp9enc negotiation error for 4k yuv streamENV:
Gstreamer: commit 20301a882008dc849abec33d5d29d86441d86cae
gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
gst-plugins-good: commit 8445685a21b7c912595827646ef2900ebc84a100
gstreamer-vaapi: commit 5fe553f4c70...ENV:
Gstreamer: commit 20301a882008dc849abec33d5d29d86441d86cae
gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
gst-plugins-good: commit 8445685a21b7c912595827646ef2900ebc84a100
gstreamer-vaapi: commit 5fe553f4c707003899c0bc17e3deb33edd89cb68
I am running below gstreamer command on TigerLake platform:
#**gst-launch-1.0 filesrc location=test_3840x2160_NV12.yuv ! videoparse format=nv12 width=3840 height=2160 ! vaapivp9enc ! matroskamux ! filesink location=/tmp/out.vp9**
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapiencodevp9-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
ERROR: from element /GstPipeline:pipeline0/GstVideoParse:videoparse0/GstRawVideoParse:inner_rawvideoparse: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbaseparse.c(3679): gst_base_parse_loop (): /GstPipeline:pipeline0/GstVideoParse:videoparse0/GstRawVideoParse:inner_rawvideoparse:
**streaming stopped, reason not-negotiated (-4)**
ERROR: pipeline doesn't want to preroll.
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
Whereas 1080p below command working fine.
#**gst-launch-1.0 filesrc location=test_1080p_NV12.yuv ! videoparse format=nv12 width=1920 height=1080 ! vaapivp9enc ! matroskamux ! filesink location=/tmp/out1.vp9**https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/508gstclock: hotdoc doesn't find deprecated GTimeVal2020-03-12T14:54:10ZGuillaume Desmottesgstclock: hotdoc doesn't find deprecated GTimeValI'm trying to update our Fedora CI image to F31. This version ships glib 2.62 which deprecated `GTimeVal`.
This [seems to confuse hotdoc](https://gitlab.freedesktop.org/gdesmott/gst-ci/-/jobs/1587534) which claims the symbol no longer ex...I'm trying to update our Fedora CI image to F31. This version ships glib 2.62 which deprecated `GTimeVal`.
This [seems to confuse hotdoc](https://gitlab.freedesktop.org/gdesmott/gst-ci/-/jobs/1587534) which claims the symbol no longer exist:
```
ERROR: [core]: (gtk-doc-bad-link): /builds/gdesmott/gst-ci/gst-build/subprojects/gstreamer/gst/gstclock.h:167:15: Trying to link to non-existing symbol ‘GTimeVal’
00165: * @tv: the timeval to convert
00166: *
00167: * Convert a #GTimeVal to a #GstClockTime.
^
00168: */
00169:#define GST_TIMEVAL_TO_TIME(tv) (GstClockTime)((tv).tv_sec * GST_SECOND + (tv).tv_usec * GST_USECOND)
```
@meh : what would be the proper way to workaround this?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/507gst_element_query_position is stuck at end position in reverse playback2023-05-28T15:10:37ZGregoire Gentilgst_element_query_position is stuck at end position in reverse playbackI'm using this tutorial:
https://gstreamer.freedesktop.org/documentation/tutorials/basic/playback-speed.html?gi-language=c
If I add the action advance_frame with the following code:
```
case 'a':
gst_element_send_event(data->pipeline...I'm using this tutorial:
https://gstreamer.freedesktop.org/documentation/tutorials/basic/playback-speed.html?gi-language=c
If I add the action advance_frame with the following code:
```
case 'a':
gst_element_send_event(data->pipeline, gst_event_new_step(GST_FORMAT_BUFFERS, 1, 1.0, TRUE, FALSE));
gint64 position;
gst_element_query_position(data->pipeline, GST_FORMAT_TIME, &position);
fprintf(stderr, "position:%ld", position);
break;
```
It's working properly, one frame is advanced and the position is incremented.
If I do 'd' to backward the rate and I do the same action advance_frame, the previous frame is shown on screen but the position remains the same. I can go back as many frames as I want, the display is correctly updated but the position remains stuck at the position when the rate was inverted.
This is happening with multiple containers such as: webm, ps, ts, matroska
To reproduce the issue:
```
wget http://gentil.com/tmp/a.zip
unzip a.zip
gcc a.c `pkg-config --cflags --libs gstreamer-1.0` && ./a.out
```
Press:
```
P
a
a
a
D
a
a
a
q
```
That gives the following output:
```
P
Setting state to PAUSE
a
position:10557831391
a
position:10582000000
a
position:10603000000
D
Current rate: -1
a
position:10625000000
a
position:10625000000
a
position:10625000000
q
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/506bus: Sync handler setting not thread-safe2020-02-15T09:36:53ZSebastian Drögebus: Sync handler setting not thread-safeWhile protected with the object lock, calling the sync handler is done without keeping the object lock and as such the sync handler might disappear in the mean time, causing crashes or worse.While protected with the object lock, calling the sync handler is done without keeping the object lock and as such the sync handler might disappear in the mean time, causing crashes or worse.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/729appsrc/appsink: Setting callbacks is not thread-safe2020-02-15T09:36:53ZSebastian Drögeappsrc/appsink: Setting callbacks is not thread-safeWhile the setters themselves protect the callbacks with the object lock, all uses are calling them without taking any locks.
This can easily cause segfaults and worse when changing the callbacks while the elements are running.
We should...While the setters themselves protect the callbacks with the object lock, all uses are calling them without taking any locks.
This can easily cause segfaults and worse when changing the callbacks while the elements are running.
We should either add a new mutex for this, or don't allow changing the callbacks (at all, or at least not in >= `READY`).
This causes segfaults every now and then in the gstreamer-rs tests since https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/merge_requests/407 .
For gstreamer-rs I guess the workaround for now is to store in qdata if callbacks were set before and simply don't allow setting them a second time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1207VP9 Encode: Using msdkvp9enc generated output cannot playback2020-02-10T14:11:52ZVUNNYSODHIVP9 Encode: Using msdkvp9enc generated output cannot playbackI am running below gstreamer command on TigerLake platform.
ENV:
Gstreamer:commit 20301a882008dc849abec33d5d29d86441d86cae
gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
gst-plugins-good: commit 8445685a21b7c91259582...I am running below gstreamer command on TigerLake platform.
ENV:
Gstreamer:commit 20301a882008dc849abec33d5d29d86441d86cae
gst-plugins-base: commit a171eb80d6d809e3be3cd0531e499dde3c3a3f33
gst-plugins-good: commit 8445685a21b7c912595827646ef2900ebc84a100
gst-plugins-bad: commit 6c1e5ab3110b5635f46a28c1d192a71fed38025b
#gst-launch-1.0 filesrc location=test_1080p_NV12.yuv ! videoparse width=1920 format=nv12 framerate=30 height=1080 ! msdkvp9enc ! matroskamux ! filesink location=/tmp/out.vp9
No error during encode, however when I do playback of encoded file, there is below error:
#gst-launch-1.0 filesrc location=/tmp/out.vp9 ! matroskademux ! msdkvp9dec ! msdkvpp ! glimagesink
Setting pipeline to PAUSED ...
libva info: VA-API version 1.6.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_6
libva info: va_openDriver() returns 0
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Got context from element 'msdkvpp0': gst.msdk.Context=context, gst.msdk.Context=(GstMsdkContext)"\(GstMsdkContext\)\ msdkcontext0";
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstMsdkVP9Dec:msdkvp9dec0: Could not negotiate the stream
Additional debug info:
../sys/msdk/gstmsdkdec.c(1069): gst_msdkdec_handle_frame (): /GstPipeline:pipeline0/GstMsdkVP9Dec:msdkvp9dec0
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Internal data stream error.
Additional debug info:
../gst/matroska/matroska-demux.c(5810): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/GstMsdkVP9Dec:msdkvp9dec0: No valid frames decoded before end of stream
Additional debug info:
../gst-libs/gst/video/gstvideodecoder.c(1205): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/GstMsdkVP9Dec:msdkvp9dec0:
no valid frames found
Setting pipeline to PAUSED ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
Note: I have tested VP9 encode functionality using MSDK no error seen during playback of encoded file.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/228[regression] GLTextureUploadMeta is broken for i965 driver2020-02-28T13:06:35ZVíctor Manuel Jáquez Leal[regression] GLTextureUploadMeta is broken for i965 driversince commit 32bf6f1e clutterautovideosink fails to negotiates gltextureuploadmeta when using i965 driver with vaapidecoder
and also fails with iHD when negotiating with vaapipostproc since commit 1c7e8208
(for now, only tested on wayl...since commit 32bf6f1e clutterautovideosink fails to negotiates gltextureuploadmeta when using i965 driver with vaapidecoder
and also fails with iHD when negotiating with vaapipostproc since commit 1c7e8208
(for now, only tested on wayland)
cc: @He_Junyan, @ullysses.a.eoffhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/240fontconfig.recipe Platform.IOS CFLAGS update to fix textoverlay: EXC_BAD_ACCESS2020-02-07T20:03:18ZCarsten Griffinfontconfig.recipe Platform.IOS CFLAGS update to fix textoverlay: EXC_BAD_ACCESSAddition of Platform.IOS specific CFLAGS to fix EXC_BAD_ACCESS error when using textoverlay in iOS as described in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/648
The resolution was found in https://github.com/taner...Addition of Platform.IOS specific CFLAGS to fix EXC_BAD_ACCESS error when using textoverlay in iOS as described in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/648
The resolution was found in https://github.com/tanersener/mobile-ffmpeg/issues/22https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/96threadshare: panic when dealing with event from non-threadshare element in tw...2020-03-21T02:55:38ZMathieu Duponchellethreadshare: panic when dealing with event from non-threadshare element in two successive threadshare onesReproduce with:
```
gst-launch-1.0 udpsrc port=50000 address=0.0.0.0 ! ts-jitterbuffer latency=80 context="1" context-wait=10 ! ts-proxysink
```
My actual use case is more complicated and has ts-udpsink instead of ts-proxysink, but th...Reproduce with:
```
gst-launch-1.0 udpsrc port=50000 address=0.0.0.0 ! ts-jitterbuffer latency=80 context="1" context-wait=10 ! ts-proxysink
```
My actual use case is more complicated and has ts-udpsink instead of ts-proxysink, but that element hasn't been upstreamed yet.
Breakdown of the problem:
* udpsrc pushes stream-start
* jitterbuffer handles the event in its sink_event function, returns a future which runtime/pad.rs handles by calling block_on, as we're not in a context thread
* runtime/pad.rs tries to push the "prelude" for the src pad, aka pad context event
* proxysink handles the event in its sink_event function the same way, returns a future which runtime/pad.rs tries to handle by calling block_on, as we're still not in a context thread
* BOOM
As far as I can tell, the faulty section is most likely in https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/blob/master/gst-plugin-threadshare/src/runtime/pad.rs#L1096-1140: we enter the else part twice in the udpsrc thread, and the comment it contains does not match the actual situation:
```
// - If there is no PadContext, we don't have any other options.
// - If there is a PadContext, it means that we received it from
// an upstream element, but there is at least one non-ts element
// operating on another thread in between, so we can't take
// advantage of the task queue.
```
Here, we do have a PadContext, and there was no non-threadsharing element between the two threadsharing elements, it is true however that we're still operating on a non-threadsharing thread.
I don't know how to solve this correctly, CC @fengalin :)Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/227Cannot create a VA display2020-02-07T13:05:47ZThomas SchniedersCannot create a VA displayI'm running my own Gstreamer-Application with the Vaapi-plugin inside a Docker-Container.
This application is only used for streaming to a server and is not in need of a Display-Device.
Unfortunatly, the Vaapi-Plugin does a check for a D...I'm running my own Gstreamer-Application with the Vaapi-plugin inside a Docker-Container.
This application is only used for streaming to a server and is not in need of a Display-Device.
Unfortunatly, the Vaapi-Plugin does a check for a Display and so it refused to initialize with following output:
`default gstvaapi.c229:plugin_init: Cannot create a VA display`
Does anyone have a suggestion, how to fix this.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/86GParameter has been deprecated2020-02-07T22:27:08ZGuillaume DesmottesGParameter has been deprecated[GParameter](https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GParameter) has been deprecated since glib 2.54.
I'm trying to update our CI image to Fedora 31 and hit those deprecation errors.
It's not clear w...[GParameter](https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GParameter) has been deprecated since glib 2.54.
I'm trying to update our CI image to Fedora 31 and hit those deprecation errors.
It's not clear which API we should use instead so maybe we should just prevent the warnings using `GLIB_DISABLE_DEPRECATION_WARNINGS`?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1206WebRTC: Sendonly streams + bundle is broken (regression)2022-09-30T05:12:09ZJan SchmidtWebRTC: Sendonly streams + bundle is broken (regression)Commit f8eef0aba0c67f99e607d2d51fd0412562b6a170 fixed a bug with transport receive bin not being blocked properly during WebRTC start up, but introduced a problem where sendonly transceivers are never unblocked and data never starts flow...Commit f8eef0aba0c67f99e607d2d51fd0412562b6a170 fixed a bug with transport receive bin not being blocked properly during WebRTC start up, but introduced a problem where sendonly transceivers are never unblocked and data never starts flowing.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/3ca87d998896f76b3d4ed62006f45f36a876de72/ext/webrtc/gstwebrtcbin.c#L3795 is the problematic line.
I think the correct fix is to remove the DROP mode from transport receive bin, as it makes things more complicated than they need to be. I think transport receive bin should either be in BLOCK mode for inactive transceivers, or PASS mode unconditionally for transceivers which have any active mlines with data flow in either (or both) directions.Jan SchmidtJan Schmidt