MagicYUV - a new fast lossless video codec

[LexSfX]

Obviously, hence the phrasing of "Why not[...]?".

[WorBry]

@Ignus2

Originally Posted by richardpl

But that contradicts current payware policy.

So let me get this right. Just over a year ago I made a donation when updating to v1.2 to 'support development':

https://forum.doom9.org/showthread.p...91#post1748491

And now I'd have to pay a fee just to update to v2.0 (standard) ?

https://www.magicyuv.com/

I would have thought that those who made a donation before this pricing was introduced at least would be honoured with a free update to v2.0.

[Ignus2]

Originally Posted by WorBry

@Ignus2
I would have thought that those who made a donation before this pricing was introduced at least would be honoured with a free update to v2.0.

They were. Everyone who made a donation, even 0.99c, got a free upgrade to 2.0. They all received an email in December about it. If you donated, that includes you. Maybe check your spam folder, or tell me the email address you used for the donation and I can resend the email.

Greets,
I.

[WorBry]

Yes, I've found it there in the spam folder. My apologies

[hajj_3]

UT 17.4.0 is out now, you should update the benchmarks on your site comparing MagicYUV to UT v17.4.0.

[mcjordan]

Dear Ignus, I've a donation for your Magic ;-) from december, 16 (my e-mail: mcjordan@abv.bg) How to get update to version 2.0 RC2?
P.S. Your automail sender never give me a password or password form for forum registration (may be some wrong with my mail provider?)

[Ignus2]

Originally Posted by mcjordan

Dear Ignus, I've a donation for your Magic ;-) from december, 16 (my e-mail: mcjordan@abv.bg) How to get update to version 2.0 RC2?
P.S. Your automail sender never give me a password or password form for forum registration (may be some wrong with my mail provider?)

Hmmm, that is strange. Anyway, I saw your registration, will write an email to you shortly.

Greets,
I.

[mcjordan]

Thank you very much Ignus, I received your email.

[dipje]

Came around to testing 2.0rc2, but I had to revert back to 2.0rc1.

Files saved through Virtualdub VDFilterMod to avi (with 4:2:2 10bit and RGB 10bit, so M0Y2 and M0RG) opened fine when I loaded them back into VDFiltermod, but no matter what I tried I couldn't get them to work in After Effects. It would jus always show a black frame. When trying to play the files in Quicktime Player they would work sometimes, but they would also crash Quicktime a lot.
Recent VDFilterMod versions have an option to save directly to .mov, that way I can skip the 'remux avi to mov with ffmpeg' step. But the .mov files saved by VDFilterMod would or show black frame, _or_ trigger After Effects in saying the .mov was corrupt.

Closing any Quicktime and Adobe processes, reverting back to 2.01rc1 and suddenly the M0RG codec works just fine again in After Effects. I can load a RGB48 .vpy file in VDFilterMod, select XRGB64 as decode format and as format delivered to the compressor, select MayivYUV 10 bit RGB, and save to .mov. That .mov opens fine in After Effects as 'trillions of colours'.

Also, _encoding_ from After Effects failed with the rc2 version, but works fine with rc1.

Of course, the YUV variant (M0Y2) is not behaving well in After Effects, but that has always been the case (After Effects and YUV just don't mix, kind of understandable).

[Ignus2]

Originally Posted by dipje

Came around to testing 2.0rc2, but I had to revert back to 2.0rc1.

Files saved through Virtualdub VDFilterMod to avi (with 4:2:2 10bit and RGB 10bit, so M0Y2 and M0RG) opened fine when I loaded them back into VDFiltermod, but no matter what I tried I couldn't get them to work in After Effects. It would jus always show a black frame. When trying to play the files in Quicktime Player they would work sometimes, but they would also crash Quicktime a lot.
Recent VDFilterMod versions have an option to save directly to .mov, that way I can skip the 'remux avi to mov with ffmpeg' step. But the .mov files saved by VDFilterMod would or show black frame, _or_ trigger After Effects in saying the .mov was corrupt.

Closing any Quicktime and Adobe processes, reverting back to 2.01rc1 and suddenly the M0RG codec works just fine again in After Effects. I can load a RGB48 .vpy file in VDFilterMod, select XRGB64 as decode format and as format delivered to the compressor, select MayivYUV 10 bit RGB, and save to .mov. That .mov opens fine in After Effects as 'trillions of colours'.

Also, _encoding_ from After Effects failed with the rc2 version, but works fine with rc1.

Of course, the YUV variant (M0Y2) is not behaving well in After Effects, but that has always been the case (After Effects and YUV just don't mix, kind of understandable).

This is odd, but thanks for the report! I'll try to check it out, but there really shouldn't be such issues, there isn't any fundamental change since 2.0rc1, except being more robust when decoding corrupt data.
I believe you do have the AE QTCodecRules XML modified, correct?

Greets,
I.

[dipje]

Yes. But in a working setup with .rc1 so shouldn't be any difference.

I'll try on my other PC just to be sure. Any tips or pointers to help debugging or figuring out what's wrong ?

Maybe something changed in AE, not impossible of course.

[dipje]

Hmm.. maybe, 'nevermind'. I don't really know.

I can load a b64a .avi file into After Effects (neatly detected as trillions of colours+), and from AE save it to MagicYUV 10bit RGB in .mov. File loads again just as fine (and yes, still detected as trillions...).
If I then install rc2 this still works, so with that part of the quicktime codec -> nothing wrong.


But if I open that b64a .avi file into VDFilterMod and from there encode an .mov with MagicYUV 10bit RGB, that file won't open correctly in AE. Sometimes it shows just black frames, sometimes it gives errors parsing / reading the .mov. Since the .mov writing of VDFilterMod is somewhat new (and probably 'hacky'), this is nothing to worry about.

But if I save an .avi with MagicYUV 10bit RGB and then remux that .avi into .mov with ffmpeg, that file also won't load anymore and will give the same black frames. I'm pretty sure this worked before.
But to be honest, now that I'm thinking about, that is an .avi file created with newer builds of VDFilterMod and it's remuxed now with newer builds of ffmpeg, so god knows what changed in those that might break it.

Loading (virtual) b64a AVI into AE and encoding and decoding from there still works, and I guess that's the most important for me.


But mounting a simple Vapoursynth script (that reads a file and outputs it as b64a / RGB48) as a virtual AVI file and then encoding it from within AE takes 2 minutes. That same Vapoursynth script encoded to MagicYUV through VDFilterMod (and I'm guessing the VfW codecs) is done in just under 30 seconds. So quite a speed difference. But I guess I have to deal with that .

[shekh]

That is sad. Writing mov function is basically ffmpeg remuxing plugged in.
As I understood: ffmpeg.exe cannot remux avi to mov correctly when codec is rc2? Is the avi in turn correct?
Any idea for simpler way to detect corrupt avi/mov other than import it to AE?

[kolak]

I don't think AE will work well with AVI for codecs with require decoding to something different than RGB 8bit.
Use MOV with edited xml file rules.

[dipje]

@kolak
You keep saying that, and I keep saying that
a) that's impossible, there is no 'virtual MOV' or anything to frameserve something into deep-colour mov, and
b) it's working fine with b64a AVI files

@sekh
remuxing with ffmpeg seemed to work before, and since your recent builds basically use the same stuff and the same ffmpeg (libavcodec/libavformat) as base it's understandable they create the same output .

I don't think this has _anything_ to do with .rc1 or .rc2 of MagicYUV. I think ffmpeg changed it's .mov wrappiong or something that causes this to stop working.
Like I said, the .avi files created by VDFilterMod with .rc2 seem to work fine when opening them in ffmpeg or back into VDFilterMod (or into Vapoursynth with their AVISource)

Only .movs that AE seems to open are the ones created by the QuicktimePlayer or by AE itself .

Just as a test, the prores_ks codec from ffmpeg wrapped into .mov seems to open just fine like it always did, and I even think your prores encoder UI in the newer VDFilterMod builds work fine.

Something changed with the whole 'remuxing VfW codecs into .mov' in ffmpeg it seems. Not sure though.

[Ignus2]

Actually, if you encode to MOV with rc1 and rc2 (using the same version of VDFM) you should get exactly the same output, could you check if this is the case?

Regarding AE reading MOVs: I had some interesting results with MOVs saved by BlackMagic Fusion and imported into AE. Even with modified XML, the MOVs saved by Fusion were not always interpreted correctly by AE. ALSO: AE seems to remember something about files it opened once, so if you save a file with the same filename/path that AE once opened before, then it'll most likely mess up loading it again if something changed in it. This was very weird. Please read through this thread: https://www.magicyuv.com/community/h...oding/#post-38

Also, AE might put some extra metadata into MOVs. But one thing is for sure: for AE to load MagicYUV 10bit+ RGB correctly as "Trillions of colors" you must modify the XML codec rules, and rename the file if it was once opened by AE!

Greets,
I.

[dipje]

Like I said, in and out from AE work fine. Yes, it required modifying the XML file but that is somehow expected.

I can recheck the rc1/rc2 output again, but when I did an encode with each from AE I can confirm they are exactly the same size to the byte. Didn't actually compare the contents byte for byte .

I think I messed up when I tried rc2 for the first time that I had 'millions of colors' selected when exporting from AE, and then MagicYUV borks because it receives 8bit input for an 10bit codec. Retrying with 'trillions' and rc2 exports fine.
Files exported that way open up fine in recent ffmpeg builds, and also ffms2 / ffms2000 in vapoursynth.

The only thing that doesn't work anymore is remuxing MagicYUV avi to MagicYUV mov and I think that has nothing to do with rc1/rc2 but with changes in the last months or so to ffmpeg.

edit: and about the 'AE remembers something about the file opened' I say the same as a few months before: If you want to make sure the file is properly 'reread', go to the 'edit' menu where you have the option to 'purge' the ram and disk media cache. If you made changes to the Quicktime XML file, make sure that the Qt32 stub-process is killed (and restarted) to the file is actually reread. Working like this, I _never_ had the experience that 'settings' are saved for a filename. Still a pain to have to remember though .

AE / Premiere are the only 'pro' tools I have experience with (well, and Davinci but never tried to export anything different than DPX-sequence or DNXHR from Davinci Resolve) so can't talk about fusion <=> AE.
Converting a b64a AVI through the Quicktime Player to MagicYUV 10bit / 12bit RGB both work fine though.

[hajj_3]

MagicYUV 2.0.0 is out now: https://www.magicyuv.com/change-log/

[Stereodude]

Any chance for YUV420P10 support? There's no option for 10-bit YUV 4:2:0 with MagicYUV 2.0. There is 10-bit VUY 4:2:2, but that option won't accept 4:2:0.

[Ignus2]

Originally Posted by Stereodude

Any chance for YUV420P10 support? There's no option for 10-bit YUV 4:2:0 with MagicYUV 2.0. There is 10-bit VUY 4:2:2, but that option won't accept 4:2:0.

Actually, it's been done for a while in the betas (not released yet), I'll make a release shortly.

I.