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 EncodingGuide.

Introduction

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 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:
There are two additional key points that our videos must adhere to:

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: 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 PrBoom); .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 EncodingGuide 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 encode must at least have a 2-to-1 scaling ratio, except for games that output at a height of 400 pixels or above natively. For handhelds, it is allowed to have a 4-to-1 scaling ratio.
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:

Logo, subtitles, and other extras

Gameplay should be prefaced by a ~2 second logo, which displays prominently the website https://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 appropriate and 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 Encoders/Logos.
For a logo creation guide, see EncodingGuide/Logo.

Subtitles

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 (https://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:
Title
'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 https://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.
If the author of the TAS has a specific request for encoding their movie (e.g. including RTA time in the subtitles), they should generally be granted, with the exception of special logos, as they're an identifier on who encoded the movie rather than who made the TAS. If unsure if the request should be granted or not, ask a Senior Publisher.
For very long runs, it is also advisable to add more subtitles throughout.

Container format

We currently prefer the MP4 container format as it is a highly compatible container that can be played on all web browsers and devices.

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

The preferred codec of choice for this website is AAC as all browsers and devices can play it without assistance. The MP4 container also supports the Opus codec, but it lacks support.
For AAC, use the Fraunhofer FDK AAC encoder (requires a custom build of FFmpeg that you have to make yourself) or Nero's AAC encoder. With either of them, set to the HE-AAC profile (keeps the quality at acceptable levels at low bitrates) and use a VBR setting that corresponds to a bitrate range of 32-64 kbps.
For Opus, use --bitrate to adjust quality. Reasonable initial values are about 40-80 kbps, depending on the system and audio complexity of the game. There are no other settings worth tweaking.
For CD-based games using Red Book audio:
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


Tips

x264

The following tips are for x264, which the site normally uses for video encoding.
For some data on tuning x264's more relevant settings, see this thread.

Antialiasing (optional)

For polygon-based platforms (N64 outside of AngryLion, Dolphin), the following will help improve visual quality:
For more info and examples on antialiasing settings, see this thread.

Per-platform screenshot size

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

Expand/Collapse collapse-content-_23a4ef30e969413c8f3a0123b3b531a6

EncoderGuidelines last edited by adelikat on 9/2/2023 2:30 PM
Page History Latest diff List referrers View Source