Should LL allow Windows Media and Real Player file formats in-world?

LL uses Quicktime because it doesn't cost them anything to support it. In order to support WMV or Real formats they'd have to license the requisite libraries.

I'm much more interested in seeing support for OPEN standards, for which free software is available. Why no support for playing Ogg Vorbis streams (despite the fact that Vorbis is the native audio format of SL!! Yep, every sound that you upload to SL is encoded with Vorbis) or Ogg Theora video? I'd also like to see support for AAC streaming (not quite as free a standard as Vorbis, but it is free for use in open source software, and there are open-source encoder and decoder applications) because of its excellent encoding efficiency; 32Kbps music streams are actually listenable.

i agree, but here is the thing, im not sure, can you play MMS encoded stream in-world, becasue windoes media stopped support for those, i think


oh and to awner earlierl, yes SL has the right coding to play windows media formats, but it requires a hack that is aggainst the TOS

mp3 would be nice and longer files too

I think some of you have missed the plot. QT MOV format is a wrapper format, in which you can apply codex. Mp4 is a codex and will also render through the QT pluggin, same with H264. A MOV file can be internally encoded with any compatible codex.

To give you a 'visual' of what I mean, imagine..

You have a DOC file and you apply a zip compression to it (a simply explaination of a codex), which is decompressed when delivered and rendered. (Its a ZIP Format)

You have a DOC file and you include a zip file inside of it (a simple explaination of a wrapper format). The DOC file is delivered and the zip file is decompressed when rendered. (Its a DOC format)

If you checkout the list of compatible codex that the QuickTime player/pluggin can render, and set those formats in the QuickTime preferences, the rendering engine of the pluggin will show/play those formats, because the QuickTime player comes with all those decompressors installed.

To get other people to see those formats, they must also enable those same formats within their QuickTime player. That is why possibly so many people see QuickTime as being 'limited'.

To stretch the point, with the correct 'preparation' software, you can 'stack' 5 codex profiles within a single wrapper MOV format.

The QuickTime pluggin will even play/render Flash movies (although due to liscencing, will only render up to version 3 (pre-actionscripts)).

Using the wrapper format correctly, you can get some great results, both myself and many other machinima creators have produced some very sharp/clear and scaleable media through the MOV format. All our movies stream at less than 100kbps (most being in the region of 50-80kbps) including music backing tracks.

The problems with much of the quality issues, is with incorrect production and pre-rendering sequences. A lot of people just squeeze their movies through a codex, with one thing in mind, data bit rate. As most codex utilise the jpg compression alogorithums, it is not surprising they become fuzzy and grainy.

In addition, over zealous use of high compression codex, can add expotentually to the loading of the Client causing lag. A well prepared movie will be sharp, scalable, clear, very little pixelations and only apply a loading of 20% to the client during rendering, which is well within the limits.
I have seen movies ingame that are 'YouTube' quality, the sound is distorted, heavly pixelated, have a date bit rate of 200kbps+ and load the client over 80%.

Below is a few examples of movies that we made, which we stream into game which is less than 100kbps data bit rate and only applied a 20% loading to the client. Ingame we apply 2x scaling, and it uses the MOV wrapper format. It is only a few of many we have made.

http://www.wba-advertising.com/antiquity/antiquity3.mov (wrapper format with mp4, H264 and AAC codex)
http://www.wba-advertising.com/sabby/666a_mp4.mov (wrapper format with mp4 and Mp3 codex)
http://www.wba-advertising.com/sabby/reception1_mp4.mov (wrapper format with mp4 and Mp3 codex)

Just load those urls into the QuickTime player. Whilst we offer these movies for viewing, they are not to be broadcast, de-engineered or copied as they are all protected by copyright through WBA-Advertising.
Enjoy

I can play H.264 in SL with Quicktime for Mac. It's just that ALL quicktime movies are unbearably slow in SL, I can watch fine if I open the stream in quicktime player separately from SL (even with SL still open), but in-world it is so incredibly slow as to be worthless.

I imagine WMV and Real Player would be just as slow when rendered onto a primitive, plus they would have far worse support for the Mac and Linux clients.

The 'slowness' is probably due to 2 things.

1) If you have the Quicktime cache set too high, with SL running which takes quite a chunk of bandwidth, it is probably taking a long time to fill before rendering. Similarily, if the bandwidth setting in SL's client preferences is set too high, there may not be enough bandwidth left for consistant streaming to take place.

2) If the creator of the movie has used an aggressive codex, SL's client, through the QT pluggin will have to decode the stream on the fly, which is then rendered by the client ingame, which may effect the CPU cycles and the GC.

I suspect the latter, if you can use the QT player with the SL client window open underneath, as the client isn't having to do the additional work. You can see the effects by pressing Ctrl+Shift+2, the lime green bars on the chart are the UpDateTexture element, when you watch a heavily coded movie, you will see those bars sometimes reach 80+% of the client rendering engine taking presidence, net effect is lag. With the QT player, it is not having to swap/render a media texture within the VR environment.

There is a 3rd possible element that may cause the problem. H.264 is a 'streaming codex' in that it produces a header within the media, which tells the server OS that it is either a RSTP or 'Progressive Download and watch' format. On our servers, using stacked codex profiles, the headers are able to trigger a 1gb burst ram feature to fill caches to each viewer. It's a fine codex, but somewhat misused.

AWM, are you saying H264 is not the best option to use for videos directed into the SL client? What in your opinion is the optimum hinted stream settings? Do you limit framerate and bandwidth?

What I am saying is, to do more post production work on the media before applying any codex. You don't actually have to use any hinted stream settings to get a movie to 'stream', the H.264 codex is potentially the only codex that incorporates the 'hinting' header element, that will work over a RSTP, whereas in reality, you only need to use that facility if you want to copy protect your product as it doesn't use a cache or download any part of the media stream onto a hard disc, it renders on the fly. Progressive downloading has many uses, it not only allows you to watch the movie as it downloads, but also once downloaded, requires no further bandwidth, unlike RSTP which requires constant and consistant bandwidth.
You can use a H.264 codex even without having to use the hinting facilities, it has some merits, but for the most part is perhaps misunderstood.

Sorry, didnt read all the question, so adding this...

There are many ways to get a movie file down to a resonable size without having to crush it using a single codex. The balance is to get the following elements under control:

Data Bit Rate
Resolution/Format size
Sharpness/Clarity
Depth of Colour

By addressing all the elements you can acheive very good and acceptable results. Simply using a codex to to all the work, will only potentially control Data Bit Rate and make every other element suffer the consequences. The greater you apply a single codex to the movie, the smaller the data bit rate may be, and yes it will download quicker, but the greater the work the rendering engine will have to work, this can be measured quite easily in the client, this can have an effect on actually reducing the amount of data being downloaded as the cache fills up, causing the stream to become interupted.

If you render your work using a round pixel as opposed to a square pixel, the greater scaleability you will have, so you can reduce the format size. Using whole numbers to reduce the format (480x480 down to 240x240) is always much cleaner than trying to use say 33.333333% (360x360) as this helps the interpolation of the pixels and maintains greater sharpness. So if you now have a movie formated at 240x240 and it is very sharp, you can upscale it ingame on the chosen render texture. The resulting file size will also have been reduced by around 75%, giving you greater flexibility to choose a much reduced codex setting.
Given the corrolations between movie format/resolution sizes and what the client renders at, a 240x240 movie resolution equates to a 2.400x2.400 mtrs screen size, which if your media is sharp, can be scaled up easily to 4.800x4.800mtrs in size. Again poor screen size can have an adverse effect of the workload placed upon the client rendering engine, so showing the same movie on a screen at 4.020x4.020 means the client has to do the computations to resolve the movie format using big decimal placed numbers as opposed to whole numbers. It is already under stress to computate the parralexing in a VR environment when you see a screen in any other view other than exactly square on.

Some people have Autoscaling turned on in 'About Land, Media tab' by default. This adds around a 50% loading to the client, which using correct setting of the texture and movie format/resolution, is not required and should be turnned off. We use the Silver Stream Network media player/screen which have an internal script, which automatically does the computations for the movie format/resolution to screen size before it is rendered, by simply setting the rendering texture to the correct placement and offsets to render the movie to the correct scale, this takes a lot of the load off the client. So we can play several different formats on a single screen without having to manually make adjustments.

To take that one stage further, we have created a 'morphing' screen using multi-faceted screens, that can turn on and off sections of the texture applied, so the remaining rendered texture will 'morph' between portrait, square, landscape and even widescreen formats on the fly. All this reduces further the loading on the client and subsequently the potential for lag.

If the only way to reduce the date bit rate is by applying an agressive codex, then perhaps it is time to go back into the rendering software and look at reducing other elements like resolution/format, colour depth, before you resign yourself that, that is the only way.

Hope that fills out the answer a bit more?

Well H264 is a cool codec but it's a hog of resources for compression/decompression.

How about piggybacking on the VideoLan project? it supports a load of streaming modes and various codecs, plus it's free and contain it's own streaming server.

The linux client uses an external application within the game to provide streaming support that plays a much broader range then quicktime does under windows. If they were to do the same thing with the windows client and use something that is cross platform like VLC everyone would be happy... tho VLC dosn't support real media, anything else you toss at it will play fine.