cortex: org/capture-video.org comparison

comparison org/capture-video.org @ 306:7e7f8d6d9ec5

massive spellchecking

author	Robert McIntyre <rlm@mit.edu>
date	Sat, 18 Feb 2012 10:59:41 -0700
parents	7351c9c0c471
children	ebdedb039cbb

comparison

equal deleted inserted replaced

-:19c43ec6958d
+:7e7f8d6d9ec5
 #+title: Capture Live Video Feeds from JMonkeyEngine
 #+author: Robert McIntyre
 #+email: rlm@mit.edu
 #+description: Capture video from a JMonkeyEngine3 Application with Xuggle, and use gstreamer to compress the video to upload to YouTube.
-#+keywords: JME3, video, Xuggle, JMonkeyEngine, youtube, capture video, Java
+#+keywords: JME3, video, Xuggle, JMonkeyEngine, YouTube, capture video, Java
 #+SETUPFILE: ../../aurellem/org/setup.org
 #+INCLUDE: ../../aurellem/org/level-0.org
 * The Problem
 # your wall, then the ball should have traveled exactly one
 # game-mile. In order to keep sync with the real world, the game
 # throttles its physics engine and graphics display.  If the
 # computations involved in running the game are too intense, then the
 # game will first skip frames, then sacrifice physics accuracy.  If
-# there are particuraly demanding computations, then you may only get
+# there are particularly demanding computations, then you may only get
 # 1 fps, and the ball may tunnel through the floor or obstacles due to
 # inaccurate physics simulation, but after the end of one user-hour,
 # that ball will have traveled one game-mile.
 # When we're recording video, we don't care if the game-time syncs
 $\frac{1}{60}$ of a user-second to render to screen, then JME3 has
 it's work cut out for it.  In order to render to the screen, it will
 first step the game forward by up to four physics ticks before
 rendering to the screen. If it still isn't fast enough then it will
 decrease the accuracy of the physics engine until game-time and user
-time are synched or a certain threshold is reached, at which point the
+time are synced or a certain threshold is reached, at which point the
 game visibly slows down. In this case, JME3 continuously repeat a
 cycle of two physics ticks, and one screen render. For every
 user-second that passes, one game-second will pass, but the game will
 run at 30 fps instead of 60 fps like before.
 The basic functions that a =VideoRecorder= should support are
 recording, starting, stopping, and possibly a cleanup step
 where it finalizes the recording (e.g. by writing headers for a video
 file).
-An appropiate interface describing this behaviour could look like
+An appropriate interface describing this behavior could look like
 this:
 =./src/com/aurellem/capture/video/VideoRecorder.java=
 #+include ../../jmeCapture/src/com/aurellem/capture/video/VideoRecorder.java src java
 However, it is also important to properly close the video stream and
 write headers and such, and even though =SceneProcessor= has a
 =.cleanup()= method, it is only called when the =SceneProcessor= is
 removed from the =RenderManager=, not when the game is shutting down
 when the user pressed ESC, for example. To obtain reliable shutdown
-behaviour, we also have to implement =AppState=, which provides a
+behavior, we also have to implement =AppState=, which provides a
 =.cleanup()= method that /is/ called on shutdown.
 Here is an AbstractVideoRecorder class that takes care of the details
 of setup and teardown.
 Now that you have a =captureVideo= method, you use it like this:
 - Establish an =Isotimer= and set its framerate :: For example, if
 you want to record video with a framerate of 30 fps, include
-the following line of code somewhere in the initializtion of
+the following line of code somewhere in the initialization of
 your application:
 #+begin_src java :exports code
 this.setTimer(new IsoTimer(30));
 #+end_src
 #+results:
 : 932K	hello-video/hello-video-moving.flv
 : 640K	hello-video/hello-video-static.flv
-And can be immediately uploaded to youtube
+And can be immediately uploaded to YouTube
 - [[http://www.youtube.com/watch?v=C8gxVAySaPg][hello-video-moving.flv]]
 #+BEGIN_HTML
 <iframe width="425" height="349"
 	src="http://www.youtube.com/embed/C8gxVAySaPg"
 #+results:
 : 180M	physics-videos/helloPhysics.flv
-Thats a terribly large size!
+That's a terribly large size!
 Let's compress it:
 ** COMMENT Compressing the HelloPhysics Video
-First, we'll scale the video, then, we'll decrease it's bitrate. The
+First, we'll scale the video, then, we'll decrease it's bit-rate. The
 end result will be perfect for upload to YouTube.
 #+begin_src sh :results silent
 cd youtube

Mercurial > cortex

comparison org/capture-video.org @ 306:7e7f8d6d9ec5