MagicYUV - a new fast lossless video codec

[EncodedMango]

The biggest downside I'm finding is support for the codec for example ffmpeg doesn't recognise it. So since usually I record RGB I just convert it to Lagarith and then go about encoding to my needs, I wanted to try YUV 4:4:4 but I can't since ffmpeg won't recognise MAGY and Lagarith doesn't have YV24 but otherwise it's a pretty fast codec.

Are you planning to ever release the source, Ignus2?
If not I guess I'll have to find another lossless codec that can convert MAGY's YUV 4:4:4 to usable YV24.

[zerowalker]

I am not entirely sure this is correct but.

UT Video Codec should be closed source, and ffmpeg has made a decoding version of it as well?
They will probably make MAGY alone or with the authors help, sooner or later.

Though i am interested in if you would release the source, but i guess that's a bit sensitive as you are the maker, and releasing it could be quite controversial in a sense,
so i at the end of the day, as long as it continues to work in all it's glory, i am happy

[EncodedMango]

I hope they do, just asked about source because if it does happen then as far as I'm aware someone could submit the codec to ffmpeg that way. I don't know the specifics but I remember glancing over it in the ffmpeg site somewhere.

[vivan]

Originally Posted by zerowalker

UT Video Codec should be closed source

Why?
It's open source, and released under gpl v2.

[zerowalker]

It is?
Was sure it was closes source and release only by the author, need to check on that.
Then my conclusion is invalid.

[Sparktank]

Originally Posted by zerowalker

need to check on that.

You can download the source for each version from his site.
http://umezawa.dyndns.info/archive/utvideo/

[Ignus2]

Originally Posted by sidspyker

The biggest downside I'm finding is support for the codec for example ffmpeg doesn't recognise it. So since usually I record RGB I just convert it to Lagarith and then go about encoding to my needs, I wanted to try YUV 4:4:4 but I can't since ffmpeg won't recognise MAGY and Lagarith doesn't have YV24 but otherwise it's a pretty fast codec.

Are you planning to ever release the source, Ignus2?
If not I guess I'll have to find another lossless codec that can convert MAGY's YUV 4:4:4 to usable YV24.

Not in the near future. I've prepared an SDK though (binary only) which can be used to integrate the codec into whatever software one wishes, though it's not released as of yet.

Greets,
I.

[Ignus2]

The 1.0rc4 version of the codec is out. This should be the last release before 1.0 final, and if all goes well (no new bugs are reported), this will become the final 1.0 release.

This release fixes a serious decoder bug which could cause random crashes during decoding. It works for all previously encoded files.
Decoder performance was improved by 8-10% overall (mainly for 64-bit).
Memory handling was also improved, the codec now uses much less memory.

Grab the release from the website: http://magicyuv.com

Greets,
I.

[StainlessS]

Many Thanks.

[Gargamel]

Congratulations, and thank you again Ignus2 !

[zerowalker]

Nice, never had any crash issues as i recall. But then again have not used it that much i guess.
But it's really one of the top choices, only time i don't use it would be when Lagarith thrives, which are for certain content.

But even faster decoding, 8-10% is great.
How come it's mainly in 64bit. was 64bit slower than 32bit?

Also less memory usage is a good bonus optimization.

Well Done!

[Videogamer555]

Please add an uncompressed raw mode as well as your lossless compression mode to your codec. I need to generate some raw YUV444 frames for a specific application I'm working on. The simplest way to do so is to use the IPImageCompress API function in my program. Unfortunately this function requires that I have a codec installed for encoding in YUV. Windows comes with a YUV420 encoder only (though it comes with decoders for other YUV formats). As such, I spend hours, looking for a YUV codec that I could install that would enable me to save YUV444 frames. In my search, I finally ran across MagicYUV. Sadly, it only is capable of saving losslessly compressed YUV frames. For many video applications, lossless compression is better than raw because it saves file space, while preserving the video data that would be lost in a lossy compression. However my application specifically requires raw YUV444 frames. As such, I need to ask you to include a "full raw" mode in the next release of your codec (a mode that would allow directly outputting raw YUV 444, 422, 420, or 400 Luma grayscale frames), so that I can complete the program I'm writing.

I don't think any other codec exists that can do what I want, and yours comes closer than any to being what I need. However as my project calls for raw YUV frames, I am going to ask you to include that in your codec's next release as a settable option from your codec's control panel.

[raffriff42]

Originally Posted by Videogamer555

I need to generate some raw YUV444 frames for a specific application I'm working on....
I don't think any other codec exists that can do what I want...

I can think of one way to generate such a video, with VirtualDub:

• Set output color depth to '4:4:4 planar'.
• Set video codec to 'uncompressed'
• The resulting video is 'rawvideo YV24' per ffprobe.

EDIT
VirtualDub's internal 'uncompressed' codec is not available for other applications, so while my suggestion does generate 'raw YUV444 frames', it doesn't meet your desire for a codec, as pointed out by Ignus2 below. And of course, ffmpeg offers another way to create such a file.

[Ignus2]

Originally Posted by Videogamer555

Please add an uncompressed raw mode as well as your lossless compression mode to your codec. I need to generate some raw YUV444 frames for a specific application I'm working on. The simplest way to do so is to use the IPImageCompress API function in my program. Unfortunately this function requires that I have a codec installed for encoding in YUV. Windows comes with a YUV420 encoder only (though it comes with decoders for other YUV formats). As such, I spend hours, looking for a YUV codec that I could install that would enable me to save YUV444 frames. In my search, I finally ran across MagicYUV. Sadly, it only is capable of saving losslessly compressed YUV frames. For many video applications, lossless compression is better than raw because it saves file space, while preserving the video data that would be lost in a lossy compression. However my application specifically requires raw YUV444 frames. As such, I need to ask you to include a "full raw" mode in the next release of your codec (a mode that would allow directly outputting raw YUV 444, 422, 420, or 400 Luma grayscale frames), so that I can complete the program I'm writing.

I don't think any other codec exists that can do what I want, and yours comes closer than any to being what I need. However as my project calls for raw YUV frames, I am going to ask you to include that in your codec's next release as a settable option from your codec's control panel.

I'm not entirely sure I understand, but basically you need an RGB to YUV converter "codec"? I wouldn't include this kind of functionality in the codec, it's a bit out of scope.
The solution by raffriff42 should be fine, except if you have to do this conversion in your program.

Greets,
I.

[zerowalker]

Hmm, is there a reason why MagicYUV is not available as a filter with 64bit (GraphStudio-Next for example)?

[Ignus2]

Originally Posted by zerowalker

Hmm, is there a reason why MagicYUV is not available as a filter with 64bit (GraphStudio-Next for example)?

Yes, it is currently implemented only as a VFW codec, not a DShow filter. It can join filter graphs however with the AVI Compressor and AVI Decompressor wrapper filters.
It is planned to implement it for DShow too, but it's not high priority (will come probably sometime after 1.0 final).

Greets,
I.

[zerowalker]

Ah okay, didn't know they were different (not that good at this stuff). But that explains it, good that the wrappers can be used as alternatives.

Thanks

[De-M-oN]

Agree, MagicYUV is doing extremely well, it's competing at UT Video Codec

its actually way faster than utvideo.
And thats quite impressive with its compression efficiency.


This codec gives me goddamn awesome fps rates when recording with Afterburner games.
I have a RAID 0 which can write 352 mbyte/s

This codec is able to write in 2560x1600 50fps, RGB with dynamic compression and NO lags at all, an awesome compression efficiency which makes me really wonder about the performance still being even faster than utvideo.

Thats outstanding. Awesome codec which performs hellish fast at recording games while having an excellent compression.

Thank you !

I have this problem though:

http://forums.guru3d.com/showpost.ph...postcount=1847

I don't know what could disturb Afterburner here..

[Ignus2]

Originally Posted by De-M-oN

its actually way faster than utvideo.
And thats quite impressive with its compression efficiency.

This codec gives me goddamn awesome fps rates when recording with Afterburner games.
I have a RAID 0 which can write 352 mbyte/s

This codec is able to write in 2560x1600 50fps, RGB with dynamic compression and NO lags at all, an awesome compression efficiency which makes me really wonder about the performance still being even faster than utvideo.

Thats outstanding. Awesome codec which performs hellish fast at recording games while having an excellent compression.

Thank you !

Thanks, that's great to hear
Though decoding performance should be what the codec excels the most, but I'm glad to hear that encoding also performs well

Originally Posted by De-M-oN

I have this problem though:

http://forums.guru3d.com/showpost.ph...postcount=1847

I don't know what could disturb Afterburner here..

I'll take a look at it, thanks for reporting.

Greets,
I.

[Ignus2]

Originally Posted by De-M-oN

I have this problem though:

http://forums.guru3d.com/showpost.ph...postcount=1847

I don't know what could disturb Afterburner here..

I seem to have tracked it down. I will try not to be too technical, but the issue is caused by Afterburner initializing/deinitializing the codec just at the same time while loading/unloading the codec DLL (so the OS has the DLL loader lock), and this causes a deadlock inside the codec while it is initializing it's worker threads. (Or at least that is what I think is happening.)
Most probably Afterburner doesn't close the codec properly.

I consider this to be a bug inside Afterburner, and the fix would involve Afterburner to open/close the codec separately from loading/freeing the codec DLL. (Or at least properly close it.)
Though it might be worked around in the codec itself (which might introduce other bugs), but this would force me to make yet another Release Candidate :-/ (as I have the policy of making the final 1.0 release directly from an RC).
I'll think about it...

Thanks for the report BTW!

Greets,
I.