• 0 Posts
  • 31 Comments
Joined 1 month ago
cake
Cake day: June 23rd, 2024

help-circle

  • Popular myth but untrue.

    The ROM is exactly 40 kiB or 40 960 bytes. The NES outputs video at a resolution of 256×240=61 440 pixels. The game never switches palettes mid-frame and thus the highest possible number of colors (of the 64 available ones, of which 55 are distinct) in any screenshot is: 4 sprite palettes × 3 non-transparent colors per palette = 12 colors among all sprites; plus 4 background palettes × 3 selectable colors per palette + 1 selectable color shared between all palettes = 13 colors in the background; or 25 colors in total.

    Even one of the most basic lossless image formats, GIF, can use an n-bit palette of 2−1 arbitrary colors plus transparent, where 1≤n≤8. For n=5, we can store up to 31 colors at 5 bits per pixel, or 307 200 bits total, which is 38 400 bytes. The palette entries, size etc. will take about 200 bytes at most, and LZW compression built into the format (or even better, whatever PNG uses) can be used to reduce the file size further (significanly because there are huge areas filled with solid color or patterns).

    I’d bet it’s possible to make an NES ROM that does nothing but fill the screen with noise-like tiles and switches the colors mid-frame, likely in just 8 kiB of video ROM plus 2 kiB of program ROM, whose screenshots will never compress to below 10 kiB in PNG format, though.







  • Yes, video too, but support by clients is inconsistent (some don’t show playback controls and loop it like a gif, some just display a link). By default, the media hosting server allows for up to 900 frames (up to 30-37 seconds of smooth video) and 2160p; the audio track is removed; the filesize limit is 40 MiB (most instance owners set it way lower, perhaps 5 or 10). There is a caveat: all media must be encoded to a single codec of the instance owner’s choice: VP9 (default), H264, H265, AV1, or VP8. Uploading in one of the others is possible but beware: it is going to be reencoded by the server, and if the process doesn’t finish within the timeout of 30 seconds, you get the error ffmpeg timed out. In 30 seconds, a server without HW acceleration will typically only process a very short video (for feddit.org, it’s about 1 MiB’s worth of H265) so anything longer than a few seconds will fail! To take advantage of the full upload limit, you must reencode the video yourself to VP9 or whatever other codec is set (you can tell by uploading a tiny file in any codec and inspecting the output).

    You can use the following command to reencode the video to VP9:

    ffmpeg -i input.mkv \
      -r 899/<duration> `only use this for longer videos where you need to reduce frames to 900` \
      -c:a libopus -b:a 48k `audio will probably be removed anyway` \
      -c:v vp9 \
      -crf 32 `constant quality mode, lower is better quality, try finding lowest value satisfying filesize limit` \
      output.webm
    

    FFmpeg can do much more to the video: resize, crop, trim etc. Look it up. If you want GUI, try Handbrake.

    Alternatively, just use a more lenient hoster like GitHub or catbox.moe and embed the file from there, which has no aforementioned limits: ![Big Buck Bunny 4K](https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm) will embed a 10-minute 4K movie.