GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-04-07T14:51:57Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/966rtpst2022-1-fecenc/rtpst2022-1-fecdec: Performance Issues (i.e. Packet recove...2022-04-07T14:51:57Zkrishnarao21rtpst2022-1-fecenc/rtpst2022-1-fecdec: Performance Issues (i.e. Packet recovery) with Increased 2D grid sizeHi Integrated rtpst2022-1-fecenc (i.e. sender side)and rtpst2022-1-fecdec (receiver) in our streaming application.
For the same drop probability, packet recovery decreases with 2D grid sizes.
In my experiment, measured the no of lost fr...Hi Integrated rtpst2022-1-fecenc (i.e. sender side)and rtpst2022-1-fecdec (receiver) in our streaming application.
For the same drop probability, packet recovery decreases with 2D grid sizes.
In my experiment, measured the no of lost frames before decoding
No of lost frames
For Drop probability of 1%
5x5: 1, 6x6: 1, 8x8: 8, 10x10: 12,
For Drop probability of 2%
5x5: 1, 6x6: 9, 8x8: 27, 10x10: 56,
For Drop probability of 3%
5x5: 4, 6x6: 12, 8x8: 45, 10x10: 213,
For Drop probability of 4%
5x5: 0, 6x6: 19, 8x8: 109, 10x10: 277,
For Drop probability of 5%
5x5: 0, 6x6: 27, 8x8: 131, 10x10: 310
Total no of frames tested 2700
clearly packet recovery decreases with 2d grid size.
Observed the logs in rtpst2022-1-fecdec element, pasted few logs
rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:549:check_fec:<rtpst_2022_1_fecdec0>[00m Too many media packets missing, storing FEC packet
rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:549:check_fec:<rtpst_2022_1_fecdec0>[00m Too many media packets missing, storing FEC packet
rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:456:xor_items:<rtpst_2022_1_fecdec0>[00m Recovered buffer through row FEC with seqnum 1455, payload len 910 and timestamp 784757681
rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:541:check_fec:<rtpst_2022_1_fecdec0>[00m All media packets present, we can discard that FEC packet
Based on the logs, and experimental data, assuming it is recovering the packets using row FEC, i haven't observed any message related to column (i.e. just like Recovered buffer through column FEC).
Theoretically, if more than one packet loss (i.e. assume two packets)in a row, then both column and row fec needed to recover
those packets (i.e. first column fec and then row fec).
with increased 2d grid size, probability for losing multiple packets in a row increases, if we use row fec only, then the recovery ratio decreses.
So my experimental data is supporting my assumption (i.e. using only row FEC to recover).
Please check.
Tested in our application and also using gst-launch.
gst-launch-1.0 rtpbin name=rtp fec-encoders='fec,0="rtpst2022-1-fecenc\ rows\=5\ columns\=5";' filesrc location="filename.yuv" ! videoparse width=640 height=360 format=2 framerate=25 ! x265enc tune=zerolatency ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! rtph265pay ssrc=0 ! rtp.send_rtp_sink_0 rtp.send_rtp_src_0 ! udpsink host=xxx.xx.xxx.xxx port=5000 rtp.send_fec_src_0_0 ! udpsink host=xxx.xx.xxx.xxx port=5002 async=false rtp.send_fec_src_0_1 ! udpsink host=xxx.xx.xxx.xxx port=5004 async=false
gst-launch-1.0 rtpbin latency=500 fec-decoders='fec,0="rtpst2022-1-fecdec\ size-time\=1000000000";' name=rtp udpsrc port=5002 caps="application/x-rtp, payload=96" ! queue ! rtp.recv_fec_sink_0_0 udpsrc port=5004 caps="application/x-rtp, payload=96" ! queue ! rtp.recv_fec_sink_0_1 udpsrc port=5000 caps="application/x-rtp, media=video, clock-rate=90000, encoding-name=H265" ! queue ! netsim drop-probability=0.05 ! rtp.recv_rtp_sink_0 rtp. ! rtph265depay ! queue ! h265parse ! avdec_h265 ! videoconvert ! videoscale ! ximagesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1138Support dual subtitles2022-04-07T09:13:47ZPanderSupport dual subtitlesPlease support displaying two subtitle files.
Reasons for using dual subtitles are:
- review subtitle files
- watch a video with multiple people that do not understand the same language
- learn or improve language skills
Important to n...Please support displaying two subtitle files.
Reasons for using dual subtitles are:
- review subtitle files
- watch a video with multiple people that do not understand the same language
- learn or improve language skills
Important to note is that the timing of subtitle files can differ, hence displaying needs to be done independently. Although often the timing can be identical, better to not assume it is for the implementation.
The support can be in two different ways. Which is to be used greatly depends on the user and what kind of video is being watched in terms of obscuring too much. The modes can be:
1. single subtitles, shown at the bottom (currently supported)
2. dual subtitles bottom, primary first, below secondary (requested)
3. dual subtitles split, primary at bottom, secondary at top (requested)
Please see the attachment for how this looks. Here the grey subtitles are the position of the single subtitles. In black are the primary subtitles and in blue the secondary.
![gstst](/uploads/06d30aa62a83c32d4595b46877447694/gstst.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/97allocation query: Add API to increase and update the minimum require buffers2022-04-07T06:00:01ZBugzilla Migration Userallocation query: Add API to increase and update the minimum require buffers## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It rep...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It represent the minimum amount of buffers required in order for a segment of a pipeline to function. Element that retain buffers must update this value in order to ensure the pool will function.
Unfortunately this value is not exposed globally, but rather per allocation pool. This means that to update/increase this value, one need to iterate over the pool list, remove pool which have a maximum too small and update minimum. In order to make this task easier, we could add utilities in the core API. Currently this is implemented by videorate only, but queues with minimum threshold should implement that too, deinterlace element, and many others may also need to do so.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/966riff-media: fix memory leak after usage for g_strjoin2022-04-06T12:04:35ZHoonHee Leeriff-media: fix memory leak after usage for g_strjoinDear All.
I've found a memory leak with g_strjoin() using valgrind.
- ==10729== 11 bytes in 1 blocks are definitely lost in loss record 810 of 8,454
- ==10729== at 0x4C31B0F: malloc (vg_replace_malloc.c:299)
- ==10729== by 0x564BBD8: g...Dear All.
I've found a memory leak with g_strjoin() using valgrind.
- ==10729== 11 bytes in 1 blocks are definitely lost in loss record 810 of 8,454
- ==10729== at 0x4C31B0F: malloc (vg_replace_malloc.c:299)
- ==10729== by 0x564BBD8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
- ==10729== by 0x566554E: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
- ==10729== by 0x168F28C2: gst_riff_create_audio_caps (riff-media.c:1533)
- ==10729== by 0x168F39D9: gst_riff_create_audio_caps (riff-media.c:1763)
- ==10729== by 0x166D783A: gst_avi_demux_parse_stream (gstavidemux.c:2466)
- ==10729== by 0x166DA4F4: gst_avi_demux_stream_header_pull (gstavidemux.c:4292)
- ==10729== by 0x166DB49F: gst_avi_demux_loop (gstavidemux.c:6242)
- ==10729== by 0x5164FA8: gst_task_func (gsttask.c:328)
- ==10729== by 0x566EC6F: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
- ==10729== by 0x566E2A4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
- ==10729== by 0x765C6DA: start_thread (pthread_create.c:463)
- ==10729== by 0x602561E: clone (clone.S:95)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/965segmentation fault : gst_buffer_fill memcpy issue2022-04-06T07:01:24ZJun Takasegmentation fault : gst_buffer_fill memcpy issue
[Goal]
I'd like to create movie file by using image files.
[Code Summary]
buffer = gst_buffer_new_wrapped_full((GstMemoryFlags)GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS, imageAddress, imageSize, 0, imageSize, NULL, NULL);
g_signal_em...
[Goal]
I'd like to create movie file by using image files.
[Code Summary]
buffer = gst_buffer_new_wrapped_full((GstMemoryFlags)GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS, imageAddress, imageSize, 0, imageSize, NULL, NULL);
g_signal_emit_by_name(appsrc, "push-buffer", buffer, &ret);
[Issue]
My source code happens segmentation-fault sometimes and the backtrace of segmentation-fault are always same.
#1 0x00007f0600faa045 in memcpy
(__len=3110400, __src=0x7f05d7a15020, __dest=<optimized out>)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
--> __builtin___memcpy_chk
30 __fortify_function void *
31 __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
32 size_t __len))
33 {
34 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
35 }
I know about "__builtin___memcpy_chk" but I couldn't understand why segmentation-fault, therefore it really difficult for me to modify this issue.
Could you teach me the reason of the segmentation-fault and how to modify it if you can?
for example)
A.FPS is too fast for Gstreamer to free memory in time and cannot memcpy.
B.Image address for gst_buffer_new_wrapped_full is wrong.
<details><summary><b>Backtrace</b></summary>
```
(gdb) backtrace
#0 __memmove_avx_unaligned_erms ()
at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#1 0x00007f0600faa045 in memcpy
(__len=3110400, __src=0x7f05d7a15020, __dest=<optimized out>)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2 gst_buffer_fill
(buffer=buffer@entry=0x7f05202856c0, offset=<optimized out>,
offset@entry=0, src=<optimized out>, size=3110400)
at ../gst/gstbuffer.c:1954
#3 0x00007f05fc0129c5 in gst_raw_video_parse_process
(raw_base_parse=<optimized out>, config=<optimized out>, in_data=0x7f05202855a0, total_num_in_bytes=<optimized out>, num_valid_in_bytes=<optimized out>, processed_data=0x7f05154f19c8) at ../gst/rawparse/gstrawvideoparse.c:938
#4 0x00007f05fc00f59a in gst_raw_base_parse_handle_frame (parse=
0x7f05202e8ed0 [GstBaseParse|rawvideoparse], frame=0x7f0508002630, skipsize=<optimized out>) at ../gst/rawparse/gstrawbaseparse.c:595
#5 0x00007f05e4043ed9 in gst_base_parse_handle_buffer
(parse=parse@entry=0x7f05202e8ed0 [GstBaseParse|rawvideoparse], buffer=<optimized out>, skip=skip@entry=0x7f05154f1b78, flushed=flushed@entry=0x7f05154f1b7c) at ../libs/gst/base/gstbaseparse.c:2251
#6 0x00007f05e4049e6e in gst_base_parse_chain
(pad=<optimized out>, parent=<optimized out>, buffer=<optimized out>)
at ../libs/gst/base/gstbaseparse.c:3300
#7 0x00007f0600fe43ff in gst_pad_chain_data_unchecked
(pad=pad@entry=0x7f0520254f30 [GstPad|sink], type=type@entry=4112, data=data@entry=0x7f0520285360) at ../gst/gstpad.c:4441
#8 0x00007f0600fe6561 in gst_pad_push_data
(pad=pad@entry=0x7f0520254150 [GstPad|src], type=type@entry=4112, data=data@entry=0x7f0520285360) at ../gst/gstpad.c:4697
#9 0x00007f0600fed753 in gst_pad_push
(pad=pad@entry=0x7f0520254150 [GstPad|src], buffer=0x7f0520285360)
at ../gst/gstpad.c:4816
#10 0x00007f05e4063b1d in gst_base_src_loop (pad=0x7f0520254150 [GstPad|src])
at ../libs/gst/base/gstbasesrc.c:3030
#11 0x00007f060101c467 in gst_task_func
(task=0x7f0520285290 [GstTask|source:src]) at ../gst/gsttask.c:384
#12 0x00007f0600e4e374 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f0600e4dad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f060718b609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
#15 0x00007f0600b00163 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
</details>https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/99Gradle sync failed: NDK not configured error occurred at the time of syncing ...2022-04-06T05:11:31ZHemant ZarkarGradle sync failed: NDK not configured error occurred at the time of syncing Gradle of android-tutorial-4Hi, I am new in Gstreamer. I want to play video by using Gstreamer, so I have cloned your code and opened android-tutorial-4 in my Android Studio 4.1 in Windows 10. After that I am trying to sync Gradle, but it gives error given below,
...Hi, I am new in Gstreamer. I want to play video by using Gstreamer, so I have cloned your code and opened android-tutorial-4 in my Android Studio 4.1 in Windows 10. After that I am trying to sync Gradle, but it gives error given below,
`FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':android-tutorial-1'.
> NDK not configured.
Download it with SDK manager.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 2s`
But I already have NDK downloaded at my NDK location.![ndk](/uploads/cae6150a71d1af6fb5891c1222cb90f7/ndk.PNG)
I also added NDK path in local.properties file. Please help me to solve this issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1030[HLS] Micro-freeze issue when refreshing live playlist2022-04-05T13:27:55ZJuan Ramírez[HLS] Micro-freeze issue when refreshing live playlistI am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments to...I am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments totaling between 10 and 15 seconds of video). It happens with most of the HLS streams I've tested with (a list is available below).
I tried adding buffering between hlsdemux and tsdemux and managed to increase performance, but the micro-freeze issue is still present. I also tried several property values (connection-speed for hlsdemux, sizes and thresholds of the queues etc) with no improvement.
I wrote to the mailing list and got this response from Charles Turner, which I think is worth quoting here:
> This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. I had a quick peek at what might be going wrong and one hunch is that adaptivedemux isn't giving itself enough time, or is somehow stalling in updates_loop during the playlist updating logic. Maybe the target_duration wait times and/or the update timer cond bits need some adjustments.
Some of the workflows I've tried are the following:
```sh
gst-launch-1.0 playbin uri=$URL
```
```sh
gst-launch-1.0 souphttpsrc location="$URL" ! hlsdemux ! queue ! tsdemux name=demux \
demux. ! queue ! aacparse ! avdec_aac ! audioconvert ! autoaudiosink \
demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
```
With `URL` being one of the following:
* http://video3.earthcam.com/fecnetwork/hdtimes10.flv/.m3u8
* http://video3.earthcam.com/fecnetwork/9974.flv/.m3u8
* http://dwstream4-lh.akamaihd.net/i/dwstream4_live@131329/master.m3u8 (DW)
* https://5c21f7ec1999d.streamlock.net/8054/8054/playlist.m3u8 (TC, Ecuador)
* http://video.oct.dc.gov/out/u/DCN.m3u8 (DCN, provides various streams, use connection-speed to stick to one)
* http://unlimited2-us.dps.live/nettv/nettv.smil/playlist.m3u8 (NETTV, Argentina)
Streams that are not live, for example, [the ones at bitmovin.com](https://bitmovin.com/mpeg-dash-hls-examples-sample-streams) work ok (in the worst case you just have to set the appropriate bit rate).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/546tsdemux: fix to keep seqnum of segment2022-04-05T13:08:42ZBugzilla Migration Usertsdemux: fix to keep seqnum of segment## Submitted by Wonchul Lee
**[Link to original bug (#781393)](https://bugzilla.gnome.org/show_bug.cgi?id=781393)**
## Description
I tried to seek on hls stream, here is the url : https://mnmedias.api.telequebec.tv/m3u8/29880.m3u8 ...## Submitted by Wonchul Lee
**[Link to original bug (#781393)](https://bugzilla.gnome.org/show_bug.cgi?id=781393)**
## Description
I tried to seek on hls stream, here is the url : https://mnmedias.api.telequebec.tv/m3u8/29880.m3u8
Hlsdemux handled the seek event and generated relevant flush-start/stop and segment event, but the tsdemux didn't keep the seqnum of segment which receiving event from hlsdemux in this case. So I fixed to keep seqnum of segment in tsdemux for this.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/338[hlsdemux] ignores EXT-X-PROGRAM-DATE-TIME tag for gaps in playlist.2022-04-05T13:02:23ZBugzilla Migration User[hlsdemux] ignores EXT-X-PROGRAM-DATE-TIME tag for gaps in playlist.## Submitted by Arjen Veenhuizen
**[Link to original bug (#759630)](https://bugzilla.gnome.org/show_bug.cgi?id=759630)**
## Description
Perhaps slightly related to` #740790`, hlsdemux completely ignores EXT-X-PROGRAM-DATE-TIME tags ...## Submitted by Arjen Veenhuizen
**[Link to original bug (#759630)](https://bugzilla.gnome.org/show_bug.cgi?id=759630)**
## Description
Perhaps slightly related to` #740790`, hlsdemux completely ignores EXT-X-PROGRAM-DATE-TIME tags (which can be used to signal an absolute offset, or to signal a gap in the playlist in conjunction with EXT-X-DISCONTINUITY).
Expected behavior:
For the following playlist (http://pastebin.com/tjdYWRRE) we would expect that the player would pause during the missing segment (fileSequence4.ts), or at least update the running time to compensate for the missing segment (e.g. skip 10 seconds).
Observed behavior:
The player continues playing, completely ignoring the EXT-X-PROGRAM-DATE-TIME tag and the gap in the playlist.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/827[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good2022-04-05T12:51:26ZBugzilla Migration User[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been sa...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been said that we should wait for` #657790` to be closed, and we might want to rename it from hls to something more generic (fragmented is the name of the plugin itself, just the folder is called hls). Ideally adding another fragmented streaming protocol with the help of the new base class.
Also there is no test suite yet but there is some work going on there.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1135ImportError: cannot import name Gst, introspection typelib not found2022-04-05T04:35:03ZequalmanImportError: cannot import name Gst, introspection typelib not found![QQ图片20220405123200](/uploads/edc9966c0ea782d9ca6a27ed7752eb37/QQ图片20220405123200.png)![QQ图片20220405123200](/uploads/edc9966c0ea782d9ca6a27ed7752eb37/QQ图片20220405123200.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1134ImportError: cannot import name Gst, introspection typelib not found2022-04-05T04:28:48ZequalmanImportError: cannot import name Gst, introspection typelib not foundhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1133ImportError: cannot import name Gst, introspection typelib not found2022-04-05T04:15:58ZequalmanImportError: cannot import name Gst, introspection typelib not foundroot@Desktop-1t5sf8m:/usr/lib/python3/dist-packages/gi# python3
Python 3.6.9 (default, Mar 15 2022, 13:55:28)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import GObje...root@Desktop-1t5sf8m:/usr/lib/python3/dist-packages/gi# python3
Python 3.6.9 (default, Mar 15 2022, 13:55:28)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import GObject
>>> from gi.repository import Gst
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 888, in _find_spec
AttributeError: 'DynamicImporter' object has no attribute 'find_spec'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/gi/importer.py", line 127, in find_module
'introspection typelib not found' % namespace)
ImportError: cannot import name Gst, introspection typelib not found
>>> exit()
root@Desktop-1t5sf8m:/usr/lib/python3/dist-packages/gi# uname -a
Linux Desktop-1t5sf8m 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I compiled the tags code [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/archive/1.20.1/gstreamer-1.20.1.tar.gz) with instructions in the page https://gitlab.freedesktop.org/gstreamer/gstreamer and install it, in subdirector ~/gstreamer-1.20.1/subprojects/gst-python, i also used meson tools and install it, when i test python code,errors above generated
in the file /usr/lib/python3/dist-packages/gi/importer.py, i find codes below, line 127 repository.is_registered()
how can i register the Gst module?
104 class DynamicImporter(object):
105
106 # Note: see PEP302 for the Importer Protocol implemented below.
107
108 def __init__(self, path):
109 self.path = path
110
111 def find_module(self, fullname, path=None):
112 if not fullname.startswith(self.path):
113 return
114
115 path, namespace = fullname.rsplit('.', 1)
116 if path != self.path:
117 return
118
119 # is_registered() is faster than enumerate_versions() and
120 # in the common case of a namespace getting loaded before its
121 # dependencies, is_registered() returns True for all dependencies.
122 if repository.is_registered(namespace) or \
123 repository.enumerate_versions(namespace):
124 return self
125 else:
126 raise ImportError('cannot import name %s, '
127 'introspection typelib not found' % namespace)
128
129 def load_module(self, fullname):
130 if fullname in sys.modules:
131 return sys.modules[fullname]
132
133 path, namespace = fullname.rsplit('.', 1)
134
135 stacklevel = get_import_stacklevel(import_hook=True)
136 with _check_require_version(namespace, stacklevel=stacklevel):
137 try:
138 introspection_module = get_introspection_module(namespace)
139 except RepositoryError as e:
140 raise ImportError(e)
141 # Import all dependencies first so their init functions
142 # (gdk_init, ..) in overrides get called.
143 # https://bugzilla.gnome.org/show_bug.cgi?id=656314
144 for dep in repository.get_immediate_dependencies(namespace):
145 importlib.import_module('gi.repository.' + dep.split("-")[0])
146 dynamic_module = load_overrides(introspection_module)
147
148 dynamic_module.__file__ = '<%s>' % fullname
149 dynamic_module.__loader__ = self
150 sys.modules[fullname] = dynamic_module
151
152 return dynamic_modulehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1044SRT srtsink with srtsrc fails locally with ":No room to store incoming packet"2022-04-04T06:50:29ZdanrossiSRT srtsink with srtsrc fails locally with ":No room to store incoming packet"I have communicated this elsewhere. I've been trying to do a test mpeg-ts send and receive locally, for testing ingesting into wowza remotely later. I am doing this test until OBS has SRT encoding support, as my UDP test via ffmpeg remot...I have communicated this elsewhere. I've been trying to do a test mpeg-ts send and receive locally, for testing ingesting into wowza remotely later. I am doing this test until OBS has SRT encoding support, as my UDP test via ffmpeg remotely barely functioned.
However the local transmission on the same machine fails as if there is not enough buffer to receive it. Using ffmpeg as a sender works, but delivering to a remote Wowza with too high bitrate produced the same errors.
Sender in a vmware or windows client. This chopmydata is required to work like pktsize in ffmpeg.
```
gst-launch-1.0 filesrc location=sintel_lang.ts ! tsparse set-timestamps=1 smoothing-latency=40000000 ! chopmydata step-size=188 min-size=188 max-size=1316 ! srtsink uri=srt://192.168.4.43:8088
```
```
12:18:07.499950/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 29 packets - lost delaying for 1024ms
12:18:07.508915/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 23 packets - lost delaying for 1024ms
12:18:07.517874/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 24 packets - lost delaying for 1023ms
12:18:07.526882/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 26 packets - lost delaying for 1023ms
12:18:07.536077/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1023ms
12:18:07.545959/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 26 packets - lost delaying for 1024ms
12:18:07.554756/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 25 packets - lost delaying for 1024ms
12:18:07.563901/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1024ms
12:18:07.572710/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 33 packets - lost delaying for 1023ms
12:18:07.581747/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1023ms
12:18:07.590694/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 33 packets - lost delaying for 1023ms
12:18:07.600530/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 18 packets - lost delaying for 1024ms
```
Receiver client on windows
```
gst-launch-1.0 -v srtsrc uri="srt://:8088" ! decodebin ! videoconvert ! autovideosink
```
```
994379595 rcv-remain=2691
12:18:10.406079*E: SRT.c: %849110327:No room to store incoming packet: offset=6901 avail=5503 ack.seq=994372726 pkt.seq=994379627 rcv-remain=2688
12:18:10.406567*E: SRT.c: %849110327:No room to store incoming packet: offset=6902 avail=5503 ack.seq=994372726 pkt.seq=994379628 rcv-remain=2688
12:18:10.415093*E: SRT.c: %849110327:No room to store incoming packet: offset=6923 avail=5503 ack.seq=994372726 pkt.seq=994379649 rcv-remain=2688
12:18:10.415430*E: SRT.c: %849110327:No room to store incoming packet: offset=6924 avail=5503 ack.seq=994372726 pkt.seq=994379650 rcv-remain=2688
12:18:10.424044*E: SRT.c: %849110327:No room to store incoming packet: offset=6956 avail=5503 ack.seq=994372726 pkt.seq=994379682 rcv-remain=2688
12:18:10.424442*E: SRT.c: %849110327:No room to store incoming packet: offset=6957 avail=5503 ack.seq=994372726 pkt.seq=994379683 rcv-remain=2688
handling interrupt.
```
Ffmpeg sender OK
```
ffmpeg -fflags +genpts -re -i sintel_lang_2000k.mp4 -acodec copy -vcodec copy -map 0:v:0 -map 0:a:0 -map 0:a:2 -strict -2 -y -f mpegts 'srt://192.168.4.43:8088?pkt_size=1316&mode=caller'
```
Reference here.
https://github.com/Haivision/srt/issues/659#issuecomment-517934242https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/18SEND_ONLY RECV_ONLY with Janus Gateway VideoRoom2022-04-03T19:26:30ZmartinangelSEND_ONLY RECV_ONLY with Janus Gateway VideoRoomHi all,
As the repository from centricular has been moved here, I am moving this [issue](https://github.com/centricular/gstwebrtc-demos/issues/205) here. As I think that it is an interesting feature for the Gstreamer community.
I have ...Hi all,
As the repository from centricular has been moved here, I am moving this [issue](https://github.com/centricular/gstwebrtc-demos/issues/205) here. As I think that it is an interesting feature for the Gstreamer community.
I have been modifying sendrecv sample code to work with Janus Gateway Video Room.
Specifically, I have a Sender which sends Video and a Receiver joining/subscribing to the peerId available at the video room.
_Sender (sendonly) <-> Janus Gateway <-> Receiver (receiveonly)_
Essentially:
- I am developing the applications on top of Gstreamer v1.18 and Ubuntu 18.04.
- I have turned the soup calls to libwebsockets messages to the Janus API.
- I have kept sendrecv sample code for the Sender declaring SendOnly for the WebRtcBin transceivers.
- I have slightly changed the sendrecv sample code to wait until a peerID is on the videoroom to join/subscribe it for the Receiver declaring RecvOnly for the WebRtcBin transceivers.
- In any case, the SDP offers and answers from/to both peers and the ICE candidates are exchanged.
I can see the video and audio stream played at the VideoRoom website from Janus. So the Sender is working ok.
But the Receiver does not receive any stream from Janus. And no errors are coming from the Gstreamer logs.
SDP offer and answer and ICE candidates are exchanged.
After the ICE candidates are sent from the Receiver to Janus and ACKs are reported, the WebrtcUp message (as it happens at the WebBrowser player available in the VideoRoom sample when the streams run) is never received by the Receiver.
So it looks like no streams are being sent from Janus to the GSt-based Receiver.
_Samples provided by this repository are helpful and mean a great work. But my feeling is that they are designed to peer a Web-browser-based player/peer. As they communicate with another Gst-based peer, problems come into place._
There is a Janus videoroom example in the janus/subdirectory that does bi-directional media. It's in python rather than C, but it has provided some guidance to get signalling with Janus working.
Janus sends ICE candidates to the Receiver, before sending the SDP offer and before the WebRtcBin state is Playing.
```
# Extract ICE candidates from the SDP to work around a GStreamer
# limitation in (at least) 1.16.2 and below
self.extract_ice_from_sdp (sdp)
```
So, I have stored them and emit('add-ice-candidate' once SDP offer has been input to the WebRtcBin g_signal_emit_by_name(webrtc1, "set-remote-description", offer, promise);
Now I receive from Janus the webrtcup message, but nothing else happens. No streams are received. DtlsStrpDemux does not receive anything after the PEMs are exchanged and SSL handshake has been performed.
In the logs of Janus I can see in response to the recvonly:
```
[2684131696657477] The DTLS handshake has been completed [2684131696657477] Telling the plugin about it (JANUS VideoRoom plugin) [janus.plugin.videoroom-0x7faabc0065c0] WebRTC media is now available
```
The same way Janus answers to the sendonly.
I am uploading the code in the case you want to debug with your own Janus VideoRoom.
[webrtcTXRX.zip](/uploads/2345350fa36e144431afc81e052745c8/webrtcTXRX.zip)
Once compiled you run them by:
**Transmitter SENDONLY H264**
_TXid is peer-id_
`GST_DEBUG=3,webrtc*:5,dtls*:5 ./webrtcTXjanus --peer-id=1001 --server=127.0.0.1 --janus-port=8188 --room=1234 --token= --display-id=2002`
**Transmitter RECVONLY H264**
_RXid is display-id (looking for peer-id in the videoroom to request its stream)_
`GST_DEBUG=3,webrtc*:5,dtls*:5 ./webrtcRXjanus --peer-id=1001 --server=127.0.0.1 --janus-port=8188 --room=1234 --token= --display-id=2002`
The pipeline is TX Video 1001 -> Janus -> RX Video 2002.
The video comes from the TX to Janus, and the signalling and GST logs are OK from Janus to RX but on Wireshark I do not see any UDP packet from Janus to RX.
By the way, my conclusion is that bundle:max-compat and remove data channel make Janus to send webrtcup message, otherwise, ICE problems comes or other signaling messages never come from Janus.
After checking the logs (GST_DEBUG=3,webrtc*:5,dtls*:5,srtp*:5,rtp*:5,ice*:5), I think that, as python code underlines, there is a problem with the timing of ICE candidates.
In rx.txt [rx.txt](/uploads/8169ae75280b1c47389c82ec81b6ce90/rx.txt) you see the logs of a working receive_only GST App using the simple_server.py with room.
ICE candidates are sent and after the exchange of Keys and Certificates comes.
Then, srtpdec and rtpsession start to run. (~line 337)
In rxjanus.txt [rxjanus.txt](/uploads/ba11dca5eab859dd874749a60eda2a26/rxjanus.txt) you will see that everything is invoked the same way, but the slow and distant in time sending of ICE candidates makes that after the Keys and Certificates comes, new ICE candidates are sent and the Caps of srtpdec are never received and rtpsession receiving a stream never happens. (~line 728)
I do not know if the asynchronous sending of ICE candidates from receive_only Gst app to Janus, making Janus receiveing some extra candidates once everything is connected and established make that no stream is sent.
Thank you in advance.
Any hint?
Best,
Angelhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1131New elements for AVIF2022-04-02T22:52:01ZkriptonNew elements for AVIFAVIF is the image format derived from HEIF and AV1. I would expect avifenc and avifdec elements similar to the existing webpenc and webpdecAVIF is the image format derived from HEIF and AV1. I would expect avifenc and avifdec elements similar to the existing webpenc and webpdechttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1110vah264enc: Broken image with non-VA memory input2022-04-02T07:39:35ZSeungha Yangseungha@centricular.comvah264enc: Broken image with non-VA memory inputI suspect video meta attached on buffer doesn't respect CPU accessible memory's stride/padding perhaps?
```
vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Foun...I suspect video meta attached on buffer doesn't respect CPU accessible memory's stride/padding perhaps?
```
vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.6.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 ()
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileNone : VAEntrypointStats
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointFEI
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointFEI
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointFEI
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointFEI
VAProfileHEVCMain : VAEntrypointEncSliceLP
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointEncSliceLP
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile1 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileVP9Profile3 : VAEntrypointVLD
VAProfileHEVCMain422_10 : VAEntrypointVLD
VAProfileHEVCMain422_10 : VAEntrypointEncSlice
VAProfileHEVCMain444 : VAEntrypointVLD
VAProfileHEVCMain444 : VAEntrypointEncSliceLP
VAProfileHEVCMain444_10 : VAEntrypointVLD
VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP
```
command line
```
gst-launch-1.0 videotestsrc ! vah264enc ! h264parse ! vah264dec ! glimagesink
```
![image](/uploads/a3ad2468576123174f7402fe2a0f702b/image.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/965v4l2h264dec0: Too old frames, bug in decoder -- please file a bug2022-04-02T01:04:28ZF. Duncanhv4l2h264dec0: Too old frames, bug in decoder -- please file a bugAn example that triggers this bug is attached below. This 1.21.0.1 master. The bug is there in V4L2 in 1.20 and 1.18;
no problems with other decoders.
This videostream starts with an SPS NAL followed by a PPS NAL followed by 125 v...An example that triggers this bug is attached below. This 1.21.0.1 master. The bug is there in V4L2 in 1.20 and 1.18;
no problems with other decoders.
This videostream starts with an SPS NAL followed by a PPS NAL followed by 125 video NALS of Big Buck Bunny (from youtube)
Here is a dump (videodump.1.h264) of 5 secs of a stream of Big Buck Bunny (15Mb, streamed over Apple Airplay to the gstreamer pipeline (in the shell script pipeline.sh)
```
#!/bin/sh
gst-launch-1.0 filesrc location=$1 ! video/x-h264 ! h264parse ! capssetter caps="video/x-h264, colorimetry=bt709" ! v4l2h264dec ! v4l2convert ! glimagesink name=video_sink sync=false
```
[videodump.1.h264](/uploads/95c2f77d9ce7c5cf0f570140b547b9bf/videodump.1.h264)
[pipeline.sh](/uploads/8638fc0723c42e92514e579bc8441ce3/pipeline.sh)
At line 644 of gstv4l2videodec.c
```
static void
gst_v4l2_video_dec_loop (GstVideoDecoder * decoder)
{
GstV4l2VideoDec *self = GST_V4L2_VIDEO_DEC (decoder);
GstV4l2BufferPool *v4l2_pool;
GstBufferPool *pool;
GstVideoCodecFrame *frame;
GstBuffer *buffer = NULL;
GstFlowReturn ret;
GST_VIDEO_DECODER_STREAM_LOCK (decoder);
if (g_atomic_int_get (&self->capture_configuration_change)) {
gst_v4l2_object_stop (self->v4l2capture);
ret = gst_v4l2_video_dec_setup_capture (decoder);
if (ret != GST_FLOW_OK) {
GST_VIDEO_DECODER_STREAM_UNLOCK (decoder);
return;
}
g_atomic_int_set (&self->capture_configuration_change, FALSE);
}
GST_VIDEO_DECODER_STREAM_UNLOCK (decoder);
if (G_UNLIKELY (!GST_V4L2_IS_ACTIVE (self->v4l2capture)))
return;
GST_LOG_OBJECT (decoder, "Allocate output buffer");
v4l2_pool = GST_V4L2_BUFFER_POOL (self->v4l2capture->pool);
self->output_flow = GST_FLOW_OK;
<================================================only frames 4,5,6..... make it past here.
do {
/* We cannot use the base class allotate helper since it taking the internal
* stream lock. we know that the acquire may need to poll until more frames
* comes in and holding this lock would prevent that.
*/
pool = gst_video_decoder_get_buffer_pool (decoder);
/* Pool may be NULL if we started going to READY state */
if (pool == NULL) {
ret = GST_FLOW_FLUSHING;
goto beach;
}
ret = gst_buffer_pool_acquire_buffer (pool, &buffer, NULL);
g_object_unref (pool);
if (ret == GST_V4L2_FLOW_RESOLUTION_CHANGE) {
GST_WARNING_OBJECT (decoder, "Received resolution change");
g_atomic_int_set (&self->capture_configuration_change, TRUE);
return;
}
if (ret != GST_FLOW_OK)
goto beach;
GST_LOG_OBJECT (decoder, "Process output buffer");
ret = gst_v4l2_buffer_pool_process (v4l2_pool, &buffer, NULL);
} while (ret == GST_V4L2_FLOW_CORRUPTED_BUFFER);
if (ret != GST_FLOW_OK)
goto beach;
if (GST_BUFFER_TIMESTAMP (buffer) % GST_SECOND != 0)
GST_ERROR_OBJECT (decoder,
"Driver bug detected - check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git");
GST_LOG_OBJECT (decoder, "Got buffer for frame number %u",
(guint32) (GST_BUFFER_TIMESTAMP (buffer) / GST_SECOND));
frame =
gst_video_decoder_get_frame (decoder,
GST_BUFFER_TIMESTAMP (buffer) / GST_SECOND);
if (frame) {
GstVideoCodecFrame *oldest_frame;
gboolean warned = FALSE;
/* Garbage collect old frames in case of codec bugs */
while ((oldest_frame = gst_video_decoder_get_oldest_frame (decoder)) &&
check_system_frame_number_too_old (frame->system_frame_number,
oldest_frame->system_frame_number)) {
gst_video_decoder_drop_frame (decoder, oldest_frame);
oldest_frame = NULL;
if (!warned) {
g_warning ("%s: Too old frames, bug in decoder -- please file a bug",
GST_ELEMENT_NAME (decoder));
warned = TRUE;
}
}
```
The first few NAL units (typically 4) dont get handled by the decoder loop and are left for garbage collection after 100 frames. One single return happens before the loop starts working.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1124Mismatched NULL handling between GstPlayer/GstPlay and playbin2/32022-04-02T00:16:42ZEmmanuele BassiMismatched NULL handling between GstPlayer/GstPlay and playbin2/3### Describe your issue
The `uri` argument for `gst_player_set_uri()` is marked as nullable:
```c
/**
* gst_player_set_uri:
* @player: #GstPlayer instance
* @uri: (nullable): next URI to play.
*
* Sets the next URI to play.
*/
``...### Describe your issue
The `uri` argument for `gst_player_set_uri()` is marked as nullable:
```c
/**
* gst_player_set_uri:
* @player: #GstPlayer instance
* @uri: (nullable): next URI to play.
*
* Sets the next URI to play.
*/
```
Internally, the `GstPlayer:uri` property calls `gst_play_set_uri()`, which is also explicitly allowing a `NULL` value for the `uri` argument:
```
/**
* gst_play_set_uri:
* @play: #GstPlay instance
* @uri: (nullable): next URI to play.
*
* Sets the next URI to play.
* Since: 1.20
*/
```
`GstPlay:uri` will eventually set the `uri` property on either the `playbin2` or the `playbin3` elements, which **do not** support a `NULL` URI:
```c
if (uri == NULL) {
g_warning ("cannot set NULL uri");
return;
}
```
#### Expected Behavior
No warning when calling `gst_player_set_uri (player, NULL)`.
#### Observed Behavior
The following warning:
```
** (amberol:2): WARNING **: 16:34:51.870: cannot set NULL uri
```
#### Setup
- **Operating System:** Fedora Silverblue
- **Device:** Computer
- **GStreamer Version:** 1.18, but verified to commit 6d2f57b6c7285053f3578a9e66005a76bd8547f4https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/924examples: gl/gtk does not build on macOS due to GTK API changes2022-04-01T13:07:12ZSebastian Drögeexamples: gl/gtk does not build on macOS due to GTK API changesThanks to https://gitlab.gnome.org/GNOME/gtk/-/issues/1737 , `tests/examples/gl/gtk/gstgtk.c` is failing to compile on macOS with newer GTK.
It seems like the API breakage is considered OK by the GTK developers, and the solution is to u...Thanks to https://gitlab.gnome.org/GNOME/gtk/-/issues/1737 , `tests/examples/gl/gtk/gstgtk.c` is failing to compile on macOS with newer GTK.
It seems like the API breakage is considered OK by the GTK developers, and the solution is to use a new header with newer GTK versions according to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3450 .
This is in no release yet.