VHS capturing without VirtualDub under Linux

[lordsmurf]

HYMT is HuffyuvMT, which is not suggested anymore. Use Huffyuv original.

I've never found FFV1 (ffmpeg lossless) to be impressive -- nor have others, apparently, given it's low adoption in the VHS/analog capture world. Doesn't it still required ffdshow? Meaning not really a "codec", but more as part of a quasi codec pack, and ffdshow can screw up capture systems. Most codecs are non-proprietary.

Huffyuv is just the safe choice for capture.
Lagarith is a 2nd, but dropped frames loss needs to be monitored, as the codec has higher resource use.
On Mac, you're mostly in ProRes422 or DV world, not much choice in lossless.

[pulga]

@ pulga
What do you mean by “not compatible” ?

That if I encode with one version of HuffYUV I can not necessarily play that with another version. E.g. VLC supports HuffYUV 2.1.1 but not huffyuvmt, it comes with its own codecs though.

Use Huffyuv original.

I will do that, thank you. I've already done some capturing, can I convert the files? It's not much, I can redo that too.

I'd capture to Huffyuv or Lagarith and then do a final FFV1 lossless conversion.

Nice, many thanks! So you convert to FFV1, then do cutting and then filtering and encoding to x264?


Maybe someone could refer to the first three questions as well, that would be very helpful

[poisondeathray]

Maybe someone could refer to the first three questions as well, that would be very helpful

1) If it's family VHS videos - you should probably encode interlaced (MBAFF for x264)

2) 4:2:0 should be ok, but it depends on the other programs you are using - specifically how they handle interlaced 4:2:0 chroma. You can get chroma errors if it's not handled properly. 4:2:2 is "safer" in that regard, but requires more bandwidth (larger filesizes) . In terms of quality, 720x576 4:2:0 is going to exceed PAL VHS chroma anyways, so you're not limited in that regard.

3) Depends if you are using other programs , mainly a compatibility issue . For example , many commercial NLE's don't support FLAC . FLAC of course will reduce the filesize of the capture since it offers lossless compression

The commands depend what you device is sending in terms of sampling rate and bit depth for the audio

[pulga]

Oh sorry, I was referring to the questions of post #27. It's very confusing, I know

I have another question to lordsmurf though: I can select HuffYUV now in VirtualDub2 64bit only, how "bad" is it using this version for capturing? I was using 1.9.11 before, the plugin-pack you uploaded here. I installed the 32- and 64-bit version of HuffYUV.
Edit: It shows up under 1.9.11 64-bit too, so that's an option as well.

[lordsmurf]

Don't use VirtualDub2 64-bit for capture. In fact, don't use VirtualDub2 for capture at all. It's based on 1.10.x, which has weird random buggy issues in capture mode. 1.9.x is safer, no problems for users for many years pre-1.10.x. The main updates to VirtualDub (and the Mod/2 fork) was in the editor mode, export/import/filters.

[pulga]

So 1.9.11 64-bit is ok?

[abolibibelot]

So you convert to FFV1, then do cutting and then filtering and encoding to x264?

There's little point in doing that. FFV1 has been said to be too slow to be practical for editing (see quote on page 1), so editing / filtering / encoding should rather be done directly from the captured HuffYUV files. Converting to FFV1 would only be to keep an archival lossless version with a better compression ratio. If later on you have to do some further editing / filtering, you may have to convert that FFV1 version (while keeping it as the “master”) to another lossless codec which is less demanding on the system – at that point Lagarith could be a good option (if it doesn't misbehave with the editor you are using), or UT Video (recommended in said quote for its “fastest scrubbing”). And convert back the audio to PCM / WAV (as indeed most editors don't support FLAC). As for lossless audio codecs, APE has a significantly higher compression ratio than FLAC ; I'm not sure but I guess that is can be put in a MKV container just as well (pretty much anything can be put in MKV) ; but the size saving would be quite small compared with the potential size saving between HuffYUV to a more efficient lossless video codec.

(As a side note, I have found out that decompressing an APE file to a WAV file generates a WAV file which is strictly identical to the one originally compressed, whereas compressing a WAV file to FLAC and then decompressing it to WAV results in a slightly different file, the audio content is the same obviously but the header / metadata is not quite identical. As for lossless video codecs, it would seem that compression / decompression never results in a strictly identical file.)

[lordsmurf]

Huffyuv vs. FFV1 vs other lossless is really the same as zip vs. rar vs. 7z, etc.
Size wise, not very different. Few % here and there.
The real key is in resource use to get the compression, and how easy it will be later to uncompress it.

So again ... Huffyuv, using VirtualDub 1.9.x (and preferably WinXP/7, not Vista/8/10/Mac/Linux)

VHS has a formula for hardware/software. Use it. KISS.

[pulga]

Alright, thank you, I'm using VirtualDub 1.9.11 64-bit and FFV1 only for archiving.

Regarding the capturing device: I just read here, that the Hauppage USB Live 2 has a mpeg hardware encoder - does that mean it's not possible to capture lossless as well?

[jagabo]

I'm pretty sure the Hauppauge USB Live 2 does not have a hardware MPEG 2 encoder. It captures uncompressed YUV 4:2:2 video and the included software converts to MPEG2 on the fly. Using other capture software gives you access to the uncompressed data.

[KarMa]

Regarding the capturing device: I just read here, that the Hauppage USB Live 2 has a mpeg hardware encoder - does that mean it's not possible to capture lossless as well?

https://forum.videohelp.com/threads/371138-Video-Audio-sync-problems-with-Hauppauge-US...ub#post2383607

[pulga]

I bought the Hauppauge USB Live 2 second-hand, I can pick DirectShow now in VirtualDub. However, there is a new option "Capture filters" where I can set the Videostandard under "Videodecoder", what should I choose here? Since I'm from Austria I guess it's either PAL b, g, d or k, but how do I find that out?

[Brad]

Since I'm from Austria I guess it's either PAL b, g, d or k, but how do I find that out?

Pick whichever letter is your favourite; there is no difference for Composite or S-Video capture.

http://ericdevos.be/kask/2BA/2BA%20videoformaten/Pal%20Secam%20NTSC%20World%20Standard...%20Convert.htm

What are the PAL-B, G, H, I & D Variations all about ?


Here's another question we're constantly asked..


Pal-B, G, H, I and D as far as the actual video is concerned, are all the same format. That is: they are all PAL. There is no difference. All use the 625/50 line/field rate..... scan at 15,625 h-lines/sec and use a 4.433618 color subcarrier frequency. The only difference is in how the signal is modulated for broadcast. Thus the B, G, H, I & D designate broadcast variations as opposed to any variation of the video format. PAL-I for example, has been allocated a wider bandwidth than PAL-B, necessitating that the sound carrier is placed 6Mhz above the picture instead of 5.5 MHz above the picture carrier. Thus a PAL-I TV (the United Kingdom for example) will get no sound if taken to the Netherlands for example (PAL-B) if all the TV's tuner is able to decode is PAL-I. (Fortunately, most European tuners support most of the broadcast variations ).
This is why for example, you won't find a standards converter that will convert a video from PAL-B to PAL-I. There's simply nothing to convert.....They are already the same PAL format. There are major differences between PAL-M and PAL-N however, that would require conversion, as the line/field rate and color subcarrier frequencies are different from standard PAL.

[richardpl]

FFv1 in these days of modern CPUs and SSD days is pretty fast, do not listen to people claiming otherwise, they do not know much out of their circle jerk.

[abolibibelot]

FFv1 in these days of modern CPUs and SSD days is pretty fast, do not listen to people claiming otherwise, they do not know much out of their circle jerk.

With all due respect, I only do square jerk, with the Father, the Son and the Holy Spirit. Watching a horny movie with Russel Crowe.

As for the main subject, a fast SSD won't help whatsoever in this particular case : since this codec is supposedly optimized to produce smaller files, the performance of the storage device is actually less of a bottleneck than with less efficient codecs (or uncompressed video, which represents the highest possible data throughput). I have no first hand experience on that matter, but “pretty fast” is not nearly enough when it comes to analog-to-digital capturing, it has to be fast enough to allow for a flawless real-time capture. Depending on the actual hardware used (not everyone has a high-end 8+ threads CPU with 16+ GB of RAM), it may or may not cut it with FFV1. If you want to add something useful to the conversation, do provide reliable measurements, instead of unnecessarily rude offhand blanket statements.

Have a nice Sunday.