Plans about audio and video?

Hi!

I'm just wondering if any developer could say anything about plans for implementing audio and video streaming.

On Windows and MacOS X, SL uses QuickTime, right? Since QT isn't available on Linux, you needs something else with about the same features.

Perhaps GStreamer from Fluendo could be the solution. Besides being a framework for dealing with codecs, network protocols and such, they also provide some fully licensed proprietary codecs. (Currently Windows Media, MP3, MPEG2 and MPEG4.) That might be the way to go, if it works well enough.

There are a couple of other libraries, similar to GStreamer, but remember that you also need the licensed codecs. Perhaps QT in Wine would do?

Or do you have other plans you could tell us about?

I'd be happy if there was just an "mplayer plugin mode" or something that let mplayer do the audio/video stuff and let the user deal with any possible copyright issues.

Getting a linux native quicktime codec is _not_ going to happen, even as a binary package.

I think an mplayer hook would be very nice, especially considering the 'essential codecs' package that can be found on the mplayer website. Might even be the easiest way of bringing sound to all those Linux distributions.

Audio streaming shouldn't be a problem. I believe all the required stuff is part of the linux fmod (assuming they're sticking with fmod for audio for the linux port).

Video streaming, yes, could be a problem....

It'd be simple to just make the URL visible in About Land, but the ones providing the streams might not like that, so that's probably not an option.

But mplayer/xine/vlc/gstreamer/whatever... doesn't really matter. It's easy to make it work, the question is what makes sense for LL and what's legally possible. My guess is that they'd prefer a fully integrated player.

Oh well, guess I'll just have to wait and see.

Is it a player, or also a recorder so you can "tape" what your camera is seeing?

Ether way:

1. Xine is best if it's DVDs with menus, and has no reprocessing. It also have a GUI for playing the videos, and changing the source, that is default.
   
2. vlc is a pain to set up
   
3. gstreamer I'm not sure of... and we may be carrying an extra library or two (GTK/Glib) because of it.
   
4. Transcoder is a converter, not a player.

Mplayer would be best in this case:

1. SL can stream the data to Mplayer over STDIN or named pipe... or let Mplayer do it.
   
2. SL can control Mplayer via a named pipe ( -input option )
   
3. There's also the built-in Mencoder.

*hugs Oddity*

Yes, audio is missed badly. Video not so much (on my side), but mplayer sounds like a good way to do it.

I'd really love to see audio implemented (preferably alsa).

Yes, I definitely love the linux client, but I need sound! Please get sound working, don't care that much about the video as I never was fond of it on my previous slow Windozes. Already I must say that there is a marked improvement in speed and loading in the Linux client, I just really really need sound.

---- BEGIN FURRY CODE BLOCK ----
Version 1.3
FLRm2amr/CW2amr/CFhms3as A- C- D H++ M+++ P++ R+ T++++ W- Z Sp++ RLCT a cl++++ d++/-- e* f+ h+ i++ j+ P* sm
---- END FURRY CODE BLOCK ----

Since they're already using SDL I think the logical thing to do would be to have sound through that.
Can't SDL be configured to use Alsa, OSS, arts, etc... though?

Woo! Go OSS!

In all seriousness though, the problem isn't just getting sounds working (like all those gestures out there that we love so much), but the thought of future implementation of parcel streamed music and later on video. If they go with using a particular audio driver they might have complications later with either having to deal with streaming and decoding the audio themselves, or switching to using mplayer as suggested above (which I wholely endorse).

However there's a problem with using mplayer, they have to provide the source because it's a GNU license. I'm not sure whether that extends to the client as a whole in this case, or just the audio/video streaming, but that might lead to security complications in the future. It's likely that they're trying to figure out some solution that doesn't open source code to the public, which is why it's taking so long.

I wouldn't supply Mplayer for the video. I'd stream to it like above, using the native copy of Mplayer, but I wouldn't supply it.

Audio is something else, and I think the SDL libraries already have that covered.