FFMPEGSource2 vs QTinput for DV Files in AviSynth

[poisondeathray]

AVISource() uses whatever VFW decoder you have installed on that system. So your decoder is outputting YV12, not the original 4:1:1

When you convert to ProRes, it will automatically be upsampled to 10bit422 . You can do it in the script, or ffmpeg will automatically do it if you feed it something else

How do I know what VFW decoder it's using? I did install Cedocida when I started researching dv this time around, is that what it's likely using then?

And would it be better (i.e. less converting colorspaces) if I just added pixel_format YUY2 to the avisource line, rather than opening in YV12 and letting ffmpeg handle it or is it basically the same exact thing / same number of conversions at that point?

If you use vdub2 x64 , load a avi file directly, file=>file information it should list the decoder used (if options=> avi => prefer internal video decoders is unchecked) for the x64 pathway

If you use vdub/vdub2 x86, same for the x86 pathway

pixel_format=YUY2 only works if the decoder is able to output that colorspace. Then it depends on what algorithm it uses. I think jagabo tested cedocida in one of the other threads

[poisondeathray]

pixel_format=YUY2 only works if the decoder is able to output that colorspace. Then it depends on what algorithm it uses. I think jagabo tested cedocida in one of the other threads

Assuming you're configured to use cedocida this is what jagabo tested

It looks to me like Cedocida uses a point resize to reduce the chroma width when encoding, and a bilinear resize when restoring the chroma width when decoding

https://forum.videohelp.com/threads/390949-Canopus-ADVC-100-has-a-TBC-after-all/page2#post2534673

[jagabo]

I didn't remember doing that.

[Christina]

If you use vdub2 x64 , load a avi file directly, file=>file information it should list the decoder used (if options=> avi => prefer internal video decoders is unchecked) for the x64 pathway

If you use vdub/vdub2 x86, same for the x86 pathway

pixel_format=YUY2 only works if the decoder is able to output that colorspace. Then it depends on what algorithm it uses. I think jagabo tested cedocida in one of the other threads

Did this and yes it is Cedocida. So, looks like I have two options:

1. Work with original .dv files and use FFVideoSource and BestAudioSource (assuming I don't have any 32-bit filters in my chain, which currently I do not). This opens the .dv file in its original 4:1:1 colorspace, so I'll have to ConverttoYV16 if going to ProRes or ConverttoYV12 if going to H264/MP4 so QTGMC can work.

2. First remux/rewrap the .dv file to either .mov and use FFMPEGSource2 with atrack=-1, or to .avi and use AviSource with cedocida codec loaded. FFMPEGSource2 is the same as above (opens in 4:1:1) and would need to convert colorspace for QTGMC. Cedocida does its own conversion by default to YV12, or I can add pixel_type="YUY2" to open in 4:2:2, which is what I would need if converting to ProRes after.

I looked at the examples and tests you sent regarding the different methods of resizing chroma (bilinear vs point) - From Jagabo's test, it appears that either of the 2 methods above will be using a bilinear resize upscaling from 4:1:1, so I should get the same results in theory. (The 3rd option which I don't think is in the running anymore was to use QTInput on original .dv file, but we think that one uses a point resizer and could appear blocky.)

Have I got this all right? I really appreciate your help on this. I definitely wouldn't have gotten this far without it!

[poisondeathray]

If you use vdub2 x64 , load a avi file directly, file=>file information it should list the decoder used (if options=> avi => prefer internal video decoders is unchecked) for the x64 pathway

If you use vdub/vdub2 x86, same for the x86 pathway

pixel_format=YUY2 only works if the decoder is able to output that colorspace. Then it depends on what algorithm it uses. I think jagabo tested cedocida in one of the other threads

Did this and yes it is Cedocida. So, looks like I have two options:

1. Work with original .dv files and use FFVideoSource and BestAudioSource (assuming I don't have any 32-bit filters in my chain, which currently I do not). This opens the .dv file in its original 4:1:1 colorspace, so I'll have to ConverttoYV16 if going to ProRes or ConverttoYV12 if going to H264/MP4 so QTGMC can work.

2. First remux/rewrap the .dv file to either .mov and use FFMPEGSource2 with atrack=-1, or to .avi and use AviSource with cedocida codec loaded. FFMPEGSource2 is the same as above (opens in 4:1:1) and would need to convert colorspace for QTGMC. Cedocida does its own conversion by default to YV12, or I can add pixel_type="YUY2" to open in 4:2:2, which is what I would need if converting to ProRes after.

I looked at the examples and tests you sent regarding the different methods of resizing chroma (bilinear vs point) - From Jagabo's test, it appears that either of the 2 methods above will be using a bilinear resize upscaling from 4:1:1, so I should get the same results in theory. (The 3rd option which I don't think is in the running anymore was to use QTInput on original .dv file, but we think that one uses a point resizer and could appear blocky.)

Have I got this all right? I really appreciate your help on this. I definitely wouldn't have gotten this far without it!

Yes, and if you re-wrap into MOV, you can use LSmashVideoSource without indexing the video (MP4, MOV do not require indexing with LSmashVideoSource; it's LWLibavVideoSource that indexes the video) , but audio will still be indexed if you use LSmashAudioSource. If you use BestAudioSource, it does not require indexing.

[jagabo]

By the way, LWlibavVideoSource() can index the file in memory (without creating a separate index file) with LWlibavVideoSource("filename.ext", cache=false). The disadvantage of that is it has to rebuild the in-memory index each time it is used with a file. So it takes more time to start up. The same goes for the LWlibavAudioSource() function.