After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773665 - playbin cannot recover from network interruption while streaming a live HTTP stream
playbin cannot recover from network interruption while streaming a live HTTP ...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.9.90
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-10-29 10:12 UTC by Eric Toombs
Modified: 2018-11-03 11:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
starts a command upon receipt of HTTP GET and returns the result. (1.21 KB, text/x-python)
2016-10-29 10:12 UTC, Eric Toombs
Details

Description Eric Toombs 2016-10-29 10:12:05 UTC
Created attachment 338770 [details]
starts a command upon receipt of HTTP GET and returns the result.

By live stream, here, I mean a stream whose content is being decided in real time.

When I try to stream such a stream with playbin, it dies after the first major network interruption (perhaps a 5 second outage). The buffer either gets stuck at 0% or goes from 0 to 100, then right back to zero again, with nothing being played during this time. I did the test using a gst-launch command like this one:

$ gst-launch-1.0 playbin uri=http://example.com/live/stream

I was testing a live flac stream (~100KB/s) over a wifi network. I simulated interruptions by toggling the rfkill for a few seconds. I tested the same stream with ffplay and with a gst-launch pipeline that looks like this:

$ gst-launch-1.0 souphttpsrc location=http://server:10000/ ! queue max-size-bytes=65536 max-size-buffers=0 max-size-time=0 leaky=downstream !
decodebin ! autoaudiosink sync=false

Both were able to recover without any problems. I am attaching the script I used as a simple HTTP server. I saw similar problems with pulseaudio-dlna's HTTP server. This is how I invoked my server:

$ todd bash -c 'pacat -r -d alsa_output.pci-0000_00_07.0.analog-stereo.monitor --latency=100000000 | flac --force-raw-format --endian=little --sign=signed --sample-rate=44100 --bps=16 --channels=2 -'

I hope somebody else can reproduce this. I've managed to do so on two different hosts, one armv7l and the other amd64, both Linux.
Comment 1 Eric Toombs 2016-10-29 10:20:16 UTC
Comment on attachment 338770 [details]
starts a command upon receipt of HTTP GET and returns the result.

>#!/usr/bin/env python
>
>from socketserver import TCPServer
>from http.server import BaseHTTPRequestHandler
>import subprocess as sp
>from sys import *
>
>class ToddHandler(BaseHTTPRequestHandler):
>    def do_GET(self):
>        stderr.write('Client has connected.\n')
>        self.send_response(200)
>        self.end_headers()
>        p = sp.Popen(argv[1:], stdout=sp.PIPE)
>        while True:
>            data = p.stdout.read(1024)
>            if len(data) == 0:
>                break
>
>            try:
>                self.wfile.write(data)
>            except BrokenPipeError:
>                break
>            except ConnectionResetError:
>                break
>        stderr.write('Client has disconnected.\n')
>        p.stdout.close()
>        # The previous call is enough to stop the command, but it will be a 
>        # zombie until after the exit code is read. This is what this last 
>        # p.wait() call is for. DIE ZOMBIES!!
>        p.wait()
>
>if len(argv) == 1:
>    stderr.write('usage: todd command [arg1 arg2 ...]\n')
>    exit(1)
>
># Create the server.
>server = TCPServer(('', 10000), ToddHandler)
>
># Activate the server; this will keep running until you
># interrupt the program with Ctrl-C
>server.serve_forever()
Comment 2 Edward Hervey 2018-05-05 16:11:52 UTC
Hi Eric,

 * Is this still an issue with latest 1.14 release ?
 * Is it fixed if you use playbin3 instead of playbin ?
Comment 3 GStreamer system administrator 2018-11-03 11:51:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/303.