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
+ Reply to Thread
Results 31 to 36 of 36
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
I didn't remember doing that.
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.
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.