linux capturing apps for Hauppauge USB-Live2

[chconnor]

Howdy -- I'm going S-Video into a Hauppauge USB-Live2. I have the Hauppauge Capture app installed in windows and it works well enough, but it would be much more convenient for me to use linux for this instead.

In linux I can see the Live2 stream just fine in OBS as a V4L2 device, but there are some technicalities I'm not clear on, hence these questions:

- if I capture with OBS, being careful to set output resolution to 720x480 (NTSC) and frame rate to 30/1001, will I get a 1:1 capture of the bare frames the Live2 is sending, or does OBS sort of resample things temporally, or otherwise transcode along the way, since it's built to be a switching/streaming app, and not a naked capture app? I've never been clear on how/if OBS "syncs" its recorded frames with the video sources it draws from, or if it messes with them in other ways.

- are there better linux apps than OBS to use for this purpose in 2024? I like OBS well enough but it's kind of a pain for simple capturing. (I'm comfortable with the command line as well, so I'd be happy spinning up an ffmpeg command if that would be straightforward and smart.)

- is there anything I would be sacrificing by going the linux route vs. the Capture app? (I don't need access to the proc amp settings in the Live2, as I believe those are just digital-realm post-capture tweaks.)

I'll be doing all my deinterlacing and cleanup after capture, so I don't want any scaling or the like: the main goal is just clean/raw captured frames from the Live2 without messing with them or dropping any, etc.

Thanks!

[ricardouk]

I cant help with you with the tech side of the question but i think obs always converts when capturing, not sure though... before using obs which i find very easy to use i used vlc.

[chconnor]

Thanks -- I figured that might be the case.

VLC for some reason is not working well with this device -- can't even get the stream up on screen. mpv worked a lot better and seems like an option. I can capture successfully with ffmpeg but I'm unclear as to whether the stream is being transcoded... more exploration needed...

[Alwyn]

post-capture tweaks.

The Live2 (or any of the other USB digitisers) procamp is certainly not "post capture". It is "post player or TBC" but not post capture. It may need to be used to legalise the brightness and/or contrast before the file is saved/captured by the capture program. I'd therefore be careful thinking "I don't need access to it" unless of course you have a proc amp in the chain before it.

Re using OBS, it does a reasonable job capturing direct to MP4, but not good at AVI ie interlaced lossless. I did some test captures, covered in this topic. So, if you want lossless, interlaced AVIs, don't use OBS.

[chconnor]

Appreciate the response, Alwyn -- so you're saying that the proc amp tweaks the Live2 performs are done in the analog domain before the signal is digitized? (I think that's what you said but just trying to be super clear.)

Also I think I'm learning that the proc amp controls might actually be available on linux via v4l2-ctl and the like, though I'm still exploring/testing that.

Thanks for the tip on OBS, I'll check that link out.

[Alwyn]

so you're saying that the proc amp tweaks the Live2 performs are done in the analog domain before the signal is digitized?

I think so! For example, a tape might play too bright or dark (washed-out whites or too-dark black areas). On a histogram (I use Virtual Dubs) you can adjust the levels with the proc amp controls in the Live2's device settings to bring the levels back to within the legal range. If you capture too-bright, you may not be able to get back the blown-out areas in post-capture.

I've written a bit of a speil about adjusting the levels here. It's for Virtual Dub+Windows, but I imagine the concepts still apply to your Linux captures. Even without the histogram, it's fairly easy to eyeball the levels: if you have areas of total white where you can't see any details, then the levels (especially the contrast) is probably too high. If you don't adjust them before capture, you may never be able to fix the over-bright areas.

[chconnor]

Great, thanks; I'm pretty familiar with the levels issue (especially in the context of photography) so I think I get it.

Before this post I did email Hauppauge support asking about the location of the proc amp in the chain; if they respond I'll post here with their answer.

[Sharc]

Great, thanks; I'm pretty familiar with the levels issue (especially in the context of photography) so I think I get it.

Before this post I did email Hauppauge support asking about the location of the proc amp in the chain; if they respond I'll post here with their answer.

Clarification would be interesting as the block diagrams and datasheets of the Conexant CX23102 chip are very vague as to what the 'analog front-end' really does in addition to performing basic AGC and anti-alias filtering, and how it is controlled via the (bi-directional) USB interface.
The TW9910 chip as used in the I-O Data GV USB2 is more specific. One could conclude that all these 'proc-amp' adjustments are done in the digital realm in the 'luma-chroma processor' block. Also, the description of the registers refers to Y, Cb, Cr adjustments which means the tweaks are done in the digital realm.....

[lollo]

To my understanding the "adjustements" are done in the "digital" domain (it can't be otherwise looking to the specifications). However, they are effective, because avoid crushing the blacks and clipping the whites, so the digital conversion of the incoming analog signal is tuned to stay inside the wished range through the internal "procamp". An esternal procamp is different.

Concerning the USB-Live 2 there are no concerns about the whites in the range 235-255, because that card is able to capture 16-254. The zone to consider is the range 0-16, where a not approprite capture can crush the (lower) blacks.

[Sharc]

To my understanding the "adjustements" are done in the "digital" domain (it can't be otherwise looking to the specifications). However, they are effective, because avoid crushing the blacks and clipping the whites, so the digital conversion of the incoming analog signal is tuned to stay inside the wished range through the internal "procamp". An esternal procamp is different.

Yes, they are effective as long as the input ADC is not overloaded and/or the incoming signal has not already been clipped/crushed by the preceeding device (camera, VCR/player, passthroug device etc.)

[lollo]

Yes, absolutely correct!

[chconnor]

Thanks, all -- so it sounds like we are saying that the proc amp settings don't affect the ADC (meaning, they are not controlling anything on the analog front end of the conexant chip), but that they are useful anyway, e.g. to prevent clipping that could show up in the output that I capture. Meaning, there is some intermediate digital stage internal to the Live2 (e.g. maybe color space conversion) which can clip if the proc amp settings are wrong?

It's obvious to me that if the proc amp settings are "wrong" (meaning too high, too low, etc.) you could crush levels at the top or bottom; what was less obvious is that if the proc amp settings are "neutral" or off that you may still lose information at the top or bottom through some internal processing of the Live2.

Said another way: "if I am a high-level expert at color and levels correction in the digital domain (say with Davinci Resolve or other digital tools), and my intention is to get a "totally raw" capture from the Live2 to process myself, there is still potential harm in leaving the proc amp settings at their neutral/default positions."

[lollo]

Said another way: "if I am a high-level expert at color and levels correction in the digital domain (say with Davinci Resolve or other digital tools), and my intention is to get a "totally raw" capture from the Live2 to process myself, there is still potential harm in leaving the proc amp settings at their neutral/default positions."

Yes, you can crush the blacks below 16 (if present in the source). When this happens at capture stage, no later post-processing can recover.

[chconnor]

Ok, thanks, that's interesting.

It's weird that there isn't a way to just get the raw output of the ADC from the card (before whatever stage is potentially crushing the blacks according to the proc amp settings), but I know there are a million subtle technicalities in how NTSC is represented digitally, so I will avoid judgement.

[lollo]

Here you can find a test performed by Bogilein about the ranges that various cards can capture, where many are limited to Y=16, which is the lowest "legal" level in YUV (legal is not the proper word, altough widely used) https://www.digitalfaq.com/forum/video-capture/9865-canopus-advc-110-a.html#post62640

[chconnor]

Edit: a bug (potentially) in ffmpeg meant audio was not capturing well... Also the -r wasn't necessary when the command was used differently; I will strike out the ffmpeg command below and replace with a working version. For info on the potential bug: https://trac.ffmpeg.org/ticket/11314 -- non-monotonic errors seem to plague no matter what (though they are harmless, maybe?). Capturing to mkv seems to alleviate them (and obviates the need for -c:a being anything but copy, which is needed with .avi due to the potential bug.)

To the original question of the post, an update in case anyone is curious:

My current process is to open OBS, which I use to preview the image coming in, set the various procamp settings, make sure it's in NTSC mode, etc. Then I quit obs, but the settings remain set in the Live2.

Then I do the raw capture with ffmpeg:

ffmpeg -f v4l2 -i /dev/video2 -c:a copy -c:v copy -r 30/1.001 out.avi

ffmpeg -f alsa -ac 2 -i hw:CARD=Cx231xxAudio,DEV=0 -f v4l2 -i /dev/video2 -c:a pcm_s16le -c:v rawvideo out.avi

...then I boot into windows and use QTGMC in virtualdub2 to uncompressed RGB24 .avi, which I can open in resolve.

Only wrinkle is that if I start capturing before pressing play on the VCR, ffmpeg throws lots of timestamp errors:

[vost#0:0/copy @ 0x5c7b44e19740] Non-monotonic DTS; previous: 154, current: 154; changing to 155. This may result in incorrect timestamps in the output file.
[vost#0:0/copy @ 0x5c7b44e19740] Non-monotonic DTS; previous: 157, current: 157; changing to 158. This may result in incorrect timestamps in the output file.
[vost#0:0/copy @ 0x5c7b44e19740] Non-monotonic DTS; previous: 206, current: 206; changing to 207. This may result in incorrect timestamps in the output file.

Working on that next...