Hi,
I'm using your codec with vegas.
I am wondering what's the meaning of the generic option I can select when i set it up (option which gives me an error BTW)
Also, when I compress interlaced file, should i check the box "interlaced"? What does it do exactly?
Generic is there because of the 1.2 version of MagicYUV, which used a single fourcc code (MAGY), but it is no longer used, only decoded. That's why a variant of the codec exists for "decoding only" that earlier fourcc, and it gives an error as it refuses encoding.
About the "Assume interlaced" option: If ON the codec assumes the input is interlaced, and does encoding more efficiently for interlaced material (treats the fields separately instead of the whole frame with jaggies), so compresses better compared to the option being OFF (for interlaced material). Also, if the codec does conversion (like when you compress RGB -> YUV 4:2:2 or decompress YUV 4:2:2 -> RGB, which could happen in many cases if an app requests that), the conversion must be done differently if the material is interlaced, otherwise it won't be correct.
So in general, if you know your material is interlaced, check that option before encoding.
Thanks a lot for your reply.
As a side question, I always encode my projects by using an external encoder (either x264 or x265) and magicyuv as intermediate file.
As those codec expect YV12 color space, is it better to make the conversion during encoding magicyuv file directly or ouputting the intermediate file in RGB, then convert it just before the final encoding?
That depends on your workflow. How does your workflow end-to-end look like?
- Original video files are h264, 8bits.
- Editing with Vegas (which works with RGB internally if I'm not mistaken)
- Outputting MagicYUV file from Vegas
- Encode this last file using external x264/265 GUI encoder.
OK, in that case if you can ensure that step 4 can use YV12 directly and absolutely sure there is no conversion going on, then in this workflow it is more efficient (in space and speed) to have step 3 encoded as YUV 4:2:0.
If you want (though it depends on what you're editing) it can speed up or make editing smoother if you transcode the originals to MagicYUV as well.
Thanks a lot for your reply.
I'm actually feeding the x264/265 GUI with an avisynth script. I will remove the converttoyv12 line and test this ASAP.
Unfortunately, converting my original footage to magicyuv before editing is not an option for me due to limited HDD space.
OK, so you're a power user then 🙂
You can check the decoded format both by howering/clicking the mouser over the MagicYUV tray icon and/or enabling logging and checking the log files (just to be sure).