• 0 Posts
  • 39 Comments
Joined 3 months ago
cake
Cake day: June 23rd, 2024

help-circle
  • the composite to HDMI converter has a single switch from 720p to 1080p

    Composite is 480i/60*. That is, 60 times per second a blanking interval occurs, then 240 lines of picture are drawn - either the top (odd) or bottom (even) field. This is neccessary for CRT TVs because a 30Hz refresh rate would cause seizures but drawing all 480 lines 60 times per second would be wasteful. Look it up online for details: if you want videos, I recommend the Television playlist by Technology Connections on YouTube, especially the first video.

    (Technically, the vertical frequency for NTSC is 59.94 Hz (precisely 60000/1001) to avoid interference between color and audio while keeping compatibility with B/W sets. In practice, you should check that the video output is actually at this frequency; if it’s 60 then every 1000th frame will be duplicated - no big deal usually unless this also swaps odd&even fields. No such problem exists for PAL, which was always exactly 50 Hz.)

    If the converter only outputs 720p or 1080p (presumably at 60 Hz), all 720/1080 lines are drawn 60 times per second, which means lines are added with some scaling technique, after some kind of deinterlacing happens. There are various deinterlacing techniques that could be used here:

    • doubling each of the lines for 240p60 video: easiest and best for temporal accuracy but loses half the vertical resolution
    • holding the previous two fields for to the next frame for 480p60 video where only every other line changes per frame: good for viewing (this is how playback usually works on progressive-scan monitors) but wasteful for storage, as each field is basically stored twice and compression does not help. Pausing will show two consecutive fields (it will be random whether top or bottom first, depending on the exact frame you pause on) so whatever moved in between will have jagged edges but that’s expected.
    • most common, and likely what your hardware converters do: doing the above but only storing every fully changed frame for 480p30 video: this is terrible for video shot on video cameras because the time difference between fields is not accounted for, and you will see jagged edges for moving objects, or even moiré patterns when scaling. However, this is the best option for PAL film scans because they were shot progressively and then scanned interlaced so the top and bottom fields correspond to the same moment in time (as long as the fields are not swapped, which is why capture software usually has that option). For NTSC film scans, 3:2 pulldown is used (each odd frame gets scanned for 3 fields, each even frame for 2 fields to convert 23.976 frames/s to 59.940 fields/s) so this technique needs to be modified to skip the correct one from every 5th field (or average it with the 3rd for noise reduction).
    • computation-heavy: guessing what the missing lines of each field would be using some kind of algorithm for 480p60 video: this is a kind of upscaling technique and as such can produce artifacts but they will be better than what you’d get with the above methods. This will probably yield the best results if you NEED the output to be progressive video with limited bitrate, such as YouTube.
    • the best: NO deinterlacing! Store the video in an interlaced format because that’s what it is, even though software support is not as good (the software support has always been good with players, and video editors have gotten better but still the capture devices/software often insist that interlaced video could be unsupported and avoid it). You can encode it to MPEG-2 AVIs (terrible option for storage though, bad quality/bitrate ratio) and burn them to a DVD (or use a DVD player’s USB port if present) and connect the DVD player’s composite output (or better, component/SCART at 480i) with a CRT TV for the intended way of viewing interlaced video. Nobody knew about LCDs when this video standard was introduced! (OLEDs can technically be driven interlaced but no controller does that in sync with NTSC as far as I know.) The best DVD players for this are from cca 2010 when USB was commonplace but they have no HDMI which could mean there is an internal scaler or advanced framebuffer (I know a device that recompresses its video output before it goes into the HDMI/composite output module: it’s horrible!). Speaking of codecs, some don’t support interlacing anymore (H.265 for example) so be careful.

    Don’t use the converter if it cannot output 480i or at the very least 480p! Scaling should happen during playback, the files should be original resolution. You can also try non-trivial upscaling with some AI tools but still DEFINITELY keep the original resolution file for archival.

    use a [separate] worse quality VCR for cleaning

    I don’t have experience with moldy tapes. It might be a good idea but adds wear; I’d just clean the VCR after every tape if I suspect mold. You’d still need to clean the cleaning VCR after every tape to avoid cross-contamination so it would be

    Is [advanced deinterlacing] possible in OBS?

    Idk, I just keep my files interlaced and stored as high-bitrate H.264 (I don’t have enough computing power to encode sufficiently good bitrate in better codecs). If I wanted deinterlacing, I could process the files with ffmpeg filters or some other tools.


  • I don’t expect newer VCRs to be made, there’s a lot of precise mechanical engineering and the R&D that would need to go into making a professional-grade VCR today does not make financial sense. However, there is an option to refurbish existing ones and capture the magnetic signal as directly as possible. On media such as VHS or LaserDisc, the signal is not quite composite video, as that would require some 6 MHz of bandwidth. Instead, the color subcarrier is remodulated to a way lower frequency and then back to normal for playback. The folks behind ld-decode (a project that takes raw signal from a LaserDisc’s laser pickup and translates it into composite video) and its fork vhs-decode have made software that captures everything the head picks up into a raw file, and then does TBC and chroma decoding to create the best possible video. They also documented what hardware can be used for the capture (usually a firmware-modded Conexant video capture card or a beefy FPGA) and how to connect it to some VCRs’ circuitry.

    Of course, this is quite an over-the-top effort for home tapes, I’d just go with a generic composite capture card that does not deinterlace nor upscale and not bother with TBC.


  • Why a separate VCR for cleaning tapes? It’s enough to clean the heads AFAIK.

    Also, you should definitely not use default deinterlacing techniques for the video, especially not ones built into these generic dongles. Capture it interlaced, preferrably as losslessly as possible, then use deinterlacing software where you can fine-tune the settings if you need to.

    No, TBC most likely cannot be done in software, unless the video features a prominent vertical bar (such as a black border). It depends on the quality you want to reach, look closely and decide if the jitter is acceptable.

    Edit: TBC can obviously be done in software if you have the raw composite or head signal but that is not possible with the capture cards you have.

















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