Gstreamer Pipeline

[sqwk]

Instead of encoding with ffmpeg, does anyone have an example for a gstreamer pipeline, preferably using webM instead of H.264?

[vbence]

I must admit, I'm not familiar with GStreamer. I remember implementing both POST and PUT (one for ffmpeg one for gstreamer's curlsink module) - because some people were experimenting with it.

Feel free to give it a try and if you have any stream-m errors let me know.

[sqwk]

Unfortunately, I have not managed to get a webM stream working, but pushing data in via RMTP works fine.

gst-launch-1.0 rpicamsrc bitrate=1000000 ! video/x-h264, stream-format=byte-stream, profile=high, width=1920, height=1080, framerate=25/1 ! h264parse ! flvmux ! rtmpsink location="rtmp://localhost:8081/publish/first?secret"

This also uses gst-rpicamsrc (https://github.com/thaytan/gst-rpicamsrc) to capture the camera from a Raspberry Pi 2. Delay is about 2s.

[vbence]

Have you tried using curlsink instead of rtmpsink, plus a http location?

[sqwk]

gst-launch-1.0 rpicamsrc bitrate=500000 ! video/x-h264, stream-format=byte-stream, profile=high, width=1920, height=1080, framerate=25/1 ! videoparse ! vp8enc ! webmmux ! curlhttpsink location=http://localhost:8080/publish/first?password=secret

The pipeline works in as it doesn't generate any errors (after compiling the hotfix mentioned in the other ticket). However, it also does not produce any log entry on the server, nor any image in the browser. (The video area stays black) Any ideas?

[vbence]

I will take a closer look later this week.

[vbence]

I'm doing a:

gst-launch-1.0 filesrc location=Downloads/univac.webm ! curlhttpsink location=http://localhost:8080/publish/first?password=secret

...but it does not connect to port 8080.

[vbence]

It looks like a GStreamer error (or rather me not coming up with the right graph). The closest I got was with this:

gst-launch-1.0 v4l2src ! videoscale ! "video/x-raw,width=320,height=200" ! vp8enc ! webmmux ! souphttpclientsink location=http://localhost:8080/publish/first?password=secret

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstSoupHttpClientSink:souphttpclientsink0: Could not write to HTTP URI
Additional debug info:
gstsouphttpclientsink.c(765): gst_soup_http_client_sink_render (): /GstPipeline:pipeline0/GstSoupHttpClientSink:souphttpclientsink0:
error: 7 Connection terminated unexpectedly
Execution ended after 0:00:01.776066719
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

On the server side I'm getting the following EBML elements:

EBMLElement ID:0x1a45dfa3 size: 16
EBMLElement ID:0x18538067 size: 72057594037927935
EBMLElement ID:0x1549a966 size: 80
EBMLElement ID:0x1549a966 size: 80
EBMLElement ID:0x1654ae6b size: 68
EBMLElement ID:0xae size: 59
EBMLElement ID:0xd7 size: 1
EBMLElement ID:0x83 size: 1
EBMLElement ID:0x73c5 size: 8
EBMLElement ID:0x536e size: 6
EBMLElement ID:0xe0 size: 16
EBMLElement ID:0x86 size: 6
EBMLElement ID:0x1549a966 size: 80
EBMLElement ID:0x1654ae6b size: 68
EBMLElement ID:0x1f43b675 size: 72057594037927935
EBMLElement ID:0xe7 size: 2
EBMLElement ID:0xa3 size: 13727

... then the connection is closed by the client.

Note: I had to patch the stream processor to accept endless Segment elements to get this far.

[sqwk]

Without a patch I seem to get the same error using this pipeline:

gst-launch-1.0 videotestsrc ! vp8enc ! webmmux streamable=true ! souphttpclientsink location=http://localhost:8080/publish/high?password=secret

Using curlhttpsink instead of souphttpclientsink produces no errors, but nothing is echoed by the server and visiting http://127.0.0.1:8080/consume/high produces a black video instead of the usual "Stream Not Running".

This works, so the beginning of the pipeline is fine:

gst-launch-1.0 videotestsrc ! vp8enc ! webmmux ! filesink location=~/test.webm

[vbence]

What I have so far is pushed to the https://github.com/vbence/stream-m/tree/gstreamer-compat branch.

[vbence]

I was trying to figure out how exactly the connection was closed, so took a look a Wireshark. The result was a very interesting:

38  3.129792000 127.0.0.1   127.0.0.1   TCP 74  [TCP Spurious Retransmission] 44923→8080 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=5866006 TSecr=0 WS=128

It seems pretty mysterious this far...