gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:36:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/779waylandsink: Add DRM modifiers and linux-dmabuf version 3 support2021-09-24T14:36:39ZBugzilla Migration Userwaylandsink: Add DRM modifiers and linux-dmabuf version 3 support## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797071)](https://bugzilla.gnome.org/show_bug.cgi?id=797071)**
## Description
waylandsink need support linux-dmabuf version 3 to enable modifier handle
### Depends on
...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797071)](https://bugzilla.gnome.org/show_bug.cgi?id=797071)**
## Description
waylandsink need support linux-dmabuf version 3 to enable modifier handle
### Depends on
* [Bug 779146](https://bugzilla.gnome.org/show_bug.cgi?id=779146)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/778Add split-field interlacing to h265parse & interlace elements2020-03-31T15:17:55ZBugzilla Migration UserAdd split-field interlacing to h265parse & interlace elements## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace el...## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace elements.
These patches are not yet ready to be merged as the caps lack the needed feature, which will be added soon. The point of submitting them already was to already get opinions/suggestions on the main changes.
Also I'm not entirely sure if the (short-cut) approach I took for interlace is what we would want. Suggestions welcome.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/777nvdec: Add support VC1 decoding2021-09-24T14:36:39ZBugzilla Migration Usernvdec: Add support VC1 decoding## Submitted by Yeongjin Jeong
**[Link to original bug (#797049)](https://bugzilla.gnome.org/show_bug.cgi?id=797049)**
## Description
Created attachment 373504
nvdec: Add support VC1 decoding
NVIDIA video decoder supports VC1...## Submitted by Yeongjin Jeong
**[Link to original bug (#797049)](https://bugzilla.gnome.org/show_bug.cgi?id=797049)**
## Description
Created attachment 373504
nvdec: Add support VC1 decoding
NVIDIA video decoder supports VC1 decoding
e.q. )
gst-launch-1.0 filesrc location=(video file path) ! avidemux ! nvdec ! glimagesink
sample video. )
http://samples.mplayerhq.hu/V-codecs/WVC1/glitch-ffvc1.avi
**Patch 373504**, "nvdec: Add support VC1 decoding":
[0001-nvdec-Add-support-VC1-decoding.patch](/uploads/36a21de833f1ddc89ec652973455fd47/0001-nvdec-Add-support-VC1-decoding.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/776kmssink: Deprecate force-modesetting in favour of "mode" property2021-09-24T14:36:38ZBugzilla Migration Userkmssink: Deprecate force-modesetting in favour of "mode" property## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797047)](https://bugzilla.gnome.org/show_bug.cgi?id=797047)**
## Description
I think force-modesetting isn't great has a property. As the time goes, we find tha...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797047)](https://bugzilla.gnome.org/show_bug.cgi?id=797047)**
## Description
I think force-modesetting isn't great has a property. As the time goes, we find that most people uses kmssink in a way one would use decklinkvideosink. It's basically the "new" way, even though still a bit limited, to handle a video output. In this regard, the typical use case is to fix the output mode using well known names, like 1080p60, 1080i60, etc. Basically, the API exposed by decklinkvideosink.
So my proposal is to replace "force-modesetting" with a mode property. We could have special values to indicate "current", for the currently configured mode (our default), "automatic", to try and match the video resolution with the output, or an alternative of type "best-match". And then, a list of modes.
The decklinkvideosink just hardcodes a fixed list of modes, we could do that, but then we'd need to improve it everything a DRM driver introduce a new mode. Maybe we could find a compromise, keep "mode" as a string and match it to one of the enumerated modes for the connector.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/775bayer2rgb: does not copy meta data2021-09-24T14:36:38ZBugzilla Migration Userbayer2rgb: does not copy meta data## Submitted by Edgar Thier
**[Link to original bug (#797043)](https://bugzilla.gnome.org/show_bug.cgi?id=797043)**
## Description
GstMeta data added to a buffer is lost when bayer2rgb is used.
It would be preferable if this da...## Submitted by Edgar Thier
**[Link to original bug (#797043)](https://bugzilla.gnome.org/show_bug.cgi?id=797043)**
## Description
GstMeta data added to a buffer is lost when bayer2rgb is used.
It would be preferable if this data is copied instead.
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/774msdkh264dec: when playing 1080P 60fps it shows lots of frames dropped, compar...2021-09-24T14:36:38ZBugzilla Migration Usermsdkh264dec: when playing 1080P 60fps it shows lots of frames dropped, comparing vaapih264dec in same hardware## Submitted by lon..@..el.com
**[Link to original bug (#797040)](https://bugzilla.gnome.org/show_bug.cgi?id=797040)**
## Description
Created attachment 373489
GST_DEBUG log
When using msdkh264dec, fpsdisplaysink and glimages...## Submitted by lon..@..el.com
**[Link to original bug (#797040)](https://bugzilla.gnome.org/show_bug.cgi?id=797040)**
## Description
Created attachment 373489
GST_DEBUG log
When using msdkh264dec, fpsdisplaysink and glimagesink in pipeline, there are a few frames dropped when playing 1080P media by msdk, especially during the starting period.
Test command:
gst-launch-1.0 filesrc location=./1080P_HOBIT3_1920x1080_2700frames.yuv_cbr_bt2000_ipb.h264 ! h264parse ! msdkh264dec ! fpsdisplaysink video-sink=glimagesink
**Attachment 373489**, "GST_DEBUG log":
[msdk_45framesdropped.zip](/uploads/fbed3ec8f312b3760205975766c2ce49/msdk_45framesdropped.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/773openh264enc: cmInitParaError on EOS2021-09-24T14:36:37ZBugzilla Migration Useropenh264enc: cmInitParaError on EOS## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when r...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when receiving the EOS event:
GST_DEBUG=videoencoder:7,openh264enc:7 gst-launch-1.0 videotestsrc num-buffers=10 ! openh264enc ! fakesink
...
0:00:00.046820534 6897 0x55bb2aff0ca0 LOG openh264enc gstopenh264enc.cpp:989:gst_openh264enc_handle_frame:`<openh264enc0>` openh264 picture coded OK!
...
0:00:00.046936637 6897 0x55bb2aff0ca0 DEBUG videoencoder gstvideoencoder.c:1216:gst_video_encoder_sink_event:`<openh264enc0>` received event 28174, eos
[OpenH264] this = 0x0x7f0d4c009220, Error:CWelsH264SVCEncoder::EncodeFrame(), cmInitParaError.
Got EOS from element "pipeline0".https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/772decklinkvideosrc: Respect pixel format property even if mode is set to auto2018-11-05T14:16:33ZBugzilla Migration Userdecklinkvideosrc: Respect pixel format property even if mode is set to auto## Submitted by Joshua M. Doe
**[Link to original bug (#796979)](https://bugzilla.gnome.org/show_bug.cgi?id=796979)**
## Description
I got hung up for several hours trying to debug why I couldn't get 10-bit YUV (v210) from an SDI so...## Submitted by Joshua M. Doe
**[Link to original bug (#796979)](https://bugzilla.gnome.org/show_bug.cgi?id=796979)**
## Description
I got hung up for several hours trying to debug why I couldn't get 10-bit YUV (v210) from an SDI source via a Decklink Extreme 12G card. Turns out 8-bit YUV will always be used if the mode is set to AUTO. Eventually I noticed a warning about this issued in gstdecklinkvideosrc.cpp:1221, "Warning: mode=auto and format!=auto may not work" (I know, I should have noticed this warning in the debug output sooner).
I created a patch which seems to fix this, and might hopefully save future users some frustrationhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/771openslessink: Equalizer support2021-09-24T14:36:37ZBugzilla Migration Useropenslessink: Equalizer support## Submitted by barunsingh
**[Link to original bug (#796970)](https://bugzilla.gnome.org/show_bug.cgi?id=796970)**
## Description
Hi All,
Current implementation of opensles audio sink element does not have any implementation...## Submitted by barunsingh
**[Link to original bug (#796970)](https://bugzilla.gnome.org/show_bug.cgi?id=796970)**
## Description
Hi All,
Current implementation of opensles audio sink element does not have any implementation of audio effects as opensles provides. I was looking into the source code, and it seems that we can add equalizer support along with interfaces in this elements.
Please suggest further.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/770Rework SRT plugin to unify client/server and add features2019-01-10T13:11:53ZBugzilla Migration UserRework SRT plugin to unify client/server and add features## Submitted by Roman Diouskine
**[Link to original bug (#796963)](https://bugzilla.gnome.org/show_bug.cgi?id=796963)**
## Description
- Unify client/server for both, source and sink elements
- Add missing properties to improve SR...## Submitted by Roman Diouskine
**[Link to original bug (#796963)](https://bugzilla.gnome.org/show_bug.cgi?id=796963)**
## Description
- Unify client/server for both, source and sink elements
- Add missing properties to improve SRT feature coverage
- Add ability to set SRT properties via URI
- Add rendezvous mode
- Add glib 2.54 compatibility
- Add optional reconnect with max reconnect retries feature to the source
- Allow overriding source message size and number of messages per read
- Improve SRT state handing in source and sink elementshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/769h264parse: wrong DTS calculation when not provided by the stream2023-07-11T12:06:53ZBugzilla Migration Userh264parse: wrong DTS calculation when not provided by the stream## Submitted by Gaylord Charles `@gaylord.charles`
**[Link to original bug (#796962)](https://bugzilla.gnome.org/show_bug.cgi?id=796962)**
## Description
Created attachment 373333
Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264par...## Submitted by Gaylord Charles `@gaylord.charles`
**[Link to original bug (#796962)](https://bugzilla.gnome.org/show_bug.cgi?id=796962)**
## Description
Created attachment 373333
Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"
I experienced some problems while transmuxing an UDP TS stream (from a live streaming hardware encoder) to a RTMP stream with the following pipeline (Gstreamer 1.14.2):
gst-launch-1.0 flvmux name=mux streamable=true ! queue ! rtmpsink location=rtmp://192.168.1.26:1935/live/my_stream \
udpsrc uri=udp://192.168.1.43:9001 do-timestamp=false ! queue ! tsdemux name=dem \
dem. ! h264parse ! queue ! mux. dem. ! aacparse ! queue ! mux.
My encoder produces a H.264 + AAC program.
There are no errors while running the pipeline but the RTMP server is not able to correctly play the received stream.
After some debugging (GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"), I found out a possible problem with the DTS calculation on H.264 stream.
Here is an example of the logs from baseparse (the full log file is available as an attachment):
0:00:00.575681258 LOG baseparse gstbaseparse.c:2147:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 8174 with dts 0:00:00.033333332, pts 0:00:02.551755111, duration 99:99:99.999999999
The origin of the bug lays in the TS where DTS is not provided:
0:00:00.530313511 DEBUG tsdemux tsdemux.c:2297:gst_ts_demux_parse_pes_header:`<dem>` stream PTS 0:00:02.551755111 DTS 99:99:99.999999999
The compliance of such a stream is debatable, but there are no B frames in the H.264 stream from the encoder. So we could assume DTS = PTS.
I made a quick (and dirty) fix in tsdemux.c (please refer to the attached patch) to make my pipeline work (and the video correctly decoded on the RTMP server).
Do you have any suggestions to solve this cleanly (maybe in h264parse or baseparse) ?
**Attachment 373333**, "Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"":
[gst_debug_dump.log](/uploads/3d9d51d2585f346be7f889f496610f1c/gst_debug_dump.log)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/768facedetect: handle haardetect max-size settings in plugin properties2023-03-13T14:39:06ZBugzilla Migration Userfacedetect: handle haardetect max-size settings in plugin properties## Submitted by flavie lancereau
**[Link to original bug (#796942)](https://bugzilla.gnome.org/show_bug.cgi?id=796942)**
## Description
Since version 2.2 of opencv, a parameter appeared in the haardetect function, this is the maximu...## Submitted by flavie lancereau
**[Link to original bug (#796942)](https://bugzilla.gnome.org/show_bug.cgi?id=796942)**
## Description
Since version 2.2 of opencv, a parameter appeared in the haardetect function, this is the maximum size. This one allows to limit the number of iteration of the search and thus to optimize this one. By default in gstreamer this parameter is set to CvSize(0,0) so no limitation, however it would be useful to be able to modify it in the plugin properties.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/767srtpdec: example pipelines do not work, caps are not detected2022-05-26T07:42:13ZBugzilla Migration Usersrtpdec: example pipelines do not work, caps are not detected## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/g...## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-srtpdec.html do not work.
System:
$ uname -a
Linux big-p 4.4.0-17134-Microsoft` #137`-Microsoft Thu Jun 14 18:46:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l | grep gst | grep bad
ii gstreamer1.0-plugins-bad:amd64 1.8.3-1ubuntu0.2 amd64 GStreamer plugins from the "bad" set
source:
gst-launch-1.0 audiotestsrc ! alawenc ! rtppcmapay ! 'application/x-rtp, payload=(int)8, ssrc=(uint)1356955624' ! srtpenc key="012345678901234567890123456789012345678901234567890123456789" ! udpsink port=5004
dest:
GST_DEBUG=srtpdec:5 gst-launch-1.0 udpsrc port=5004 caps='application/x-srtp, payload=(int)8, ssrc=(uint)1356955624, srtp-key=(buffer)012345678901234567890123456789012345678901234567890123456789, srtp-cipher=(string)aes-128-icm, srtp-auth=(string)hmac-sha1-80, srtcp-cipher=(string)aes-128-icm, srtcp-auth=(string)hmac-sha1-80' ! srtpdec ! rtppcmadepay ! alawdec ! pulsesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.080196000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:770:request_key_with_signal:`<srtpdec0>` Could not get caps for stream with SSRC 1356955624
0:00:00.083958000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:1212:gst_srtp_dec_chain:`<srtpdec0>` Invalid buffer, dropping
...
repeats forever
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/766avfassetsrc: deadlock on processing (flushing) seek event2021-09-24T14:36:36ZBugzilla Migration Useravfassetsrc: deadlock on processing (flushing) seek event## Submitted by Stephan Hesse `@tchakabam`
**[Link to original bug (#796933)](https://bugzilla.gnome.org/show_bug.cgi?id=796933)**
## Description
Running on XCode Simulator any iDevice model with iOS v11.4 as well as real devices (f...## Submitted by Stephan Hesse `@tchakabam`
**[Link to original bug (#796933)](https://bugzilla.gnome.org/show_bug.cgi?id=796933)**
## Description
Running on XCode Simulator any iDevice model with iOS v11.4 as well as real devices (for example iPhone 7 with v11.4.1):
Reproduce:
When playing a local MP3 or MP4 file via playbin, and filesrc factory-rank is downgraded against avfassetsrc (like it is done in the current gst-examples iOS playback project) performing any flushing seek will cause a deadlock to happen.
When processing the seek event, we are waiting somewhere after `avfassetsrc.m:726:gst_avf_asset_src_stop_reading`
...but I haven't investigated the exact cause yet. Someone who has touched this code before has an idea here?
See logs here: https://gist.github.com/tchakabam/0b277e1947ba51395399206725049171
A local file URL can be bundled in the project `Resources` folder and passed to the player conveniently like so:
```
NSString *localFile = @"guitars.m4a";
NSURL *localURL = [[NSBundle mainBundle] URLForResource: localFile withExtension:nil];
g_object_set (player, "uri", [localURL.absoluteString UTF8String], NULL);
```
... just adding that snippet, because the current gst-examples code doesn't include any local files for testing (only the deprecated media library stuff).
We suspect this issue might be result of Apple-side API implementation having evolved since previous versions when this plugin was made and that it used to work back then. Could that be possible?
Our current workaround is to use the filesrc instead to access local media, which results in a decodebin/atdec based pipeline, which as expected works fine.
Some more questions:
We were also wondering what the advantages are to use a monolithic approach to reading/decoding as it is done with avfassetsrc compared to filesrc/decodebin based pipeline? We suspect performance is more optimal when using the native system component to do the whole job, but is it really noticeable? When playing HLS via adaptivedemux for example we don't seem having to worry about that, and it is using the same pipeline downstream, while it's more logic in adaptivedemux than what happens in filesrc I would guess. Or is there such a large overhead in accessing files with filesrc compared to AVAssetReader? Should we worry about using the filesrc mode and actively try to fix this so our app can use avfassetsrc instead?
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/765waylandsink: add property to set window resolution2021-09-24T14:36:35ZBugzilla Migration Userwaylandsink: add property to set window resolution## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#796932)](https://bugzilla.gnome.org/show_bug.cgi?id=796932)**
## Description
add two property for user to set window resolution when using waylandsink in cmdline## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#796932)](https://bugzilla.gnome.org/show_bug.cgi?id=796932)**
## Description
add two property for user to set window resolution when using waylandsink in cmdlinehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/764wasapi plugins fail to build with Visual Studio when using the Windows 8.1 SDK2019-11-26T06:46:28ZBugzilla Migration Userwasapi plugins fail to build with Visual Studio when using the Windows 8.1 SDK## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#796928)](https://bugzilla.gnome.org/show_bug.cgi?id=796928)**
## Description
Install Visual Studio 2015 with only the Windows 8.1 SDK selected, open a Visual Stu...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#796928)](https://bugzilla.gnome.org/show_bug.cgi?id=796928)**
## Description
Install Visual Studio 2015 with only the Windows 8.1 SDK selected, open a Visual Studio command line prompt, clone gst-build and build it with Meson. You'll get the following error:
ninja: Entering directory `build'
[1/130] Linking target subprojects/gst-plugins-bad/sys/wasapi/gstwasapi.dll.
FAILED: subprojects/gst-plugins-bad/sys/wasapi/gstwasapi.dll
link @subprojects/gst-plugins-bad/sys/wasapi/gstwasapi.dll.rsp
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_FormFactor already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_ControlPanelPageProvider already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_Association already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_PhysicalSpeakers already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_GUID already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_Disable_SysFx already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_FullRangeSpeakers already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_Supports_EventDriven_Mode already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEndpoint_JackSubType already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEngine_DeviceFormat already defined in gstwasapi.c.obj
gstwasapisrc.c.obj : error LNK2005: _PKEY_AudioEngine_OEMFormat already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_FormFactor already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_ControlPanelPageProvider already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_Association already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_PhysicalSpeakers already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_GUID already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_Disable_SysFx already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_FullRangeSpeakers already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_Supports_EventDriven_Mode already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEndpoint_JackSubType already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEngine_DeviceFormat already defined in gstwasapi.c.obj
gstwasapisink.c.obj : error LNK2005: _PKEY_AudioEngine_OEMFormat already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_FormFactor already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_ControlPanelPageProvider already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_Association already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_PhysicalSpeakers already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_GUID already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_Disable_SysFx already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_FullRangeSpeakers already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_Supports_EventDriven_Mode already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEndpoint_JackSubType already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEngine_DeviceFormat already defined in gstwasapi.c.obj
gstwasapiutil.c.obj : error LNK2005: _PKEY_AudioEngine_OEMFormat already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_FormFactor already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_ControlPanelPageProvider already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_Association already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_PhysicalSpeakers already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_GUID already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_Disable_SysFx already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_FullRangeSpeakers already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_Supports_EventDriven_Mode already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEndpoint_JackSubType already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEngine_DeviceFormat already defined in gstwasapi.c.obj
gstwasapidevice.c.obj : error LNK2005: _PKEY_AudioEngine_OEMFormat already defined in gstwasapi.c.obj
Creating library subprojects\\gst-plugins-bad\\sys\\wasapi\\gstwasapi.lib and object subprojects\\gst-plugins-bad\\sys\\wasapi\\gstwasapi.exp
subprojects/gst-plugins-bad/sys/wasapi/gstwasapi.dll : fatal error LNK1169: one or more multiply defined symbols found
[8/130] Linking target subprojects/gst-plugins-bad/sys/winks/gstwinks.dll.
Creating library subprojects\\gst-plugins-bad\\sys\\winks\\gstwinks.lib and object subprojects\\gst-plugins-bad\\sys\\winks\\gstwinks.exp
[10/130] Compiling C object subprojects/gst-plugins-bad/ext/gl/subprojects@gst-plugins-bad@ext@gl@@gstopenglmixers@sha/gstglvideomixer.c.obj.
ninja: build stopped: subcommand failed.
---
This error is confusing to me because I have no idea where those symbols are coming from. Probably a header? But we guard all our header includes.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/763compositor pipeline stalling pipeline at "Redistribute latency"2021-09-24T14:36:35ZBugzilla Migration Usercompositor pipeline stalling pipeline at "Redistribute latency"## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#796927)](https://bugzilla.gnome.org/show_bug.cgi?id=796927)**
## Description
I am facing an unclear stall of a pipeline involving a raw h264 file source, vaa...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#796927)](https://bugzilla.gnome.org/show_bug.cgi?id=796927)**
## Description
I am facing an unclear stall of a pipeline involving a raw h264 file source, vaapi decoding and compositor. This affects 1.14.2 and master.
1) generate a sample
gst-launch-1.0 videotestsrc num-buffers=30 ! "video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1" ! vaapih264enc bitrate=16000 keyframe-period=30 rate-control=2 aud=true ! "video/x-h264,profile=baseline" ! filesink location=/tmp/sample.h264
2) launch this:
gst-launch-1.0 filesrc location=/tmp/sample.h264 ! h264parse ! vaapih264dec ! vaapipostproc ! queue ! vmix. compositor name=vmix ! "video/x-raw, format=(string)NV12, width=(int)3840, height=(int)2160, framerate=(fraction)30, colorimetry=(string)bt709" ! tee name=tvmix tvmix. ! queue name=qmain1080p ! videorate ! queue name=qscale1080p ! videoscale ! queue name=qcsp1080 ! videoconvert ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, pixel-aspect-ratio=(fraction)1/1" ! fakesink tvmix. ! queue ! fakesink sync=False
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
Redistribute latency...
Redistribute latency...
[STALLED]
I can work around it by:
- inserting identity or videorate right after vaapipostproc
- setting drop-only=true to videorate
- removing the trailing tvmix. ! queue ! fakesink sync=False
- replacing vaapih264dec and postproc by software components (like avdec_h264 or openh264dec)
The last items in the debug log are:
0:00:01.131839487 6613 0x5599f71268a0 DEBUG GST_PADS gstpad.c:4072:gst_pad_query:<qmain1080p:sink> sent query 0x7f0f84006de0 (allocation), result 1
0:00:01.131852946 6613 0x5599f71268a0 DEBUG tee gsttee.c:637:gst_tee_query_allocation:`<tvmix>` Aggregating AllocationParams align=15 prefix=0 padding=0
0:00:01.131863008 6613 0x5599f71268a0 DEBUG tee gsttee.c:659:gst_tee_query_allocation:`<tvmix>` Aggregating allocation pool size=12441600 min_buffers=1
0:00:01.131878205 6613 0x5599f71268a0 DEBUG tee gsttee.c:595:gst_tee_query_allocation:`<tvmix>` Aggregating allocation from pad tvmix:src_1
0:00:01.131889278 6613 0x5599f71268a0 DEBUG query gstquery.c:678:gst_query_new_custom: creating new query 0x7f0f84006d40 allocation
0:00:01.131900974 6613 0x5599f71268a0 DEBUG GST_PADS gstpad.c:4049:gst_pad_query:<queue4:sink> doing query 0x7f0f84006d40 (allocation)
[STALLED]https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/762add support for DASH events2021-10-20T07:34:16ZBugzilla Migration Useradd support for DASH events## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" th...## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" that is used to convey events. These events can be used to signal changes in the DASH stream, convey metadata or provide application specific information.
Section 5.10.4 (DASH-specific events) defines a method for an in-band signal to indicate that a live DASH stream has finished.
Currently there is no support in qtdemux or dashdemux for these DASH events.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/761ttml: Do not ignore style elements2021-09-24T14:36:34ZBugzilla Migration Userttml: Do not ignore style elements## Submitted by joonyoung.kwak
**[Link to original bug (#796911)](https://bugzilla.gnome.org/show_bug.cgi?id=796911)**
## Description
In the previous version, the style set of the "style"
tag was ignored although including the "st...## Submitted by joonyoung.kwak
**[Link to original bug (#796911)](https://bugzilla.gnome.org/show_bug.cgi?id=796911)**
## Description
In the previous version, the style set of the "style"
tag was ignored although including the "style" tag in a element.
In order to apply the style set of included "style" tag
to the element, the recursion is required to merge style of child elements.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/760rsvg: Add animated SVG support2021-09-24T14:36:34ZBugzilla Migration Userrsvg: Add animated SVG support## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796909)](https://bugzilla.gnome.org/show_bug.cgi?id=796909)**
## Description
The following pipeline output EOS but no buffer:
```
gst-validate-1.0 uride...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796909)](https://bugzilla.gnome.org/show_bug.cgi?id=796909)**
## Description
The following pipeline output EOS but no buffer:
```
gst-validate-1.0 uridecodebin uri=https://gitlab.gnome.org/GNOME/pitivi/uploads/8dd8d9d988b5eb6cc38f871196caac6f/Titel-Tafel3.2_anim.svg ! imagefreeze ! identity silent=false ! videoconvert ! checksumsink
```
It should output the exact animation described in the SVG.