The old "war of opinion" - Capture 8mm tapes in DV or lossless?

[lollo]

Many capture guys swear on huffyuv 2.1.1 CCESP2 patch version for some reason.

As capture guy, I swear only on original huffyuv 2.1.1; no MT patch, no CCE patch.

[Marvolo]

Better/worse in what way ?
In short, it depends on how you're going to be using it. Beware of mishandling issues with NLE's as discussed above

I would prefer the highest compression with the highest compatibility at the same time and an interlace flag would be nice as well. Is there a codec that more or less meets the two? I am aware there might not be one that has the best compression AND the best compatibility at the same time.

From what I can see in your description, the ones that remain would be HuffYuv, Lagarith, UT video or magicyuv.

[poisondeathray]

Compatibility with what scenario or programs ? How is it going to be used ? "quirks" can be an issue in some programs. Open source programs tend to be the most compatible

Another criteria is data integrity . FFV1 (in I-frame configuration) is the codec of choice for archival purposes, because of it's slice CRC option. Recommended by U.S. Library of Congress

[Marvolo]

Yes, the main purpose would be archival purposes. My chain of thought was: capture as is, no editing, restoration etc. = Master/Archival Files. Then derive intermediates from these master files for editing, restoration and export into viewable files (MP4 or DVD).

So the first process would be to have a codec suitable for archival (and maybe editing/restauration. That way I wouldn't have to create intermediates just for the purpose of editing).

So compatibility with editing software, but other than that it should be used as an archive / master files that depict the 1:1 (raw) state of the tape it came from.

[poisondeathray]

But what are you using to edit ? If it's a NLE like vegas, premiere - that means none of those YUV lossless codecs are lossless, they all clip. It wouldn't be editing the "lossless" master file directly in a pro NLE . You would have to convert the master to something else to edit


Another potential issue is your "lossless" captures were TFF . A file can be flagged "interlaced" but have the field order incorrect or not specified . You can just manually interpret the file in the other program (most people do), but it sort of defeats the purpose of having the flag

DV "just works", it's very standardized as mentioned by the others above. Interlace and BFF flag. Almost no confusion or "gotchas", almost foolproof .

[Marvolo]

But what are you using to edit ?

At the moment I'm using the Magix software. I have worked with Adobe Premiere in the past but since they upgraded it to the Cloud-based version, I have distanced myself from it. I don't want to "rent" a program on a monthly basis. Either I own it or I don't. No idea if Magix can handle those lossless formats without clipping...

Would you know of a NLE that can?

Another potential issue is your "lossless" captures were TFF . A file can be flagged "interlaced" but have the field order incorrect or not specified . You can just manually interpret the file in the other program (most people do), but it sort of defeats the purpose of having the flag

OK. I agree. I never set the field order specifically. Seems like the Blackmagic capture software recorded it that way. Is TFF not correct?

[poisondeathray]

At the moment I'm using the Magix software.

It clips too, same with Avid MC, Edius . Basically all Windows NLE's will clip "lossless" YUV codecs such as huffyuv, lagarith, ut vidoe etc...

Would you know of a NLE that can?

No good options

None of the "Pro" ones . Resolve Studio (not free version) and PP could import FFV1 at one point , but there are still various issues . They could also import x264 lossless, but only in 4:2:0 configuration - still various issues

Open source ones - Shotcut, Kdenlive - the GUI's are not as nice, not as complete IMO, but they don't clip. Shotcut had an issue with interlace handling but it was fixed in the lastest release

Another potential issue is your "lossless" captures were TFF . A file can be flagged "interlaced" but have the field order incorrect or not specified . You can just manually interpret the file in the other program (most people do), but it sort of defeats the purpose of having the flag

OK. I agree. I never set the field order specifically. Seems like the Blackmagic capture software recorded it that way. Is TFF not correct?

It's not "wrong" to have TFF, it just captures the fields/scanlines as the come. But Interlaced SD is usually BFF by convention. Interlaced HD is usually TFF by convention. SD is more varied, it comes as both . But HD is 99.99999% TFF

FFV1 can flag aspect ratio , interlace, field order as well, but only in the ffmpeg version. Not all programs can read the flags, but at least something like mediainfo will see them correctly. Some of the other lossless compression options either do not flag AR, or interlace, or field order , only 1 of them

[Marvolo]

What do professional TV stations or film production houses use if they have to deal with digitized analog video? Which software do they use that can handle those lossless formats correctly without clipping?

Is this issue not known to those NLE manufacturers and don't / didn't they plan to fix it?

[poisondeathray]

Actually magicyuv has a "full range" option that didn't clip in vegas . I posted about this a few years ago , Let me test it again and get back to you . I think it was still lossy in other ways, but at least it did not clip

What do professional TV stations or film production houses use if they have to deal with digitized analog video? Which software do they use that can handle those lossless formats correctly without clipping?

TV stations generally don't use lossless codecs , most use prores, though some will use DNxHD/DNxHR (avid based studios)

A film production studio that deals with restoration will uncompressed, unless it's low budget/quick transfer - then it's prores too . v210 is the standard capture format for pro studios (uncompressed 10bit 422)

Is this issue not known to those NLE manufacturers and don't / didn't they plan to fix it?

Lossless codecs are a niche thing . And it's more of a codec issue - if the codec author(s) enabled UYVY output for 8bit422 (instead of YUY2), v210 for 10bit422 - they would be lossless too

[Bogilein]

@poisondeathray

It clips too, same with Avid MC, Edius . Basically all Windows NLE's will clip "lossless" YUV codecs such as huffyuv, lagarith, ut vidoe etc...

Interesting discussion. As an Edius 5,6,8 & Lagarith user can you give me an example of how to check if and how the Lagarith files are clipped?

[Sharc]

What do professional TV stations or film production houses use if they have to deal with digitized analog video? Which software do they use that can handle those lossless formats correctly without clipping?

Is this issue not known to those NLE manufacturers and don't / didn't they plan to fix it?

It is not only an issue with NLEs and PC vs TV range. Clipping should be avoided during capturing to begin with. Once the signal is clipped there is no way to recover it.

[Sharc]

@poisondeathray

It clips too, same with Avid MC, Edius . Basically all Windows NLE's will clip "lossless" YUV codecs such as huffyuv, lagarith, ut vidoe etc...

Interesting discussion. As an Edius 5,6,8 & Lagarith user can you give me an example of how to check if and how the Lagarith files are clipped?

Different methods, from basic to more sophisticated, e.g.
- Play the video file on the PC (player set for TV range). Take a color picker and check some bright and dark spots in the picture. If the color picker returns (255,255,255) or (0,0,0) for RGB, it is an indication that the RGB got clipped.
- Use the Avisynth histogram in 'classic' and 'levels' mode. If Y (the luma) reaches out to <16 or >235 it is an indication that there will be clipping when converting to RGB.
- Load the .avi in Shotcut and inspect the RGB Parade (and the Video waveform) in its Color Layout. The RGB Histogram and RGB Parade will immediately show clipped components.
- Using Avisynth, convert the .avi to RGB and back to YUV and compare this with the original picture (e.g. by subtracting). A visible difference indicates clipping and out-of-gamut RGB.

It is noted that when the luma reaches out to <16 and >235 in Avisynth's histogram without clipping at Y=0 or Y=255, the capture is ok and can be processed in post to ensure valid RGB. Shrinking the histogram (reducing the range of the luma) is however not lossless, producing spikes in the histogram. Details otherwise lost will be recovered though.

[poisondeathray]

magicyuv -

The full range preserves the range in vegas when using studio RGB. But there are other rounding losses from integer RGB conversion . If you work in float, the vegas downconversion dithers, and that adds loss . Even if you could somehow disable dithering , there is evidence of chroma up/downsampling losses . You would need to use nearest neighbor for chroma/up downsampling for that to be lossless .

In PP, there is RGB conversion too , thus clipping. If you use magicyuv full range option, the levels/slope are changed, since PP works in full range RGB only (not limited range RGB or Studio RGB), so not lossless

[poisondeathray]

@poisondeathray

It clips too, same with Avid MC, Edius . Basically all Windows NLE's will clip "lossless" YUV codecs such as huffyuv, lagarith, ut vidoe etc...

Interesting discussion. As an Edius 5,6,8 & Lagarith user can you give me an example of how to check if and how the Lagarith files are clipped?

Sharc pointed out some methods above




To test clipping for 8bit material use a test video that has Y values <16 , >235 .

I use a perfect ramp Y 0-255, because it's easy to identify problems on a waveform. The slope is 1. For 8bit it's 256x256 dimensions. Each x-coordinate corresponds to the Y-value. You can use a color picker in avspmod , for example, it reports the native Y,U,V values, and the converted RGB values (or vice versa if loading RGB)

When viewing the ramp (converting YUV to RGB for display), use a full range matrix , other wise you won't "see" the missing data in the preview. So the preview image is RGB converted correctly (full range), but the waveform corresponds to the actual Y' values. I do these manipulations/analysis in avisynth because you have full control


[Attachment 72072 - Click to enlarge]

Typical clipping would show a hardline


[Attachment 72073 - Click to enlarge]

Clipping can be accompanied by other issues, such as gaps (banding), slope change (contrast), because of wrong interpretation . This is lagarith in vegas. It has undergone a standard ComputerRGB conversion upon importing before you can do anything in the editor. It's irreversible. The slope change is from StudioRGB timeline. The gaps are from 8bit integer (you can't have fractional values)

[Attachment 72077 - Click to enlarge]

You can apply a computer to studio RGB filter, but still clipping

[Attachment 72078 - Click to enlarge]


Always test exporting uncompressed first (most NLE's , "uncompressed" will be UYVY 8bit 422), to see what the NLE "engine" is doing underneath the hood, before you test other export formats. For example, if you test some other export codec, there can be some other filter also auto inserted upon export. This can confuse the analysis because there are multiple things going on at the same time. This is true for vegas for example, when exporting something like huffyuv, ut video etc...

You also have to do other tests, with color - for example up/down subsampling tests, color accuracy.

If psnr is infinity, you can forget doing any tests, it's lossless. If you suspect something to be lossless, you can skip everything and jump right to PSNR. Not infinity, not lossless - then you have to figure out why



You can also use other tools like avisynth, avspmod to compare, waveforms, etc... psnr to test losslessness . ffmpeg has a nice psnr waveform filter too. Waveform is nice because it's easy to see patterns, disontinunities, gliches, clipping right away (straight horizontal line on a waveform)

avspmod is very nice, because you can compare in different tabs and hotswap with number keys. Timeline is aligned if dimensions and frame count is the same. Its like imgsli, or a NLE togglilng track visibibilty, but 10x better, 10x faster because of the hotkeys - you don't need to take screenshots, or upload,You can compare filter chains in different tabs, navigate to different frame, and all versions are aligned. You have all the avisynth manipulation tools, color picker (read pixel values, coordiantes), scopes.

[johnmeyer]

I would prefer the highest compression with the highest compatibility at the same time and an interlace flag would be nice as well. Is there a codec that more or less meets the two? I am aware there might not be one that has the best compression AND the best compatibility at the same time.

Bwaak mentioned earlier that he captures using Cineform. I've already mentioned why I think this is a great choice for editing, and it perfectly meets the two requirements you just stated. If you can capture using that and keep everything in that format until you're ready to put the video into a delivery format, I think you'll be very happy.

BTW, I screwed up thinking you wanted uncompressed. I had been having a conversation with someone in another forum who said storage space didn't matter and he felt that uncompressed was he only way to go. So, my fault for getting that wrong.

[DB83]

^^ From the begining, I do not think the OP wanted uncompressed either. He just ended up with it due to his capture setup.

And unless he has also messed up his vdub/vdub2 capture setup he is stuck with that unless he concedes that he should invest in a different setup.


But here's the thing. Without having an opinion since I have done both DV and Lossless (compressed), he stated right from the off that he was happy with his original files which even displayed fine on a 4K display. Now, after some input, he has changed his opinion. 'Faults' are only there if you go looking for them.

[Bwaak]

Bwaak mentioned earlier that he captures using Cineform. I've already mentioned why I think this is a great choice for editing, and it perfectly meets the two requirements you just stated. If you can capture using that and keep everything in that format until you're ready to put the video into a delivery format, I think you'll be very happy.

Cineform was very popular among pros 10-20 years ago and then Apple dropped its support along with DNxHD/DNxHR. This does not mean individual apps stopped supporting it, just that Apple does not support it in Apple's own apps. To add insult to injury, GoPro made it harder to install just the Cineform codec. I can capture to Cineform in VDub2, but to edit it in Vegas I need a standalone codec, so I had to install some GoPro junk that comes packaged with Cineform codec, and I don't know how easy this is on Mac.

So, the common intermediate options are: Avid DNxHD/DNxHR, Cineform, Grass Valley HQ/HQX, and ProRes. It is clear that Apple wants everyone to use ProRes. I am not sure what Microsoft wants.

What is best for long term archival? Clearly, one needs at the very least a tool to read the video file and convert it into uncompressed stream. Better yet, a driver for common OSes. Should I be worried about me using Cineform for archival? If my NLE stops supporting it, I can read such a video in VDub2 and render as something else, but this would be a hassle. So I would prefer having something that can be accepted by major NLEs, cheap and expensive alike, simple and Pro. So far, it seems ProRes has a brighter future

[lollo]

Bwaak mentioned earlier that he captures using Cineform. I've already mentioned why I think this is a great choice for editing, and it perfectly meets the two requirements you just stated. If you can capture using that and keep everything in that format until you're ready to put the video into a delivery format, I think you'll be very happy.

OP likes and wants lossless. By principle. So instead changing codec he may change NLE or switch to AviSynth/VapourSynth if their "editing" functions are sufficient for his purposes. I think he will be happier

[Sharc]

Eventually, I hope, we have been through most facts, opinions and religions

[poisondeathray]

Bwaak mentioned earlier that he captures using Cineform. I've already mentioned why I think this is a great choice for editing, and it perfectly meets the two requirements you just stated. If you can capture using that and keep everything in that format until you're ready to put the video into a delivery format, I think you'll be very happy.

Cineform was very popular among pros 10-20 years ago and then Apple dropped its support along with DNxHD/DNxHR. This does not mean individual apps stopped supporting it, just that Apple does not support it in Apple's own apps. To add insult to injury, GoPro made it harder to install just the Cineform codec. I can capture to Cineform in VDub2, but to edit it in Vegas I need a standalone codec, so I had to install some GoPro junk that comes packaged with Cineform codec, and I don't know how easy this is on Mac.

What is best for long term archival? Clearly, one needs at the very least a tool to read the video file and convert it into uncompressed stream. Better yet, a driver for common OSes. Should I be worried about me using Cineform for archival? If my NLE stops supporting it, I can read such a video in VDub2 and render as something else, but this would be a hassle. So I would prefer having something that can be accepted by major NLEs, cheap and expensive alike, simple and Pro. So far, it seems ProRes has a brighter future

Cineform is open sourced with an SDK. There are command line apps and it's in libavcodec, ffmpeg . No worries about not being able to read it

Cineform is native to Adobe - they implemented the SDK . Both PC/MAC versions are bundled with it

Some issues with the vdub implementation -it's missing things like interlace,AR flagging . It flags as progressive (which is worse than no flag, unless you're dealing with progressive content) . If you encode cfhd through ffmpeg , you can specify AR, field order flags . It also has a fs3+ quality , 1 higher than vdub's fs3 implementation (slightly higher bitrates and quality)



ProRes is INSANELY fast on a Mac with M1/M2 with HW acceleration. UHD feels faster than SD DV editing (!) . (But It's still slower than cineform on a PC)

ProRes used to be "locked" environment, basically Apple only , difficult to use on Wn / Linux . Not the case anymore. For high quality intermediates, it's the best supported for software/hardware /platforms in the industry by FAR . Prores IS the standard mezanine intermediate for production work. If you need a higher quality intermediate, Prores4444XQ is pretty good next level up

The only similar HQ format faster is Daniel2 - also HW accelerated, but Nvidia. But this is basically locked to Adobe environment. It's worse than Apple/Prores used to be in terms of freedom


All the commonly used "visually lossless" intermediates like cineform fs3 , prores HQ - typically get around 50-55dB on typical content. Nothing like DV blocks, just very minor noise . 4444XQ gets around 60-65db. You can get higher with x264 --qp 1 (10bit422 AVC intra is like "AVC-Intra" from Panasonic/Sony - another standardized format - just higher bitrates, also widely supported by pro editors) it gets 80-85dB, but is very sluggish compared to cineform.

[johnmeyer]

All the commonly used "visually lossless" intermediates like cineform fs3 , prores HQ - typically get around 50-55dB on typical content. Nothing like DV blocks, just very minor noise . 4444XQ gets around 60-65db. You can get higher with x264 --qp 1 (10bit422 AVC intra is like "AVC-Intra" from Panasonic/Sony - another standardized format - just higher bitrates, also widely supported by pro editors) it gets 80-85dB, but is very sluggish compared to cineform.

You point out something I forgot to mention: Cineform lets you dial in quality settings, and if you use something like one of their "Filmscan" presets, it is pretty much impossible to find or see differences from the original lossless capture.

[Marvolo]

And unless he has also messed up his vdub/vdub2 capture setup he is stuck with that unless he concedes that he should invest in a different setup.

I haven't yet figured out why VirtualDub won't accept my Blackmagic Intensity Card. I managed to get it to work in OBS studio software, but only after I changed the input signal in the Panasonic from 576i to 1080i. Apparently, 576i was too low for OBS.

I haven't been able to make it work under VirtualDub. So, yes, you're right, as long as I can't get it to run on Vdub, I'm stuck with uncompressed capture via the Blackmagic Media Express software.

Not even my NLE works for capture. It does recognize the Blackmagic Capture card, but just like Vdub the preview window remains pitch black.

[Marvolo]

Also, one thing I noticed yesterday:

Could it be that even my system seems to be strong enough according to CPU & HDD monitoring via TaskManager (where it displays the load in percentages and graphs) I seem to get what I would call "dropped frames" in the uncompressed capture?

By "dropped frames" I mean the following:

I inserted both an uncompressed as well as a DV-2008-capture of a tape into my NLE and just like I always do put both tracks right on top of each other (Track 1 & 2) and lined them up by frame. So if I mute one track, it shows the exact frame of the other track. They're in sync.

If I do this with two DV captures, say 2008 and 2023, this sync stays locked until the very end, even though these captures have been made with two different cams and 15 years apart.

If I do this with an uncompressed file and a DV-2008 version, I notice that after a while the two captures seem to drift apart. After a couple minutes they're like 3 to 4 frames apart of each other and I have no idea why this would be if both DV captures (2008 & 2023) stay locked in sync forever until the end.

Is this because during the capture some individual frames have been skipped or lost? But like I said: neither CPU nor RAM nor HDDs were stressed during capture. CPU stayed between 2 and 4% load, and the HDD which was captured on was between 10 and 20%.

I have no idea why these two files would eventually drift apart a couple frames when two different DV captures will not?

[poisondeathray]

Is this because during the capture some individual frames have been skipped or lost? But like I said: neither CPU nor RAM nor HDDs were stressed during capture. CPU stayed between 2 and 4% load, and the HDD which was captured on was between 10 and 20%.

I have no idea why these two files would eventually drift apart a couple frames when two different DV captures will not?

DV is essentially "foolproof."

You can see "YUF-Sample_2.avi", near the beginning there is a dropped field between 8 and 9 (jump in motion). Field 8 and 10 are duplicates. There is a forward/back motion. 10 is the compensatory duplicate field inserted for the field dropped between 8 and 9

If you align the fields at the beginning with "DV-Sample_2.avi" (DV is BFF, other is TFF) , they are no longer aligned after the glitch . At the same timecode, the DV sample is now 1 field ahead


Drops happen even with slack resources. Make sure you don't have other things going on - instant messengers, virus scans, defragging etc... Make sure you're not on some power saving/eco mode for all hardware

[Marvolo]

Drops happen even with slack resources. Make sure you don't have other things going on - instant messengers, virus scans, defragging etc... Make sure you're not on some power saving/eco mode for all hardware

Valuable tip, thanks. Is there a way to thoroughly detect drops other than comparing it the way I did? You did it with Vdub - but does that mean, I'd have to go through the entire capture frame by frame?

Is there a software or anything that can detect lost frames? So I could maybe feed in the DV file as reference and the software compares it with the lossless capture?

Do drops happen because I capture uncompressed? Would they not happen if I captured directly in Lagarith or Huffy?

[johnmeyer]

Dropped frames is why I always recommend DV.

I've posted this many times: I've never once had a dropped frame while capturing with DV.

However, given that you want to make this other capture chain work, you can sometimes get better captures with other approaches, so keep trying. Here are things I would look at if you want to get rid of the drops:

1. Capture on a system running Windows XP. Windows 7 might also work. Later Windows versions sometimes have timing problems with capture drivers.

2. Turn off as many background services as you can. I still mostly use XP and Win7, even though I have Windows 10 computers, so I don't know if the procedure is the same. In my ancient Windows versions you used MSCONFIG and then turn off every service that you didn't need to do the capture. Do the same with the background programs. You can re-enable them later.

3. Along the same lines, close down ALL other programs, and don't do anything else on your computer while capturing.

4. Do not capture to external drives. USB 3.0 is much faster than earlier versions, so perhaps this isn't as important as it used to be, but the problems with dropped frames usually have nothing to do with the theoretical transfer rates and instead have to do with buffering issues. The old example was DMA with IDE drives: if DMA wasn't enabled, you'd get dropped frames no matter how fast the drive. Windows XP used to turn off DMA if it sensed any sort of problem, and so a huge number of people had computers which had really slow disk drive reading/writing, all because of a Microsoft "feature" that never should have changed this setting without notification, and without letting the user decline the change.

5. Turn off indexing for the capture drive. It used to be that you could right-click on the drive, select properties and under the General tab was an option to turn off indexing for that drive. Hopefully, it still works that way in Windows 10/11. (I haven't ever checked this).

6. You can also type "services.msc" in the Run box and shut down even more services there. However, this is not as easily reversible, and you can screw things up (set a system restore point before you do this).

If you haven't already done so, read the sticky in this forum:

Why does your system drop frames?

[edit]A corollary to this problem is streaming: even is you have 1 Gbps Internet speed, you may find that your Netflix, AppleTV, etc. still drops frames. This is often due to wireless settings and is why, when the option exists I always use a wired connection. Even a Cat5 100 Mbps connection beats wireless, even when ten feet from the router, by a huge margin.

[Sharc]

Do drops happen because I capture uncompressed? Would they not happen if I captured directly in Lagarith or Huffy?

Yes, if the bottleneck is the data tranfer rate to your storage medium. No, if the bottleneck is the CPU.

[johnmeyer]

Is there a software or anything that can detect lost frames? So I could maybe feed in the DV file as reference and the software compares it with the lossless capture?

I've written such scripts, but a far better programmer, StainleSS, has written something called DropDeadGorgeous (he has a sense of humor):

Duplicity2/DropDeadGorgeous v2.13 - Dupe Tool - 17 Nov 2018

His post is a little confusing because, as others have pointed out, drops are usually followed by dups, to keep the audio in sync, so you end up having to deal with both (which is what my scripts do). His post deals with both (hence the confusion) so you will have to search for the Drop detection, and also find the latest version of his script, later in the thread. You'll find the downloads in his signature.

[johnmeyer]

Do drops happen because I capture uncompressed? Would they not happen if I captured directly in Lagarith or Huffy?

Yes, if the bottleneck is the data transfer rate to your storage medium. No, if the bottleneck is the CPU.

I don't think drops are usually from a traditional bottleneck, where a peripheral or a buss or a CPU isn't fast enough, but instead is from the still-poor Windows multitasking which too often allows a process to seize control and not release a resource in time. We've all experienced where you click and the computer doesn't respond right away. That shows how bad the problem is because that delay is measured in seconds, and dropping a frame only requires a few milliseconds delay.

[Marvolo]

Thanks a lot @johnmeyer! Also @Sharc!

I believe I might have to set up a special boot-up partition just for capturing where nothing is installed but the capture software. Not even sure if my Black Magic Intensity is supported under WinXP?

Luckily my actual Win10 system would also be able to host WinXP natively. The mainboard is from 2009 and it was one of the last boards that still got XP drivers.

I never used XP on this system though. Started with Win7 in 2009, then upgraded to Win8.1 and since 2015 it's been running with Win10.