Accounts e-mail HP

Faster replay generator

Can you help improve your favourite game? Hardcore C mages, talented artists, and players with any level of experience are welcome!

Faster replay generator

Postby Davide » Sun Aug 26, 2012 12:49 am

This may not seem a question about the superficial waves we are used to see in Freeciv. In fact the question goes quite deep into the underlaying mechanics that generate video replays, the goal being as innocent as to speed up their generation.
This deals with the transfer of the video frames from the server which generates them to the server which streams the videos.
Transferring the videos currently takes 80% of the "post-generation" time, meaning the time from when the message "a video is being forged - wait." appears, to the time when the video is completed and ready to watch.

The generic question which appeared on linuxquestions.org:

----

I'm looking for an efficient solution to stream a big volume of images over a small bandwidth line. The goal is to transmit all the images transferring the smallest amount of data.
The images are ordered sequential frames of a video and between two consecutive frames most of the pixels (~ 95%) are exactly the same.
Each image is about 1MB of compressed png format (compression level 3), with 24 bits per pixel. Let's define this format to be the canonical one.

A list of the ideas / attempts I went along:
    • Note: all rsync transfers are performed between ordered frames; the source frame is always the n-th, and the destination is the n-1-th, so that their visual difference is minimal. All the frames preceding the n-th are available on the source computer.

  • Transfers performed by rsync with delta algorithm, on the canonical png images:
    For each 1MB image, rsync transfers about 900KB and saves 100KB. This results to be unsuitable; Probably the delta algorithm isn't able to spot similarities in the images if these are compressed.

  • Transfers performed by rsync with delta algorithm, on uncompressed ppm images:
    I converted a pool of canonical images into ppm*, each one resulting about 8MB; for each image, rsynch was able to detect ~7MB of similarity and transfer "only" 1MB. This proved to be unsuitable as the canonical images are 1MB themselves.

  • Extract a difference image to be transmitted (idea, not tested):
    Instead of using rsync's delta algorithm, I can create an image on the local computer composed of only the pixels which differ from the two frames; given that two consecutive frames are identical for about 95% of pixels, this method could generate very light compressed images to be transfered.
    Contrarily, I think this would be very cpu-intensive on both source and destination.

  • Assemble a video and transmit frame chunks (idea, not tested):
    It is possible to assemble the frames into a video file. Video encoders are extremely able to recognize similarities between frames and present the differences in a vectorial form, which uses very little space on the video file. If it could be possible to cut and extract from the video file the portions representing each image, they would be very light to be transferred over the network.
    However, standing by the ffmpeg's manual, it doesn't seem possible to extract frames from an encoded video with this program.

If more details about the systems are required, I'll describe them in an appendix here.


* The ppm format is uncompressed and stores each pixel color "linearly" with its position on the picture
User avatar
Davide
 
Posts: 864
Joined: Sat Mar 24, 2012 12:34 am

Re: Faster replay generator

Postby Keysersoze » Mon Aug 27, 2012 10:57 pm

Try it with 8 bits/pixel. It won't lose any relevant detail.
Keysersoze
 

Re: Faster replay generator

Postby Davide » Wed Aug 29, 2012 11:15 pm

For the last four days I've been undergoing the most complicated method of the list (video streaming). This is requiring much, much and much more work than expected. Among the issues there are color space transformations, video encoder, TCP/IP transmission, all to be dealt in C.
I'm not totally insane to prefer such a way to do things, as, after the work will be completed, video replays won't just be faster to produce, but this will free the DSL line from the heavy load it's currently subject at the end of a match, when the video is transferred from the local server to the streaming one. In practice, this will permit scalability over a bigger and bigger number of running instances of Freeciv. Or, at least this will prevent the DSL from being such an obstacle.
User avatar
Davide
 
Posts: 864
Joined: Sat Mar 24, 2012 12:34 am

Re: Faster replay generator

Postby Davide » Fri Sep 21, 2012 6:02 pm

Fast replay generator is nearly ready for deployment. It's code is complete, but when I run a test yesterday to experiment its functioning, I found an unexpected problem with the I/O communication side of the video encoder. In fact, the replay generator will run a custom, unique-in-world Theora video encoder meant to stream frames over network.
For the curious and for who would like to help, this final problem to be solved is discussed here at stackoverflow.
User avatar
Davide
 
Posts: 864
Joined: Sat Mar 24, 2012 12:34 am

Re: Faster replay generator

Postby Davide » Sun Sep 23, 2012 3:04 pm

The Fast Replay Generator is live.
Video replays have now higer definition and are produced faster. The post-game wait time to have a replay has reduced to about 90 seconds, compared to the 10 minutes players were used to.
This acceleration exploits the parallelization of the video computation with its transfer to the remote server from which users stream the replays. That is, while each game turn is computed into a video chunk, the ready chunks are transferred out, concurrently.
User avatar
Davide
 
Posts: 864
Joined: Sat Mar 24, 2012 12:34 am

Re: Faster replay generator

Postby Kryon » Sun Jan 06, 2013 2:25 pm

Davide, this is a great feature to have.

Do you really have to transfer images? Can't you keep the savefiles and the image server the same? If not, wouldn't it be easier to transfer savefiles instead of image files?

In any case, it'd be great if we could create the replays for the old LT games. I'll talk to akfaew to provide you the saved games for LT30.
Kryon
 

Re: Faster replay generator

Postby Kryon » Sun Jan 06, 2013 2:28 pm

If the replay generator is now live, where can we see the replays of completed games?
Kryon
 

Re: Faster replay generator

Postby Davide » Sun Jan 06, 2013 2:50 pm

Kryon wrote:Davide, this is a great feature to have.

Do you really have to transfer images? Can't you keep the savefiles and the image server the same? If not, wouldn't it be easier to transfer savefiles instead of image files?

In any case, it'd be great if we could create the replays for the old LT games. I'll talk to akfaew to provide you the saved games for LT30.


It would be easier if transfers were not involved at all :p
The truth is that the server running games has a slow internet line, and the VPS running the website has slow CPU. So, to compute CPU-intensive videos and stream them at wide-band, I need to generate the videos on the game server and transfer each set of frames to the VPS each turn.

For generating an LT30 replay: it's possible, but the video will have a huge frame size. For a 30x30 tiles map, the video is about 500x500 pixels. Of course it can be zoomed out to fit the screen, but the details would then get too small I think.

You can get an idea looking at viewforum.php?f=24
User avatar
Davide
 
Posts: 864
Joined: Sat Mar 24, 2012 12:34 am


Return to Contribution

Who is online

Users browsing this forum: No registered users and 2 guests

cron