gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2023-10-12T17:51:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/388rtspsrc: reduce default latency from 2.0 secs to 0.5 secs2023-10-12T17:51:39ZBugzilla Migration Userrtspsrc: reduce default latency from 2.0 secs to 0.5 secs## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By d...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By default rtspsrc uses a fairly high default latency of 2 seconds.
I wonder if this really makes sense, and what this is based on.
If there's no Good Reason(tm) then perhaps we should reduce that drastically to something lower, maybe 500ms or even 250ms ?
People who are on very bad networks can still set this to something higher manually.
**Patch 355318**, "rtspsrc: reduce default latency from 2.0 secs to 0.5 secs":
[0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch](/uploads/f189ee328b755dcc3970016a9ac74065/0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/385rtp: vrawdepay: add support for 8-bit monochrome along with UK DEF STAN 00-82...2021-09-24T13:32:29ZBugzilla Migration Userrtp: vrawdepay: add support for 8-bit monochrome along with UK DEF STAN 00-82 compliant scan lines## Submitted by Craig McLaren
**[Link to original bug (#784254)](https://bugzilla.gnome.org/show_bug.cgi?id=784254)**
## Description
Created attachment 354575
Patch file including modified versions of rtpvrawdepay .c and .h
m...## Submitted by Craig McLaren
**[Link to original bug (#784254)](https://bugzilla.gnome.org/show_bug.cgi?id=784254)**
## Description
Created attachment 354575
Patch file including modified versions of rtpvrawdepay .c and .h
modified rtpvrawdepay.c + .h to allow 8-bit monochrome sampling as per section 5 figure 12 in UK DEF STAN 00-82 Part 1 Issue 2. Also added scan line modification for DEF STAN 00-82 compliant feeds.
**Patch 354575**, "Patch file including modified versions of rtpvrawdepay .c and .h":
[0001-rtp-rtpvrawdepay-added-support-for-8-bit-monochrome-.patch](/uploads/c3d7492604bc02e9289366ad0a7c28c3/0001-rtp-rtpvrawdepay-added-support-for-8-bit-monochrome-.patch)
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/383rtpmanager: Add support for in-band synchronization (RFC 6051).2022-04-20T15:14:58ZBugzilla Migration Userrtpmanager: Add support for in-band synchronization (RFC 6051).## Submitted by GstBlub
**[Link to original bug (#784132)](https://bugzilla.gnome.org/show_bug.cgi?id=784132)**
## Description
Created attachment 354323
rtpmanager
This allows endpoints to synchronize instantly rather than ha...## Submitted by GstBlub
**[Link to original bug (#784132)](https://bugzilla.gnome.org/show_bug.cgi?id=784132)**
## Description
Created attachment 354323
rtpmanager
This allows endpoints to synchronize instantly rather than having to wait for the first RTCP SR.
~~**Patch 354323**~~, "rtpmanager":
[0001-rtpmanager-Add-support-for-in-band-synchronization-R.patch](/uploads/2daa428c2c926ff9edd973cdb5d24798/0001-rtpmanager-Add-support-for-in-band-synchronization-R.patch)Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/381splitmuxsink: Added new async-finalize mode2020-03-11T05:26:15ZBugzilla Migration Usersplitmuxsink: Added new async-finalize mode## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#783754)](https://bugzilla.gnome.org/show_bug.cgi?id=783754)**
## Description
See commit message## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#783754)](https://bugzilla.gnome.org/show_bug.cgi?id=783754)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/366multifilesink: add "prefix" property2023-06-02T16:43:27ZBugzilla Migration Usermultifilesink: add "prefix" property## Submitted by Ligverd
**[Link to original bug (#781497)](https://bugzilla.gnome.org/show_bug.cgi?id=781497)**
## Description
Created attachment 350066
add property prefix multifilesink
add property "prefix"
multifilesi...## Submitted by Ligverd
**[Link to original bug (#781497)](https://bugzilla.gnome.org/show_bug.cgi?id=781497)**
## Description
Created attachment 350066
add property prefix multifilesink
add property "prefix"
multifilesink prefix="record/%Y/%m/%d/%H%M" location=-%010d.ts""
prefix is the syntax for strftime
and automatically creates the required directory
/2017/04/01/1056-0000000001.ts
**Patch 350066**, "add property prefix multifilesink":
[add_prefix_multifilesink.patch](/uploads/b852ae3bde60fd9f2f71aad118cfb86d/add_prefix_multifilesink.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/356souphttpsrc: Implement soup session sharing2020-02-19T04:52:39ZBugzilla Migration Usersouphttpsrc: Implement soup session sharing## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#780140)](https://bugzilla.gnome.org/show_bug.cgi?id=780140)**
## Description
Also needs some patches for adaptivedemux to make use of that, but with that
it's then...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#780140)](https://bugzilla.gnome.org/show_bug.cgi?id=780140)**
## Description
Also needs some patches for adaptivedemux to make use of that, but with that
it's then possible to use exactly the same connection for the initial
manifest, any variant manifests and the fragments. Which speeds up
time-to-play a lot especially if using HTTPS where every connection setup is
very expensive.
### See also
* [Bug 785110](https://bugzilla.gnome.org/show_bug.cgi?id=785110)
* [Bug 762138](https://bugzilla.gnome.org/show_bug.cgi?id=762138)1.13.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/354rtspsrc: allow to override the range in the SDP2021-09-24T13:32:15ZBugzilla Migration Userrtspsrc: allow to override the range in the SDP## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779859)](https://bugzilla.gnome.org/show_bug.cgi?id=779859)**
## Description
Created attachment 347644
The Time range to use for media descriptions
Some RTSP ...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779859)](https://bugzilla.gnome.org/show_bug.cgi?id=779859)**
## Description
Created attachment 347644
The Time range to use for media descriptions
Some RTSP stacks cause havoc with timing when they advertise the time in the RTSP negotiation.
**Patch 347644**, "The Time range to use for media descriptions":
[0002-rtspsrc-add-forced-range-to-overrule-the-range-in-th.patch](/uploads/e225e53d31b855ea0b2479b1c658201e/0002-rtspsrc-add-forced-range-to-overrule-the-range-in-th.patch)
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/353misc payloaders: remove dependency on payload type in caps to link2021-09-24T13:32:15ZBugzilla Migration Usermisc payloaders: remove dependency on payload type in caps to link## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779851)](https://bugzilla.gnome.org/show_bug.cgi?id=779851)**
## Description
Created attachment 347635
Relax PTs
Some payloaders have strict dependencies on t...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779851)](https://bugzilla.gnome.org/show_bug.cgi?id=779851)**
## Description
Created attachment 347635
Relax PTs
Some payloaders have strict dependencies on the pt type to link, while some hardware encoders do not use these.
This fails to link the elements, when the encoding-name should be enough to link.
**Patch 347635**, "Relax PTs":
[0004-Apply-and-update-patch-gst-plugins-good-relax-pts.di.patch](/uploads/9e718623daa19a22789587d3ba1d0ca2/0004-Apply-and-update-patch-gst-plugins-good-relax-pts.di.patch)
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/352multifilesink: add URI handler2021-09-24T13:32:14ZBugzilla Migration Usermultifilesink: add URI handler## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779850)](https://bugzilla.gnome.org/show_bug.cgi?id=779850)**
## Description
Created attachment 347634
mfilesink: add uri-handler
Add uri handler to mfilesink...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779850)](https://bugzilla.gnome.org/show_bug.cgi?id=779850)**
## Description
Created attachment 347634
mfilesink: add uri-handler
Add uri handler to mfilesink
~~**Patch 347634**~~, "mfilesink: add uri-handler":
[0011-multifilesink-add-URI-handler.patch](/uploads/0da908abb469d28d6904b5fb4c1f5be7/0011-multifilesink-add-URI-handler.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/345isomp4: initial ftyp/moov streamheader missing2023-10-13T15:59:32ZBugzilla Migration Userisomp4: initial ftyp/moov streamheader missing## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#777984)](https://bugzilla.gnome.org/show_bug.cgi?id=777984)**
## Description
i've tried to randomly enter a stream generated with mp4dashmux from
https://bugzill...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#777984)](https://bugzilla.gnome.org/show_bug.cgi?id=777984)**
## Description
i've tried to randomly enter a stream generated with mp4dashmux from
https://bugzilla.gnome.org/show_bug.cgi?id=668091 to play it in the browser using MSE. unfortunately, this failed, using a tcpserversink element and trying the various sync-methods. looking at the captured streams i discovered that the global headers are missing:
when it should start with:
0000 0000: 00 00 00 1C 66 74 79 70 69 73 6F 35 00 00 00 01 ....ftyp iso5....
0000 0010: 69 73 6F 35 69 73 6F 32 64 61 73 68 00 00 03 45 iso5iso2 dash...E
0000 0020: 6D 6F 6F 76 00 00 00 6C 6D 76 68 64 00 00 00 00 moov...l mvhd....
the randomly entered streams only start with:
0000 0000: 00 00 00 14 73 74 79 70 6D 73 64 68 00 00 00 00 ....styp msdh....
0000 0010: 6D 73 64 68 00 00 00 60 6D 6F 6F 66 00 00 00 10 msdh...` moof....
0000 0020: 6D 66 68 64 00 00 00 00 00 00 00 6B 00 00 00 48 mfhd.... ...k...H
qtmux does implement some streamheader handling, but it seems to be missing something for my use case. i'll investiage.
### Depends on
* [Bug 668091](https://bugzilla.gnome.org/show_bug.cgi?id=668091)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/338gtk4: Add Gst (GL) Gtk4 plugin2023-10-12T18:18:40ZBugzilla Migration Usergtk4: Add Gst (GL) Gtk4 plugin## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 wo...## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 works correctly, we can build a plugin with this version.
**Patch 342658**, "[PATCH] Add Gst (GL) Gtk4 plugin":
[0001-Add-Gst-GL-Gtk4-plugin.patch](/uploads/c9ca16d576a27b9b20dc2dcfd7c565d3/0001-Add-Gst-GL-Gtk4-plugin.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/334Add support for resolving IPv4 address literals for DNS64 support2023-10-13T16:05:44ZBugzilla Migration UserAdd support for resolving IPv4 address literals for DNS64 support## Submitted by joe..@..il.com
**[Link to original bug (#776344)](https://bugzilla.gnome.org/show_bug.cgi?id=776344)**
## Description
The source of creating this bug can be found in the discussion here: http://gstreamer-devel.966125...## Submitted by joe..@..il.com
**[Link to original bug (#776344)](https://bugzilla.gnome.org/show_bug.cgi?id=776344)**
## Description
The source of creating this bug can be found in the discussion here: http://gstreamer-devel.966125.n4.nabble.com/NAT64-support-td4681208.html.
When on NAT64 networks, passing an IPv4 address literal does not get automatically resolved to its IPv6 equivalent so streaming via elements such as udpsink or udpsrc doesn't work. This is required for iOS as described here: https://developer.apple.com/library/content/documentation//NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/333matroskamux: reduce muxing overhead with audio-only streams2021-09-24T13:32:06ZBugzilla Migration Usermatroskamux: reduce muxing overhead with audio-only streams## Submitted by Tim Müller `@tpm`
**[Link to original bug (#776326)](https://bugzilla.gnome.org/show_bug.cgi?id=776326)**
## Description
+++ This bug was initially created as a clone of [Bug 754696](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#776326)](https://bugzilla.gnome.org/show_bug.cgi?id=776326)**
## Description
+++ This bug was initially created as a clone of [Bug 754696](https://bugzilla.gnome.org/show_bug.cgi?id=754696) +++
We might need to add a property to configure the max interleaving delay for audio-only streams, so we can lace multiple audio frames into one cluster and only mark the cluster start as keyframe for multifdsink, in order to avoid the extra mux overhead of putting each audio frame into its own cluster.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/328ximagesrc crashes if its display is restarted.2021-09-24T13:32:04ZBugzilla Migration Userximagesrc crashes if its display is restarted.## Submitted by Stirling Westrup
**[Link to original bug (#774814)](https://bugzilla.gnome.org/show_bug.cgi?id=774814)**
## Description
We have a pipeline that we wish to keep running as long as possible, even in the face of various...## Submitted by Stirling Westrup
**[Link to original bug (#774814)](https://bugzilla.gnome.org/show_bug.cgi?id=774814)**
## Description
We have a pipeline that we wish to keep running as long as possible, even in the face of various failures. In particular, we sometimes need to restart X seervers. If we are currently using ximagesrc to capture from that X server, then restarting the server will crash ximagesrc:
[root@chronos ~]# gst-launch-1.0 ximagesrc display-name=:46 ! fakesink sync=true
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
# pkill -fl -9 "Xorg :46"
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":46"
after 51 requests (51 known processed) with 0 events remaining.
This brings down our entire pipeline, even when we are handling dozens of video outputs and only one or two would be logically affected by the loss of the input.
We would far rather have a black screen, possibly accompanied by an internal pipeline message, than a crash if an X server is rebooted.
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/325multifilesink: Added parameter for setting min keyframe based file size2021-09-24T13:32:03ZBugzilla Migration Usermultifilesink: Added parameter for setting min keyframe based file size## Submitted by Dimitrios Katsaros
**[Link to original bug (#774621)](https://bugzilla.gnome.org/show_bug.cgi?id=774621)**
## Description
Currently, multifilesink using the key-frame option for the next-file
parameter creates segm...## Submitted by Dimitrios Katsaros
**[Link to original bug (#774621)](https://bugzilla.gnome.org/show_bug.cgi?id=774621)**
## Description
Currently, multifilesink using the key-frame option for the next-file
parameter creates segments with a minimum duration of 10 seconds.
However, depending on the application or the format being used, the
user may require a different duration or a minimal size for every
segment. This patch adds the min-keyframe-file-size parameter,
allowing the user to set the minimal duration.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/324matroskademux: should not do I/O in seek handler2021-09-24T13:32:02ZBugzilla Migration Usermatroskademux: should not do I/O in seek handler## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774315)](https://bugzilla.gnome.org/show_bug.cgi?id=774315)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774315)](https://bugzilla.gnome.org/show_bug.cgi?id=774315)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_bug.cgi?id=613351) +++
Matroska demux (and other parsers/demuxers) should not do any I/O in the seek handler, as currently done in gst_matroska_demux_search_pos(). This should be
done from the streaming thread instead, and the element should maybe also post PROGRESS messages on the bus about seek started/finished/failed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/322splitmuxsink goes to dead lock when used along with other sinks2021-09-24T13:32:02ZBugzilla Migration Usersplitmuxsink goes to dead lock when used along with other sinks## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#773940)](https://bugzilla.gnome.org/show_bug.cgi?id=773940)**
## Description
pipeline goes to dead lock when splitmux sink is used in parallel with other sink.
...## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#773940)](https://bugzilla.gnome.org/show_bug.cgi?id=773940)**
## Description
pipeline goes to dead lock when splitmux sink is used in parallel with other sink.
Example pipeline.
gst-launch-1.0 videotestsrc ! x264enc ! tee name=split \
split.! queue ! splitmuxsink muxer=mpegtsmux location=/root/vinod/apple_tv_ad__.ts \
split.! queue ! mpegtsmux ! udpsink host=10.0.100.3 port=9000
When udpsink is replaced with another splitmux sink pipeline works perfectly fine.
This issue is present in 1.6.4 , 1.8.2 1.10.0 and master.
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/321tests/jitterbuffer: fix indentation2019-05-30T15:30:53ZBugzilla Migration Usertests/jitterbuffer: fix indentation## Submitted by Håvard Graff (hgr)
**[Link to original bug (#773906)](https://bugzilla.gnome.org/show_bug.cgi?id=773906)**
## Description
Created attachment 339055
indentation-fix
And make the beautiful ascii-art gst-indent p...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#773906)](https://bugzilla.gnome.org/show_bug.cgi?id=773906)**
## Description
Created attachment 339055
indentation-fix
And make the beautiful ascii-art gst-indent proof.
**Patch 339055**, "indentation-fix":
[indentation-fix.patch](/uploads/44071074ffc829ad33e395521cc02284/indentation-fix.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/320rtpL16depay, rtpL24depay: support depayloading in place2023-10-12T18:26:04ZBugzilla Migration UserrtpL16depay, rtpL24depay: support depayloading in place## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to d...## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to depayload in place. It always allocates a new buffer and copies the payload.
This is the log I'm seeing:
```
0:00:13.489419481 1060 0x1ec5150 DEBUG rtpL16depay gstrtpL16depay.c:243:gst_rtp_L16_depay_process:`<rtpl16depay0>` got payload of 192 bytes
0:00:13.489596481 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:798:gst_buffer_new: new 0x75c05370
0:00:13.489760981 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:2038:gst_buffer_copy_region: new region copy 0x75c05370 of 0x75c054b0 12-192
0:00:13.490969772 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:514:gst_buffer_copy_into: copy 0x75c054b0 to 0x75c05370, offset 12-192/204
--
0:00:13.493352979 1060 0x1ec5150 TRACE GST_LOCKING gstminiobject.c:177:gst_mini_object_lock: lock 0x1ecb690: state 00020000, access_mode 3
0:00:13.493546312 1060 0x1ec5150 DEBUG GST_LOCKING gstminiobject.c:212:gst_mini_object_lock: lock failed 0x1ecb690: state 00020000, access_mode 3
0:00:13.493717020 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:317:gst_memory_map: mem 0x1ecb690: lock 3 failed
0:00:13.493910270 1060 0x1ec5150 TRACE GST_REFCOUNTING gstobject.c:249:gst_object_ref:`<allocatorsysmem0>` 0x1ddc010 ref 6->7
0:00:13.494091270 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0x1ecb578, maxsize:195 offset:0 size:192
0:00:13.494364978 1060 0x1ec5150 DEBUG GST_PERFORMANCE gstallocator.c:462:_sysmem_copy: memcpy 192 memory 0x1ecb690 -> 0x1ecb578
```
And this is the command:
`GST_DEBUG=9 gst-launch-1.0 audiotestsrc is-live=true wave=silence samplesperbuffer=48 ! "audio/x-raw,format=(string)S16BE,rate=(int)48000,channels=(int)2,channel-mask=(int)0x3" ! rtpL16pay ! rtpL16depay ! fakesink
2>&1 | grep -B 5 copy`
It happens in gst_audio_buffer_reorder_channels() when mapping the buffer read-write. It doesn't really matter what the source is, the same happens with udpsrc.
--
The other thing here is that if the channels don't require reordering (like in my case) the buffer shouldn't be remapped read-write. Otherwise the potential buffer copy is redundant.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/317souphttpsrc: Use non-blocking reads2021-09-24T13:32:00ZBugzilla Migration Usersouphttpsrc: Use non-blocking reads## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#773727)](https://bugzilla.gnome.org/show_bug.cgi?id=773727)**
## Description
+++ This bug was initially created as a clone of [Bug 773509](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#773727)](https://bugzilla.gnome.org/show_bug.cgi?id=773727)**
## Description
+++ This bug was initially created as a clone of [Bug 773509](https://bugzilla.gnome.org/show_bug.cgi?id=773509) +++
It had to be reverted in 60d30db912a1aedd743e66b9dcd2e21d71fbb24f due to some problems. Needs further investigation and then get added back.
Problem might be in GLib or libsoup.