@KaraUSA Historical reasons, among other things. Also, mp4 is pretty specific about what it can contain (of which only a handful are actually widely supported): http://mp4ra.org/#/codecs

@MagicYUV Will you export to mp4 in the next update?

MP4 standard prevents this.

@KaraUSA No. mp4 is widely known to contain MPEG-related audio/video, abusing it to contain MagicYUV video would provide no benefit.

Thanks for your responses @MagicYUV
What codecs will you release for version 3 ultimate?

@KaraUSA That's up for the future. So I'm not making any commitments/statements about future releases for now.

Hi @MagicYUV. I had previously done some render quality codec comparisons, (see link in my profile) including MagicYUV.

Great to have it as a plugin. Just installed it, works fine, I tested/rendered out to 420 8 bit FHD (source is 420 8 bit) and compared to the previous version that worked through VFW.

I haven't yet used WWAGS render quality metrics tool, just the ffmpeg RQM as a quick comparison.

I now get a much lower quality result? I can see a difference in that the dimensions of the previous version was 1920 x 1080 x 24, whereas the new plugin rendered out file is 1920 x 1080 x 12, maybe that accounts for it?

I also tested again a UHD version that was previously done. The source in this case was Source.mxf 422 10 bit and I had previously only been able to render out MagicYUV to 422 8 bit through VFW.

The results this time is even better than with the previous 8 bit render, see screenshot below. The dimensions of the previous MagicYUV version was 3840 x 2160 x 24, and the new MagicYUV version gives 3840 x 2160 x 20.

I'll update my # 09 UHD table with this result tomorrow, The MagicYUV results are identical to the "Sony YUV 10 bit 422 lossless.avi" The big difference is that the Sony file is 13.9 GB and the MagicYUV file is 5.42 GB.😅

"Sony YUV 10 bit 422 lossless.avi" ...

SSIM All........ 0.999518 (33.167520)
PSNR Average ... 60.987161
VMAF ........... 100.00000

FWIW I get these best UHD results using VP18 with Project properties set to legacy 8 bit video levels and using the MagicYUV Plugin set to 10 Bit YUV 422. Source is source.mxf 10 bit 422.

@JN- There's some error in the measurement. Both outputs (in case of 8-bit) must be mathematically identical.

I just did a test of rendering both through VFW and the plugin from an 8-bit source using 8-bit Vegas engine mode (pixel format setting in Properties...) to MagicYUV 8-bit YUV 4:2:0, and the result was mathematically identical (apart from AVI muxing differences, since for VFW it is Vegas doing the AVI muxing, while for the plugin it is done by the plugin, but that can easily be normalized using VirtualDub2 in Direct Stream Copy mode to re-mux both).

About 24 vs 12 bits, that field is irrelevant. 12 is actually the more correct value for 8-bit YUV 4:2:0, but the VFW codec writes 24 there always for 8-bit (except for RGBA with alpha, then 32), because it it used to confuse certain old apps in the past if it wasn't 24 there.

About UHD 10-bit 24 vs 20, obviously the since the VFW codec was 8-bit, it wrote 24 there. The plugin writes 20, as it outputs true 10-bit compressed. But again, that value is irrelevant in general.

But back to the original issue, we have to be careful about the measurement, not to accidentally compare apples to oranges, meaning what exactly gets compared to what (in terms of colorspace). Essentially your measurement basically measures the quality of RGB<->YUV conversion, since the codec is otherwise mathematically lossless.

So on the compression side we have:

8-bit 420 original source ==>> Vegas RGB --> MagicYUV RGB ==>> MagicYUV 420

The double arrow (==>>) represents color space conversion, first done probably by Vegas, and on the output side done by the codec. And on the decompression side:

MagicYUV 420 ==>> ffmpeg

8-bit 420 original source ==>> ffmpeg

What colorspace does ffmpeg do the measurement in? YUV 420?

@JN- Also, I see a significant difference in file size (for 8-bit), that definitely means that the codec got different input in those 2 cases (whether due to some Vegas setting or something else).

@MagicYUV Not sure what colour space ffmpeg uses, MusicVid and others are more knowledgeable in that regard. It’s basically a tool to use for me, and one key point to consider is that so far its results have tracked wwaags RQM tool, with one exception, UTVideo. So I don’t consider imho that the problem lies in ffmpeg.

I thought that the most likely candidate for the low results using your plugin was that maybe using VP18 and its new default mode selecting 8 bit full range. So I just now tested using VP17 to bypass that (can be also set manually in vp18) but the results are still too low for the fhd 8 bit test.

Later on I’ll select some different source files and test, no need for me to rob an orchard, the source I already used was 8 bit 420 fhd and I used your 8 bit 420 fhd vp plugin render template.

If I can’t resolve the issue re: the plugin fhd render I'll just leave the old non plugin result as is to remain in the FHD table. Later on i’ll update the new results for the uhd table with the new plugin 422 10 bit results.

@JN- Could you upload the file you test with?

I tested both VP17/18 and all renders with either VFW or the plugin to MagicYUV 4:2:0 all come out as mathematically identical. If it wouldn't, it means that they got different input (there is just no other way, they use the same algorithm).

@MagicYUV Just did another test using vp17 and the MagicYUV non plugin for all of below.

Previously I knew that I had to select, check, the full range option in your configuration dialog, indeed my render template was still there with that setting.

So I rendered out two files, one with it checked and one with it unchecked.

The results now surprised me. The unchecked, limited range file, now gives the correct results and the checked, full range, file gives lower results, quite the opposite to what I got several months ago.

Update: The above underlined comments is not the case, the results are as several months ago testing, the FULL RANGE box checked gives the best result. I'm getting too old for this.

I will upload and send link later with link to dropbox download. I’ll post here when done.

@JN- Ah, I see. The plugin doesn't have that option, and always converts to limited range for 8-bit. But to be honest, the VFW full range option should give better results since it contains full range YUV data (more range).

ffmpeg also comes into play here, because it very much depends on how it does the metric calculation. For instance when comparing to the original, if it is comparing in YUV space it needs to take into account that the original source is limited YUV while MagicYUV could be full range YUV, and do a range-conversion step to bring them to a common YUV ground. If it doesn't do that, then the metrics will be off and misleading.

The full vs limited option absolutely makes no difference when you work in Vegas though, as Vegas always gets and always gives RGB to MagicYUV 8-bit, so it never actually knows what the YUV range is, it sees the files as if they were RGB.

@MagicYUV So I used VP18 again, for the #1 to #5 ffmpeg tests below, because it does have the new option to either use legacy 8 bit video levels or 8 bit full range. Worth a try. Note that this source.mp4 has mostly a range of 16 - 255.

NOTE: #5 Has had the Colour range properties changed to FULL in the media's properties, see Marco's 6th. bullet point.

#1 Full range Pixel format selected in VP properties, using plugin

SSIM All........ 0.997291 (25.672511)
PSNR Average ... 41.788040
VMAF ........... 98.377520

#2 Legacy 8 bit video levels Pixel format selected in VP properties, using plugin

SSIM All........ 0.990140 (20.061420)
PSNR Average ... 31.279292
VMAF ........... 71.350714

#3 Using VFW, Full range NOT selected in configuration dialog box.                                                     

SSIM All........ 0.997291 (25.672511)
PSNR Average ... 41.788040
VMAF ........... 98.377520

 #4 Using VFW, Full range IS selected in configuration dialog box.             

 SSIM All........ 0.987547 (19.047138)
 PSNR Average ... 30.750991
 VMAF ........... 100.00000

#5 Using VFW, Full range IS selected in config. dialog box, + Media colour range flag is changed to FULL. See NOTE: #5 item above.

SSIM All........ 0.998402 (27.964279)
PSNR Average ... 55.023211
VMAF ........... 99.750632

I later used a source.mp4 file similar to the above file used in the five VP18 tests, but internally conformed with a range limited to ~ 16-235.

These are the results below, using VP17, so hardly any improvement over #5 above.

#6 Using VFW, Full range IS selected in configuration dialog box. 
 SSIM All........ 0.998602 (28.546275)
 PSNR Average ... 56.06059
 VMAF ........... 99.801485

@JN- OK, I think I understand what is/was happening, it'll be a bit difficult to explain or comprehend at first, but I'll try:

In VP17 your original input file was probably decoded into Vegas as limited range RGB. If you did no level correction manually, then when you encoded via VFW the codec got limited range RGB as well. Which meant that when you checked the full range option in the codec, the final result actually ended up as limited range YUV, since the codec always treats RGB as full range.

However when the full range option in the codec was not checked, it meant that it got limited RGB, and then when it converted to YUV it did the RGB->limited YUV conversion, so it became "double limited".

Visualized it is something like this:

VP17, VFW Codec Full range option OFF (same as how plugin works):

Original Limited YUV --> Vegas Limited RGB --> MagicYUV Limited RGB --> MagicYUV "Limited Limited" YUV (output file thinks it's Limited YUV)

VP17, VFW Codec Full range option ON:

Original Limited YUV --> Vegas Limited RGB --> MagicYUV Limited RGB --> MagicYUV Limited YUV (output file thinks it's Full YUV)

As you see there are a lot of discrepancies here, also in the second case even though the data in the output file is Limited YUV, the file flags actually indicate that it's Full YUV, which is totally messed up.

For VP18, the whole story is different. As I read the excellent summary by @Marco. here: ( https://www.vegascreativesoftware.info/us/forum/vp18-notes-on-the-8-bit-full-level-option--122749/ ) VP18 finally caught up with the way how practically every other piece of editing software has been working for decades: to treat RGB as full range always. IMO limited RGB never ever made sense, at least not in my lifetime that is.

So for VP18, this is what happens (with 8-bit full range):

VP18, VFW Codec Full range option OFF (same as how plugin works):

Original Limited YUV --> Vegas Full RGB --> MagicYUV Full RGB --> MagicYUV Limited YUV (output file thinks it's Limited YUV)

VP18, VFW Codec Full range option ON:

Original Limited YUV --> Vegas Full RGB --> MagicYUV Full RGB --> MagicYUV Full YUV (output file thinks it's Full YUV)

So here everything matches up nicely.

At least, this is what I THINK is happening, I hope I'm not totally wrong.

The bottom line is this: MagicYUV always treats RGB as full range. The MagicYUV 8-bit codecs always communicate RGB with Vegas. So in conclusion the data sent to either VFW or the plugin must always be Full range RGB for 8-bit.

Also, the Full Range option in the VFW codec settings should never ever be set, unless someone totally understands what's happening. It's there because of the origins of MagicYUV was the doom9 forums, and people there expects total control. The option is left out of the plugin precisely for this reason, as to avoid confusion.

@JN- In any case, to confirm the above, I'd need the original source file you tested with, so thanks in advance if you could upload.

@MagicYUV I made a correction to my post at 2:20 PM above. See the underlined comment and update. So if you’re analysis above needs any modification then take it into account.

I was trying to to get as much done as possible, will upload shortly, and post accordingly.

@JN- If that refers to VP17 then I believe it's still in line with what I think. My only question is regarding this in your post:

#3 Using VFW, Full range NOT selected

...

Full range NOT selected where? In the codec or in VP? (So to be precise: what was VP range setting and what was VFW codec range setting?)

Full range NOT selected where?

@MagicYUV The #3 Refers to the check box in your configuration dialog in the VFW, render option in VP17, not the plugin.

As I pointed out in my correction, underlined text, updated, nothing has changed re: VFW, the full range selection is required to get best results. Apologies for any confusion caused, re: VFW.

@MagicYUV Link sent see PM.

@JN- Thanks, I took a look at the source, and just right off the bat it's range is problematic. The mp4 says it's limited, but if you look at the histogram in VP18 in 8-bit full range Pixel Format mode, and set the "Color range:" setting in the footage properties to "Full" you'll see that it goes all the way up to 255. So it's more like 16-255.

I'll explain in more detail what is happening and why you got the results you got, but it'll take some time to condense it all into a comprehensible post.