GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:23:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/431Reduce amount of memory allocations when payloading fixed-size audio buffers2021-09-24T13:23:39ZBugzilla Migration UserReduce amount of memory allocations when payloading fixed-size audio buffers## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#795021)](https://bugzilla.gnome.org/show_bug.cgi?id=795021)**
## Description
This is a follow-up on https://bugzilla.gnome.org/show_bug.cgi?id=794544
### Depends ...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#795021)](https://bugzilla.gnome.org/show_bug.cgi?id=795021)**
## Description
This is a follow-up on https://bugzilla.gnome.org/show_bug.cgi?id=794544
### Depends on
* [Bug 794544](https://bugzilla.gnome.org/show_bug.cgi?id=794544)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/428baseaudiopayload: refactor to let subclasses prepare the output buffer2021-09-24T13:23:38ZBugzilla Migration Userbaseaudiopayload: refactor to let subclasses prepare the output buffer## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#794545)](https://bugzilla.gnome.org/show_bug.cgi?id=794545)**
## Description
The default implementation wraps the payload in a newly-allocated RTP
buffer. Subcla...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#794545)](https://bugzilla.gnome.org/show_bug.cgi?id=794545)**
## Description
The default implementation wraps the payload in a newly-allocated RTP
buffer. Subclasses may want to use alternative methods.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/427rtpbuffer: expose gst_rtp_buffer_initialize_header function2021-09-24T13:23:38ZBugzilla Migration Userrtpbuffer: expose gst_rtp_buffer_initialize_header function## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#794544)](https://bugzilla.gnome.org/show_bug.cgi?id=794544)**
## Description
An example use case is to avoid using gst_rtp_buffer_new_allocate
as it implies a pa...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#794544)](https://bugzilla.gnome.org/show_bug.cgi?id=794544)**
## Description
An example use case is to avoid using gst_rtp_buffer_new_allocate
as it implies a particular memory layout.
### Blocking
* [Bug 795021](https://bugzilla.gnome.org/show_bug.cgi?id=795021)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/426gstaudioresample: insufficient anti-aliasing2021-09-24T13:23:37ZBugzilla Migration Usergstaudioresample: insufficient anti-aliasing## Submitted by Aaron Viets
**[Link to original bug (#794411)](https://bugzilla.gnome.org/show_bug.cgi?id=794411)**
## Description
I am using GStreamer for calibration of LIGO data. After an update from version 1.4.5 to version 1.10...## Submitted by Aaron Viets
**[Link to original bug (#794411)](https://bugzilla.gnome.org/show_bug.cgi?id=794411)**
## Description
I am using GStreamer for calibration of LIGO data. After an update from version 1.4.5 to version 1.10.4, I discovered that the anti-aliasing was much lower in quality than before, leading to` ~2`% systematic errors. I set the property quality = 9, and the rest of the properties were the default values.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/425Add DRI3/Present extension support in ximagesink, glimagesink, etc.2021-09-24T13:23:37ZBugzilla Migration UserAdd DRI3/Present extension support in ximagesink, glimagesink, etc.## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#794339)](https://bugzilla.gnome.org/show_bug.cgi?id=794339)**
## Description
DRI3 has an extension which allows to convert DRM_PRIME_BUFFER to Pixmap and presen...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#794339)](https://bugzilla.gnome.org/show_bug.cgi?id=794339)**
## Description
DRI3 has an extension which allows to convert DRM_PRIME_BUFFER to Pixmap and present it on the screen using "Present" extension.
This could help to do zero-copy pipelines like
VAAPI_decdoe ! ximagesink
MediaSDK_decode ! ximagesink
https://lwn.net/Articles/569701/
This is a PR against intel-vaapi-driver: https://github.com/intel/intel-vaapi-driver/pull/369
Another third-party implementation: https://github.com/intel/gstreamer-media-SDK/blob/master/gst-libs/mfx/x11/gstmfxwindow_x11.c#L469https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/424decodebin2: Fix detecting when a group or chain is really done2021-09-24T13:23:36ZBugzilla Migration Userdecodebin2: Fix detecting when a group or chain is really done## Submitted by GstBlub
**[Link to original bug (#794099)](https://bugzilla.gnome.org/show_bug.cgi?id=794099)**
## Description
Created attachment 369367
decodebin2: Fix detecting when a group or chain is really done
I ran int...## Submitted by GstBlub
**[Link to original bug (#794099)](https://bugzilla.gnome.org/show_bug.cgi?id=794099)**
## Description
Created attachment 369367
decodebin2: Fix detecting when a group or chain is really done
I ran into a problem where decodebin2 accidentally emits the "drained" signal (which an application could act on) and then causes the pipeline to stall with the demuxer continuing on. This happened when using hlsdemux with a video stream, but without any (suitable) video decoder plugin present. The application intentionally ignores the typefind error as we're only interested in the audio portion. This works fine until hlsdemux triggers a bitrate switch, which causes decodebin2 to believe everything is drained (despite the new pads being added and properly signalled). When this happens there are two chains in a group, one for the video portion (that isn't active) and one for the audio portion.
I attached a patch that appears to fix this issue for me. Since I'm not too familiar with this code, I'd appreciate any feedback.
**Patch 369367**, "decodebin2: Fix detecting when a group or chain is really done":
[0001-decodebin2-Fix-detecting-when-a-group-or-chain-is-re.patch](/uploads/68a0ce4adc933b29456aca34eb3e6dd1/0001-decodebin2-Fix-detecting-when-a-group-or-chain-is-re.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/423missing vaapipostproc causes gstreamer crash in glupload2021-09-24T13:23:36ZBugzilla Migration Usermissing vaapipostproc causes gstreamer crash in glupload## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesin...## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesink.
Local video plays well (pipeline is
gst-launch-1.0 filesrc location=bbb_sunflower_1080p_30fps_normal.mp4 ! decodebin ! glupload ! glimagesink
) however, when I'm trying to play RTSP stream using
gst-launch-1.0 udpsrc port=9001 ! application/x-rtp, encoding-name=H264 ! rtph264depay ! h264parse ! vaapih264dec low-latency=true ! videoconvert ! glupload ! glimagesink
it fails with following message:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayGBM\)\ gldisplaygbm0";
Got context from element 'vaapidecode_h264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Caught SIGSEGV
And here's the stack:
Thread 5 "gstglcontext" received signal SIGSEGV, Segmentation fault.
```
[Switching to Thread 0x7fffde651700 (LWP 2656)]
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
491 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt full
#0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
No locals.
#1 0x00007fffe96f87cf in memcpy (__len=3686400, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
No locals.
#2 gst_gl_buffer_upload_cpu_write (info=<optimized out>, size=3686400, mem=0x7fffd55a9470) at gstglbuffer.c:195
gl_map_flags = 2
gl = 0x555555c25950
data = <optimized out>
#3 _gl_buffer_map (mem=0x7fffd55a9470, info=<optimized out>, size=3686400) at gstglbuffer.c:212
gl = 0x555555c25950
#4 0x00007fffe96f7749 in _map_data_gl (context=<optimized out>, transfer=0x7fffde650b90) at gstglbasememory.c:277
alloc_class = 0x555555b43930
mem = 0x7fffd55a9470
info = 0x7fffde650c00
prev_map_flags = 0
prev_gl_map_count = 0
__func__ = "_map_data_gl"
__PRETTY_FUNCTION__ = "_map_data_gl"
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/422gl: GBM backend fixes2021-09-24T13:23:36ZBugzilla Migration Usergl: GBM backend fixes## Submitted by Daniel Stone `@daniels`
**[Link to original bug (#793997)](https://bugzilla.gnome.org/show_bug.cgi?id=793997)**
## Description
+++ This bug was initially created as a clone of [Bug 782923](https://bugzilla.gnome.org/...## Submitted by Daniel Stone `@daniels`
**[Link to original bug (#793997)](https://bugzilla.gnome.org/show_bug.cgi?id=793997)**
## Description
+++ This bug was initially created as a clone of [Bug 782923](https://bugzilla.gnome.org/show_bug.cgi?id=782923) +++
On devices with working libdrm support, it is possible to use Mesa3D's GBM library to set up an EGL context directly on top of KMS. This enhancement adds a GBM backend to the GstGL stack.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/421gst-play-1.0 --videosink=fakesink : position gets confused2021-09-24T13:23:35ZBugzilla Migration Usergst-play-1.0 --videosink=fakesink : position gets confused## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#793726)](https://bugzilla.gnome.org/show_bug.cgi?id=793726)**
## Description
Use case: "Let me listen to the music on this video file"
gst-play-1.0 file.mp4 --...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#793726)](https://bugzilla.gnome.org/show_bug.cgi?id=793726)**
## Description
Use case: "Let me listen to the music on this video file"
gst-play-1.0 file.mp4 --videosink=fakesink
The time counter at the bottom of gst-play-1.0 progresses much more quickly than the audio, I assume it progresses according to the fakesink. If I pause, the correct position is displayed, but then unpausing doesn't work.
If I use --videosink="fakesink sync=true" it works fine.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/420gstclockoverlay: Add ability to specify which time to be displayed by GstCloc...2021-09-24T13:23:35ZBugzilla Migration Usergstclockoverlay: Add ability to specify which time to be displayed by GstClockOverlay## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay ...## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay
GstClockOverlay presently displays buffer arrival time as default. In certain scenarios, users would like to display buffer's timestamp, rather than buffer arrival time - to avoid any gaps caused by latency between frame source and clockoverlay element in pipeline.
I propose to add property called "time-mode", where users should be able to specify what time to show. So other than current default, there can be another option for time-mode say "buffer-time", to indicate that clockoverlay will be using buffer's time for display.
Example element configuration can look like following :
clockoverlay halignment=right valignment=bottom time-format="%Y-%m-%d %H:%M:%S" time-mode=1
Where time-mode=1 represents "buffer-time".
Attached is the implementation for the same.
Note: GstTimeOverlay uses buffer time, but that doesn't have capability to display in clock format. Since clockoverlay is used to display text in clock format, it was found more suitable for said requirement.
**Patch 368688**, "Patch for adding ability to specify time to be displayed by GstClockOverlay":
[0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch](/uploads/df1e6b1c23d46b7b913d6173e0e8a506/0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/419theora_parse_chain segfaults on zero length buffer (gsttheoraparse.c)2021-09-24T13:23:34ZBugzilla Migration Usertheora_parse_chain segfaults on zero length buffer (gsttheoraparse.c)## Submitted by Cy
**[Link to original bug (#793500)](https://bugzilla.gnome.org/show_bug.cgi?id=793500)**
## Description
I'm not sure why gst_pad_push_data is pushing an empty 0-length buffer to theora_parse_chain, but the latter f...## Submitted by Cy
**[Link to original bug (#793500)](https://bugzilla.gnome.org/show_bug.cgi?id=793500)**
## Description
I'm not sure why gst_pad_push_data is pushing an empty 0-length buffer to theora_parse_chain, but the latter fails to deal with it properly, segfaulting instead of ignoring it, or erroring out. theora_parse_chain calls gst_buffer_map without checking the return value, then tries to access map.data[0] without checking whether map.data is NULL.
gst_buffer_map itself returns FALSE when the buffer's length is zero (in g_return_val_if_fail) and then checks again for some reason, zeroing out the GstMapInfo structure if the buffer's length is zero, then returning TRUE. I'm not sure if the second code branch is ever reached under any circumstances, but it'd probably be good to check if mem.data is NULL, even if gst_buffer_map returns TRUE.
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/417rtpbasepayload: inconsistent units for running-time in stats2021-09-24T13:23:33ZBugzilla Migration Userrtpbasepayload: inconsistent units for running-time in stats## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#793094)](https://bugzilla.gnome.org/show_bug.cgi?id=793094)**
## Description
The rtpbasepayloader reports the running time of the last processed buffer in the st...## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#793094)](https://bugzilla.gnome.org/show_bug.cgi?id=793094)**
## Description
The rtpbasepayloader reports the running time of the last processed buffer in the stats property. The unit of running time can be either ns or rtptime ticks depending on the setting of perfect-rtptime.
The gst-rtsp-server uses the running time to calculate the clock base for the RTP-Info header and assumes that running time is in ns and scales it to rtptime ticks afterwards. If the streams do not start at the same time, this can lead to an erroneous clock-base in the RTP-info and out of sync streams on the receiver.
I would expect that the running time in the stats is always in ns, but I am not sure about the actually intended design. Even the test-case for the rptbasepayloader rtp_base_payload_property_stats_test() switches the units of running time depending on the setting of perfect-rtptime.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/416GStreamer crashes when volume is set to 0 for raw PCM audio data with sink ti...2021-09-24T13:23:31ZBugzilla Migration UserGStreamer crashes when volume is set to 0 for raw PCM audio data with sink timestamp sync turned off## Submitted by Andrei Mikheev
**[Link to original bug (#793081)](https://bugzilla.gnome.org/show_bug.cgi?id=793081)**
## Description
Our raw PCM data does not have timestamps for the pipeline and it causes volume plugin to crash wi...## Submitted by Andrei Mikheev
**[Link to original bug (#793081)](https://bugzilla.gnome.org/show_bug.cgi?id=793081)**
## Description
Our raw PCM data does not have timestamps for the pipeline and it causes volume plugin to crash with messages complaining about a timestamp expected when we set the volume to 0 or mute. Note that we use autoaudiosink with "sync=false" option.
How to reproduce:
gst-launch-1.0 -v filesrc location=rawpcm.wav ! decodebin ! queue ! audioconvert ! volume volume=0 ! autoaudiosink sync=false
The version of this with volume set to non-zero value actually works:
gst-launch-1.0 -v filesrc location=rawpcm.wav ! decodebin ! queue ! audioconvert ! volume volume=1 ! autoaudiosink sync=false
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/414audiotestsrc: wrong offset when rate is changed at runtime2021-09-24T13:23:28ZBugzilla Migration Useraudiotestsrc: wrong offset when rate is changed at runtime## Submitted by Justin Kim `@joykim`
**[Link to original bug (#792395)](https://bugzilla.gnome.org/show_bug.cgi?id=792395)**
## Description
If rate is changed at runtime, audiotestsrc sends buffers with wrong offset.
It can be fix...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#792395)](https://bugzilla.gnome.org/show_bug.cgi?id=792395)**
## Description
If rate is changed at runtime, audiotestsrc sends buffers with wrong offset.
It can be fixed by accumulating offset whenever it sends buffers. However, when it comes to seek, it seems not to be easy.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/413subtitleoverlay: caps negotiation error2021-09-24T13:23:27ZBugzilla Migration Usersubtitleoverlay: caps negotiation error## Submitted by Philippe Normand `@philn`
**[Link to original bug (#792309)](https://bugzilla.gnome.org/show_bug.cgi?id=792309)**
## Description
Created attachment 366466
pipeline dump
This happens on macOS with blu-ray rips ...## Submitted by Philippe Normand `@philn`
**[Link to original bug (#792309)](https://bugzilla.gnome.org/show_bug.cgi?id=792309)**
## Description
Created attachment 366466
pipeline dump
This happens on macOS with blu-ray rips containting subtitle tracks. The issue seems to be in subtitleoverlay.
**Attachment 366466**, "pipeline dump":
![0.00.00.881026000-gst-play.error](/uploads/f0c1fdf96f0200fdd1603e1197c1c8a1/0.00.00.881026000-gst-play.error.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/412appsrc: uncertainty moment in the documentation2021-09-24T13:23:26ZBugzilla Migration Userappsrc: uncertainty moment in the documentation## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freede...## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsrc.html#gst-app-src-push-buffer
Function takes ownership, but signal doesn't.
It was tricky, because I didn't find the documentation for signal in the web.
But in appsrc's code it exists:
/**
* GstAppSrc::push-buffer:
* @appsrc: the appsrc
* @buffer: a buffer to push
*
* Adds a buffer to the queue of buffers that the appsrc element will
* push to its source pad. This function does not take ownership of the
* buffer so the buffer needs to be unreffed after calling this function.
*
And the web-page only says:
----
The main way of handing data to the appsrc element is by calling the gst_app_src_push_buffer() method or by emitting the push-buffer action signal.
----
But gst_app_src_push_buffer
is not a signal handler for "push-buffer", that's what's tricky.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/411glimagesink: need fix video tearing2021-09-24T13:23:25ZBugzilla Migration Userglimagesink: need fix video tearing## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791937)](https://bugzilla.gnome.org/show_bug.cgi?id=791937)**
## Description
video will tearing when using glimagesink. eglswapbuffer is an async call. That means the GP...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791937)](https://bugzilla.gnome.org/show_bug.cgi?id=791937)**
## Description
video will tearing when using glimagesink. eglswapbuffer is an async call. That means the GPU has not complete the drawing on display, but sink has return and doing next buffer perparing.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/410Add KLV meta and add support for it in matroska mux/demux2023-02-04T15:09:15ZBugzilla Migration UserAdd KLV meta and add support for it in matroska mux/demux## Submitted by Tim Müller `@tpm`
**[Link to original bug (#791918)](https://bugzilla.gnome.org/show_bug.cgi?id=791918)**
## Description
Created attachment 365925
buffer: add gst_buffer_get_n_meta() convenience function (core)
...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#791918)](https://bugzilla.gnome.org/show_bug.cgi?id=791918)**
## Description
Created attachment 365925
buffer: add gst_buffer_get_n_meta() convenience function (core)
This adds a GstKLVMeta to libgsttag, which allows attaching arbitrary metadata in KLV format to buffers.
Plus patches to read/write those to/from Matroska as BLOCKADDITIONALs.
And an extra patch to v4l2src for testing which is not for merging.
**Patch 365925**, "buffer: add gst_buffer_get_n_meta() convenience function (core)":
[0001-buffer-add-gst_buffer_get_n_meta-convenience-functio.patch](/uploads/a27b4ac622569edcf68110d8ec669d6e/0001-buffer-add-gst_buffer_get_n_meta-convenience-functio.patch)
### Depends on
* [Bug 791415](https://bugzilla.gnome.org/show_bug.cgi?id=791415)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/409opusenc, opusdec: add option to disable phase inversion2021-09-24T13:23:24ZBugzilla Migration Useropusenc, opusdec: add option to disable phase inversion## Submitted by Hector Martin
**[Link to original bug (#791771)](https://bugzilla.gnome.org/show_bug.cgi?id=791771)**
## Description
http://opus-codec.org/docs/opus_api-1.2/group__opus__genericctls.html#ga10fa1f6eab136baf83c232afa98...## Submitted by Hector Martin
**[Link to original bug (#791771)](https://bugzilla.gnome.org/show_bug.cgi?id=791771)**
## Description
http://opus-codec.org/docs/opus_api-1.2/group__opus__genericctls.html#ga10fa1f6eab136baf83c232afa989b6a8
When downmixing stereo streams to mono, having phase inversion enabled produces terrible audio quality (it sounds like a low bitrate MP3), since frequency bands randomly cancel out. This should be exposed in the encoder (to produce bitstreams that always sound good when downmixed to mono, regardless of what the decoder does), and in the decoder (to allow any arbitrary bitstream to sound good when downmixed to mono, regardless of what the encoder did). On the decoder, additionally, it should probably default to disabled (i.e. OPUS_SET_PHASE_INVERSION_DISABLED(1)) when the output channel count is 1.
Here's a sample of just how bad decoding opus to mono without this enabled sounds: https://mrcn.st/t/opus_decoding_test.ogg . This is 6 seconds of stereo decoding, 3 seconds of mono decoding, repeatedly. The input bitstream is the same in both cases, with phase inversion enabled, as is the case right now in gstreamer. It gets *really* bad at 0:50 or so.
See also: https://tools.ietf.org/html/rfc8251#section-10https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/408tcpserversink and tcpclientsrc: fail to stream tcp/rtp in Windows2021-09-24T13:23:24ZBugzilla Migration Usertcpserversink and tcpclientsrc: fail to stream tcp/rtp in Windows## Submitted by Prezla Petrus
**[Link to original bug (#791766)](https://bugzilla.gnome.org/show_bug.cgi?id=791766)**
## Description
Created attachment 365732
server and client pipes screen capture
tcpserversink and tcpclient...## Submitted by Prezla Petrus
**[Link to original bug (#791766)](https://bugzilla.gnome.org/show_bug.cgi?id=791766)**
## Description
Created attachment 365732
server and client pipes screen capture
tcpserversink and tcpclientsrc don't appear to stream rtp data in Windows 10 (and Windows 7) environment. The problem reproduces for me with gstreamer 1.12.2 and 1.12.4.
Steps to reproduce
1. Turn off firewall in Windows
2. Install gstreamer using gstreamer-1.0-x86_64-1.12.4.msi and selecting full installation
3. Install gstreamer-devel using gstreamer-1.0-devel-x86_64-1.12.4.msi and selecting full installation
4. Start command line and run this server pipeline gst-launch-1.0 --gst-debug="tcp*:7,3" videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! rtpstreampay ! tcpserversink host=127.0.0.1 port=5000
5. Start 2nd command line and run this client pipeline gst-launch-1.0 --gst-debug="tcp*:7,3" tcpclientsrc host=127.0.0.1 port=5000 ! fakesink silent=false
6. Noticed the problem where no rtp data flows between server and client
Notes:
a) Same pipelines work in Raspberry Pi (linux) with gstreamer 1.10.4
b) If I use udpsink and udpsrc the pipelines work in Windows, e.g. these pipelines work:
gst-launch-1.0 -v videotestsrc is-live=true ! videoconvert ! videoscale ! video/x-raw,format=I420,width=800,height=600,framerate=25/1 ! x264enc ! rtph264pay ! udpsink host=127.0.0.1 port=5000
gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! avdec_h264 ! autovideosink
Thanks
**Attachment 365732**, "server and client pipes screen capture":
[pipes.zip](/uploads/602cb0e944bb31da128d41077184c309/pipes.zip)
Version: 1.12.4