want to help develop a movie server for EL?

[ttlanhil]

first off, I'll need to tell you a bit about this all.

 

I talked to entropy about this idea a few months ago, to get permission. he liked the idea (I'm hoping that this video server may get 'official' hosting once it's well checked... we'll see on that)

a while later I did some work on it now and then... recently I rewrote a lot of it, and today I finished that off. so far it has been working well as far as I can tell... which means it needs more testing

 

it's not a movie like an MPEG or AVI or anything like that... it's recorded EL (the actual network traffic is recorded to be sent later as a movie)... what does this mean?

well, with this setup, you can have a bot recording a PK match, and then anyone can later view it... not only is it available, but you have total client control when watching the movie.

that means you can zoom, pan, etc (none of the normal server commands work, although being able to pause matches and the like will be of interest)

that also means that since people don't have to be there at the time to see the action, there's less lag for the fighters... while they'll probably enjoy having a bit of a crowd, this will be an advantage (the fact that you won't see much of a crowd in the videos either is perhaps the one downside)

and since it's recorded EL traffic, it's light on the networking... if you can normally play EL on dial-up, you should be able to watch the movies on dial-up as well (note: if there are a lot of people at the event, etc, it'll be higher than average traffic. you need to consider if you'd be able to be there, rather than if you can normally play)

 

right now, AFAIK, only vakana/yaelbot is set up to record anything, but the saved movie file format is simple enough (skip it if you're not interested in coding):

optional 'description' as the first line (cannot start with a number), ended with EOL

then repeated until end: a timestamp, tab, packet length, tab, packet, EOL

the timestamp is in millisecond resolution... what it starts at doesn't matter, only the difference between them.

packet length is the number of bytes in the entire packet (if the packet holds exactly one message, then packet-length will be the message-length plus two (EL protocol says you don't count the length bytes when making the message length))

the packet is a byte-wise copy of what was received from the EL game server over the network. the video server and file format are perfectly happy for a single message to be spread over many packets, or for a single packet to have many messages (which happens at the moment)

 

as of right now, only linux has been tested... if you have gnu-make and gcc/g++ then I assume any *nix system should work...

windows is probably not going to work, at least at the moment... there are 3 platform issues; listing a directory (it uses the same code I wrote for ELC, so that part should be windows ready), signals, and networking (that won't work on windows).

right now it uses SIGUSR1 to indicate re-reading the movies (there's no admin mode once logged in... the only things you need to do as an admin are reloading data and shutting down... unless an IP blacklist is added). the signals parts could probably just be removed for windows builds, they aren't needed.

if you want to port the networking to windows (convert the BSD sockets to winsock or whatever), feel free.

MSVC won't work. ported gcc like in cygwin, dev-cpp, code::blocks, etc may or may not.

the intended target is *nix (linux and *BSD, mostly), however, so I don't have much interest in the porting to other platforms

 

you should need only the normal C++ development environment (make, gcc, g++, stdc++, glibc) to compile and run (well, and tar/bzip2 to extract from the archive )

part of the work I've been doing has been to get it to compile without warnings (g++ -Wall -pedantic -Wextra), and to run under valgrind without error... I expect it could be made more efficient in places, but it shouldn't be too bad as is.

 

I don't have a static IP, so I don't want to run a server from this computer... and I'm not too interested in running it on someone else's server at the moment (I'm hoping there will be a number of improvements to make, which is a lot easier if I have control over it)

 

today's archive is here. download, unzip, make, run.

then start an EL client pointed at localhost:1999 (or if you run it on another computer on your network, use that, naturally)

I won't tell you more about what happens next, because the usability of the commands is one of the things that needs testing

 

now, a warning: there's one included test movie... it's a recording from vakana logging in and waiting a bit. vakana, when not in video-only mode, checks a bunch of stuff on login. you will be spammed. after the initial tests, I (ttlanhil) checked inventory. then a while later, you'll see people walking around. and that's it until the end (no, it's not exciting or even that interesting)

 

stuff like rewind, fast forward, etc won't work. stuff like statistics might, but I'm not too interested in that. as far as the server itself, I'm pretty happy with the options available, though I will consider suggestions for more features... I'm mostly looking at fine-tuning what it currently does

 

so... questions, comments, patches?

[0ctane]

Fantastic! This is a long overdue feature. I forsee future Red vs Blue movie possibilities and YouTube postings in the future. Maybe even a reenactment of The Holy Grail in EL.

[Roja]

That sounds interesting

[KarenRei]

I'm too busy working on eye candy to help, but I think this is a great idea.

[bluap]

Compiled and worked flawlessly. Very interesting piece of work. I can see it being used for wedding videos and all kinds of get togethers. Any suggestions are probably on your to-do list already but here we go. You already said you were going to add rewind/fast forward etc, that would be great. Some on screen indication of time into the movie would be nice. If its an officially sanctioned piece of work, it would be nice to add a proper control GUI to the client - a DVD control like thing. It could be opened/enabled by a server (your movie server) command so would not be available during normal play. My only minor observation is that having the full client interface available but some bits not functioning is slightly odd but there's not a lot you can do without major changes to the client I guess. Mind you, I'm so use to the client interface and what it can do that I get confused when I can't zoom and rotate a screen shot. Great work though.

[Mar(c)]

Sounds nice!

 

Just wondering, is it related to, or did you use anything of the Cpp's EL Movie Making?

[crusadingknight]

Darn, I felt like doing this last summer, but couldn't be bothered. Looks like you beat me to it.

Anyway, since I'm working on RPC on windows right now anyway, I can probably port the networking to winsock pretty quickly (ie. possibly tonight.) Be back when I have.

Edited March 15, 2007 by crusadingknight

[ttlanhil]

YouTube postings

I certainly hope you mean a server using this being used like youtube, not that stuff from here goes on youtube (since it's not that sort of video)

I can see it being used for wedding videos and all kinds of get togethers.

the big ones, sure, though since they'd have to be vetted by whoever runs the server (if anyone can submit them) or only made by certain people, it'd be limited to the bigger events

Any suggestions are probably on your to-do list already but here we go. You already said you were going to add rewind/fast forward etc, that would be great.

stuff like rewind, fast forward, etc won't work.

Some on screen indication of time into the movie would be nice.

I'll add the current/full time to play/pause, but any sort of display beyond that would mean client modifications... which may happen, but since it's for an outside server they'd have to be minimal, unobtrusive, and with ent's blessing

ed: scratch the above, it's not as easy as I thought. the entire length is shown in #list though

If its an officially sanctioned piece of work, it would be nice to add a proper control GUI to the client - a DVD control like thing. It could be opened/enabled by a server (your movie server) command so would not be available during normal play. My only minor observation is that having the full client interface available but some bits not functioning is slightly odd but there's not a lot you can do without major changes to the client I guess. Mind you, I'm so use to the client interface and what it can do that I get confused when I can't zoom and rotate a screen shot.

me too. when I see a screenie I often wanna left/right to change the view. that's probably part of what made me wanna do this. as for a GUI, well, the only commands available ATM are to list movies, play one of them, pause (and resume) playback, and stop playback (which goes back to nomap.elm, while reaching the end just stops on the last frame)... there could be a GUI made, but it wouldn't be able to add much

Just wondering, is it related to, or did you use anything of the Cpp's EL Movie Making?

nope, I don't think I've seen that before, if I did, I don't remember it... no, as far as I can tell, that's a client addon, whereas my setup is a server for what a bot records. I've considered making a patch to the client to be about to work with movies, but it'd end up being different to that one

Anyway, since I'm working on RPC on windows right now anyway, I can probably port the networking to winsock pretty quickly (ie. possibly tonight.) Be back when I have.

okay, a patch with #ifdef windows (which would probably also remove the signals parts) or something like that would probably work fine Edited March 16, 2007 by ttlanhil

[ttlanhil]

okay, a quick *bump*... it's simple enough that there shouldn't be hidden bugs, and it's been tested a fair bit, but it'd still be good for it to get a number of solid stress-, exploit-. and bug- testings; as well as any ideas that don't expand on it too much

 

being able to compile C++ really is the main requirement; if you can compile EL then you should be able to compile this, it shouldn't be at all difficult to use (if the interface once it's running could be improved, please let me know how, interfaces aren't my best point)

[ttlanhil]

Okay, well, since I recorded the EL Gala, I may as well have this open. It's currently running with a server address of "ttlanhil.homeip.net".

Please test it out

[Lumino]

Thanks for recording the gala with your bots One thing I think is even more desirable than your video is still images that can be rotated...watching the videos gets boring because there are times when nothing happens and you have to wait So what if you just had a bot standing and the admin could PM it /botname take_pic. Or something like that. And it takes a still frame that can be rotated and zoomed and such. Also, and this of course is way harder to code but not too too much really; what if you took an area and placed bots such that the person could actually move through the recorded world and watch things happen? Of course the issue is they would walk in squares where people are supposed to go per the recording...so maybe if you could have concurrent recordings from several bots and type #switch_view and you would move to another bot and what it is seeing at that precise moment. Just some ideas to make it better, it's already awesome.

 

Lum

[Torg]

So what if you just had a bot standing and the admin could PM it /botname take_pic. Or something like that. And it takes a still frame that can be rotated and zoomed and such.

Well its not really taking a picture as such, as it is impossible to rotate a picture. What you would do (and what this does) is take a snapshot of the data from the server so you can actively rebuild the scene later.

 

Also, and this of course is way harder to code but not too too much really; what if you took an area and placed bots such that the person could actually move through the recorded world and watch things happen?

Well that would require taking the data from all the bots and merging it to build a list of server commands sent to the players along the whole section you want to view, for the entire time required. It's actually quite complex, but I guess possible.

[ttlanhil]

Building a snapshot setup would be possible, but it's a lot more complex than simply replaying what the real server sent to the bot... At the least, it'd probably look like a resync to change to next image... If not a full new map-load... And any chat from before the snapshot won't be showing on-screen, because while the client displays it for a while, it's only sent the once.

On the up side, if I did have that working, I could make it automatically snapshot each minute, so people can jump forwards/backwards a minute at a time.

And if that were done, and I could build lists of movies with offsets (as to the difference in when each started) then I could add a command to jump from one camera to another at the closest snapshot... Mind you, that's again at least a resync, and probably a full map-load. Some people's computer speeds will mean they miss a heap.

The alternative to that is combining the video logs from several bots, which would look better, but would be more work again (just adding #jump would probably be more work than building the recording into the bots and the playback server was).

Of course, for it to be worth my time to do all this, I'd need to be doing a fair few showings, which means having a number of camerabots approved to go to a wide range of events. I did have a short test video before, but this was the first real test of how it worked (as far as I can tell, it all worked as it should, although some people seem to have trouble with a double-login which is in some logs).

As some people may have noticed, my 'Net connection dropped out earlier today (Ever since we upgraded to ADSL2+, there have been dropouts now and then, once per 2 weeks or so, on average. The 1.6MB/sec is nice, but still), and I have dynamic IP anyway; so it's no-where near being ready for many EL residents to be able to use.