support post-record processes

[dericed]

There are several issues that could be considered as events that would conditionally happen after a recording is complete:

• https://github.com/amiaopensource/vrecord/issues/592 would require a binary edit to resulting v210/mov files which could be done with mediaconch and sfk.

• https://github.com/amiaopensource/vrecord/issues/482 would need a post-process to analyze if the data received was dv or m2ts and rename the output file accordingly

• a post process could run sccyou and enable subtitles

• and I've heard requests for an mp4 derivative to be made following capture as well.

There's currently a couple after-processes happening now like the qctools report and that graphical image that shows up if you have gnuplot, but let's discuss what after-processes should look like in vrecord.

[bturkus]

This is all sounds really good to me. Other post-processes that I've been thinking of:

• Trimming heads/tails, which maybe could occur before some of these other things? Audiorecorder has a similar function, but could video pose a unique problem?
• Digital proc amp. I can envision some objections to this, but I got a few uses cases: (1) you're working with a set up that has a functional but not awesome TBC, something like the AVT-8710. The AVT provides stability but iirc the proc amp adjustments are either limited or really extreme, like you push a button and the signal jumps 10 dB; (2) you've set your levels using a better TBC, but you didn't preview the entirety of the tape and you'd like to do some fine tuning after the transfer; (3) you're transferring a particularly problematic, maybe one-pass tape that doesn't really lend itself to extended previewing/level setting.

Thanks for considering and for getting this conversation going!

[privatezero]

Just my thoughts, and maybe it's because I spend too much time over in Linux land, but I am a big fan of the Do one thing and do it well mantra for software! (With vrecord's purpose being signal capture as opposed to editing/derivatives/etc).

While these are all functions that would definitely be useful, I feel like some of them like derivatives and file manipulation might be better suited (and more easily maintainable) in a separate tool than the main vrecord script - perhaps one that could still live in the repo and be installed via the same homebrew tap? Then maybe it could have a stand alone GUI and also be set up for automated calls by vrecord? vrecord and vpost?

Lol I know that I am hypocritically saying this now even though I am the one who added trim to audiorecorder :-P

[retokromer]

Just my thoughts, and maybe it's because I spend too much time over in Linux land, but I am a big fan of the Do one thing and do it well mantra for software! (With vrecord's purpose being signal capture as opposed to editing/derivatives/etc).

This is my position as well (possibly for the same reasons ;-)

[XFRCollective]

Was about to drop in our wish list, but @privatezero's thoughts are well-taken. We are always hurting for a user-friendly FOSS program to edit ffv1/mkv and make use of all the great .mkv features, such as setting presentation ins/outs and attaching things, in addition to color grading, trimming, transcoding etc. (+1 digital proc am adjustments).

[geskalney]

I would like to request the ability to define the aspect ratio. I have a lot of DV tapes that were recorded in 16:9. Many of these tapes were recorded on Panasonic AG-DV1000 decks. vrecord doesn't seem to support or recognize the aspect ratio (it transfers the video perfectly, just with the 4:3 pixel aspect ratio).