[sldev] Call for requirements: ISO MPEG-V (mpeg for virtual worlds) Deadline: July 16, 2008

[Lawson English]

Argent Stonecutter wrote:
> On 2008-05-25, at 15:32, Lawson English wrote:
>> Sure, but MPEG-4 streams audio/video anyway, and I doubt that there's 
>> more data coming into SL than a streaming QT movie, MPEG-4 or not.
>
> Um, I'd think about that again if I were you. Steady state, maybe not, 
> but right after you rez? Bandwidth requirements in SL when you're 
> moving around from area to area and sim to sim are pretty high these 
> days. 

For a new sim yes, but I think its mostly SL's *really bad* (tm) texture 
caching that makes sim-crossing/rezzing such a bandwidth hog. Unless 
you're TPing into a sim with 50 overly-blinged avatars, there's no 
reason for the texture downloading issues you say except that SL doesn't 
cache very well.

Also, 1 BG caches are tiny by today's stndards. A better cache 
mechanism, combined with a larger cache, would make things a little more 
sane, at least if you've visited a sim recently.
> You can do credible videoconferencing (which has to use a real time 
> codec, not a super-efficient one) over ISDN. If you set your SL 
> bandwidth that low you're in a world of pain.
>
>> Even so, I think the idea is that with an MPEG-5, you could stream it 
>> to whatever  MPEG-5 box you have, and use the "standard" codec for a 
>> virtual world
>
> But then you wouldn't be encapsulating the game engine, which is what 
> I thought you were talking about. Now you're talking about a 
> standardized scheme that the SL environment could be mapped into, 
> which is what I was presenting as a more credible alternative.
Sorry. I hadn't even dreamed of encapsulating the game engine itself, 
which is probably why I misunderstood half of what you were talking about.

>
>>>> They could never figure out a use for VRML in MPEG-4 which is why 
>>>> no-one has used it in any major products.
>>>
>
>>> Apple uses QTVR, which is more or less the Quicktime equivalent, for 
>>> providing "hands on" views of objects and scenes.
>
>> Yeah, but the interactivity is all client-side and the QTVR is a 
>> single image built from multiple perspectives that have been stitched 
>> into a fisheye view of a panoramic scene (or a rotating view of a 
>> single object/scene stitched into an inverse of that with the camera 
>> focus at the center of the object).
>
> VRML is little more than that, and could have been used that way.
>
>> Regardless, QTVR's intactivity is purely client-side so its not a 
>> good model for what a MPEG-xx codec would need to do.
>
> I don't think we're really at the point where defining one will give 
> us anything more useful than VRML.
>
At the least, you need a reasonably good way to send data back to the 
server. I think I was wrong: there's no real 2-way pipe in MPEG-4 
streaming. There's bound to be "resend lost data" signals, but we need 
something to send, at the least, keypresses for avatar movement, and 
preferably ways of uploading data for baked textures, locally built 
items, etc.

Lawson