Tool-assisted game movies
When human skills are just not enough

Encoder Guidelines

Guidelines for making multimedia files for publication

This page explains general guidelines for making multimedia files up to the standards of the TASVideos website. A more detailed "how to" can be found at the Encoding Guide.


TASVideos (formerly Nesvideos) was born from the need to provide good-quality multimedia files of tool-assisted speedruns. We take quality very seriously, and strive to produce files that are pleasant to watch and that are as small as possible. We also stress the informative value of the movies, and thus we have a few guidelines, that are mandatory reading for anyone who wants to make MKV or MP4 files to be published on this site.

As set out in our introduction page and parts of the Movie Rules, our runs are intended to appear as though they could be played on the original hardware (if not actually capable of being played back on the original hardware). Thus, one core guideline for our encodes is to appear, as closely as possible, as though the run was played on the original hardware.

The other and possibly more fundamental core guideline here is annoy the viewer the least. This implies the following constraints, between which we aim for the best possible compromise:

  • Quality: The video should look and sound as close to the pre-encoding input (i.e. raw emulator output) as possible.
  • Size: The video file should be as small as possible; this is enforced with per-platform ratio limits, as described below.

There are two additional key points that our videos must adhere to:

  • The video content must label the movie as tool-assisted so as to prevent the misconception that it is an unassisted speedrun (a significant amount of controversy has arisen over such misconceptions in the past). Normally, this also includes a pointer to the TASVideos website because it is currently the most reliable source of TAS-related information in the Internet.
  • The video content must label the player by name and the TASVideos website as the source. This information should be presented in such a fashion that it cannot be removed from the movie without extraordinary effort; this mostly means that labeling in the form of metadata or "soft subs" is not sufficient, and "hard subs" must be used.

Emulation settings

In keeping with the "as close as possible to hardware output" principle, settings that cause video or audio to deviate significantly from an actual console's output (as compared to not using the settings) should not be used. Examples of these settings include FCEUX's "allow more than 8 sprites per scanline" or Gens's "PSG High Quality".

These requirements are relaxed significantly when dealing with 3D games, especially on emulators that cannot accurately replicate the original console's output (example: Mupen, Dolphin). In these cases, it is permitted to use anti-aliasing, anisotropic filtering, and other texture filtering settings, even if they are not available on the original console.

Video capture

Video must be captured using a recorder that will not skip or duplicate frames; our emulators normally provide this functionality natively. Most screen recorders and other external program (such as Camtasia or Fraps) are not acceptable because they do not know when the contents of the emulator window change and hence cannot capture all frames, nor can they slow down the capture in the event of an encoding or I/O stall. When an emulator has no internal capture or an extremely poor internal capture (such as PCSX or Mupen); .kkapture is allowed. It can throttle recording speeds correctly for slow CPUs and comes much closer to frame accuracy than most screen capture tools, but is still not allowed for systems that have working internal capture.

The Encoding Guide contains links on how to configure various emulators for video/audio capture.

Frame rate

The movie should be captured at full frame rate (approximately 60fps for NTSC consoles and 50fps for PAL) so that each unique frame that is rendered by the hardware is displayed precisely once - i.e. frames cannot be skipped. If the emulator's built-in video dumping cannot satisfy this requirement (such as VBA), then the best result that can be reasonably obtained is preferred.

Resolution (image size)

The video content must not be scaled; when viewed without aspect ratio correction, it must have a 1-to-1 pixel ratio (this ensures that the video is as close as possible to the original stream, and ensure that our viewers who prefer video to be viewed as though being played back in the emulator are capable of doing so).
  • For NES, SNES, and SGB, the resolution must be 256x224 or 256x240 (or 512x448 in the case of the SNES HiRes mode).
  • For GB/CGB/GG, the resolution must be 160x144.
  • For GBA, the resolution must be 240x160.
  • For DS, the resolution must be 256x192 per screen.
  • For SMS, the resolution must be 256x192.
  • For Genesis, the resolution must be 320x224, 320x240, 256x224 or 256x240 (the latter two are only for games that use the low resolution mode for the entirety of them, such as Shining Force).
  • For N64/PSX, the resolution can be 320x240 or greater (see below).

Some consoles (currently, Genesis, PSX and DOS) display content at multiple resolutions. In this case, an exception is allowed to allow content to be scaled either to the resolution most commonly used in the run (ensuring that the video content most often seen is free of scaling artifacts) or to the largest width and height of all present video content (such that no data is lost in scaling).

If an emulator is not capable of producing output that matches pixels on the actual emulated system 1:1, then this requirement is relaxed (example Mupen, Dolphin).

For those consoles which are intended to be displayed on a TV or on CRT monitors, the video must specify the correct display aspect ratio (often 4:3), as the video output for those consoles is normally displayed at that aspect ratio. Handhelds or other consoles not intended for TV/CRT display don't need AR correction, because their resolution is always fixed to match the display matrix pixel-for-pixel without any kind of stretching involved; thus, any AR that doesn't match the native resolution will distort the image.

Duration of the video

The video must start at the beginning of the input file (normally console start-up) and must include the full ending (with at least one full loop of the ending song for those games that have them).

Some games contain secret messages of different kinds that appear in some time of waiting after the credits end. It's at the discretion of the publisher/encoder to include secret messages. Here's the list of games known to contain such messages: NES Lagrange Point, SNES Secret of Evermore, Genesis Chakan and NES Takeshi no Chousenjou.

Logo, subtitles, and other extras


Gameplay should be prefaced by a ~2 second logo, which displays prominently the website http://TASVideos.org/ and the text "This is a tool-assisted emulator movie" or a close variant thereof. Logos are additionally meant to identify the encoder, so personalized content of some sort is advisable so long as it does not overshadow the website and the designation of the movie as a TAS.

Logos are subject to approval by the senior publisher.

Some examples of currently-in-use logos can be seen at SiteHistory/EncoderLogos.

For a logo creation guide, see Encoding Guide/Logo.


The following information must be present in the encode, normally in the form of hard-coded (i.e. embedded in the video stream directly) subtitles:

  1. What game is being played in the movie
  2. Branch, if applicable
  3. Who created (played) the movie
  4. The length of the movie, directly derived from the number of frames
  5. The rerecord count
  6. A pointer to this website (http://TASVideos.org/)
    • Please be careful to not make typing errors in the address. A simple mistake to happen is adding www into the address, don't make this mistake.
  7. A mention that the movie is tool-assisted.

The total duration of the subtitles should be approximately 10 seconds, divided into two parts of five seconds as follows:

The first part:

  'branch' (if applicable)
  in hh:mm:ss.ss
  by PlayerName
  Rerecord count: number
The second part:
  This is a tool-assisted recording.
  For details, visit http://TASVideos.org/
The first part discourages people from claiming the movie their own work, and also prepares the viewer for what will be shown.
The second part explains that the video is not a real-time playing performance. It is explained briefly, and a pointer to the TASVideos website is given to provide the opportunity to read the full details, as well as to point to a repository of more videos.

The subtitles should appear within the movie once gameplay has started, while not blocking any relevant parts of gameplay. The rational for this is to ensure that full segments of gameplay ripped from an encode will still show the information described above. Therefore, subtitles should appear after any intro scenes.

If a run has multiple fully independent segments, there should be subtitles near the beginning of each of them. As an example, Super Metroid which has Ceres Station and Planet Zebes segments, subtitles should appear close to the start of both of those. This only applies to games which feature an often ignored intro level or similar. In order to determine the need for additional subtitles, use your judgment to decide if realistically people who have only seen the latter segment(s) of a game would believe they've seen all the necessary gameplay.

For very long runs, it is also advisable to add more subtitles throughout.

Container format

We currently prefer the MKV (because it is a free format with numerous technical advantages) or MP4 (for having similar technical advantages while having the added benefit of being streamable) container formats.

Video codec

Our encodes presently use x264 for video compression, for being the best currently available compromise between:
  1. Preserving all interesting video information (color, brightness, animation, movement), and
  2. Having as small a file size as possible.

Other codecs may be permissible, so long as they are freely available for all operating systems; it is strongly recommended that you consult a publisher or admin before doing so.

It is highly recommended that you experiment with different settings when encoding; a great deal of settings impact file size and visual quality. In particular, bit rate is not the only thing that affects the visual quality!

See tips below.

Audio codec

Your choice of codec depends to some extent on the container format. For MKV, we recommend encoding audio with Opus; Vorbis and AAC are also technically allowed. For MP4, use AAC encoding (the end result will be streamable if both of these are met).

For Opus, use --bitrate to adjust quality. Reasonable initial values are about 40-80, depending on the system and audio complexity of the game. There are no other settings worth tweaking.

For Ogg Vorbis, one can simply use -q1, which results in an average bitrate of approximately 70–80 kbps.

For AAC, use Nero's AAC encoder (the current preferred choice by the site) and -q 0.25; this will normally produce HE-AAC (sound quality at effectively double the nominal bitrate) with bitrates from 32-64 kbps depending on the platform.

For CD-based games using Red Book audio:

  • Bitrate may be additionally raised to preserve quality.
  • Use of a dump of the game that preserves the audio tracks losslessly (normally in .bin/.cue format) is required.

Furthermore, you may (and should) adjust the bitrates as needed, depending on the properties of the sound in the particular game.

Most common reasons of not accepting an encoded video file for publication on this site

  1. Video has incorrect resolution or aspect ratio information
  2. Quality is below that of current publications (where visual quality is roughly equal, smaller encodes are preferred)
  3. Bad audio-video sync or drift (e.g. audio lags incrementally behind the video)
  4. Poorly placed or incomplete subtitles (overlaps action, does not contain all relevant information such as site information, etc.)
  5. Unacceptable logo (does not contain site information or distracts unnecessarily from said information, or is too long)



The following tips are for x264, which the site normally uses for video encoding.

  • Constant rate factor 20 (--crf 20) is considered the site standard for video quality; it is recommended unless this provides an unacceptably large bitrate.
    • Good average bitrates vary between 140-250 kbit/s for NES, SMS or Game Boy games and 200-600 kbit/s for other consoles, depending on the video content. Some Genesis games and most N64 and PSX games may exceed this.
    • Using CRF 16 is really recommended in 3D N64 games, since at CRF 20, the encode gets a lot of artifacts and it could be unappealing to the viewers.
    • If you are aiming for a specific bit-rate, use multi-pass encoding. It nearly always improves the quality-to-size ratio.
  • Use the best motion detection settings you can afford. Our expert encoders normally use exhaustive searches (esa or tesa) with range settings around 32 (some encodes have used up to 64 for tougher to encode games where the file size needs to be crunched down even further to keep inside the site's size-to-length ratio limit). This slows down the encoding speed but the size and quality benefits are very much worth it.
  • Use 15 or 16 reference frames (--ref).
  • Use maximum subpixel refinement setting if your game uses subpixel motion (N64 uses always, SNES sometimes, NES never). If it doesn't, you don't need to use the maximum setting, though, again, the quality and size benefits are usually worth it if you don't mind slowing down the encoding speed.
  • Use bframes, which almost always reduce video size.
  • Do not set the keyint value too high, as this reduces the ability to seek in the video and inconveniences viewers. The default is 250; values higher than 600 are discouraged. Most published encodes use either 600 or 300.
  • Do not use "noise reduction". Emulators do not simulate antenna or tape signal degradation, so there's no point in trying to reduce it.
  • Use duplicate frame removal (by means such as AVISynth's DeDup plugin or sgrunt's dedup.c filter); this virtually always reduces file size at no cost in quality.

For some data on tuning x264's more relevant settings, see this thread.


For polygon-based platforms (N64, PSX with some gpu plugins, Dolphin), the following will help improve visual quality:
  • Use the maximum anti-aliasing setting.
  • Use the maximum full-screen anti-aliasing setting (FSAA).
  • Use the maximum anisotropic filtering setting.
  • Ensure that in your display card settings, there is no color-correction/skew curve active.
  • Record the movie at a high resolution (such as 1280x960), then downscale it to target resolution with a lanczos or bilinear (only when scaling to half the original resolution, for instance 1280x960->640x480) scaler before or when encoding it. Yes, it will drastically slow down the sampling, but the quality difference is worth it.
    • When capturing at higher resolutions, use integer ratios so that the image won't be unnecessarily blurred upon downscaling. For example, N64's native resolution is 320x240, so capture at 640x480, 960x720, or 1280x960, and so on.

For more info and examples on antialiasing settings, see this thread.

Per-platform screenshot size and ratio limits

  • The screenshot size limit is 45,000 bytes. If PNG can't be gotten below this, use JPEG.
  • The correct screenshot resolution may not be among ones listed (especially for Arcade, Wii, OS).
    • Admin-level users can override this check.
  • Ratio limits set the allowed size of encode
    • Unit of ratio is 10^6 bytes of filesize per minute of encode.
      • E.g. 10min30s encode with ratio limit of 0.05-2.05 can be from 525,000 to 21,525,000 bytes.
    • Reasonable effort shall be given to getting encode below ratio limit with good quality (but with some games, this is impossible).
    • Senior publisher and site managers can override ratio limits.
    • The ratio limits are no license to make unnecessarily large encodes. Each encode should be as small as it can be without sacrificing quality, given the content of the game in question. A graphically simple game might be encodable well under this limit; graphically complex games might hit or exceed it.

TODO: 10bit444 is now standard. Edit the table accordingly.

Shortname Description Nominal width Screenshots Ratio
NES Nintendo Entertainment System 256 256x224, 256x240 0.15 - 5.05
SNES Super NES 256 256x224, 256x240 0.25 - 8.05
Genesis Sega Genesis 320 256x224, 256x240, 320x224, 320x240 0.30 - 9.05
GB Game Boy 160 160x144 0.05 - 2.05
SGB Super Game Boy 256 256x224, 256x240 0.10 - 3.05
GBC Game Boy Color 160 160x144 0.10 - 4.05
GBA Game Boy Advance 240 240x160 0.25 - 8.05
N64 Nintendo 64 320 320x224, 320x240 0.35 - 11.05
DOS DOS 320 320x200, 320x240 0.20 - 9.05
SMS Sega MasterSystem 256 256x192 0.10 - 4.05
PSX Sony PlayStation 320 320x224, 320x240 0.40 - 13.55
PCE TurboGrafx 16 256 256x224, 256x240 0.20 - 6.05
WSWAN WonderSwan 224 224x144 0.20 - 6.05
PCFX PC-FX 256 256x224 0.25 - 8.05
NGP Neo Geo Pocket 160 160x152 0.20 - 6.05
Lynx Atari Lynx 160 160x102 0.05 - 2.05
DS Nintendo DS 256 256x192, 256x384 0.30 - 10.05
GG Game Gear 160 160x144 0.10 - 3.05
Arcade Arcade 384 384x224 0.30 - 10.05
Saturn Sega Saturn 320 320x240 0.30 - 10.05
32X Sega 32X 320 256x224, 256x240, 320x224, 320x240 0.30 - 9.05
SegaCD Sega CD 320 256x224, 256x240, 320x224, 320x240 0.30 - 9.05
FDS Famicom Disk System 256 256x224 0.15 - 5.05
PCECD TurboGrafx 16 CD 256 256x224 0.20 - 6.05
VBoy Virtual Boy 384 384x224 0.20 - 8.55
MSX MSX Home Computer System 320 256x192, 256x212 0.10 - 4.05
GC Nintendo GameCube 320 320x240, 384x216 0.60 - 25.05
Wii Wii 320 320x240, 384x216 0.60 - 25.05
Windows Windows 320 320x240 0.50 - 15.05
SG1000 Sega SG-1000 256 256x192 0.10 - 3.05
TI83 Texas Instruments TI-83 Series 96 96x64 0.05 - 2.05
SGX SuperGrafx 256 256x224 0.25 - 8.05
DOOM DooM 320 320x200 0.40 - 13.55
A2600 Atari 2600 320 320x192, 320x262 0.10 - 4.00
Coleco ColecoVision 256 256x192, 256x224 0.10 - 3.05
A7800 Atari 7800 320 320x262, 320x312 0.10 - 5.05
C64 Commodore 64 320 320x200 0.05 - 2.05
AppleII Apple II 280 280x192 0.10 - 6.05

Checking your encode.

After you've made an encode, please ensure it encoded properly, and meets the above criteria. Go over the checklist.

See also

Combined RSS Feed
EncoderGuidelines last edited by feos on 2016-03-20 12:25:01
Page info and history | Latest diff | List referrers | View Source