Not as good as a DVD, but quite respectable for a 50-year old home video format. The tape itself is 30 years old. The sleeve reads, "digital transfer". Closed captions. Hi-Fi stereo. Too bad it is not widescreen.

There is about half an hour of a wedding recorded. Attached is a small clip.

I bought a 6 TB drive from Walmart a month ago. Connected it to power, connected to a computer, it just works. I gave it to my son.

Then I bought an 8 TB drive - did not work for me, the LED blinked rapidly, the drive did not spin up, Device Manager showed nothing (tried Win 10 and Win7). I returned it and bought another one, again from Walmart. And it does the same!

Am I doing something wrong? Does 8 TB drive need additional magic compared to 6 TB?

Also, the second 8 TB drive has some dusty spots on it despite being packaged as new. Weird.

This comes from a VHS-C recording made sometime in the 1990s. IDK who recorded it, I got the tape on an estate sale and digitized it. See the full 20-minute tape on my YT channel in proper 60 fps (Reddit converts everything to 30 fps).

The camcorder + two batteries + two cables + camera bag for $25 shipped. If I needed a charger, which I did not, it would be another $7.

Someone was spotting Amtrak locomotives in the 1990s. The video comes from a 20-minute VHS-C video cassette that I came into possession of. The full 12-minute recording is on my YT channel in 60 fps, no cuts, no edits, no color correction.

A VHS-C tape recorded in 1998 in EP mode. The quality is not great, the picture goes out of sync occasionally. No idea what is the make and model of the camcorder.

Digitized with the Portta VD22P VHS-to-Digital converter having the firmware updated to VD22P.25.28. Reddit cannot reproduce 60 fps, as it converts everything to 30 fps.

I hate unmotivated camera shake, zoom in-out, pans and tilts, especially executed with a camera having dreaded rolling shutter. I hate unmotivated slo-mo. I like slow panning with a camera on a fluid head. Crane is fine, handheld is fine when shooting closeups of excited ravers.

Panasonic SDR-H40P in pristine condition, two battery packs, AV cable, USB cable, camera bag — all for $25 including shipping. Not a lucky find in a thrift store, but a boring "Buy It Now" of a "Used" item on eBay.

Catch #1 — no charger included. I have several chargers from other Panasonic camcorders that I own, so not a problem for me, but if I needed it, a charger is $7 shipped.

Catch #2 — No AC adapter included. The camcorder needs to be powered from an AC adapter to be connected to a PC via USB. A regular adapter with a barrel-shaped plug does not work, as the camcorder does not have a corresponding socket. It needs a DC cable with a dummy battery: K2GJ2DC00021 or K2GJ2DC00022. I think I have one somewere, but in the meantime the solution is to record onto an SD card instead of the built-in HDD. The camcorder supports SDHC cards up to 32 GB. For reference, the built-in HDD is 40 GB.

I copied the MOD files, deinterlaced them with BWDIF and upscaled to 720p.

for /r %%d in (*.mod) do (
ffmpeg  -i "%%~nd%%~xd" -c:v h264 -vf "bwdif=1:0:0, scale=1280:720, setsar=1" -c:a aac -strict experimental -b:a 256k "%%~nd.MP4"
)

BWDIF is not the best deinterlacer, but it is fast, and it is better than the crude bobber employed in the $150 PowerPlay, not to mention it makes cleaner image than blocky 30p garbage produced by the $30 MiniDVR or the $90 iRecord.

Of course, because the camcorder has a CCD sensor, the video has the vintage traits that kids look for, namely vertical saturation trail (actually, a defect) and proper frame geometry thanks to global shutter.

Reddit converts everyting to 30 fps, so you cannot enjoy 60 fps smoothness from the attached video :)

Panasonic DMR-ES35V → SVideo → Portta VD20P (1080 16:9 @ 12 Mbps) → force aspect ratio to 4:3 in Avidemux → cut out four songs that blocked the video → save to MP4 container without re-encoding.

Watch the whole tape (I had to remove four songs) here: Rock Video Monthly | Heavy Metal, Hard Rock | January 1993 Releases (0193H, VHS).

• Device model: LG LM-K500UM
• OS version: Android 11
• Steps to reproduce: upload a video with non-square pixels, observe image proportions in the feed.
• Expected: correct proportions of the video according to size in pixels and pixel aspect ratio
• Observed: correct video proportions in the post itself, wrong proportions in the feed.

Long story

First video is posted in r/vhs. Frame size in pixels is 1920x1080, DAR is forced to 4:3 in Avidemux, therefore the video must have 4:3 proportions. Observed correct proportions in the post itself, but stretched horizontally in the feed.

Second video is posted in r/camcorders. It is an HDV video. 1440x1080 with DAR 16:9 in metadata, so must be shown as 16:9. Observed correct proportions in the post itself, but squeezed horizontally in the feed.

I suspect that the feed renderer assumes square pixels, while the post renderer correctly handles DAR and SAR.

In a desktop browser both feed and post videos render with correct proportions.

Expected outcome of this report: Android feed video renderer must be fixed to take into account pixel aspect ratio of a video.

Panasonic DMR-ES35V -> component video, stereo audio -> Portta VD22P (1080 16:9 @ 12 Mbps) -> force aspect ratio to 4:3 in Avidemux -> save to MP4 container without re-encoding.

Reddit has issues with non-square pixels. On my Android phone, the video looks stretched horizontally in the feed, but has correct proportions in the post itself.

You may be wondering, why capture into "1080 16:9", when the capturing device offers "1080 4:3"? The reason is, both of these modes produce a 16:9 frame, but in the "1080 4:3" case a 4:3 picture is pillarboxed inside a 16:9 frame, which is correct from the broadcast standpoint, but does not work for me. I don't want to have black bars on the sides. So, I capture into "1080 16:9", which stretches the picture, but avoids black bars. Then I force 4:3 aspect ratio. It works for Youtube, and it works for Reddit inside a post, but presently does not work for Reddit feed.

I filed a bug report, hopefully this will be fixed.

This is another clip taken from five two-hour tapes recorded in December 1993 - January 1994.

I have finished a 1-hour movie, which you can watch on YouTube: Alex and Ivan travel America: From New York to San Francisco in an Oldsmobile. The narration is in Russian, and there are custom English closed captions.

I've had these TS files sitting around for 17 years.

Today, I threw them into Vegas, they were recognized as 24p. Scrubbing over timeline looked fine. I edited them a little, rendered, but the output video was full of combing!

I tried processing the source files in VirtualDub, but its IVTC filter could not handle them cleanly, showing occasional combing.

As an act of despair, I did a straight-cut edit in AviDemux based on my Vegas project, rendered without re-encoding into TS file, then removed the pulldown with ffmpeg:

ffmpeg -i input.ts -vf "fieldmatch,yadif,decimate" -r 23.976 -c:v libx264 -crf 18 -c:a copy output.mp4

Here is the log:

Input #0, mpegts, from 'input.ts':
  Duration: 00:00:41.06, start: 0.104100, bitrate: 25720 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
  Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 25000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn
      Side data:
        cpb: bitrate max/min/avg: 25000000/0/0 buffer size: 7340032 vbv_delay: N/A
  Stream #0:1[0x101](und): Audio: mp2 (mp3float) ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 384 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (copy)

Output #0, mp4, to 'output.mp4':
  Metadata:
    encoder         : Lavf61.7.100
  Stream #0:0: Video: h264 (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1440x1080 [SAR 4:3 DAR 16:9], q=2-31, 23.98 fps, 11988 tbn
      Metadata:
        encoder         : Lavc61.19.101 libx264
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1(und): Audio: mp2 (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 384 kb/s
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #73 at 2.5025 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #146 at 5.005 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #457 at 15.5155 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #545 at 18.5185 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #603 at 20.5205 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #706 at 24.024 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #883 at 29.9299 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #884 at 30.03 is still interlaced
[Parsed_fieldmatch_0 @ 00000000004eebc0] Frame #957 at 32.5325 is still interlaced

Despite the warnings that some frames were still interlaced, the results looks acceptable. Ugh.