Video Script in SL????

Ok its probably not even possible...

but does anyone know of a way, or could think of some crazy impossible rediculously inefficent way to play video in SL

id LOVE to have my FUTURAMA stream on a widescreen in my house.... How cool would that be, and its only 120 BPS which isnt much more than the music streaming function

Im sure we could ask the devs to put it in...

so lets

A. figure out how to script it

B. Whine to the devs untill they put it in

Dude. It's really easy. Just make a texture with all the frames of the animation on it and then animate the texture. Apply sound as needed.

Sure, it's woefully inefficient, but I'm honestly not sure I want live video all the time in SL.

Streaming video could be done via script request (like a script permission). ("This object is looking to show you a steaming video do you want to grant it permission to?" should be not connected with permissions as an object should be able to ask many people if they want to.

I wonder if it's possible to scan the video buffer and replace a static texture with the video buffer from another program like .

you would need to load at least 15 textures a second,
wouldnt SL flip out if you did that

I was thinking along the lines of using hardware video-overlay, which is do-able, as long as you have a 3rd-party app sitting over the top of SL.

-Adam

hadn't thought of having an application sit ontop of SL handling it. Yes it is doable. Would be a bad hack, SL would probably go nuts.

YOU COULD:
Have a program outside sl read video stream, each fram by frame, and rpc ALL the pixels in it... that whould probably crash all of rpc in about 3 secs of video unless you can find a way to fit every pixel of a frame in one call off 255 charracters :/
You could use the xylor block method to display 3 pixels per prim...

Doing this method would require (if you can send all the data in one call) rough 15 calls a second... I don't know exactly how long it takes sl to recieve rpc, but its pretty fast....THEN you would need a very fast computer to squish all the info into one call, 15 times a second AND you would have to use multiple objects to recieve the rpc calls, parse it, and send it to the pixels... knowing sl it is possible, but with my tries I got roughly .5 fps on a stream 100 * 100 big in black and white... but that was on a 700 mhz computer and one script in sl...

I could give it a shot, just cant promise anything
now AUDIO is a different story...
I dont know how that would work


--Ming

Just some notes on implementing with hardware-video-overlay.

1: Require the user to sit on a object facing a screen, screen is set 'lit' with a special color used in the hardware overlay.

2: When the user sits down, have it email your local computer to tell it to start drawing the stream. When you get up, send another email to stop.

SL shouldnt have any issues, since I've seen this done before over existing 3D apps without too many hassles. Alternatively, you dont even need hardware-video-overlay, but directly positioning a window [or equivilent] above the 3D drawspace at the position defined by #1.

-Adam

Adam thats the easy way of doing it. the cool way would be to inject the video in to the clients rendering engine so it actually rendered the video on the face of the prim. This could be done by having the application catch texture keys and use that to identify the polygons to play with. Video on warper surfaces is quite doable. I was thinking you would have a centralized server that would handle the translation of textrure keys to streams.

I agree it's the easy way, however, I dont believe there is much of another way of doing it, without reversing the AGP transfer (since it's only half-duplex this means killing rendering, and FPS). Since you need to know a few things about the box. Specifically where it's points are located, and prefferably a memory address for where the texture is, and the size of the texture. (so you can overwrite appropriately)

-Adam

i remember some guy came up with an AVI player for Half-Life

looked pretty cool


As for the audio, Right now you can stream 96 BPS audio on your plot of land...
so getting the audio to work probably wouldnt be much of a hassle

and.... if we are already streaming 96 bps of sound.... 128 of sound AND video shouldnt be too much of a stretch...

I havent really looked into the scripting in SL much, im not really sure what im doing

but i would LOVE to have this....

Im gonna try to teach myself some scripting.... but im sure you guys will figure it out way before me

It would be best to stream the audio and video in the same stream as otherwise they will become de-sync.

if your app hacked the audio stream handler you could mux the video into that stream...
if the app changed the request SL request header for the audio streaming the server could then use that to serve both hacked and normal clients the correct stream.

PS: did say it would be an ugly hack.

how unreasonable would it be to petition the lindins to add it?

it wouldnt kill too much CPU.... at least i wouldnt think so,

Another way to do it, is to have a prim with the exact color, somehow get rid of the lighting, of the windows media blank screen.

Windows has a feature that wont let you copy movies by making that exact color bleed through every program.

SO, if you have that color ..... and go into photoshop... you can do like john madden and circle peoples asses while watching a movie....


SO, if you made a script that changed your view to squarely look at the wall, then made a prim with the exact color needed, and then had winamp run in the background at such and such a location on the screen, you could watch the movie...


but it would be alot cooler to just have a prim with video ON it, so as you walk around it would be just like looking at a TV

Just FYI, but I've actually built a working TV that plays back short video clips with sound. I'm planning on selling them and the "DVDs" soon (they are public domain videos). I even built a movie theater to show the clips on in Cartmel.

It uses the texture/sounds method described above which isn't perfect but does work. One 10x10 grid texure contains 100 frames for 10 seconds of video.

The biggest downfall I've discovered is having to display each texture beforehand long enough so that it is properly downloaded and buffered before playback. This can take a while, sometimes longer than the clips themselves. =/

If LL did allow say MPEG-4 video streams to be added to a prim, streamed via HTTP from out outside server, it would probably require a very serious change/addition to the 3D engine they are using.

Do you have experience programing 3d rendering engines that use open gl? Or are you just speculating? I ask because one of my friend was teaching me how to program using open gl calls in objective c. We were able to set the texture of some polygons to a quick time movie (MPEG 4). And then manipulate the polygons with out problems.

heck I think apple and ms both give out demo code, that demonstrate video play back on-top of polygons.

I think open gl render what ever polygon's texture is set to. if it's really that simple, then they just have to learn how to throw out frames, so that video stays in real time. But that not counting the mother bored, and it's bus bottle neck. Or the system requirements that every open would need to play back real time video in 3d, while they're also rendering a hole 3d land scape. Made up of at least a thousand polygons?

While i haven't writen any apps that do this i have read the code samples given out in the dxsdk and played with them some. I keep corrent on video encoding trends by reading and posting on doom9.org (one of the premere video encoding and codec development forums).



My main concern is that it would be an ugly hack. System limitations would be a major issue.
I think it can be done because programs like fraps can inject data into the rendering. But i think the correct way to do it is to manipulate the data before it renders instead of modifying part way throught the rendering (hijack before any dx or ogl calls).

Using video overlays (which is what has been discribed above) is going to be really hard on the video card as it will have to do 2 renderings and combine them.

Not quite, hardware video overlay mixes in the two video streams (both pre-rendered) on the GPU with minimal effort (done outside 3D rendering at a later point in the pipeline). Not a huge fps drop from doing it.

-Adam

Bender cant wait...........

lets crank out some code

GO MONKEYS GO



Perhaps a community prize is in order?

It would have to be fairly big, this isnt simple script here. The number of people who could do it well, that I know of, I could probably count on one hand.

-Adam