My Eight-Year Quest to Digitize 45 Videotapes
mtlynch.io
mtlynch.io
Technology Connections (YouTube) does some good coverage of capturing/converting analogue video - hardware choices make huge difference. https://www.youtube.com/watch?v=ZC5Zr3NC2PY
There's clearly a need/desire for this kind of stuff (though it's sad how many times I'm approached as someone is near death). Don't wait til that moment to save the stories and memories that you have.
I've been back and forth about how much I want to dive in with this project. If anyone is local and really interested in some of it, drop me a line. There are some cool avenues I've touched - seniors, alzheimers, story capture.
TBH 35mm slides are the biggest pain in terms of time-vs-return out of any format. It's a painstaking process and I could not justify the $5000+ cost for a dedicated high-speed machine. But if the end output is ~300dpi for TV display, etc I may be able to help with a fast option.
I think this was in reference to your comment that your side gig that provides this service is “kinda on pause though”. :-)
Especially I wonder if you've got advice on picking a useful level of resolution when digitizing slides. I seem to recall that a 35 mm slide contains around 10 megapixel data. If correct, is it at all useful to digitize at a higher resolution for general purpose usage, eg display on a computer or showing slideshows with a digital projector.
Otherwise I'm currently leaning towards digitizing at 4K resolution as a default, given that 4K is 8.2 Mpx.
How does dynamic range come into play? I seem to recall that slide film has a high dynamic range in general.
[0] https://www.usa.canon.com/internet/portal/us/home/support/de...
(I used to have a CanoScan 8800F.)
For high-speed photos a popular choice is the Kodak Ps50/ps80 -but it was discontinued like 2 years ago so you have to get it second hand. TBH, I've used the Epson FastFoto series for fast scans at 600dpi (useful when you have literally thousands you want to get through - a shoebox will hold 1500+ photos) and it has great quality if you set it up right (read: turn off any image post-processing and do manual correction). But beware of a few caveats: the rollers are garbage once they heat up and glossy photos will 'stretch'. You can mod the rollers (kinda). The rolling action also causes some static buildup (thus: dust) and there's no Digital ICE (image correction/enhancement) to remove it.
For video, check the youtube video above for one option. I've found that you can get really good results with a Digital8 camcorder with a good Digital/Analog converter. They existed in this weird sweet spot of the transition of analogue to digital. They often have RCA/SVideo connections out to Firewire (yes.) Use it as a pass-through for a really good VCR (which are getting harder and harder to find).
I've heard of d8 camcorders that are v8 compatible but never seen. V8 and hi8 I just use rca.
Blackmagic digital studio capture cards work very well.
No matter what you do all these old formats never look good imo.
I can only add, that for me it worked best to capture the tape all in one go, and not try to start-stop the camera with DV control. Be it deteriorating tapes or whatever the cause, but the capture software had problems resuming the camera if it was ever paused.
And it leads to that other challenge worth mentioning: Even though DV is technically a lossy format, it results in really large files.
Just run the tape at half or a quarter of the speed. The spinning helical head should still produce data. Then it's a matter of assembling it in software.
Modern computers with thunderbolt will take a converted fw stream without any problem. I am using several old fw400 sound interfaces with a string of adapters without any problems, on both mac and pc. The mac laptop has tb built in, for my workstation pc (Windows 10) I bought a PCI Express io adapter for 30 euro. Works perfectly.
Sound interface -> fw400 -> fw800 -> tb -> tb3 -> mac|pc
YMMV with video, but I can't think of why it wouldn't work. I haven't tried a converter.
I started down the path of doing this project for a family member after we found an old VCR and I had been playing with a few of the cheap HDMI capture cards.
I've had a world of hurt with video/audio sync issues and the recommendation he uses to grab the component to HDMI device led me down a path of searches where I finally found that my V4L2 capture with ffmpeg was using a different clock than the ALSA sound capture device. Using ffmpeg's -ts flag I have set V4L2 use 'abs', the same as ALSA.
I haven't done any extended length captures yet so I'm not positive I won't have drift, but on the shorter length clips it has worked flawlessly.
Anyway, thanks again for the link. His advice led me down a path that finally seems to have made the capture aspect of this project work!
The capture part was easy enough, did it over a single weekend. I bought a camera that could play the tapes (~$100) and an Elgato Video Capture (~$80). Quality was as good as possible from the tapes and no audio issues. I also did not want to use a third party because I was concerned they might botch the job / lose the irreplaceable tapes / etc.
The editing took about a month, I've never done video editing before. I just loaded up stuff in iMovie and grouped stuff together as it made sense to me. Most of the time was spent just watching the videos (I think I had around 60 hours of footage) which was enjoyable and necessary.
In terms of sharing, I paid a friend who does video editing to make a supercut of all the best moments and I screened it at the family Christmas (many laughs and tears). I gave folks thumb drives of clips that were specific to them, but honestly I'm not sure if people even watched them. The movie format made it more digestible.
If anyone wants the Elgato, I still have it and can give it to you for the cost of shipping. Also happy to refer you to my friend for editing needs, he's very affordable.
Your story sounds like the experience I thought I'd have. There'd be certainly a lot less difficulty if the equipment I got just captured accurately right out of the box.
I agree with you on the value of making supercuts of the clips. I've made two video montages from my videos, and those are the clips I most often re-watch.
Thanks!
Although presumably they don't do audio...
When digitalizing VHS tapes, generally one doesn't have a HDMI signal to use. They either have Composite (typical) or S-Video (better, but rarer). Typically, one should get a Composite/S-Video to USB device rather than trying to add a Composite/S-Video to HDMI device into the link here. Adding more pieces that you don't have control over tends to result in more issues and/or worse capture quality (due to extra filtering/compression steps applied).
Devices like the "Hauppauge 610 USB-Live 2" and "Elgato Video Capture" (I'd use the Hauppage device personally) provide a Composite/S-Video to USB 2.0 adapter that can provide uncompressed video.
I spent much longer on this project than I expected to, and I learned a lot from the experience. I wrote this in hopes that it might be useful for others who want to digitize their old photos and home videos.
I'm happy to answer any questions or take any feedback about this post. I'm by no means an expert on digitization or video processing, but I'll gladly share what I know.
But, yes, definitely. That was the biggest breakthrough in this project. I'm glad it came to me, as it otherwise would have taken me hundreds more hours, or I'd have given up before finishing.
thx!
Once I realized I could script the editing, that became the least stressful part to me. Fixing mistakes was just a matter of tweaking some code and re-running the scripts. Capturing, to me, was harder because I constantly worried about missteps that would cause quality losses I'd only discover later.
Timebase correction just fixes up the sync pulses so they arrive in an orderly fashion, which improves the picture quality.
In retrospect, I should have spent more time studying the technical side of of digitization. My process was to just Google problems as I encountered them so I could get unstuck. I never took a step back to understand the fundamentals, but I think that would have saved time overall.
"The NTSC field refresh frequency in the black-and-white system originally exactly matched the nominal 60 Hz frequency of alternating current power used in the United States. Matching the field refresh rate to the power source avoided intermodulation (also called beating), which produces rolling bars on the screen. Synchronization of the refresh rate to the power incidentally helped kinescope cameras record early live television broadcasts, as it was very simple to synchronize a film camera to capture one frame of video on each film frame by using the alternating current frequency to set the speed of the synchronous AC motor-drive camera. When color was added to the system, the refresh frequency was shifted slightly downward by 0.1% to approximately 59.94 Hz to eliminate stationary dot patterns in the difference frequency between the sound and color carriers, as explained below in 'Color encoding'. By the time the frame rate changed to accommodate color, it was nearly as easy to trigger the camera shutter from the video signal itself."
https://video.stackexchange.com/questions/32492/what-causes-...
>mediagoblin looks like the perfect solution for hosting media in a more convenient way than just folders and files.
I'll just warn you now that MediaGoblin is deceptively hard to work with. I chose it because I got it up and running quickly, but over time, I'd keep running into issues that should have been simple but required digging through their source and sometimes making my own patches. It also doesn't specify dependencies very precisely, so I constantly had issues installing it when its dependencies changed out from under it and broke everything. I tried hard for a while to get my patches merged upstream to prevent others from re-doing my work[0], but the project has effectively been unmaintained for the past 2+ years, save for a few brief spurts of work every few months.
If I were starting from scratch, I'd use a static site generator like Hugo or Gatsby to just generate thumbnails and URLs for each clip. You'd have to write a little custom code, but I suspect it's less time overall than you'd spend getting MediaGoblin to work.
[0] https://issues.mediagoblin.org/ticket/5574 (their bugtracker is currently down, which should give you a sense of the state of the project)
I've got a decent capture setup (semi-Professional gear that captures at up to 10-bit uncompressed 4:2:2 - over 100GB an hour!) that I obtained basically for free since it is fairly old (early 2000s). Since good VHS decks are getting harder (and more expensive) to find, I haven't got a good[1] one yet. I'd be interested to know if the difference between the two decks was noticeable!
[1] I consider the recommendations on this thread: http://www.digitalfaq.com/forum/video-restore/1567-vcr-buyin... to be fairly good at separating good VHS decks from the rest of the pack.
VHS only has 3MHz bandwidth, let's don't pretend that a software-defined VTR is not practical.
Answering your actual question: S-VHS vs VHS deck should not make any difference for playback of VHS cassettes. Cassettes recorded in S-VHS cannot be played on a VHS deck, so that would be an obvious difference.
My (admittedly basic) understanding of VHS vs S-VHS decks is that due to the stricter tolerances required by the S-VHS standard, S-VHS decks typically have better transports than regular VHS decks (lower wow/flutter, better tracking, etc...). And of course many of the high-end decks have a built in TBC.
S-VHS decks weren't necessarily any better than VHS ones, and the two formats are incompatible.
Mitsubishi, Panasonic, and Sony made the best VHS VCRs, IIRC. The best ones for capture maybe different, but this is what I recall for analog NTSC playback. S-Video connectors, if you can get them may help, but not always.
If I were going green-field the design of a VHS/S-VHS VCR from scratch today, I use some sort of solid-state helical-scan-equivalent head that can over-capture tape domains, pre-process data to align scan lines per PAL or NTSC, and output unencrypted HDMI.
I was wondering if the digitisation company provided any kind of report. The sawtooth graph of your audio and video sync issue presents itself as being a hardware rather than software issue, envisioning ammonitic erosion of a plastic spindle. I'm just wondering whether this was fixed with the (despite your heroic attempts to source) right hardware, or if a software algorithm was involved (handcoded, ML?)
Yes, I feel very fortunate that my family recorded so much, and I do look forward to sharing it with my children.
One of the interesting parts of revisiting this footage is just seeing how attitudes towards video changed over time, at least among my circles. When I was a child, home video recording seemed so novel, even to my parents, that there was an excitement and enthusiasm in a lot of the videos just based on the sheer fact that we were recording a home video. Nowadays, I don't think people are as excited to record these kind of "slice of life" videos, even my friends with children.
The digitization company did provide a report, but it wasn't very detailed. They just listed which tapes seemed to have physical degradation or imperfections. I don't know what their methodology was, but I didn't get the impression that it was anything especially advanced. I imagine that they just trained some technicians to use their equipment and then run through a standard process for each tape.
Now when I see a camera out somewhere, all I can think is "oh jeez...are they gonna publish this on freaking Facebook?" and debate whether to ask (and risk coming off like the paranoid nutjob acting like a buzzkill).
Now when I see a camera out somewhere, all I can think is "oh jeez...are they gonna publish this on freaking Facebook?" and debate whether to ask (and risk coming off like the paranoid nutjob being a buzzkill).
Simply put, the entirety of 1 "frame" has more data than required, but a CRT TV would hide those "error margins" behind the borders. Your digital capture however has grabbed all the available data, and the pro would have done the same, but they would have then cropped it down to the desired area/resolution. You can see this when you compare the videos side by side, as the baby is "longer" in the pro version.
>You can see this when you compare the videos side by side, as the baby is "longer" in the pro version.
The baby in the video is actually me at five months old, although I'm quite a bit "longer" today.
I found any free video editing options out there difficult to learn and unintuitive. I ended up using Sony Vegas which was a big improvement.
In my case I only needed to offset my audio track to get it to sync and it was fine. However some of my videos have that same tell-tale edge tearing, I didn’t bother trying to fix it.
Glad this was reposted as I missed it first time 'round.
One of the difficult parts of the process that you can't really "productize" is cataloguing. If you receive a stranger's videotapes, you wouldn't be able to label a clip, "Grandma Alice Visits for Bobby's Kindergarten Graduation," because you don't know anyone's names or relationships or the context of the video.
There might be a product in a tool that helps people edit and tag clips after they've digitized them, but I'm not passionate enough about that work to go after a product like that.
Almost everyone on HN seems to be worried that a computer at, say, Google, knows about mundane things in their life (went to the grocery store at 4:43pm). My guess is that the ratio of worried/unworried is something like 90% on HN and 10% amongst normals.
To your point, it's probably a minority but I'd guess it's more than 10%. There's a ton of stuff in the market (identity theft insurance, new VPNs cropping up, Apple's privacy-focused branding and marketing efforts (I'm not saying they're inherently better on privacy, they just are branding themselves as such)) pointing in that direction now.
Normals need to hear more stories of seemingly innocuous things like home movies resulting in identity theft. Maybe fear isn't the best way to motivate people on principle, but it does work. Imagine how many "security questions" and other PII can be gleaned just by watching some family's childhood home movies.
For my part: Way back in like 2001 or so, I decided to digitize my family's collection of super-8 videos from when I and my sister grew up. I used a borrowed DV camera (with a firewire interface), the 70s projector and projection screen. Ended up with decent 480p quality. Used some ancient Linux/GTK-based editing tool to do the cutting. Ended up with what is now a 90 minute, 700 MB .mp4 file. I'm happy that I ended up keeping the audio track, recording the noise from the projector and my occassional giggles
It took about 1-2 days. Also I somehow broke that expensive borrowed DV camera (pretty certain it broke itself), so i paid like $150 to have it fixed.
Anywy, ~two decades later: I'm so happy I did all of that!
That said, I do worry about all those family WhatsApp videos that my family shares and/or the videos that my siblings keep in their phones with no backup whatsoever. Maybe this post will finally convince me to put something together.
Video capture:
1. there seems to be no capture device on the market that has a linux driver
2. some capture devices only provide their drivers on a CD/DVD
3. elgato video capture works (as long as the computer doing the capture is fast enough to process input in real time, otherwise the output is laggy)
Video processing (linux):
1. there's a bug in blender[1] that introduces audio skew to elgato-captured footage upon rendering. the skew is not there while editing
2. kdenlive[2] works fine with no audio skew
[1]: https://github.com/NixOS/nixpkgs/blob/6b74f99abd2f4c62e8093c...
[2]: https://github.com/NixOS/nixpkgs/blob/f6cd17269ea00766319388...
Just going with hardware I've personally used, Elgato's got one (the Camlink 4K). Blackmagic Design actually has a few options; the ATEM Mini line all output video over USB, as will their Web Presenter.
The tape tins themselves don't reveal anything about the media type or actual content.
Apparently there are some cheap (~A$500) devices that let you convert these directly to digital, but reviews and blogs suggest highly variable results, probably based on how well the tapes have been stored.
Paying someone to convert them is hideously expensive, however, and is generally charged on a per-tape processed rather than viable output basis -- which is why most people stump up for a 'single use' device and spend the time. On the upside, at least there's no audio track for these things.
An easier / cheaper way that seems fairly popular is to buy an old projector, set it up square to a good screen / wall in a very dark room, and just record that. The quality loss is probably going to be modest, given the low-quality of the original material in any case.
The rig is basically a stepper motor, driver, arduino, and IR LED. Most cameras have remote controls and you can program the arduino to send camera trigger signals with the IR LED.
It shouldn't be much modification to get it to turn a reel and take a photo.
Plugged into the back of the machines, presumably via an eye-wateringly expensive I/O card, was an original IBM XT computer running something called, from memory, "Shot Lister" but perhaps that was a generic term. Shot Lister was monitoring the timecode from the tapes and would generate an EDL, or Edit Decision List, for the editor's work. Various manually entered reference IDs plus U-matic tapes frame numbers lead back to the original 35mm negatives.
The EDL would be sent off, using a fancy new 3.5inch floppy via a courier, to another company to use the master negatives to "print" the final edit together.
I remember someone, often the 'new kid' in the suite, would be tasked with manually writing down timecodes to clapper board references when the tapes arrived containing the rushes for whatever was being edited. Overall, remarkably similar!
:(
Video Hub App https://videohubapp.com/en/
MIT Open Source: https://github.com/whyboris/Video-Hub-App
I know this isn't the place for any of this, but
1) Can you look into the delete functionality when the file is located on a mounted filesystem (I think it might be fusefs? specific scenario uses rclone Google Drive mounts!). I don't think it works with the `trash` module you're using from npm.
A few other ideas/improvements I've had:
- Do not immediately delete metadata if a file is removed. For example, if the hub contains multiple sources, some which may not always be mounted (external drives or cloud drives), deleting metadata may mean that it needs to be re-analyzed when the drive is present again. Maybe a soft-delete of this metadata would be better, so the video is hidden from the library, and then you could have an option to purge historical data periodically / on-demand. - Option to show the full file-path in one of the gallery views
Thanks!! If I ever get around to it I'll get in touch on gh.
1) Current 'delete' function sends things to the recycling bin (safe!) but does not work on network drives unless you "enable recycling bin on network drives" (some setting on the OS). I have added "dangerously delete file" which does a "rm" command instead - it will be released with version 3 of the app. Until I release, you can just build the current code which has this feature already.
Thank you for the suggestion about file metadata. This discussion is probably better as a GitHub Issue. I'm a little unclear about the scenario you describe. The app will not remove videos from the "hub" even if a source folder (like external drive) is not connected - it will just have a small icon indicating "not connected".
Cheers!
I was nervous about this part of the solution, but I can't think of any plausible scenario of unauthorized access given that I use a long, random bucket name, like mediagoblin-39dpduhfz1wstbprmyk5ak29.
I was wondering about this for a similar project recently and the best I came up with is that is if someone has a bad browser extension or their system is compromised in general. Couldn't that leak the bucket name to a untrusted 3rd party?
What I am trying to say is your good from random people on the internet, but the minute someone compromises one of the systems that has legitimate access they could extract the info they needed to access anything that user accessed.
To be clear, I think the risk of this is low and still use security through obscurity myself.
This isn't a direct answer to your question, but a quick search turned up this article for finding unsecured assets in a Google bucket https://www.andreafortuna.org/2019/08/07/some-useful-tools-f...
What would be the value? If my family members send a link to someone else, that person will have the link forever? If the unauthorized person has a link to a video, they can simply download that video and keep it forever anyway. They can't retrieve other videos in the bucket unless they can correctly guess their (not very predictable) filenames.
Resolve is wonderful. I've even put emacs bindings on mine.
I can't find a single other comment among so many emotional messages seeking solutions, for even one other semi professional or Pro tool.
Obviously the first names are BMD Black Magic Design for Resolve which now includes the Fairlight audio workstation for free. And AJA the other end of the budget spectrum, only cheaper than BMD if you have any kind of obligatory work flow or more than a weekend project. Color space transformation so you can watch on wide colour gamut panels in anything close to captured quality comes to mind for what you leave AJA to manage but need to research and invent a new work flow for if using BMD.
Now that you have reasonably high quality versions of the videos you can start exploring other things to “enhance” the videos. If you want to make a parent cry, surprise them with a 1080p (or more) version of their 1970s wedding that was transferred from Super 8 tape. I spent way too long exploring the options and trying my own models there, in the end I did some hand tweaking and used Topaz for the rest. It’s not perfect, but it’s better than the Super 8.
Yeah, I've been getting feedback that I should experiment with upscaling. It sounds interesting, but I haven't explored it in earnest yet.
Bumping the frame rate up using SVP was an easy enhancement and worked surprisingly well.
I love that the authors' baby footage shows the vintage Apple ][, that's what I cut my teeth on.
I don't understand why you wouldn't record the audio and video stream differently - with an SVHS player, you could output s-video and capture that at better quality and then audio separately from the RCA lines. And then use virtualdubmod to time it properly, then curate.
But then again, if it randomly got out of sync in recording, that could be annoying so maybe I don't fully understand the issue.
What he did do was use the 3 FBAS connectors for Stereo Audio and Composite video. Still subtle issues can crop up because analogue video is hard.
Just choosing a different capture device or finding one with less broken driver support would have been workable.
An ancient Premiere project file is unlikely to work in the future. To re-render or edit those old videos again, I will need to run a cracked ancient Premiere in a VM. That's a poor way to work with archives.
With a good transform script format, we could make software that renders the transformation on the fly. You could save a transform file with a URL to the source files. To display the transform file, your browser will download the source files, apply the transformations, and show it in real-time.
We could also use software engineering process tools on transform scripts: source control, code reviews, integration tests, declarative artifact generation like Bazel, etc. Do tools like this exist?
>For example, I captured video from 20 tapes before realizing that the audio was slightly out of sync. Or I discovered after weeks of editing that I’d been exporting video in a format that doesn’t support online streaming.
Both of these are fixable with some ffmpeg incantations.
I knew that I could re-encode for web streaming, but doesn't each re-encode degrade quality? I didn't realize that I could have fixed the audio issues with ffmpeg, though.
You also don’t always need to re-encode for streaming. It depends on why the format couldn’t stream in the first place. If you use the wrong container format for streaming (like you create an MKV file), then you can use -codec:v copy -codec:a copy and you’re not re-encoding anything. On the other hand, if you got a yuv444 and you need yuv420 for streaming, that requires re-encoding.
amusing I made the same mistake when batch digitising tapes, did about 20 before realising the audio was out of sync
Sometimes, it depends on what you were transcoding between in the previous steps, but it most likely doesn't matter because your original consumer-handheld-camera-and-cheap-tapes quality was trash anyway. Like another commenter mentioned, in cases like this you'd want one high-quality archive export, then transcode to one or a few lossy formats for ease of streaming.
You'd fix the audio drift by changing the sample rate of the audio stream with asetrate: https://ffmpeg.org/ffmpeg-filters.html#asetrate (or you could change the framerate of the video, either way)
ffmpeg has documentation, and people actually read it and learn to use it...
1. https://en.wikipedia.org/wiki/Vertical_interval_timecode 2. https://en.wikipedia.org/wiki/Linear_timecode
> This process obviously took me a long time, but I hope this article can save others 80-90% of the effort of digitizing and sharing their home videos. The next section has a detailed walkthrough of the nuts and bolts of my solution, but here are some general tips for digitizing and sharing home videos:
> Capture as much metadata as possible during the raw capture and edit stages.
> Labels on the tapes often have valuable information. Keep a record of which clip came from which tape and in what order.
> Note any clues in the clip about the recording date.
> Consider outsourcing the raw capture to professionals.
> It’s extremely difficult and expensive for you to match the quality of a video digitization company.
> ...
https://github.com/ehrmann/vhs-capture
I even found a bug in VLC's libdvdread.
The big commonalities worth pointing out are using a good video capture device and a particular family of JVC VCR.
I had a follow-up adventure digitizing Super8 film that was telecined onto VHS. It nominally runs at 18 fps, but the projector probably wasn't that accurate, so removing duplicate frames was actually a big challenge. I ended up using dynamic programming to remove similar frames with specific restrictions and a target framerate.
Looking at your post, I'm really curious what the commercial service did to get it to look better.
I went down this rabbit hole several years ago, and while finding quality equipment was important, at some point I had to step back and decide the capture was "good enough" - that the incremental quality gained by spending an additional several hundred dollars on more professional equipment wouldn't substantially improve the poor quality of the source material.
To that end, does anyone have familiarity with putting 640*480 videos on Blu-ray in H264 format, in order to cram hours and hours of video on one disk and allow it to be viewed on a standard Blu-ray player?
FWIW, archive the files however you want, then mux a copy into mkv files - most TVs, game consoles etc from the last 3 years or so will play those off USB
That's an interesting idea. If you're writing the whole backend yourself, it would work, but wouldn't you run into issues if you're using tools that expect individual video files (e.g., utilities to generate thumbnails)? It's taking something that could just be static files (possibly even an entire static site) and introducing on-the-fly processing.
Anyway, this rings very true:
> With home videos, about 90% of the footage is boring, 8% is entertaining, and 2% is amazing. After you digitize the tapes, there’s still lots of work to do.
Even as an exercise in learning, it's a deadend. Southtree and their ilk will be gone in this generation.
Next project is to digitize my grandfather's Super-8 film from the 1970s.
I discovered that Izotope RX-8 Does a nice job of removing hiss, though at the expected cost in hi-freq content.
This was all public speaking, so the noise removal worked pretty well. Not sure if it would be appropriate for music.
There is some great tech out there to help cut through the first 90%, I think. I've done a couple projects using Amazon Rekognition (and Google's equivalent) to:
- automatically detect scene changes (cuts in the video)
- annotate the video with a transcription, and
- perform facial detection and image classification
With Rekognition alone; it's entirely possible to give it a 1 hour home movie, and code up how you'd like your computer to generate a highlight reel for you. "Show me everyone's face at least once, prefer smiling faces. If there's a gap of >4 seconds without dialogue, cut it down to 4 seconds."
I've used a few different static site generators over the years.
Jekyll - Probably the most widely used, so whatever you're trying to do, there's a good chance it's documented somewhere online. It's Ruby-based, but I used it for years even though I can't read Ruby at all, and it was rarely an issue.
Hugo - This is what I currently use to generate my blog because it's incredibly fast. There's a bit of a learning curve, but you probably wouldn't have to learn a ton about Hugo to make a simple site that lists video clips.
Gridsome - This is a good solution if you already know Vue, because it's all Vue-based. Documentation is a bit spotty because it's kind of a niche tool, and development slowed down a lot in 2020.
Gatsby - I briefly used it, but I found it very confusing as someone not familiar with React. Friends who like React seem to love it though.
I unfortunately don't know of any templates for this type of project, though. Next time I get really frustrated with MediaGoblin, I might publish one. : )
I don't know if the author uses an iPhone, but I have personally enjoyed scanning old photo/video and then uploading it into my iCloud Photos account.
If you edit the metadata the media shows up correctly in-place early on your chronological timeline. You can tag the location, and easily share.
This has been the key to my photos archiving enjoyment. Get old digital camera pics off of old hard drives and servers and into the same private memories timeline that your smartphone uses.
And right there folks, is why spreadsheets will never die.
A 78RPM record sounds orders of magnitude better than it did on the equipment that existed when the record was first released. Heck, even amplification means that a silent movie with a keyboardist or orchestra will sound better for everybody in the theater, not to mention saving the vocal cords of the intertitle card narrator (if applicable).
Conversion equipment is always improving as well. The Super-8 movies I had digitized 20 years ago should be reconverted again because they were ripped at 640x480, which was the style at the time. I'm not sure of the world of upsampling algorithms, but I bet those are improving as well.
Digitized media will never look or sound better than they do now, and that's on consumer equipment. Ripping VHS with current hardware would undoubtedly result in a better image than 10 years ago.
Backing them up and preservation, on the other hand, is much easier with digital media.
Oh? [1] has been working great for the past 5-6 years.
They still have a line of capture devices, but I have no current experience with them. Just throwing the name out there as an option to research in addition to some of the ones mentioned in other comments.
I used to (2000 through about 2015 or so) do a lot of different captures, through not off of VHS. I have considered a BlackMagic setup for some VHS that is simply not available digitally ...
Tearing at the top and bottom of the image is unavoidable. You just have to crop the top & bottom of the video. If you look carefully at the author's example video, you can see that the professional video was zoomed in slightly, indicating that it was cropped.
Just make sure its not Legacybox https://www.youtube.com/watch?v=SSj3RbdhjzA
No, no, no! Never throw away the originals! You've had them in a box for this long, just keep them.
They:
* Had a security flaw that made everyone's private videos trivially discoverable and left it open for six months after I notified them.
* Failed to remove my files from cloud storage after I asked them to (especially troubling, given the flaw above).
* Put my videos on a hard drive even though I asked them not to, and then tried to charge me for it.
* Tried to charge me a different rate than initially quoted.
* Send me marketing emails with no unsubscribe link (in violation of CAN-SPAM).
* Robocall me with promotions a year later.
I also get a massive headache just from using Audacity.
The issue for me was my video and audio were using separate clock sources on the capture end. This meant the streams started recording at different times AND drifted apart over time.
Using a V4L2 capture device I finally managed to get something workable in ffmpeg by using the -ts flag with option 'asb' for both audio and video sources.
Does anyone have a TL;DR or a link to a good way to understand this and how its fixed?
This was a fun read, partly because I'm one such domain specialist and have answered questions on HN before about the weirdness of video encoding and all the things that can go wrong with it (which I also had to learn the hard way over a long period).
As a general rule, when you're trying to grasp or automate something that's a little out of the mainstream, 90%+ of all the pain points are already well understood and even documented by other people - but you have to really go looking for that information. Reinventing the wheel takes 10 times longer than looking it up, and looking it up takes 10 times longer than asking people.
The trick is to not ask people how the wheel works, which will require a great deal of time on their part in educating you on the fundamentals, so they'll often give you the brush-off or an abridged answer that it unhelpfully above or below your comprehension level. Instead, ask what they consider to be best reference material. You'll get a variety of answers; usually the more accessible material is a bridge to the harder material.
Where video synchronization is concerned, the standards were set by the Society of Motion Picture and Television Engineers; sync problems originate in a tweak to analog video frame rates (from 30 to 29.97) dating back to the introduction of color TV, which require slightly more bandwidth than was already available for monochrome TV transmission.
But the SMPTE documentation was written for people building equipment from scratch, and in a pre-digital era. The best documentation on recording and converting audio at different frame rates (for people who didn't wish to build their own equipment) was in an idiosyncratic spiral-bound manual available from only one store in Hollywood, and a text document from the website for Avid's Pro Tools audio engineering software respectively.
For quite a few years most pro audio/video editing software could not handle such conversions properly because the programmers didn't understand the use cases, and for commercial and legal reasons were reluctant to study their competitor's materials. trying to explain the analog antecedents of the quirky frame rate standards to people whose only experience with video was digital was an absolute nightmare.
(Avid + Pro Tools were the first movers in this space, and developed hardware and software for video editing for the Star Wars movies. But as so often happens, their solution was horrendously expensive and professionals were locked into their platform, which lead to user interface ossification. As other vendors tried to enter the space, they were limited for years to 'semi pro' status because they couldn't handle complex use cases, even if they were better than A/PT in other respects.)
In the 2000s I was a beta tester for Adobe and it took a full year of extended and repeated explanation to communicate the fact that editors were often handed material with the wrong frame rates because there were 10 or more places in the production cycle where an incorrect decision could throw everything off, and that that could happen every day of a many-day production cycle due to unforeseeable changes in personnel or location or equipment or service vendor.
The vagaries of industrial production were very different from the idealized dependencies of software production, and it was hard to convince developers wrestling with already-arbitrary-seeming domain standards that it was not just a matter of 'fixing the inputs' without access to a time machine or unlimited cash.
People who do a lot of reverse engineering seem to grasp this sort of problem much faster, but for obvious reasons there are very few of them on corporate development teams.