Icecast dev - Jul 2013 - How to use http-put for JavaScript source client

I'm following up on a thread started by Stephen a couple months ago about
building a JavaScript source client using webrtc.

The first step suggested was to figure out how to mux the audio and video. After
I posted a feature request on the webrtc experiment js library, we seem to have
a solution:
https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-20791759

Based on the last comment on the icecast Dec list, we now only need to do do an
HTTP put request to the icecast server (
http://lists.xiph.org/pipermail/icecast-dev/2013-May/002171.html).

Great! I've got my jquery ready, but am having trouble finding docs on how
to build the put request. I tried looking at the libshout source, but my c
skills aren't quite good enough to figure it out.

Any help would be appreciated, particularly with an example.

Thanks for all your work on icecast - we use it a lot here at May First/People
Link.

Jamie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20130723/1dff78bc/attachment.htm

Hi Jamie,

The webRTC API does not sound suitable for source->server streaming
for many reason. For instance, the peer-to-peer connection requires
input from both end and seems quite unfeasible to implement in a
server. Likewise, codecs are completely abstracted and much more.

In reality, webRTC is an API to acheive full-duplex conversations a-la
skype and not for streaming.

For these reasons, we at liquidsoap have been working on implementing
a simple websocket protocol for sending source streams from a browser
to a server. The protocol is documented and implemented there:
  https://github.com/savonet/webcast

We also have a pull request on liquidsoap that implements the protocol
and should be merged fairly soon:
  https://github.com/savonet/liquidsoap/pull/90

The bottlenecks right now are the availability of the Web Audio API,
which is only partially implemented in firefox and the encoding speed.

Because there is no native encoding API for browser-side javascript,
we have (temporarily?) resorted to using javascript-compiled libraries
for mp3 encoding. However, only firefox seems to show suitable
performances for mp3 encoding, using the libshine build and thanks to
its asm.js support.
  https://github.com/savonet/shine/tree/master/js

On the other hand, only chrome implements the adequate Web Audio API,
but is too slow to encode :-o

All in all, if we keep forging, it is very likely that once mozilla
finishes implementing the web audio API, we should have a function
browser source client using firefox. And Chrome when their asm.js
perfs improve as well.

Romain
2013/7/23 Jamie McClelland <jm at mayfirst.org>:
> I'm following up on a thread started by Stephen a couple months ago
about
> building a JavaScript source client using webrtc.
>
> The first step suggested was to figure out how to mux the audio and video.
> After I posted a feature request on the webrtc experiment js library, we
> seem to have a solution:
>
https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-20791759
>
> Based on the last comment on the icecast Dec list, we now only need to do
do
> an HTTP put request to the icecast server (
> http://lists.xiph.org/pipermail/icecast-dev/2013-May/002171.html).
>
> Great! I've got my jquery ready, but am having trouble finding docs on
how
> to build the put request. I tried looking at the libshout source, but my c
> skills aren't quite good enough to figure it out.
>
> Any help would be appreciated, particularly with an example.
>
> Thanks for all your work on icecast - we use it a lot here at May
> First/People Link.
>
> Jamie
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev
>

DELETE ME FROM THIS MAILING LIST PLEASE


2013/7/24 Romain Beauxis <toots at rastageeks.org>
> Hi Jamie,
>
> The webRTC API does not sound suitable for source->server streaming
> for many reason. For instance, the peer-to-peer connection requires
> input from both end and seems quite unfeasible to implement in a
> server. Likewise, codecs are completely abstracted and much more.
>
> In reality, webRTC is an API to acheive full-duplex conversations a-la
> skype and not for streaming.
>
> For these reasons, we at liquidsoap have been working on implementing
> a simple websocket protocol for sending source streams from a browser
> to a server. The protocol is documented and implemented there:
>   https://github.com/savonet/webcast
>
> We also have a pull request on liquidsoap that implements the protocol
> and should be merged fairly soon:
>   https://github.com/savonet/liquidsoap/pull/90
>
> The bottlenecks right now are the availability of the Web Audio API,
> which is only partially implemented in firefox and the encoding speed.
>
> Because there is no native encoding API for browser-side javascript,
> we have (temporarily?) resorted to using javascript-compiled libraries
> for mp3 encoding. However, only firefox seems to show suitable
> performances for mp3 encoding, using the libshine build and thanks to
> its asm.js support.
>   https://github.com/savonet/shine/tree/master/js
>
> On the other hand, only chrome implements the adequate Web Audio API,
> but is too slow to encode :-o
>
> All in all, if we keep forging, it is very likely that once mozilla
> finishes implementing the web audio API, we should have a function
> browser source client using firefox. And Chrome when their asm.js
> perfs improve as well.
>
> Romain
> 2013/7/23 Jamie McClelland <jm at mayfirst.org>:
> > I'm following up on a thread started by Stephen a couple months
ago about
> > building a JavaScript source client using webrtc.
> >
> > The first step suggested was to figure out how to mux the audio and
> video.
> > After I posted a feature request on the webrtc experiment js library,
we
> > seem to have a solution:
> >
>
https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-20791759
> >
> > Based on the last comment on the icecast Dec list, we now only need to
> do do
> > an HTTP put request to the icecast server (
> > http://lists.xiph.org/pipermail/icecast-dev/2013-May/002171.html).
> >
> > Great! I've got my jquery ready, but am having trouble finding
docs on
> how
> > to build the put request. I tried looking at the libshout source, but
my
> c
> > skills aren't quite good enough to figure it out.
> >
> > Any help would be appreciated, particularly with an example.
> >
> > Thanks for all your work on icecast - we use it a lot here at May
> > First/People Link.
> >
> > Jamie
> >
> > _______________________________________________
> > Icecast-dev mailing list
> > Icecast-dev at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast-dev
> >
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20130724/1d63dd64/attachment.htm

Thanks so much for the comprehensive response Romain. It sounds like you
are working hard getting this working with audio streams and it's a lot
more complicated than I had originally hoped.

I'm still curious about the proper syntax of the http put command though
(and I'm sure others would be interested as well). Is there any
documentation on the parameters to send?

I also had a (probably naive) question about your approach...
> For these reasons, we at liquidsoap have been working on implementing
> a simple websocket protocol for sending source streams from a browser
> to a server. The protocol is documented and implemented there:
>   https://github.com/savonet/webcast
> 
<snip> 
> The bottlenecks right now are the availability of the Web Audio API,
> which is only partially implemented in firefox and the encoding speed.
> 
> Because there is no native encoding API for browser-side javascript,
> we have (temporarily?) resorted to using javascript-compiled libraries
> for mp3 encoding. However, only firefox seems to show suitable
> performances for mp3 encoding, using the libshine build and thanks to
> its asm.js support.
>   https://github.com/savonet/shine/tree/master/js
I'm curious why encoding speed on the browser is an issue. If you are
sending the data to a nodejs app on a server, why not have the nodejs
app doing any additional encoding necessary?

jamie

-- 
Jamie McClelland

May First/People Link
Growing networks to build a just world
http://www.mayfirst.org
https://support.mayfirst.org

OpenPGP Key: http://current.workingdirectory.net/pages/identity/ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url :
http://lists.xiph.org/pipermail/icecast-dev/attachments/20130725/d0de8159/attachment.pgp

Hi,

On 07/23/2013 07:44 PM, Jamie McClelland wrote:
> I'm following up on a thread started by Stephen a couple months ago
> about building a JavaScript source client using webrtc.
>
> The first step suggested was to figure out how to mux the audio and
> video. After I posted a feature request on the webrtc experiment js
> library, we seem to have a solution:
>
https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-20791759
I saw that, I didn't grasp if that provides a proper Ogg muxed stream,
but we'll find out.
> Based on the last comment on the icecast Dec list, we now only need to
> do do an HTTP put request to the icecast server (
> http://lists.xiph.org/pipermail/icecast-dev/2013-May/002171.html).
That's correct. Make sure to use a recent beta version of Icecast 2.4
though!
> Great! I've got my jquery ready, but am having trouble finding docs on
> how to build the put request. I tried looking at the libshout source,
> but my c skills aren't quite good enough to figure it out.
It's even easier, you can even use CURL (that's why we implemented PUT
to provide better interoperability through standard compliance).
> Any help would be appreciated, particularly with an example.
Using my example from http://icecast.org/#release_2.4-beta2 :

cat foo.ogg | curl -u source:hackme -H "Content-type: application/ogg"
-T - http://localhost:8000/mountname.ogg


This is the plain text dump of the HTTP connection:

PUT /mountname.ogg HTTP/1.1
Authorization: Basic c291cmNlOmhhY2ttZQ=User-Agent: curl/7.31.0
Host: localhost:8000
Accept: */*
Transfer-Encoding: chunked
Content-type: application/ogg
Expect: 100-continue

Then the server acknowledges and raw data follows.
Note that there's still a 100-continue patch not landed, so we're not
100% compliant yet. Usually things shouldn't break though.

Hope that helps.

Cheers

Thomas

Hi all,

On Wed Jul 31, "Thomas B. R?cker" wrote:
> Hi,
> 
> On 07/23/2013 07:44 PM, Jamie McClelland wrote:
> > I'm following up on a thread started by Stephen a couple months
ago
> > about building a JavaScript source client using webrtc.
> >
> > The first step suggested was to figure out how to mux the audio and
> > video. After I posted a feature request on the webrtc experiment js
> > library, we seem to have a solution:
> >
https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-20791759
> 
> I saw that, I didn't grasp if that provides a proper Ogg muxed stream,
> but we'll find out.
Yeah... I somehow doubt it given Romain's response, but it's been
instructive trying.
> > Based on the last comment on the icecast Dec list, we now only need to
> > do do an HTTP put request to the icecast server (
> > http://lists.xiph.org/pipermail/icecast-dev/2013-May/002171.html).
> 
> That's correct. Make sure to use a recent beta version of Icecast 2.4
> though!
Done. (I documented this process back in December for anyone else
running Debian:
http://current.workingdirectory.net/posts/2012/vp8-and-debian/). I just
updated to the beta 3 version of 2.4.

> > Great! I've got my jquery ready, but am having trouble finding
docs on
> > how to build the put request. I tried looking at the libshout source,
> > but my c skills aren't quite good enough to figure it out.
> 
> It's even easier, you can even use CURL (that's why we implemented
PUT
> to provide better interoperability through standard compliance).
> 
> > Any help would be appreciated, particularly with an example.
> 
> Using my example from http://icecast.org/#release_2.4-beta2 :
> 
> cat foo.ogg | curl -u source:hackme -H "Content-type:
application/ogg"
> -T - http://localhost:8000/mountname.ogg
Very elegant indeed. 

I'm continuing my debugging and discussion on the webrtc-experiment
issue tracker which seems more appropriate than the icecast list. I'll
give an update here if we get anything working.

Here's my latest status:

https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-21896312

Thanks for all the help.
jamie


-- 
Jamie McClelland

May First/People Link
Growing networks to build a just world
http://www.mayfirst.org
https://support.mayfirst.org

OpenPGP Key: http://current.workingdirectory.net/pages/identity/ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url :
http://lists.xiph.org/pipermail/icecast-dev/attachments/20130731/4d7f9fbc/attachment.pgp