MagicYUV - a new fast lossless video codec

[poisondeathray]

Its funny that in your case 64 bit version is about 50% slower than 32 bit one.

You can't really draw that conclusion from those observations, because the VFW decoder tested was 32bit one, not 64bit.

Only 64bit ffmpeg was compared for the ffmpeg magicyuv implementation, because decoder was not present in 32bit ffmpeg version , at least in zeranoe's version

A proper comparision would compare 64bit VFW and 32bit VFW , 64bit ffmpeg and 32bit ffmpeg

The only conclusion that is supported from those observations is the 64bit ffmpeg implementation is markedly slower than 32bit VFW native, at least on windows

[poisondeathray]

And another test with 32bit l-smash (compiled with libav sources) avisynth, avsmeter ~230FPS . This is a directly comparable "apples to apples" comparison to the AVISource VFW avisynth, avsmeter results. So it suggests libav / ffmpeg implementation not as optimized as native VFW

[raffriff42]

Testing decoders at 250-450 fps is invalid IMHO, as there are probably unknown bottlenecks at that speed, such as RAM bandwidth. But as long as you're doing these tests, why not compare MagicYUV to some other fast codecs, say, YUV uncompressed and HuffYUV.

[poisondeathray]

Testing decoders at 250-450 fps is invalid IMHO, as there are probably unknown bottlenecks at that speed, such as RAM bandwidth. But as long as you're doing these tests, why not compare MagicYUV to some other fast codecs, say, YUV uncompressed and HuffYUV.

I think it's perfectly valid, and there is very strong correlation with those synthetic numbers (at least the trend) with actual usage in a NLE or a final encoding codec. ie. Something at say 600fps will have a higher final speed and faster operations than something at 400fps.

I've posted bencharks / observations on UT, MagicYUV, Huffyuv before (either here or videohlep), as well as the effect on actual encoding speed on a final encoder like x264 , not just synthetic benchmarks. The summary is magicyuv (VFW) is the fastest by a hair, overtaking UT Video

There is absolutely no reason to use Huffyuv. UT Video is more compressed, more colorspace support (huffyuv original didn't even support 4:2:0, and the final encoding speed with x264 was about 5-10% faster). Stability is high for UT video in host applications like NLE's, compositing programs, but I cannot say the same for MagicYUV only because it's not as extensively tested in NLE's etc... It simply hasn't been around long enough yet

The one issue windows users will be having is QT support is removed. QT for windows is no longer developed. The QT MOV versions for both magicyuv and utvideo are actually more compatible in some professional programs, because AVI has been depreciated out, and higher depth support is problematic. But now MOV is being phased on (at least the QT implementation, some programs have their own native QT implementation that doesn't rely on Apple QT)

[raffriff42]

Agree, HuffYUV is not the way to go any more. I meant to say, compare them on speed only, as a way to cancel out (as much as possible) everything outside the decoder. They have roughly similar compression ratios, therefore roughly similar data throughput.

[Music Fan]

I've posted bencharks / observations on UT, MagicYUV, Huffyuv before (either here or videohlep), as well as the effect on actual encoding speed on a final encoder like x264 , not just synthetic benchmarks. The summary is magicyuv (VFW) is the fastest by a hair, overtaking UT Video
For a capture in real time (analog to digital), do you advise UT, MagicYUV, or it doesn't matter and both are good for this ?

[wiak]

For a capture in real time (analog to digital), do you advise UT, MagicYUV, or it doesn't matter and both are good for this ?
most lossless ones are good, eerm they are lossless, you should probobly test on your content

there can be some big size diff and performance diff based on content

[poisondeathray]

For a capture in real time (analog to digital), do you advise UT, MagicYUV, or it doesn't matter and both are good for this ?

Both are good.

But depending on what programs you are using afterwards , or your specific workflow is - that might influence which you use.

[Music Fan]

Ok. I need avi container (easier to use with Virtual Dub and others) : I generally make some denoising with avisynth and sometimes editing with Vegas.
For the capture in real time, I believe the least possible CPU (and maybe RAM) use is better.
And I need 4:2:2. Until now I used to capture in Lagarith yuy2 but I read that it could bug sometimes.
Ut seems ok, I never tried MagicYUV.

[poisondeathray]

Ok. I need avi container (easier to use with Virtual Dub and others) : I generally make some denoising with avisynth and sometimes editing with Vegas.
For the capture in real time, I believe the least possible CPU (and maybe RAM) use is better.
And I need 4:2:2. Until now I used to capture in Lagarith yuy2 but I read that it could bug sometimes.
Ut seems ok, I never tried MagicYUV.

I would use MagicYUV if Vegas is somewhere in the workflow

Because the full range option in MagicYUV gets treated as "Studio RGB" in vegas . Other lossless codecs in YUV mode get clipped in Vegas , because they get treated as "Computer RGB"

[Music Fan]

Ok, interesting.
For captures I already did in Lagarith, I guess I can convert them in MagicYUV yuy2 if I need to edit them in Vegas.
By the way, why are they treated differently by Vegas ? Isn't there any trick to avoid clipping ?

[kolak]

Agree, HuffYUV is not the way to go any more. I meant to say, compare them on speed only, as a way to cancel out (as much as possible) everything outside the decoder. They have roughly similar compression ratios, therefore roughly similar data throughput.

If you test pure decoding speed in RAM then there should be no bottlenecks and definitely not at 400fps for HD frame (this is just 1.6GB/sec). I had speeds way above 1000fps on dual Xeon machine.

[poisondeathray]

Ok, interesting.
For captures I already did in Lagarith, I guess I can convert them in MagicYUV yuy2 if I need to edit them in Vegas.
By the way, why are they treated differently by Vegas ? Isn't there any trick to avoid clipping ?

If you adjust your captures at the source to Y = 16-235 , you'll be "safe" using other lossless YUV codecs. It's only if you have "superbrights" or "superdarks" that you'll lose data in those regions

I don't know why it's treated differently; vegas does all sorts of things differently. Generally, native camera sources get studio RGB treatment, everything else gets computer RGB treatment, including most lossless YUV codecs. You can read about it more in the Glenn Chan article series or do some testing

[Music Fan]

If you adjust your captures at the source to Y = 16-235
How to do this ?
With Lagarith, there is only the choice between RGB, yv12 and yuy2, I chose yuy2.
With Ut there is rgb, rgb 10 bit, 4:2:0 BT 601, 709 ... I would select 4:2:2 BT 601 for VHS captures.

And with MagicYUV I don't know how to select it, but I just saw it was not free thus I probably won't test it, I make too few captures to buy it.

You can read about it more in the Glenn Chan article series
Where is it ?

[poisondeathray]

How to do this ?


Adjust your capture hardware setup so everything is in "legal range". Otherwise it will get clipped when using YUV lagarith or ut video in vegas




Where is it ?

Search for "Glenn Chan" and "Vegas"

http://www.glennchan.info/articles/articles.html

[Music Fan]

http://www.glennchan.info/articles/articles.html[/url]
Thanks.

Adjust your capture hardware setup so everything is in "legal range".
I believe all I can do is to select the appropriated colorspace (4:2:2) in the capture software, there is nothing about 16-235 and 0-255.

[ChiDragon]

He means you need to manually ensure the levels are set so that nothing you care about reaches outside 16-235, using the capture device's proc amp, an external proc amp, etc.

[Music Fan]

Ok, but I don't know how to do this, it is maybe not possible with my hardware. Anyway I guess that the card does only 16-235 and adapt the signal for this when digitizing the analog signal.

[Micheal813]

I just found MagicYUV today. I'm using Avisynth with VirtualDub. I captured video and compressed it with MagicYUV as YUY2. At a point in my workflow I'm trying to convert the YUY2 to RGB24 using MagicYUV. I know I can not upsample directly so I add ConvertToRGB24 to the end of my script. VirtualDub is set to Fast Recompress and the Color Depth output format to compressor is set to same as decompression format. I also have compress as is selected in MagicYUV.

The saved file shows RGB32. Now I'm no expert, so this may be completely normal. Is RGB32 & RGB24 the same as far as MagicYUV is concerned? Am I misunderstanding something?

[mariush]

In Virtualdub, you can choose the decompression format and the format sent to the compressor. Go in the Video menu, select Normal Recompress (or Full Processing Mode, but at least Normal Recompress is required) and from there, select 24bit RGB (888).
If you know the source format, in some cases you may want to select the decompression format there instead of leaving it on autoselect.
In rare cases, some codecs have quirks and compress yuy2 content but when an application like virtualdub opens the file, the same codec enumerates several output formats (for example rgb24, yv12 and last yuy2) and by default they do an extra color space conversion to give Virtualdub RGB24 or something like that. By changing the autoselect, you may sometimes speed decoding by forcing the codec to not do a color space conversion before passing the raw video frames to Virtualdub.

Of course, you could also set YUY2 at both decompression format and output to compressor, so the frames just pass through Virtualdub and configure MagicYUV to do the conversion from YUY2 to RGB24 inside.

You should also keep in mind that most modern codecs like h264 (with x264.exe as most known encoder) or hevc (x265.exe being most known encoder) default to using YV12 and Youtube and other video playback sites default to YV12 so whatever you'd upload would be reconverted. So it makes no sense to keep videos around in RGB24 unless they're for your own use, for archival, some specialized cases like old video game captures etc

[Micheal813]

In Virtualdub, you can choose the decompression format and the format sent to the compressor. Go in the Video menu, select Normal Recompress (or Full Processing Mode, but at least Normal Recompress is required) and from there, select 24bit RGB (888).

Thanks for the response, but this did not work. I want it to be RGB24 for Neat Video denoiser. Neat Video works in and outputs RGB24. I know it can just do the conversion itself, but I like to take care of the conversions myself when possible.

My script is:

Avisource("YUY2Video.avi")
AssumeTFF()
ConvertToRGB24()

I open this with Virtualdub and select the above settings. If I add Info() to the script it show Colorspace as RGB24. I save the avi. Then to check it, I use this script:

Avisource("NewVideo.avi")
AssumeTFF()
Info()

It shows RGB32 as the colorspace.



Of course, you could also set YUY2 at both decompression format and output to compressor, so the frames just pass through Virtualdub and configure MagicYUV to do the conversion from YUY2 to RGB24 inside.

I thought MagicYUV could not do upsampling. Isn't YUY2 to RGB24 considered upsampling? Am I misunderstanding? I don't see any setting to make it convert the YUY2 to RGB24.



You should also keep in mind that most modern codecs like h264 (with x264.exe as most known encoder) or hevc (x265.exe being most known encoder) default to using YV12 and Youtube and other video playback sites default to YV12 so whatever you'd upload would be reconverted. So it makes no sense to keep videos around in RGB24 unless they're for your own use, for archival, some specialized cases like old video game captures etc

Yes, after I convert it to RGB24, and process it with Neat Video's VDub filter, I plan on converting to YV12 and compressing with x264 to save a lot of space. I have lots of video to process.

[Music Fan]

You can put converttorgb32() instead of ConvertToRGB24(), this way you are sure the conversion to rgb32 is done by avisynth, that's what I do when using Neat.
And you don't have to create any lossless video before to compress in x264, you can use Neat in your avisynth script (look at Neat's user guide).

[Micheal813]

You can put converttorgb32() instead of ConvertToRGB24(), this way you are sure the conversion to rgb32 is done by avisynth, that's what I do when using Neat.
And you don't have to create any lossless video before to compress in x264, you can use Neat in your avisynth script (look at Neat's user guide).

So going from YUY2 to RGB32 will be just a good as YUY2 to RGB24? I'm trying to keep as few color conversions a possible.

Neat works in RGB24. Is capturing with MagicYUV in YUY2 ----> RGB32 for Neat ---> YV12 for x264 just the same as MagicYUV in YUY2 ---> RGB24 for Neat ---> YV12 for x264?

I'm really just not understanding why it is not being saved as RGB24 when it shows up as RGB24 in Vdub when I add Info() to my script.

I really don't want to bother learning how to use Neat with Avisynth. I'm more comfortable with the Neat GUI in VDub. I convert to x264 with MeGUI or Handbrake.

[kolak]

If you see RGB24 in Source Information this means nothing.
What goes to codec depends on your setting in out section for Color Depth settings:

http://forum.videohelp.com/attachment.php?attachmentid=12456&d=1337168317

If you have it set this way (or RGB32) than MagicYUV should use RGB mode for encoding. MagicYUV may require RGB32, I'm not sure, but you can try.

[Micheal813]

If you see RGB24 in Source Information this means nothing.
What goes to codec depends on your setting in out section for Color Depth settings:

http://forum.videohelp.com/attachment.php?attachmentid=12456&d=1337168317

I have tried that but it still ends up as RGB32 according to VLC Media Player and VDub.

[kolak]

This is fine- I think this is how MagicYUV works. Most likely original data is RGB24, but it's decoded to RGB32 (RGB24+ dummy/empty alpha channel) for better compatibility with apps. Nothing to worry about.

[Music Fan]

I really don't want to bother learning how to use Neat with Avisynth. I'm more comfortable with the Neat GUI in VDub.
I do both :
-I open my script (without Neat function) in Vdub,
-configure Neat,
-save the settings (dnp and nfp files),
-close Vdub,
-add the Neat lines in the script (referring to these dnp and nfp files),
-open the script in the x264 encoder (I use Hybrid).

[djonline]

Still can't use MagicYUV as preview codec format in Adobe Premiere, like described in http://forum.doom9.org/showpost.php?p=1746640&postcount=415
Yes, i see it in vdub

[Ignus2]

Still can't use MagicYUV as preview codec format in Adobe Premiere, like described in http://forum.doom9.org/showpost.php?p=1746640&postcount=415
Yes, i see it in vdub

I'll try to take a look.

[Ignus2]

Still can't use MagicYUV as preview codec format in Adobe Premiere, like described in http://forum.doom9.org/showpost.php?p=1746640&postcount=415
Yes, i see it in vdub

OK, here is the solution:

Open this file with a text editor: c:\Program Files\Adobe\Adobe Premiere Pro CC 2015.3\Settings\EncoderPresets\SequencePreview\9678AF98-A7B7-4bdb-B477-7AC9C8DF4A4E\Microsoft AVI.epr
Search for the line: <PresetComments>...</PresetComments>
For me it looks like this:
<PresetComments>IsConstrained,dsv2,dsvn,dsvp,VUYI,ELRM,CVSM,YVYU,012v,BID,SGAL,2YLU,GRLU,ARLU,g01R,k01R,k01r,yuV2,yuv2,yvyu,DHFC,dsvd,52vd,1hvd,05vd,SEMM,407M,107M,507M,207M,201M,401M,101M,301M</PresetComments>
I think you are getting the clue by now...
Remove the content between those tags, so it looks like this: <PresetComments></PresetComments>

After this, all the VFW codecs should show up.

Now, whether they will work or not, that's a different question. I don't know, and as I haven't got the foggiest at all how to use Premiere, I didn't test, but if you do, please report back your findings.

rant:
Did I mention I LOVE this type of hackery? It's the same madness you have to do for 10bit+ QuickTime codecs to show up in AE. Only this time, it's a hard-coded list in the app directory.
Next time we'll be hex-editing DLLs...
Whoever comes up with these brilliant ideas of hard-coded FCC lists should be awarded something...

Greets,
I.

[Rotareneg]

In Sony Movie Studio (and Vegas) 13, the software can pass frames directly without recompression if they haven't been changed, which can really speed things up. This works fine with the Ut Video codec, but I cannot get this to work with MagicYUV. Are there any particular settings in MagicYUV that I might be able to change to make it work?

[Ignus2]

In Sony Movie Studio (and Vegas) 13, the software can pass frames directly without recompression if they haven't been changed, which can really speed things up. This works fine with the Ut Video codec, but I cannot get this to work with MagicYUV. Are there any particular settings in MagicYUV that I might be able to change to make it work?

Not in particular. I don't know how MS/Vegas does smart rendering so I'm not sure what would be needed to make it work. It would be nice to know what do those programs look at to make the decision to smart render.
Maybe they too have a hard-coded list of fourccs (I wouldn't be surprised) :)

Greets,
I.

[Rotareneg]

Ah, I think I figured out what the problem might be: I'm recording from games using Dxtory, which outputs 32 bit RGB data (RGBA compression is unchecked in MagicYUV) If I re-compress that video as 24 bit RGB smart rendering will work fine in MS. Videos recorded from Dxtory with MagicYUV set to convert to YUV420 won't smart render either.

It would seem MS/Vegas smart rendering does not like it when a codec supports multiple color spaces on the same fourcc. I was able to get MS to spit out a corrupted magicYUV .avi by re-compressing a RGB24 video through MS with MagicYUV converting to YUV420, and then trying to smart render that file. The MagicYUV tray icon will show it's converting RGB24 to RGB while MS is smart rendering the YUV420 video, which crashes anything, including the windows explorer when it trying to build a preview for it.

Here's a link to the corrupted avi, packed in a 7zip archive: https://drive.google.com/file/d/0BzS6i2JCDwdteUJoVFZuTmdkcXM/view?usp=sharing

Beware, it'll crash explorer.exe if it tries to build a thumbnail for the file, it's that messed up!

[Ignus2]

Great, thanks for the info! I might have some ideas here.
Could you also share:
- a sample which is recorded directly with dxtory and refuses to smart render (either compressed RGB or YUV420 or both)
- a recompressed sample of the above which actually smart-renders
That would help a lot, as I could look at what the differences are.

About the crash: yes, as there are mixed frames in the container AVI, the codec barfs. It should check for this at least and either refuse to decode the mixed-up frames or do something about it. So it can be considered a bug also in the codec.

In any case, the next release will have separate fourccs, the current solution is problematic for multiple reasons (the alpha checkbox being one prime example, among others).

Greets,
I.

[Ignus2]

On a side note: Are you the one, who reported the following issues with dxtory?
http://forum.exkode.com/index.php?topic=1793.0
http://forum.exkode.com/index.php?topic=2165.0

In fact, I remember someone writing to me about similar strange issues, and we couldn't track it down. I tried writing to the dxtory devs to look into the issue, but no answer so far.
Were you able to find out the cause?

Greets,
I.

[Rotareneg]

Yes, I was the one who reported that. I can only imagine it's an issue with with Dxtory itself as I've not seen that problem happen when testing MagicYUV or Lagarith with other software.

Here's a 7zip with three videos, one direct from dxtory, one recompressed with msp13, and the final smart rendered from the previous with msp13: https://drive.google.com/open?id=0BzS6i2JCDwdtLWdFT3hBZ19LdzA

[Ignus2]

About Dxtory: Does the issue still persist? Do you still get storage bottleneck? BTW, how did you measure disk queue length and drive active time?

About the videos: Thanks. The immediate difference I see between the Dxtory record and the recompressed video is the global AVI bitmap info header field "biSizeImage".
Hmmm... My guess would be Vegas/MS probably checks this global header of the original video and the newly compressing video, and if it differs in any way, then refuses to smart-render as maybe it thinks the format is not exactly the same.
The funny thing about this value however is that it's not relevant for compressed formats in the GLOBAL AVI header, as each frame has a different size (obviously, each frame is compressed to different sizes, duh). But unfortunately it must have some global value, whatever that is. The codec doesn't care.

The reason it works "sometimes" is that currently I simply pass the raw input value in there. So as Dxtory gives RGB32, this value gets to be: ( width * height * 4 ) in the compressed AVI.
BUT, when an app (like Vegas) begins to smart render, it passes the codec RGB24, so the value gets to be: ( width * height * 3 ) (well, precisely it is round_to_4(width*3)*height, but anyway...).
So now we have a difference in this irrelevant global AVI header field, and my guess is Vegas detects it as difference!
The reason it works in the recompressed case is that the recompressor also passed RGB24 to the codec, so now this irrelevant field ended up being the same that Vegas will produce in the smart rendering case.

So it seems I should set this field to something consistent, so apps like Vegas can smart-render.

Greets,
I.

[Rotareneg]

Yes, the disk usage bug is still present in Dxtory. You can monitor the disk queue length and other similar info in Windows using the resource monitor, accessible through the appropriately named "resource monitor" button in the performance tab of the task manager.

[Ignus2]

I see. I just tried, but I can't reproduce. I have the same value in Resource Monitor "Disk Activity" (the small green block below the process list there) as the bitrate reported by Dxtory, and "Highest Active Time" corresponds accordingly: 7-10% for 32 MB/s.
Do you also have a higher value for "Disk Activity" in MB/s compared to the bitrate reported by Dxtory?

Greets,
I.

[Rotareneg]

Here's two screenshots showing the difference between recording with utvideo:

http://i.imgur.com/4tEtD2a.png

And MagicYUV:

http://i.imgur.com/vNnmqIi.png

When recording utvideo, it was writing about 133 megabytes/sec with a drive activity of about 55%. With MagicYUV it was writing only 111 megabytes/sec, but with a drive activity of 64%.

Now that I've got both those screenshots up next to each other I can see something else odd: when recording utvideo Dxtory had very little read activity, about 700 bytes/sec, but with MagicYUV it was reading around 250000 bytes/sec, a significant difference.

[Ignus2]

Indeed, that Read is abnormal, I can reproduce. It's zero for Ut, but well around 200K for MagicYUV. It also happens for x264vfw and Lagarith.
This very well could be a reason, but I have no idea about the cause yet...

[Ignus2]

OK, I think I tracked it down.
It happens if the codec produces an odd number of bytes as output. If I round up the compressed data to be an even number (pad with a byte when it's odd), the Read is zero.
I'd say this is mildly insane...

Greets,
I.

[Asmodian]

OK, I think I tracked it down.
It happens if the codec produces an odd number of bytes as output. If I round up the compressed data to be an even number (pad with a byte when it's odd), the Read is zero.
I'd say this is mildly insane...

Greets,
I.

I wonder if it is related to sector sizes? If you write less than the sector size to a drive it has to read that data back when writing the next bit of the file because it fills up the partial sector with the new data and can only write complete sectors.

Is there a 4K aligned write buffer in MagicYUV?

[Ignus2]

I wonder if it is related to sector sizes? If you write less than the sector size to a drive it has to read that data back when writing the next bit of the file because it fills up the partial sector with the new data and can only write complete sectors.

Is there a 4K aligned write buffer in MagicYUV?

The destination buffer is given by the application using the codec (which is large enough for the worst case), the codec simply writes there the compressed data and specifies how many useful bytes have been written to that buffer.
And it still wouldn't explain why only odd sizes are affected, and a single byte of padding (to be even) fixes it.

So what I think might happening instead, is that AVI chunks must be padded to a 2 byte boundary, and Dxtory probably has something like:
write(compressed_data, compressed_size)
if compressed_size is odd:
write(0,1) // write a single byte

So I assume it makes a separate write call to pad with that 1 byte, which could cause the read-back you describe.

EDIT: This also explains the 200K read-back, as at 60 FPS you write 60 AVI frame chunks, and if you have all buffers odd that would be 60 * 4k = 240k. For me it fluctuates between 120k-240k, as some buffers end up being even.

Greets,
I.

[Ignus2]

1.2rev1 is out which includes the workaround, and it seems to fix the disk activity issue with Dxtory.

It also has some changes which might help with smart-rendering. It needs testing though, so if someone (or you Rotareneg) can check that out that'd be very helpful.

Big kudos to Rotareneg for pointing in the right direction to nail down the issue!

Greets,
I.

[Rotareneg]

The smart rendering works in Movie Studio 13 Platinum now, with a few catches. If you render an RGB video to YUV420 or 422 it properly re-renders all frames, but if you render to YUV444 it smart renders it and you get a video that's blank but has the file size of a proper video. If you render a YUV420 video with MagicYUV set to compress as-is it also creates a blank video that's still full sized. If you set MagicYUV's "Mode (conversion)" setting to YUV420 it will properly smart render a valid video. Here are the YUV420 files if you want to take a look at 'em: https://drive.google.com/open?id=0BzS6i2JCDwdtNXYwMW5SWWdqb3c

I wouldn't be surprised if these odd behaviors are just MS13 being a bit buggy, in normal use everything's working great now, many thanks! :)

[Ignus2]

Thanks. Looking at it "Untitled_420.avi" and "Untitled_420_convert_to_420.avi" are identical, and they are correct.

However "Untitled_420_compress_as_is.avi" in it's global AVI header indicates that it is compressed RGB, however it contains compressed YUV420 frames. This is why it turns out blank, as the codec now checks this and errors out (instead of crashing, as it did before).
The reason it's RGB in the global header is that MS can only send RGB frames for compression, so the resulting video gets compressed "as-is", as RGB, BUT, being "smart"-rendered, the original YUV420 frames are simply copied, hence you get a discrepancy between the global header (RGB) and the actual frames (YUV420).

Now, MS cannot seem to detect that the compressed output will be different than the input, as it only checks a few parameters, which seem to be:
- frame size (width, height)
- codec fourcc
- bit count

The problem is those values are the same for both compressed RGB and compressed YUV420:
- codec fourcc: MAGY
- bit count: 24

MagicYUV, and as I've seen with other codecs as well, bit count is set to 24 for non-alpha and 32 for alpha compressed formats. I'm reluctant to modify this, as it might break other apps expecting it to be this way.

Having separate fourccs for the different compressed color space/subsampling variations could help further with smart-rendering (which 1.3 will have), but not fully, as even in this case, the various other differences in codec settings (full-range/limited-range YUV, color matrix, etc.) would not be detected (MS cannot reliably check for these), making the resulting compressed file broken.

Conclusion:
So as it stands now, smart-rendering is a slippery terrain, it can work, but you have to know exactly ALL the parameters the input file was encoded with, and absolutely make sure that the new compression settings match those exactly.

Greets,
I.

[Sparktank]

:thanks: Had just enough to buy the Ultimate version (after currency exchange). Thanks!

[Ignus2]

:thanks: Had just enough to buy the Ultimate version (after currency exchange). Thanks!

Yeah, I saw, thank you very much! :thanks:
BTW, you can get over to the MagicYUV forums if you wish, I'd like to know how do you make use of the codec (especially the 10bit+ variants).

Greets,
I.

[De-M-oN]

I never knew that Median is the best method for game capture. Thank you for the much better quickinfo text and its really awesome that you even consider game capture at codec development and giving us even tips for best settings to do it (the median compression tip was very good it works indeed very fast and more smooth than dynamic. Thank you!)

Predict Left is gone as a setting or fully gone? I dont miss it. I'm just interested what happened to this.

maybe you can try to add a mode for maximum compression in the region like Lagarith has? Lagarith has an insane good compression and I think that your codec may be faster than lagarith, especially because lagarith' last update was some years ago and I would assume that it doesnt support AVX instruction and so on.
Sometimes maximum compression can be useful. :) This time I mean in general, not as game capture. There I'll stay at median of course.