This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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 video.)
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.
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).