Choosing a Video
YouTube accepts videos in a variety of formats. Once uploaded,
the videos are converted into a format understood by YouTube's video player,
which is based on Macromedia's Flash technology.
One of the video codecs that YouTube accepts for upload is
Theora, maintained by the Xiph Foundation. Theora comes with a compact,
open-source reference implementation and has a license that allows you to use
the codec in non-commercial and commercial games free of charge.
Theora encoded videos are embedded into the Ogg video
container format and thus have an “.ogv” filename extension. Ogg can also
contain audio (usually encoded with the Vorbis codec from the same
organization), although the demo ignores audio for simplicity.
320x240 pixels is the minimum resolution you'll want to
use. For higher quality videos, YouTube recommends 480x360 pixels or more.
YouTube selects the quality of a displayed video by taking the viewer's
bandwidth, the source material of the video, and the quality settings into
account. (A YouTube viewer can change the default quality for videos in the
account settings or click on the “watch in high quality” link underneath a
If you have a lot of text or other high contrast data in your videos, a
higher resolution will considerably improve the video's quality.
Another consideration is file size. One minute of video in
Theora format (768 kbit/s) results in roughly 4.5 MB of data. YouTube itself
limits uploaded videos to a length of 10 minutes and a file size of 1 GB.
I have had good experiences with Ogg and Theora in my
programs, but if you want to explore other options, have a look at ffmpeg
(supports a variety of formats; GPL/LPGL), Xvid (MPEG-4; GPL), or DivX (MPEG-4;
commercial, but community codec free as in beer).
At this point, the system implemented for the demo has
arrived at the structure depicted in Figure 2.
After the game has rendered the current frame, a scaled
copy of the framebuffer content is read back, converted, and encoded into a
video frame. The conversion step needs a bit more explaining.
Theora expects the video frames in Y'CbCr format. Y'CbCr –
often used interchangeably with the term YUV – is a color space that separates
an image into one luma component (roughly equivalent to the light intensity)
and two chroma channels (the color information). The prime on the Y means that
the luma channel contains gamma corrected values.
Y'CbCr encoded images contain less redundancy and thus
produce smaller files than RGB. In addition, the human vision is more
perceptible to light intensity than color. For this reason, the two chroma
channels can be stored in a lower resolution than the luma channel.
The demo application contains a routine that converts the
framebuffer's RGB values to the required Y'CbCr based on values I found at this link.
At the same time, the image is subsampled to a 4:2:0 format, which reduces the
two chroma channels to a quarter of the original size.
To encode the screenshots into a video, the demo
application defines the following interface to the Theora and Ogg libraries:
TheoraResourceWriter(size_t width, size_t height, unsigned int fps,
unsigned int bitrate = 768000, unsigned int quality = 0);
bool open(const std::string& fileName);
bool write(const Image& image);
Where Image is a wrapper for a piece of memory that
contains the framebuffer contents in Y'CrCb format, which is passed to TheoraResourceWriter::write()
for every frame.
YouTube's Data API
Now that the video exists on your hard disk, you can
upload it to YouTube.
To start developing a YouTube application, you'll first
need a client ID and a developer key that identify your software, which you can
request from Google; this is in addition to a YouTube account. Whereas
client ID and developer key are usually built into your application, user name
and password are asked for when the user logs in to your application.
Google offers client libraries to access YouTube's servers
for several programming environments. Unfortunately, a C/C++ API is not
available, which puts the many games developed in this language at a
disadvantage. On the up side, YouTube uses an HTTP based protocol that is
straightforward to implement yourself.
Applications that want to communicate with YouTube's
servers can use one of several HTTP request methods, of which GET and POST are
the most common ones. HTTP GET asks the server to read a resource, for example
the description of a video feed that you subscribed to. HTTP POST, on the other
hand, is used to create resources, such as when uploading a new video.
A resource in this context is anything addressable by a
URL, for example http://gdata.youtube.com/feeds/api/standardfeeds/top_rated to
get access to the most highly rated YouTube videos.
After accessing a resource
in this way, YouTube's server answers with an HTTP response code,
signaling the result of the operation,
and a content document with additional information (usually in XML format) -- more info here.
This style of request/response mechanism is referred to as
REST (representational state transfer).