Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Streaming container for HTML5 <audio> tag

I have a Go application in which I would like to stream live uncompressed audio to the browser. I was hoping to stream over HTTP by just having the browser open a URL corresponding to the stream, and then feeding that connection with the audio data.

I was planning on using WAV to send the data uncompressed, However the WAV file format requires the file size be predefined in the header. Is there a better container format for doing this streaming that I can work with easily in Go?

I know that one approach would be to use a proper streaming server and transcode my audio through that, but if I'm implementing this myself, is there a fairly straightforward way to get off the ground? Perhaps a Go library to make this easier?

Thanks

EDIT I've solved this via ffmpeg as outlined in my answer below

like image 306
wxs Avatar asked Mar 05 '13 18:03

wxs


People also ask

Does HTML5 support audio tag?

HTML5 supports <audio> tag which is used to embed sound content in an HTML or XHTML document as follows. The current HTML5 draft specification does not specify which audio formats browsers should support in the audio tag. But most commonly used audio formats are ogg, mp3 and wav.

How do I make audio play automatically in HTML?

The autoplay attribute is a boolean attribute. When present, the audio will automatically start playing as soon as it can do so without stopping.

Can we play audio and video in HTML5?

HTML5 Audio and Video are two new media elements used to add media content like, a song, a movie etc. Both of these elements are used to add media content on a webpage. Chrome 3+, Firefox 3.5+, safari 4+ and IE 9+ supports both Audio and Video tags.


1 Answers

If you are still thinking about uncompressed WAVs for ultimate quality then I think you've got two choices

  1. Lie in the header - say that the WAV is very long (2GB say)
  2. Add additional chunks into the RIFF container

The first choice is easy to implement, but will mean naive browsers try to download a 2GB file instead of streaming it. I would hope that anything implementing HTML5 wouldn't be that naive, but I think you'd need to try it.

The second choice, adding additional chunks seems to be supported by the RIFF spec of which WAV files are a subset. You could then write a WAV file with multiple shorter chunks of sound data within. This should be supported by WAV players, but may not be as WAV files have never been particularly well standardised, and a lot of players just look for a 44 byte header which is not very RIFF compliant!

If I was you I'd try the first option first and see how that works out.

like image 84
Nick Craig-Wood Avatar answered Oct 10 '22 01:10

Nick Craig-Wood