Workflow from VapourSynth to DaVinci Resolve

[sunshine]

Hello -

I'm working on an archival/ restoration project. I have a ton of MiniDV and VHS which I've captured to my PC via FireWire (60 hours approx).

The video is all BFF interlaced, 720x480, 30000/1001 fps, yuv411 8bit dvsd in AVI.

These are home videos shot with poor lighting, incorrect white balance, hand-held, etc., so I'd like to do some color correction and stabilization to make them more enjoyable to watch on a modern TV or mobile device. All playback will be done by a PC/ mobile device.

I own Davinci Resolve, which I plan to use for editing, color grading, stabilizing, and so on, but the deinterlacing and scaling in Resolve compares poorly to what I've seen with VapourSynth.

Here's what I'm thinking I'll do to deinterlace and resize the video. I'm looking for feedback on this, as I'm very new to this stuff.

#!/usr/bin/env python

# import the needed modules
import vapoursynth as vs
import havsfunc as haf
import edi_rpow2 as edi

core = vs.get_core()

# read the clip, it's passed as a param named "INVID" by vspipe
clip = core.ffms2.Source(source=INVID)

# I believe this converts the clip colorspace from yuv411 to yuv420, at 8 bit depth, as required for QTGMC.
clip = core.fmtc.resample (clip=clip, css="420")
clip = core.fmtc.bitdepth (clip=clip, bits=8)

# Use QTGMC to deinterlace - Are these good settings for my use-case?? These are your standard "home video" types of videos
clip = haf.QTGMC(clip, Preset='Slower', TFF=False)

# Use nnedi3_rpow2 to scale 2x
# from 720x480 to 1440x960
clip = edi.nnedi3_rpow2(clip=clip, rfactor=2)

# I believe this resizes to 1440x1080, with 4:3 DAR, with yuv422p8 colorspace and 709 color matrix. This part is way over my head, and I'd appreciate feedback
# Also, I'm scaling from 1440x960 to 1440x1080. Is this distorting my image (stretching its height)? Or is this compensating for 4:3 pixel AR, because I gather it's being output in a 1:1 pixel AR now? I'm lost on this one.
clip = core.resize.Spline36(clip, 1440, 1080, format=vs.YUV422P8, matrix_in_s='709')

clip.set_output()


As far as where this is being sent next, it's ffmpeg to encode into x264, crf 10, veryslow, as follows.

vspipe --y4m ./DeinterlaceAndScale.py -a "INVID=$INVID" - | ffmpeg -nostdin -i pipe: -i "$INVID" -pix_fmt yuv422p -c:v libx264 -preset veryslow -crf 10 -tune fastdecode -x264opts keyint=1 -c:a copy -map 0:0 -map 1:1 "$OUTVID"

This intermediate output is my input to DaVinci Resolve. I COULD do x264 CRF 0 lossless, but the file sizes and processing overhead are a little ridiculous.

From DaVinci Resolve, I'll output likely dnxhr-sq for archival, and x264 CRF 20 for posting to Youtube, using on Plex, and so on.

I'd love some expert feedback on this workflow. Am I doing anything obviously wrong?

Thanks

[lansing]

You can mount your script into a fake avi using avfs.exe in your plugin folder. There's a avfs program in your vapoursynth/core64 path, just drag and drop your script into the program and it's mount it. The mount point will be C:\volume if you're using Windows.

[sunshine]

You can mount your script into a fake avi using avfs.exe in your plugin folder. There's a avfs program in your vapoursynth/core64 path, just drag and drop your script into the program and it's mount it. The mount point will be C:\volume if you're using Windows.

Thanks for the idea Lansing, but I'm using Arch Linux for this and have several hundred clips to process, so I've written scripts that automate the process.

Any suggestions around the processing steps I'm applying to the SD video?

Thanks!

[poisondeathray]

clip = core.resize.Spline36(clip, 1440, 1080, format=vs.YUV422P8, matrix_in_s='709')




601 => 709 should be

matrix_in_s="170m", matrix_s="709"


into x264, crf 10, veryslow, as follows.


Why "veryslow ?" Waste of time IMO . These are intermediate temp files



I'd love some expert feedback on this workflow. Am I doing anything obviously wrong?



Alternatively you can edit in SD after bob deinterlacing ; it's much faster to process, stabilize,filter etc...at SD than HD. Then upscale at the last step

[WorBry]

You can mount your script into a fake avi using avfs.exe in your plugin folder. There's a avfs program in your vapoursynth/core64 path, just drag and drop your script into the program and it's mount it. The mount point will be C:\volume if you're using Windows.

Does this actually work with Resolve ? Resolve has native support for import and export of a very limited range of VFW codecs (Cineform, Grass Valley, Uncompressed) and tends to be very picky about the AVI formatting - won't import uncompressed 4:2:0 in any form and you need the licensed (paid) Studio version to import lossless x264 (Hi444Pred). No ffmpeg support either, although that has oft been requested.

[ChaosKing]

As far as I know CRF 0 is NOT lossless, only -q 0 is!
I always used a fast or faster preset and --tune fastdecode + mp4 for my lossess encodes. (you need to remux a mkv produced by x264 as it doesn't have a proper index --> seeking means read the whole file then)

[_Al_]

QTGMC can work with 422, so there can be just one color space conversion:
clip = core.ffms2.Source(source=INVID)
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_in_s="170m", matrix_s="709")
clip = haf.QTGMC(clip, Preset='Medium', TFF=False)
clip = edi.nnedi3_rpow2(clip=clip, rfactor=2)
clip = core.resize.Spline36(clip, 1440, 1080)
clip.set_output()

[WorBry]

Alternatively you can edit in SD after bob deinterlacing ; it's much faster to process, stabilize,filter etc...at SD than HD. Then upscale at the last step

I've been following Sunshine's parallel thread on the Blackmagic: Resolve Forum. The advice he received from others was to deinterlace (QTGMC) and upscale (NNEDI) to HD before editing.

Resolve does support field processing (free and Studio version) but applies title and transition macros as progressive frame. The Studio version supports in-program deinterlacing and its single-rate (same field) only.

[poisondeathray]

I've been following Sunshine's parallel thread on the Blackmagic: Resolve Forum. The advice he received from others was to deinterlace (QTGMC) and upscale (NNEDI) to HD before editing.

What where the main reasons ? Can you provide link the thread ?

Pros / cons either way

But if he's complaining about filesizes , CRF 10 SD will consume less disk space, process faster, edit faster, compared to 1440x1080

Also, depending on the project, a lot of footage is cut out. It's a waste of disk space, time, QTGMCing, upscaling stuff that is going to be cut out anyways

It might not matter much for DV/ VHS , but there are some decent , newer upscale methods on the horizon . NNEDI3 is a neural net trained (you can call it "AI") by tritical, but there are newer neural net scalers being developed. I wouldn't want to "lock" the coarse NNEDI3 method into the upscale at this point

[Cary Knoop]

Does this actually work with Resolve ? Resolve has native support for import and export of a very limited range of VFW codecs (Cineform, Grass Valley, Uncompressed) and tends to be very picky about the AVI formatting - won't import uncompressed 4:2:0 in any form and you need the licensed (paid) Studio version to import lossless x264 (Hi444Pred). No ffmpeg support either, although that has oft been requested.
I'd be interested in hearing from someone who successfully managed to get this to work. I tried before but did not succeed.

Link to the BM forum thread:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=88796

[WorBry]

Yes, t'was I who gave the sagely, but redundant advice about preserving interlace fields if he intends to re-interlace...which he doesn't.

Resolve does also support native DV import but again tends to be picky about the AVI format (doesn't like Sony's) - may have to remux to MOV. No DV export though.

[sunshine]

601 => 709 should be matrix_in_s="170m", matrix_s="709"

My script is very heavily based on this post in Andrew's blog (http://macilatthefront.blogspot.com/2018/12/using-vapoursynth-for-qtgmc-round-one.html).

Like in his post, my input video is SD DV, yuv411 and 601 color matrix, so I just went with his approach. Much of this stuff is well over my head!

Do the processing steps prior to that final resize affect the color matrix? Is there a way for VapourSynth to tell me the color matrix before and after a processing step?


Why "veryslow ?" Waste of time IMO . These are intermediate temp files


Good catch, if I understand correctly, this only affects compression ratio and output file size, right? So I could go say "medium", without affecting the video quality right? Just use more disk space (I've got ~20-30 TB available, so no biggie).


Alternatively you can edit in SD after bob deinterlacing ; it's much faster to process, stabilize,filter etc...at SD than HD. Then upscale at the last step


Interesting idea! You mention bob deinterlacing. QTGMC produces such nice deinterlaced output, is there a reason I'd not want to use QTGMC?

[sunshine]

Yes, t'was I who gave the sagely, but redundant advice about preserving interlace fields if he intends to re-interlace...which he doesn't.

Resolve does also support native DV import but again tends to be picky about the AVI format (doesn't like Sony's) - may have to remux to MOV. No DV export though.

Thanks for your advice over on the BM forums!

I do have a paid-for Resolve Studio to work with, but its deinterlacing is not nearly as nice as QTGMC (to my untrained eye).

Resolve does not like the AVI I'm working with (Sony MiniDV camcorder to PC via FireWire, using WinDV to create AVI), but seems to work fine in Resolve after I remux into MOV as you describe.

[poisondeathray]

Do the processing steps prior to that final resize affect the color matrix? Is there a way for VapourSynth to tell me the color matrix before and after a processing step?


You can look at the clip props, but sometimes videos are flagged incorrectly and you will get the wrong results

In general SD is 601, HD is 709



Good catch, if I understand correctly, this only affects compression ratio and output file size, right? So I could go say "medium", without affecting the video quality right? Just use more disk space (I've got ~20-30 TB available, so no biggie).


Roughly , yes. I you might get 1-3 % space savings for 2-3x slower processing . You can do some mini tests, but it's really not worth it .



Interesting idea! You mention bob deinterlacing. QTGMC produces such nice deinterlaced output, is there a reason I'd not want to use QTGMC?

I mean bob deinterlacing (ie. double rate) with QTGMC . Not using "bob" algorithm to deinterlace

[Cary Knoop]

Like in his post, my input video is SD DV, yuv411 and 601 color matrix, so I just went with his approach. Much of this stuff is well over my head!
You video is Rec.601 when you upscale it to HD I would convert it to Rec.709. At any rate, using Rec.709 as input is incorrect (as was already mentioned in the BM thread). Also, the primaries should be converted.


Good catch, if I understand correctly, this only affects compression ratio and output file size, right? So I could go say "medium", without affecting the video quality right? Just use more disk space (I've got ~20-30 TB available, so no biggie).

The quality is determined by the CRF option, all that faster processing will do is to make the compression less effective but that only translates into a slightly larger file.


Interesting idea! You mention bob deinterlacing. QTGMC produces such nice deinterlaced output, is there a reason I'd not want to use QTGMC?
QTGMC is way better than bob deinterlacing. Edited to add: poisondeathray made already clear he meant bob deinterlacing as part of QTGMC.

[poisondeathray]

As far as I know CRF 0 is NOT lossless, only -q 0 is!

(For x264, CRF 0 is lossless too . You can do a diff to verify. For x265 you need to add the --lossless switch)

[poisondeathray]

For vpy avfs mounting, resolve will accept 10bit422 with the v210 flag (enable_v210 = True)

But not a good idea IMO when you have many clips or larger project. Way too much trouble, way too slow in terms of overhead

Not sure about other pixel formats in the v16 beta .

[WorBry]

(For x264, CRF 0 is lossless too . You can do a diff to verify.

With 8bit sources, libx264 switches -crf 0 to -qp 0 automatically, but for 10bit you need to set -qp 0.

[sunshine]

(For x264, CRF 0 is lossless too . You can do a diff to verify. For x265 you need to add the --lossless switch)

I did the following tests to compare PSNR of x264 and dnxhr vs. raw, and CRF 0 scored "inf" which may confirm it's lossless, if I understand correctly.. but again I'm a noob.


Size MB File PSNR
32007 MiniDV-47.SHORT.yuv NA
6621 MiniDV-47.SHORT.x264.crf0.veryslow.mov PSNR y:inf u:inf v:inf average:inf min:inf max:inf
4083 MiniDV-47.SHORT.x264.crf1.veryslow.mov PSNR y:53.512392 u:61.432235 v:60.652085 average:55.813724 min:53.405067 max:67.970034
3284 MiniDV-47.SHORT.x264.crf3.veryslow.mov PSNR y:51.757858 u:60.172675 v:59.398284 average:54.130656 min:51.885540 max:67.841050
2081 MiniDV-47.SHORT.x264.crf7.veryslow.mov PSNR y:48.699226 u:57.827356 v:57.149576 average:51.168932 min:48.984561 max:63.049205
1510 MiniDV-47.SHORT.x264.crf10.veryslow.mov PSNR y:46.652977 u:56.481528 v:55.907612 average:49.204670 min:46.846824 max:58.420081
1254 MiniDV-47.SHORT.x264.crf12.veryslow.mov PSNR y:45.362313 u:55.802922 v:55.325697 average:47.976095 min:45.501538 max:56.102836
957 MiniDV-47.SHORT.x264.crf15.veryslow.mov PSNR y:43.455688 u:54.798423 v:54.447722 average:46.145881 min:43.542113 max:53.632696
47 MiniDV-47.SHORT.x264.crf28.mov PSNR y:29.511193 u:46.680560 v:48.086853 average:32.450267 min:15.007240 max:41.752188

7104 MiniDV-47.SHORT.dnxhrhq.mov PSNR y:53.555803 u:61.071902 v:60.056131 average:55.772436 min:55.019938 max:56.028969
4701 MiniDV-47.SHORT.dnxhrsq.mov PSNR y:52.896759 u:60.668225 v:59.693643 average:55.158653 min:54.212876 max:55.469476
1498 MiniDV-47.SHORT.dnxhrlb.mov PSNR y:45.928688 u:56.024373 v:55.573581 average:48.512562 min:44.856081 max:51.501520

[poisondeathray]

With 8bit sources, libx264 switches -crf 0 to -qp 0 automatically, but for 10bit you need to set -qp 0.

Yes, and I'm not sure why they changed the behaviour (inconsistent)

[sunshine]

QTGMC can work with 422, so there can be just one color space conversion:
clip = core.ffms2.Source(source=INVID)
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_in_s="170m", matrix_s="709")
clip = haf.QTGMC(clip, Preset='Medium', TFF=False)
clip = edi.nnedi3_rpow2(clip=clip, rfactor=2)
clip = core.resize.Spline36(clip, 1440, 1080)
clip.set_output()

Thanks for the suggestion Al - I'm curious about your QTGMC line, where you went with Medium. Is that intentionally not using "Slower"?

[WorBry]

I did the following tests to compare PSNR of x264 and dnxhr vs. raw, and CRF 0 scored "inf" which may confirm it's lossless, if I understand correctly.. but again I'm a noob.


Yes it does confirm, but you'd see it had switched to encoding qp=0 anyway in the encode parameters - check with MediaInfo > Text view.

[_Al_]

Do the processing steps prior to that final resize affect the color matrix? Is there a way for VapourSynth to tell me the color matrix before and after a processing step?
clip = core.text.FrameProps(clip)
that line would show you Matrix value, if 2, it means unknown, 1 is 709, 5 is 470bg (PAL DV), 6 is 170m (NTSC DV),

before encoding don't forget to comment out that line

or right after you load clip you could make sure and and set props correctly so Vapoursynth knows what the input is:
clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=6)
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_s="709")

btw, QTGMC takes YUV422P10 or YUV444P10 also

I'm curious about your QTGMC line, where you went with Medium. Is that intentionally not using "Slower"?
no , it is just faster

[sunshine]

Yes it does confirm, but you'd see it had switched to encoding qp=0 anyway in the encode parameters - check with MediaInfo > Text view.

I'm not sure about Text View as I don't see that in mediainfo output on Linux, but here's what I see in Encoding settings:

Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0x1:0x131 / me=umh / subme=9 / psy=0 / mixed_ref=0 / me_range=24 /
chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=18 / lookahead_threads=1 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=1 / keyint_min=1 / scenecut=40 / intra_refresh=0 /
rc=cqp / mbtree=0 / qp=0

[Cary Knoop]

Do the processing steps prior to that final resize affect the color matrix? Is there a way for VapourSynth to tell me the color matrix before and after a processing step?

Resize has nothing to do with it.

The resize command:
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_in_s="170m", matrix_s="709")

does not do a resize, it is simply used to change the colorspace.

[WorBry]

I'm not sure about Text View as I don't see that in mediainfo output on Linux, but here's what I see in Encoding settings:

Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0x1:0x131 / me=umh / subme=9 / psy=0 / mixed_ref=0 / me_range=24 /
chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=18 / lookahead_threads=1 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=1 / keyint_min=1 / scenecut=40 / intra_refresh=0 /
rc=cqp / mbtree=0 / qp=0



There you go, qp=0.

Yes, I think with the linux version of MediaInfo you have to look in 'Show All Formats' or something. I'm not on linux just now to check.

[WorBry]

With 8bit sources, libx264 switches -crf 0 to -qp 0 automatically, but for 10bit you need to set -qp 0.
Yes, and I'm not sure why they changed the behaviour (inconsistent)

Actually, to qualify that - with 8bit sources libx264 swiches -crf 0 to -qp 0 automatically when encoding to 8bit (by default or set -pix_fmt). But for 10bit sources and 10bit x264 encoding, you need to set -qp 0.

[lansing]

Does this actually work with Resolve ? Resolve has native support for import and export of a very limited range of VFW codecs (Cineform, Grass Valley, Uncompressed) and tends to be very picky about the AVI formatting - won't import uncompressed 4:2:0 in any form and you need the licensed (paid) Studio version to import lossless x264 (Hi444Pred). No ffmpeg support either, although that has oft been requested.

Just output the video to rgb30, it works

[sunshine]

You can look at the clip props, but sometimes videos are flagged incorrectly and you will get the wrong results

In general SD is 601, HD is 709

Roughly , yes. I you might get 1-3 % space savings for 2-3x slower processing . You can do some mini tests, but it's really not worth it .


I mean bob deinterlacing (ie. double rate) with QTGMC . Not using "bob" algorithm to deinterlace

I'm taking your recommended approach (deinterlace the SD DV, then do my edits, color correction, etc. in resolve, then resize to 1080 height) but I've encountered a small problem.

The aspect ratio is incorrect, and the video looks off.

AVI input file to VapourSynth:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 0.889


MOV output from ffmpeg:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 1.000



To correct this, I've updated my ffmpeg command with "setsar=sar=8/9,setdar=dar=4/3" as follows.. Did I do this correctly?!

vspipe --y4m ./Deinterlace.py -a "INVID=$INVID" - | ffmpeg -nostdin -i pipe: -i "$INVID" -pix_fmt yuv422p -c:v libx264 -crf 0 -tune fastdecode -x264opts keyint=1 -c:a copy -map 0:0 -map 1:1 -vf setsar=sar=8/9,setdar=dar=4/3 "$OUTVID"

After this adjustment, the MOV output from ffmpeg:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 0.889


Thanks!

[poisondeathray]

The aspect ratio is incorrect, and the video looks off.

AVI input file to VapourSynth:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 0.889


MOV output from ffmpeg:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 1.000



To correct this, I've updated my ffmpeg command with "setsar=sar=8/9,setdar=dar=4/3" as follows.. Did I do this correctly?!

vspipe --y4m ./Deinterlace.py -a "INVID=$INVID" - | ffmpeg -nostdin -i pipe: -i "$INVID" -pix_fmt yuv422p -c:v libx264 -crf 0 -tune fastdecode -x264opts keyint=1 -c:a copy -map 0:0 -map 1:1 -vf setsar=sar=8/9,setdar=dar=4/3 "$OUTVID"

After this adjustment, the MOV output from ffmpeg:

Width : 720 pixels
Height : 480 pixels
Pixel aspect ratio : 0.889


Thanks!





Without getting into a lengthy AR interpretation discussion, that's one way of getting 4:3 DAR . Typically I only set the SAR, because setting the DAR will only give you non ITU aspect ratio options

But for analog sources like VHS, technically the SAR is actually 10:11 . DV too. And those are what you are using according to the 1st post. The central portion or active image area is 702 width (rounded to 704), and pillar boxed

You can verify with some objects, such as a round clock or car tire shot straight on. 99% of the time 10:11 will give you the perfect circle, but 8:9 will give you slightly oval. It also depends on the lineage and what steps or types of transfers were done inbetween. It also depends on the software, you might have to interpret the AR in some software, but resolve can distinguish between the two (at least with the SAR flag)

It's the same with upscaling to HD . The AR will be slightly off if you use the wrong AR interpretation.

(But many people don't care about tiny AR error . I guess it depends on how picky you are, or if driving on "oval" tires is ok :) )

[sunshine]

Without getting into a lengthy AR interpretation discussion, that's one way of getting 4:3 DAR . Typically I only set the SAR, because setting the DAR will only give you non ITU aspect ratio options


Is there a better way you'd recommend? I want to do this as "properly" as possible.



But for analog sources like VHS, technically the SAR is actually 10:11 . DV too. And those are what you are using according to the 1st post. The central portion or active image area is 702 width (rounded to 704), and pillar boxed


According to "ffprobe -i", my AVIs are:

Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv411p, 720x480 [SAR 8:9 DAR 4:3], 28772 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

Is it possible this is incorrect? I used this to inform my choice to "setsar=sar=8/9,setdar=dar=4/3", maybe I'm misunderstanding but I assumed that would suggest my deinterlaced output should also target that.


You can verify with some objects, such as a round clock or car tire shot straight on. 99% of the time 10:11 will give you the perfect circle, but 8:9 will give you slightly oval. It also depends on the lineage and what steps or types of transfers were done inbetween. It also depends on the software, you might have to interpret the AR in some software, but resolve can distinguish between the two (at least with the SAR flag)

It's the same with upscaling to HD . The AR will be slightly off if you use the wrong AR interpretation.

(But many people don't care about tiny AR error . I guess it depends on how picky you are, or if driving on "oval" tires is ok :) )

I'm VERY picky, as I'm trying to produce "archival" grade footage of my family's old home movies. I'm OK spending the time and effort to get it right! :)

When it comes time to process in Resolve, I'll likely scale up 2x, crop those pillarboxes and the fuzzy bit at the bottom of the image out (not sure what it's called, but it's that distorted portion at the bottom of old video recordings).

Do you have a suggestion for dimensions to output from Resolve? Would you avoid cropping? I want to do this properly, but am unsure what the "right way" would be.

[poisondeathray]

Is there a better way you'd recommend? I want to do this as "properly" as possible.

According to "ffprobe -i", my AVIs are:

Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv411p, 720x480 [SAR 8:9 DAR 4:3], 28772 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

Is it possible this is incorrect? I used this to inform my choice to "setsar=sar=8/9,setdar=dar=4/3", maybe I'm misunderstanding but I assumed that would suggest my deinterlaced output should also target that.




ffprobe/ffmpeg , like mediainfo cannot tell you things such as what the actual content AR is. It will only tell you what the flags or how it was encoded. The content SAR is probably 10:11 . If you use 8:9 likely you will get ovals instead of circles for things like DV, VHS . 99.9% of those types of sources will NOT use 8:9. They will use the ITU aspect ratio rules

So I am suggesting -vf setsar=sar=10/11 , but you have to check the actual footage with known objects or references because all sorts of things might distort the AR (studio screw up before broadcast, bad cap etc...) But a native DV camcorder will use ITU rules 99.9% of the time





When it comes time to process in Resolve, I'll likely scale up 2x, crop those pillarboxes and the fuzzy bit at the bottom of the image out (not sure what it's called, but it's that distorted portion at the bottom

Do you have a suggestion for dimensions to output from Resolve? Would you avoid cropping? I want to do this properly, but am unsure what the "right way" would be.

You're probably referring to the VHS head switching noise. It's personal preference, but some people would cover them up with black overlays / black borders. Others prefer to crop . But that can distort the AR slightly if the areas are not proportional and it's not done properly

Personally, I wouldn't use resolve to do this part . It's too limited of an editor (it's getting better... but... can't handle simple things like interlace properly). I would actually keep it as DV interlaced and edit it that way in a proper editor

Resolve is fantastic for some things, not so much for others. Pros/cons

[sunshine]

So I am suggesting -vf setsar=sar=10/11 , but you have to check the actual footage with known objects or references because all sorts of things might distort the AR (studio screw up before broadcast, bad cap etc...) But a native DV camcorder will use ITU rules 99.9% of the time


Great suggestion - I'll find myself a perfect circle, make a video of it and examine the two options. Back sometime next week with the results!

[Cary Knoop]

I'm VERY picky, as I'm trying to produce "archival" grade footage of my family's old home movies. I'm OK spending the time and effort to get it right! :)

Archival grade means you do not alter the video at all but capture the original as best as possible. Once you deinterlace and scale (unless it is lossless) you 'cook' the video.

[poisondeathray]

Great suggestion - I'll find myself a perfect circle, make a video of it and examine the two options. Back sometime next week with the results!

Maybe for the VHS footage , because of generational and possible transfer issues;

But the native DV camera, don't waste your time. Or do it for fun, because 99.9% is really underestimating and conservative. It's really 100% for 4:3 NTSC DV.

https://en.wikipedia.org/wiki/Pixel_aspect_ratio

PAR (pixel aspect ratio) is known as "SAR" (sample aspect ratio) in MPEG4 terminology. They mean the same thing, they just decided to change names. You can think of it as the w:h of the pixels . Eitherway 10:11 is correct . It's been confirmed many, many times over the years, and it's official in all the documentation and ISO standards

Here is another recent example from another forum from a DV camera
https://forum.videohelp.com/threads/392737-Capturing-Tapes-to-ProRes-vs-DV/page5#post2547654

4/3 = 704/480 * 10/11



And definitely, "archive" is the original DV footage . Keep that safe. Something better might come along (definitely for scaling; but nothing on the horizon in the near future for deinterlacing compared to QTGMC, but you never know, some parts of it can be improved such as the NNEDI3 routines)

[sunshine]

Archival grade means you do not alter the video at all but capture the original as best as possible. Once you deinterlace and scale (unless it is lossless) you 'cook' the video.

A fair point, and I'm addressing that by:

1. Archiving the original MiniDV and Hi8 cassettes, though they're becoming effectively inaccessible due to the obsolescence of the hardware needed to use them.

2. Archiving the AVI transfers from the MiniDV camera. I'll keep these unedited as-is. They're not very "watchable" though, as they're interlaced and most playback devices my family/ friends will be using will not automatically deinterlace, and when they do, they do so relatively poorly compared to QTGMC for example.

3. From the AVIs, I'm producing deinterlaced, edited, color corrected, and likely scaled version for consumption on modern devices.

If someone wants to view the original AVIs, they'll remain accessible for years to come. If they want to view the cassettes, it'll be a challenge but they'll be here. For day to day viewing, I feel the deinterlaced, edited, color corrected versions will be the most enjoyable.

I think I'm covering all my bases with this approach, but I could be wrong. Thoughts?

[sunshine]

Maybe for the VHS footage , because of generational and possible transfer issues;

But the native DV camera, don't waste your time. Or do it for fun, because 99.9% is really underestimating and conservative. It's really 100% for 4:3 NTSC DV.

https://en.wikipedia.org/wiki/Pixel_aspect_ratio

PAR (pixel aspect ratio) is known as "SAR" (sample aspect ratio) in MPEG4 terminology. They mean the same thing, they just decided to change names. You can think of it as the w:h of the pixels . Eitherway 10:11 is correct . It's been confirmed many, many times over the years, and it's official in all the documentation and ISO standards

Here is another recent example from another forum from a DV camera
https://forum.videohelp.com/threads/392737-Capturing-Tapes-to-ProRes-vs-DV/page5#post2547654

4/3 = 704/480 * 10/11


I don't doubt your expertise and knowledge, but I definitely doubt mine. The video I'm working with is coming from so many sources that I may have miscommunicated, misunderstood, or just plain goofed something in the process. For example - much of it is from the 80's, shot on analog Hi8. Much is Digital8. Some is VHS, shot on god knows what. All of it was passed through a "modern" Sony Digital8, including the VHS (from a TBC VHS to the the SVHS input of the camera, out its firewire to WinDV).

So it's a mixed bag.. and ideally I'd like to at least eliminate any damage I might do to it by goofing the AR. So a quick test (shot using analog Hi8, and some shot on Digital8, both sent to the PC via the same path described previously) may help me to identify any issues I'm introducing through this approach.


And definitely, "archive" is the original DV footage . Keep that safe. Something better might come along (definitely for scaling; but nothing on the horizon in the near future for deinterlacing compared to QTGMC, but you never know, some parts of it can be improved such as the NNEDI3 routines)

Absolutely. See my other reply, I have a plan to store physical and digital media at every stage for the reasons you describe.

[Cary Knoop]

A fair point, and I'm addressing that by:

1. Archiving the original MiniDV and Hi8 cassettes, though they're becoming effectively inaccessible due to the obsolescence of the hardware needed to use them.

2. Archiving the AVI transfers from the MiniDV camera. I'll keep these unedited as-is. They're not very "watchable" though, as they're interlaced and most playback devices my family/ friends will be using will not automatically deinterlace, and when they do, they do so relatively poorly compared to QTGMC for example.

3. From the AVIs, I'm producing deinterlaced, edited, color corrected, and likely scaled version for consumption on modern devices.

If someone wants to view the original AVIs, they'll remain accessible for years to come. If they want to view the cassettes, it'll be a challenge but they'll be here. For day to day viewing, I feel the deinterlaced, edited, color corrected versions will be the most enjoyable.

I think I'm covering all my bases with this approach, but I could be wrong. Thoughts?
I would stay away from AVI's as a container and use something more flexible.

[sunshine]

I would stay away from AVI's as a container and use something more flexible.

For archival, I’m keeping the AVIs produced during WinDV transfer. For intermediary output I’m using x264 lossless in MOV, and for final output from Resolve I’m looking for a good lossless option for archival, and will use x264 in mp4 or mov for local use and pushing to YouTube.

[WorBry]

and for final output from Resolve I’m looking for a good lossless option for archival.

I see you brought that up on the BMD forum:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=88567&p=494354&hilit=lossless+TIFF#p494354

[Tormaid]

i’m looking for a good lossless option for archival, and will use x264 in mp4 or mov for local use and pushing to youtube.

ffv1?

[sunshine]

So I am suggesting -vf setsar=sar=10/11 , but you have to check the actual footage with known objects or references because all sorts of things might distort the AR (studio screw up before broadcast, bad cap etc...) But a native DV camcorder will use ITU rules 99.9% of the time



My tests confirm the same -

Approach:
- Captured video directly over a perfect circle, filling the frame as much as possible
- Transferred via FireWire WinDV
- Transcoded using the ffmpeg seen in my script, using both the original setsar I'd proposed, and the recommendation you made, but I added a -vf filter to include the frame number so I can compare frame to frame between them easily.
- Opened both videos in Resolve, with a 1920x1080 timeline square pixel
- Added both videos to the timeline
- Took screen-shots of the fullscreen scaled 1920x1080 (still 4:3, with pillar boxes) from both versions of the video (the sar 8:9/dar 4:3 and sar 10:11)
- Imported the screenshots into Gimp, and used various circle tools to examine them

Result:

The SAR 10:11 version was a more perfect circle than the other.

I repeated the same test for video captured using a legacy SD Hi8 analog camcorder, with the same results.

Thanks again all - it's time to let my machine crunch on the videos. Soon I'll be color grading in Resolve.

I'll follow-up with a reply that includes my full script etc.

[sunshine]

ffv1?

Not available from Resolve :/

[sunshine]

OK here's the full version of my workflow. Perhaps it'll help someone one day.

Source: MiniDV (Digital8 and Hi8)

Connect camcorder via FireWire and import video using WinDV. Save the clips somewhere with a lot of space..


#!/usr/bin/bash

# I include my VapourSynth script right inside my script that automates all of this.. it keeps things in one place.
################
read -r -d '' VAPOURSYNTH <<'VSScript'
#!/usr/bin/env python

# import the needed modules
import vapoursynth as vs
import havsfunc as haf
import edi_rpow2 as edi

core = vs.get_core()

clip = core.ffms2.Source(source=INVID)
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_in_s="170m", matrix_s="709")
clip = haf.QTGMC(clip, Preset="Slower", TFF=False)

clip.set_output()

VSScript
##############

# This outputs the python VapourSynth script to "Deinterlace.py"
echo "$VAPOURSYNTH" > ./Deinterlace.py


# List all your clips here, full paths, one per line
ALLVIDS="/clips/clip1.avi
/clips/clip2.avi
/clips/clip3.avi"

# I took this approach vs. a "find /clips -name \*.avi | while read INVID; do" approach because ffmpeg seems to mess with STDIN/ OUT and makes looping that way painful.. This avoids that pain.

for INVID in $ALLVIDS; do
echo "--------------------------------------"
OUTVID=$(echo "$INVID" | sed -e 's/\.avi/\.mov/')
#OUTVID=$(echo "$OUTVID" | sed -e 's/\.mov/\.10-11\.mov/')
#OUTVID=$(echo "$OUTVID" | sed -e 's/\.mov/\.8-9\.4-3\.mov/')
if [ -e "$OUTVID" ]; then
if [ -e "$OUTVID.complete" ]; then
echo "Found existing complete version of this video; skipping"
echo "--------------------------------------"
continue
else
rm "$OUTVID"
fi
fi


mediainfo "$INVID" | grep -qi "16:9"
if [ $? -eq 0 ]; then
# some of my videos are wide-angle SD DV.. I'll deal with them later.
echo "This video is in 16:9 - skipping it and do it by hand later"
echo "--------------------------------------"
continue
fi


echo "Processing Input $INVID and outputting to $OUTVID"
vspipe --y4m ./Deinterlace.py -a "INVID=$INVID" - | ffmpeg -nostdin -i pipe: -i "$INVID" -pix_fmt yuv422p -c:v libx264 -crf 0 -tune fastdecode -x264opts keyint=1 -c:a copy -map 0:0 -map 1:1 -vf setsar=sar=10/11 "$OUTVID" 2>&1

if [ $? -eq 0 ]; then
echo "Successfully converted $INVID"
(
echo "Vapoursynth Script:"
echo "$VAPOURSYNTH"
echo
echo "ffmpeg:"
echo "vspipe --y4m ./Deinterlace.py -a \"INVID=$INVID\" - | ffmpeg -nostdin -i pipe: -i \"$INVID\" -pix_fmt yuv422p -c:v libx264 -crf 0 -tune fastdecode -x264opts keyint=1 -c:a copy -map 0:0 -map 1:1 -vf setsar=sar=10/11 \"$OUTVID\""
) > "$OUTVID.complete"

fi
echo "--------------------------------------"
done | tee process.$(date +%Y%m%d%H%M%S).log

[_Al_]

there is no "BT709" flag during encoding, so be careful, colors (reds, orange) are going to be most likely wrong if you try to view those archives , players might be defaulting to BT601 because of resolution

[sunshine]

there is no "BT709" flag during encoding, so be careful, colors (reds, orange) are going to be most likely wrong if you try to view those archives , players might be defaulting to BT601 because of resolution

Oh oh!

What have I missed Al, and do you have a suggestion for how I might fix it?

Should I output 601 from the VapourSynth deinterlacing? If so, I'm not sure what I'd need to change.

Should I somehow flag that it's 709 during ffmpeg encode? If so, again.. I'm not sure what I'd need to change.

Thanks for spotting that Al!


FYI - I checked my input video with the following:

#!/usr/bin/env python

# import the needed modules
import vapoursynth as vs
import havsfunc as haf
import edi_rpow2 as edi

core = vs.get_core()

# read the clip
clip = core.ffms2.Source(source=INVID)
clip = core.text.FrameProps(clip)
clip.set_output()


Chroma Location: 2
Matrix: 2
Primaries: 2
Transfer: 2

Hopefully that's helpful info... but I recall you saying seeing a "2" there means unknown. All I know from MediaInfo is that the original AVIs are yuv411.

[_Al_]

-x264opts colormatrix=bt709:transfer=bt709:colorprim=bt709

and you can also make sure in Vapoursynth to make sure about input, not sure if it is redundant to include transfer and color primaries as well:

#clip is NTSC DV avi
#here is clip 4:1:1 (loaded by ffms2) and matrix, transfer and colorprimaries are unknown
clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=6)
clip = core.std.SetFrameProp(clip, prop="_Transfer", intval=6)
clip = core.std.SetFrameProp(clip, prop="_Primaries", intval=6)
#here you have matrix, transfer and color primaries as NTSC DV
clip = core.resize.Bicubic(clip, format=vs.YUV422P8, matrix_s = '709', transfer_s = '709', primaries_s = '709' )
#here you have all as bt709 and also YUV422P8

[poisondeathray]

I think he's using SD, and not upscaling at that stage ; so probably shouldn't use 709

(although resolve doesn't care if SD import has wrong 709 flag, other programs might)

[_Al_]

that's another way to go:
clip = core.resize.Bicubic(clip, format=vs.YUV422P8)
and
-x264opts colormatrix=smpte170m:transfer=smpte170m:colorprim=smpte170m
is that ffmpeg x264opts correct?

[poisondeathray]

@_Al_
yes, smpte170m

@sunshine
In vapoursynth, the matrix_in_s="170m", matrix_s="709" arguments were for when you were upscaling the dimensions. It's similar to using colormatrix for 601->709 . But since you decided to change strategy, it's no longer required . However, when you export for a HD targets, you still need to take care of that (if the programs you are using do not take care of it automatically)

And I question the use of 422 , it will just make the filesize larger. Resolve will handle 420 AVC fine, unless there is some special way resolve handles 422 preferably to 420, from a 411 DV source ? Maybe on the BM forum that I don't know about ? (420 still exceeds the 411 source chroma - it's technically upscaled chroma)

422 has benefits in some programs for handing interlace, but you're QTGMCing it here