[Cin] Fwd: [oyvindln/vhs-decode] Readme.md need more editing? (Issue #73)
randrianasulu at gmail.com
Fri Feb 10 05:22:39 CET 2023
---------- Forwarded message ---------
От: Harry Munday <notifications at github.com>
Date: пт, 10 февр. 2023 г., 06:58
Subject: Re: [oyvindln/vhs-decode] Readme.md need more editing? (Issue #73)
To: oyvindln/vhs-decode <vhs-decode at noreply.github.com>
Cc: Andrew Randrianasulu <randrianasulu at gmail.com>, Mention <
mention at noreply.github.com>
For analogue tapes, FM RF capture and software decoding is the best way to
go for correction and preservation.
For CVBS sources you can use CVBS-Decode
it's not going to give anywhere near the results of VHS-Decode this is only
ideal for live sources like cameras or digital formats, or analogue ones
that have already been through a hardware TBC of some forum (so the whole
point of the powerful software TBC in vhs-decode is lost)
FFV1 is *not supported by Avid Pro Tools/DaVinchi Resolve/Adobe Suite/Final
Cut* hence why it's pretty much disregarded for editing and re-muxing to
V210/ProRes HQ (and setting the CLAP/Colr Atom data in amcdx-video-patcher
properly after the fact) it meant more so for tossing into StaxRip etc and
using a deinterlacer like QTGMC on then tossing into an NLE directly.
The issue is also the output from the gen_chroma_vid.sh script is not
flagged for interlacing properly this is a limit of FFmpeg but re-muxing
fixes this issue.
(It is supported in Lossless Cut but at potato render quality.)
The wiki is pretty extensive but post-processing docs are being worked on.
Reply to this email directly, view it on GitHub
You are receiving this because you were mentioned.Message ID:
<oyvindln/vhs-decode/issues/73/1425140053 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cin