Icecast Streaming Media Server Forum Index Icecast Streaming Media Server
Icecast is a Xiph Foundation Project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Newbie Question - Performing Seeks on MP3 Audio

 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Icecast Server
View previous topic :: View next topic  
Author Message
tqisjim



Joined: 22 Mar 2013
Posts: 4

PostPosted: Mon Mar 25, 2013 3:41 pm    Post subject: Newbie Question - Performing Seeks on MP3 Audio Reply with quote

Please bear with this newbie.

Since I downloaded Icecast a few weeks ago, I've been under the impression that Icecast is primarily designed for transient data, for example, a live broadcast where the data may never be specifically written as a stored file (caching notwithstanding). Most of the discussions and documentation seems to focus on relaying and propagating these data streams.

On behalf of a local church, I am trying to host files that consist of 90 minute worship services. I now feel pretty confident that we could live broadcast these services. But in fact, they just want to make these recordings available after the fact.

Some people have confidently told me that HTML5 will magically do what needs to be done without any server considerations. But so far, this seems to be a statement of faith (heh heh).

As with most apps, I only have control of one end. No idea who the clients are, what apps they're using, whether they listen to the whole service, or jump ahead to the sermon. As a minimum, I want to include the common functionality of being able to seek to an arbitrary position in the file. This substantial effort so far has been summarized in the following post:

http://stackoverflow.com/questions/15420096/how-is-audio-streamed-using-http/15618279#15618279

The first question is whether my legacy Apache server can handle range requests. If not, does IceCast have this functionality? I assumed that after so many inquiries, someone could identify a specific protocol and then I could review the docs to see if that protocol is implemented.

The second question is trying to second guess what client capabilities need to be considered. Again, this question would be easier if there were a specific protocol to reference. I've been told that the files are currently available on a podcasting server, but I don't even know if that term refers to a brand or technology.

Thanks!
Back to top
View user's profile Send private message
Nonapeptide



Joined: 08 Sep 2012
Posts: 40
Location: Scottsdale, Arizona

PostPosted: Mon Mar 25, 2013 9:18 pm    Post subject: Reply with quote

One of my clients does something very similar. They take broadcasts that are typically between 60 and 180 minutes from a source, record the audio to a file using the IceCast <dump-file> directive, and then allow listeners to hear the audio later. They simply link to the audio file and then people can hear it in the player of their own choosing. Here's a simple flow chart for how it works and what the end results are:

    1) Source client connects to the IceCast server.
    2) IceCast server has per-mountpoint directives for where the dump-file will be located so when they connect, a file is created.
    3) A script runs to rename the dump file with the date that the transmission started.
    4) A script runs to upload the file to long-term storage that is accessible by web users through a pay-walled section of a website.
    5) Users sort through the audio files they want to hear.
    6) Users click on the audio file link which simply downloads the audio file, but for the vast majority of browsers it will load right in the browser tab. The audio file is between 20 and 100MB in size, usually, so takes just a few seconds to load and start replaying. By the time someone is trying to seek around in the file, it's mostly downloaded. Any seeking is handled by the multi-media plugin in the browser or whatever default program is selected on the user's PC.

The other part to this client's service model is that, yes, they allow for live listening of the streams. In that case, we chose to use jPlayer as the multimedia player, but you can also use it for static files. It's been customized just a tad for this client, mostly the UI, but it's a great HTML 5 player that has a flash fallback. It can take multiple source files or live sources, so you can have maximum browser compatibility. Pro Tip: FireFox users have issue listening to MP3 streams so double-up with MP3 and Vorbis sources. Patent disputes and such.

jPlayer is built using JavaScript and jQuery as the DOM manipulation library, so it's pretty standardized and you have a good chance at knowing how to work with it already if you know JavaScript.

Quote:
The first question is whether my legacy Apache server can handle range requests. If not, does IceCast have this functionality? I assumed that after so many inquiries, someone could identify a specific protocol and then I could review the docs to see if that protocol is implemented.


Legacy? Are we talking 0.7.x here? Laughing Range requests are also known as byte serving and can also be abused pretty bad for DoS attacks, so you'll probably want to be up on Apache 2.20 at least.

Quote:
The second question is trying to second guess what client capabilities need to be considered. Again, this question would be easier if there were a specific protocol to reference. I've been told that the files are currently available on a podcasting server, but I don't even know if that term refers to a brand or technology.
Clients are the easier part of the equation if you choose a pre-existing project to develop off of. For example the project known as jPlayer that I mentioned earlier. There are plenty of others as well, but that one was the most robust that I could find. I like it's HTML 5 nature as well as the Flash fallback player.
Back to top
View user's profile Send private message
tqisjim



Joined: 22 Mar 2013
Posts: 4

PostPosted: Thu Mar 28, 2013 12:15 pm    Post subject: jQuery Reply with quote

Apparently this discussion has nothing to do with icecast, so it seems inappropriate to continue this thread here. (Server capability was raised in another discussion on stackoverflow- but as I understand your response about 0.7, their answer was a red herring.)

After visiting the http://jplayer.org website, I'd describe their product is shareware- that is proprietary software whose owners give the product away at no charge. So this old cynic is a little more sceptical of their claims, in spite of your endorsement.

Where is the codec? And even if I could be convinced that the codecs are written in JavaScript, how does jPlayer access the underlying system, say, to adjust the volume? I seem to recall some discussion about ActionScript, so I've more or less concluded that jPlayer is just a frontend for a Flash player whose main benefit is to twiddle with the skin. (Admittedly the HTTP protocol is different than the Flash player used by YouTube.)

Since you described this "project" as a framework for developers, it's hard to believe we're talking about the same thing. So please let me know if I went off on the wrong tangent.

Thanks!
-Jim
Back to top
View user's profile Send private message
Nonapeptide



Joined: 08 Sep 2012
Posts: 40
Location: Scottsdale, Arizona

PostPosted: Fri Mar 29, 2013 11:15 pm    Post subject: Re: jQuery Reply with quote

I'll start with your last point first:

tqisjim wrote:
Since you described this "project" as a framework for developers, it's hard to believe we're talking about the same thing. So please let me know if I went off on the wrong tangent.

Hmmm... maybe so? From what I gathered, you wanted to present pre-recorded audio files to listeners on-demand. You want to serve those files to them with the ability to seek in the audio. You were wondering about byte-serving features of web servers to be able to do that. I mentioned that it's less about the web server software and more about the player that listeners are accessing the files with. You could source the static files on a regular Apache server and cut IceCast out totally as it's not the best platform for static file streaming. I mean, you can do it with mount points, mp3 files, and playlists, certainly. I just find it to be something of a pain compared to using a regular purpose web server.

So in it's simplest form, if you simply put the MP3 files on a publicly accessible web server, you can just provide links to the MP3s and let client systems decide what to do with them. That's how one client of mine handles static audio files being listened to by customers. Link to an MP3 and the browser opens it up in it's own audio handler in most cases and they can seek back and forth in a simple interface. The browsers that don't automatically pop the MP3 open will download it and people can double-click it and open it in whatever program is default for MP3s.

If you must have a prettier web player, then that's where the discussion for jPlayer came in. Certainly IceCast can be the backend system that serves the static files to the web player, but it might as well be plain ol' Apache with the files accessible as a URL. As for byte serving, I'd recommend Apache 2.20 for security reasons, but you can use Apache 1 as well.


tqisjim wrote:
Apparently this discussion has nothing to do with icecast, so it seems inappropriate to continue this thread here. (Server capability was raised in another discussion on stackoverflow- but as I understand your response about 0.7, their answer was a red herring.)

I'm thinking it's outside the realm of IceCast, yes, but don't be afraid to keep the discussion going. I'm sure it could be valuable for the 'nets at large to have this conversation preserved.


tqisjim wrote:
After visiting the http://jplayer.org website, I'd describe their product is shareware- that is proprietary software whose owners give the product away at no charge. So this old cynic is a little more sceptical of their claims, in spite of your endorsement.

It's released under a GPL/MIT license. All source code is freely available. No part of the project uses proprietary, closed source, or black box components. Proprietary bits such as codecs are all provided by means outside of the project. It's simple an audio / video player, so hands off the decoding to a pre-existing codec that will need to already exist on the user's device. In the example of iPhones and Androids, the MPEG codecs exist as part of the inherent OS stack. Apple and Google paid the royalty fees to include that support in their devices.

Which brings be to the next point...


tqisjim wrote:
Where is the codec?

Codecs are not provided by the player, but rather are on the client system. Most web browsers come with built in support for the major audio and video codecs. For example IE, Safari, and Chrome. Microsoft, Apple, and Google all paid the royalties to ship their browsers with innate support for MP3s. In Safari on my Mac, I can't, however, listen to WMA encoded streams. Not without the added help of Flip4Mac or some other third party application. That's because Apple didn't find it in their best interest to pay the fees and provide inherent support for WMA in their browser.

This brings up an interesting point that I alluded to in my previous post. FireFox / Mozilla did not do what was necessary to be legally entitled to fold MP3 codecs into their browser. The streaming service provider that I do a lot of contracting for to build their systems ran into an issue where their MP3 streams could not be heard by listeners using FireFox on any OS (except in the very few cases where the listener had previously installed some kind of special multi media plugin like VLC with FireFox support). The reason is not only because FireFox does not have innate MP3 codec support, it also does not, by default, support handing off MP3 files to support applications that may exist on the OS (like opening it in Windows Media Player or iTunes). It's something of a dust-up in the Mozilla community and I think that default behavior might change and they'll at least ship it to seek support applications that might already exist on the system.


tqisjim wrote:
And even if I could be convinced that the codecs are written in JavaScript, how does jPlayer access the underlying system, say, to adjust the volume?

So now we've established that jPlayer doesn't bring codecs to the table, but to add interest to the discussion, yes there have been codecs written in JavaScript. JSMad is an example. It's a port of a C library. Moving on...

As for accessing the underlying system... it just does. JavaScript is a helluva tool these days. As for underlying system sound, that's not something that it can do, nor can any other multimedia player that I'm aware of. Certainly there are volume controls in jPlayer, but it controls relative audio based on system sound volume.

Think of Pandora. In fact, guess what? Pandora uses jPlayer! So if you open up Pandora, you've got audio controls that can increase and decrease sound. But it's not really increasing or decreasing the system sound. If your system sound is at 50%, and you increase Pandora's audio to 100%, you're not increasing the system sound to 100%, you're increasing Pandora to use 100% of the available 50%. Also, think YouTube. Increasing a video's volume doesn't increase system sound. I haven't seen a web multimedia player that can fiddle with system sound, and in fact that's totally verboten in some mobile platforms SDKs.


tqisjim wrote:
I seem to recall some discussion about ActionScript, so I've more or less concluded that jPlayer is just a frontend for a Flash player whose main benefit is to twiddle with the skin. (Admittedly the HTTP protocol is different than the Flash player used by YouTube.)

The flash fallback of jPlayer is fairly described as that. Wether the backend audio reception is done by a HTML 5 compliant browser or through the .swf application, there's the same set of HTML / CSS elements that a user interacts with. There's nothing to say you couldn't forgo the HTML 5 part altogether and just stick with the flash component, but at that point I think there are better pure flash systems you could choose from. Then again, in 2013 with Flash's future (and present) being what it is, the full HTML 5 jPlayer might be a better option.

Yes, multimedia on the web is a huge topic and I frequently wonder why I'm even in it and how much longer I can last. Laughing
Back to top
View user's profile Send private message
tqisjim



Joined: 22 Mar 2013
Posts: 4

PostPosted: Sat Mar 30, 2013 3:44 pm    Post subject: Reply with quote

Wow!

I feel a little guilty about the last response. My scepticism was confirmed when I tried running the demo in Firebug and the debugger hit all the (.min.js) obfuscated code. JPlayer is licensed under GPL and, according to Wikipedia, is required to release unobfuscated code. When I saw the link to the source code some significant amount of faith in humanity was restored.

If you look at my original post on stackoverflow, the responses (eg Pitts) seemed to conclude that a large MP3 data set is broken up into smaller pieces, which I confirmed using YouTube's Flash Player. But JPlayer doesn't seem to have this feature, and Firefox's current HTML5 implementation is even more primitive.

In summary, your responses seem to be 100% accurate: The best (ie only practical) solution is to hack the server and a client player to get the results I want... A project for a long weekend or a slow week at work. In my own thinking, the question has changed from "Where's the protocol spec?" to "Why isn't there a protocol spec?", and maybe that'll evolve to "Here's a proposed protocol spec".

If I'd originally approached this problem from the client end, and stumbled on the JPlayer group before the icecast forum, would the outcome have been any different?
Back to top
View user's profile Send private message
Nonapeptide



Joined: 08 Sep 2012
Posts: 40
Location: Scottsdale, Arizona

PostPosted: Sat Mar 30, 2013 11:45 pm    Post subject: Reply with quote

tqisjim wrote:
I feel a little guilty about the last response. My scepticism was confirmed when I tried running the demo in Firebug and the debugger hit all the (.min.js) obfuscated code. JPlayer is licensed under GPL and, according to Wikipedia, is required to release unobfuscated code. When I saw the link to the source code some significant amount of faith in humanity was restored.

Yes, they used minified versions of their JavaScript libraries, but that's not obfuscation in the sense of something unreadable and proprietary like IonCube does for PHP code. Minification is just removing unnecessary characters to tighten the delivery to the client system just that little bit more. Gotta shave those milliseconds off!

tqisjim wrote:
If you look at my original post on stackoverflow, the responses (eg Pitts) seemed to conclude that a large MP3 data set is broken up into smaller pieces, which I confirmed using YouTube's Flash Player. But JPlayer doesn't seem to have this feature, and Firefox's current HTML5 implementation is even more primitive.

I don't see a link to your StackOverflow question and can't find a user named "tqisjim" or one named "Pitts" that has answered a question along this topic. As for large MP3 data, if HTTP is the application layer protocol, and of course IP and TCP are the network and transport layers respectively, then it'll be handled as per the norm of those protocols. I don't know of any special way that MP3 data would be handled unless the HTTP server has some module or special case that does something funky to iy.

This brings in the topic of RTSP and its close relatives RTP and RTP Control Protocol (AKA RTCP). Instead of using HTTP as the application layer protocol, RTSP is a purpose built protocol for streaming media. If you use a RTSP server, like ffmpeg, VLC, Darwin Streaming server, Wowza, etc. and then choose a multimedia client that supports getting it's source files from a RTSP server (jwplayer for example - not jPlayer. I don't believe jPlayer supports RTSP) you might have better support for those kinds of features that you're looking for.

IceCast simply uses HTTP to stream multimedia and doesn't have a vast support for things like this. It's great for simple live streaming, but not so great IMO for on-demand libraries. In fact, in a parallel situation, my church wants to do a video stream of their service and also record them for playback later. I've avoided that project for now because I know it'll take some decent amount of engineering. I'm thinking I'll use VLC or ffmpeg as the server and then I'll need to choose a player that has specific support for static playlists. I'm getting a headache just thinking about it, but I'm also thinking about turning it into a side business. Hosted streams and on demand multimedia for event venues like churches, concert halls, live events, etc.

tqisjim wrote:
In summary, your responses seem to be 100% accurate: The best (ie only practical) solution is to hack the server and a client player to get the results I want... A project for a long weekend or a slow week at work. In my own thinking, the question has changed from "Where's the protocol spec?" to "Why isn't there a protocol spec?", and maybe that'll evolve to "Here's a proposed protocol spec".

I think the spec is RTSP, but I'm not 100% familiar with it. I've chosen to use HTTP as my streaming application layer protocol for maximum compatibility and firewall sneakiness. Most firewalls don't block HTTP traffic, and I built my client's streaming system to simply use port 80 and so far they haven't had a single listener or source complain about not being able to hear the audio as a result of firewall issues (and they're nearing a quarter million listeners since I implemented it late last year).

Also, here's my list of web based media players that I've collected in my journey through the not-so-wonderful world of streaming. Players that do audio and video. Some may focus more on video than audio. Also, beware that this is a copy/paste of my raw notes so they might not make sense. =)

Emphasis on video, but varying layers of support for audio-only uses:

• http://videojs.com
○ Nice but doesn't seem to have a lot of streamers using it. Streaming seems to be an afterthought if it's thought of at all.
• http://flowplayer.org/
○ Very nice.
○ Analytics
○ Lots of devices
○ Some of the known problems seem scary: http://flowplayer.org/docs/known-issues.html
• http://viperwolfplayer.com/
○ Kind of a strange vibe surrounding it.
○ No mention of streaming anywhere on the net
• http://www.hdflvplayer.net
○ Seems confusingly tied to specific CMSs. Not even sure if it's a full HTML5 player with inherent cross platform compatibility.
• http://sublimevideo.net
○ All in all a good video delivery platform, however it's not really looking like it could be used to source audio from a stream. Also doesn't appear to have a deep JS library. Still a possibility, especially if there's a decision to change between a video player and an audio player (video loads, then JS changes to audio player).
○ Wouldn't be good for the future hopes for video streaming live events, I don't think.
• List of video players: http://praegnanz.de/html5video/
• Another list to peruse through: http://html5video.org/wiki/HTML5_Player_Comparison
• http://www.jcplayer.com
• http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5
• http://mediaelementjs.com
• http://corp.kaltura.com
• http://www.leanbackplayer.com
• http://www.projekktor.com/index.php
• http://www.hdwebplayer.com

Audio players:

• http://mediaelementjs.com (Really nice!)
• http://dz0ny.github.com/AudioJS/
○ Fork of video.js
○ Looks decent
• http://kolber.github.com/audiojs/
○ Not sure if this is the same as the above. I'm pretty sure it isn't.
• http://www.catswhocode.com/blog/10-awesome-html5-audio-players
○ List of HTML 5 audio players
• http://www.musesradioplayer.com
○ MP3/OGG but no AAC
Back to top
View user's profile Send private message
tqisjim



Joined: 22 Mar 2013
Posts: 4

PostPosted: Thu Apr 04, 2013 12:12 am    Post subject: Reply with quote

The link to the stackoverflow post is in my very first post at the beginning of this thread.

Ultimately, I deployed JPlayer. JPlayer includes the file jPlayer.swf, and my MP3 file doesn't play on Firefox without the Flash Player installed. So I've concluded that the Flash Player contains the codec. The JPlayer source includes ActiveScript and requires nothing special from the server.

The seek function is one feature that YouTube has I think should be universally implemented. If all servers are capable of Range requests, why not?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Icecast Server All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2002 phpBB Group
subRebel style by ktauber