MagicYUV - a new fast lossless video codec

[Ghostlamer]

Ignus2, could you add an option, something like this "forced decoding YUV 4.0.0, 4:2:0, 4:2:2, 4:4:4 as RGB".
There are non-linear video editors that support YUV 4.0.0, 4:2:0, 4:2:2, but convert it to rgb(on the fly), do it not very correctly, resulting in slightly incorrect brightness and color output.
Converting videos to RGB, takes up more space and time.
Forced codec decoding in RGB, in most cases will work around this problem.
Input will be RGB, and the editors will not make any color conversions.
But make it disabled by default.
Thanks.

[Ignus2]

Originally Posted by Ghostlamer

Ignus2, could you add an option, something like this "forced decoding YUV 4.0.0, 4:2:0, 4:2:2, 4:4:4 as RGB".
There are non-linear video editors that support YUV 4.0.0, 4:2:0, 4:2:2, but convert it to rgb(on the fly), do it not very correctly, resulting in slightly incorrect brightness and color output.
Converting videos to RGB, takes up more space and time.
Forced codec decoding in RGB, in most cases will work around this problem.
Input will be RGB, and the editors will not make any color conversions.
But make it disabled by default.
Thanks.

So instead of the NLE software, you want the codec to do the conversion, always? The reason being NLE software do it incorrectly?

So this means, you want to be able to disable decompressing into native format. Or something like "Always suggest RGB when decoding"?

So if I understand correctly, you want to store material compressed always as YUV 4:x:x but edit it in RGB?

Greets,
I.

[zerowalker]

Isn't this already available since you added the "Avisynth Fix"?

[Ghostlamer]

So instead of the NLE software, you want the codec to do the conversion, always?
So this means, you want to be able to disable decompressing into native format. Or something like "Always suggest RGB when decoding"?
So if I understand correctly, you want to store material compressed always as YUV 4:x:x but edit it in RGB?

Yes, that's right.
To force the output was always RGB.
Just most nonlinear editors make conversion from YUV 4:x:x to RGB in realtime(even when the codec RGB options enabled), if the source is not the RGB.
And do it in different ways, some better some worse..

[Ignus2]

Originally Posted by zerowalker

Isn't this already available since you added the "Avisynth Fix"?

No, as it currently prevents upsampling only, but you cannot disable decoding to native format of what was compressed (i.e. cannot prevent lossless decompression without conversion).

What Ghostlamer needs is the opposite: to prevent decoding into native format and allow only upsampling/conversion.

Whether this scenario makes sense for a lossless codec is another question

Greets,
I.

[Ghostlamer]

Certainly at the codec level it will be more correct than in the editors.

What Ghostlamer needs is the opposite: to prevent decoding into native format and allow only upsampling/conversion.

Make it optional.

Сurrent decoding options:
For player - 1, 2.
Video editing software (Magix Video Pro X6) - useless.

[Ignus2]

Originally Posted by Ghostlamer

Certainly at the codec level it will be more correct than in the editors.


Make it optional.

Сurrent decoding options:
For player - 1, 2. http://simplest-image-hosting.net/
Video editing software - useless.

It would be quite funny making it non-optional, that would basically defeat the purpose of the codec

The Decompression settings currently refer to conversions only, so decoding to the native format (ex. to YV12 from compressed 4:2:0) is currently always possible.

Maybe I'll add the settings to the next release.

Greets,
I.

[Ghostlamer]

Maybe I'll add the settings to the next release.

Thanks.

[WorBry]

Hey Ignus,

It's been a while since I tested Magic-YUV, not since those early tests with your pre-release versions in fact. But I'm happy to report that version 1.0rc2 now works very well with my AVCHD and HDV camcorder clips in the NLE I use - Corel VideoStudio Pro x6.

VSPx6 is still only 32-bit and performs edit transformations in RGB colorspace. As such, any compatible third party vfw codecs need to be able to convert from and to RGB. It's pretty useless for 'native editing' of AVCHD and HDV, but the 'smart rendering' feature works well with intra-frame intermediate formats and the program has very good MT process support.

My current practice is to pre-transcode the source clips to the intermediate format via AVISynth using a suitable frame-indexing decoder (DGIndex/Dec for HDV MPEG-2 and now DGIndex/DecIM for AVCHD). VDub is set for Fast Recompress so Magic YUV should be receiving YV12 input anyway, but as a precaution (perhaps unnecessary) I've configured Magic YUV with the Input Colorspace set to YUV 4:2:0 and the Mode Conversion set likewise.

The transcodes look fine and play very well. UTVideo is also fast, but playing the files in MPC-HC, there's always a bit of stutter and unresolved offset delay. The Magic YUV encodes play very smoothly and the initial sync delay resolves very quickly. I haven't done any repeat comparative metric testing with this version but the fast decompress rate definitely shows.

So, then I load the Magic YUV (avi) encodes in VSPx6 and set the edit Project to use Magic YUV as the timeline format. You might re-call that when I tried to do this with the pre-release versions, VSPx6 always crashed and would only work if I installed an intermediary transform codec like the YUVFilters pack. Now, no such problems provided the Magic YUV input colorspace is set to Auto or RGB. Set to anything else and VSPx6 complains for lack of a suitable compressor. I have the Mode (conversion) set to YUV 4:2:0.

So configured, the Magic YUV encodes edit very smoothly on my PC at least (6-core AMD FX600 CPU) and it looks like the 'smart rendering' is working fine i.e. when set to render out in the same format as the Project (or the format of the 'first clip') it only re-encodes those frames affected by an an applied edit effect/transform and copies the unaffected frames. Unfortunately there's no 'Smart Render' analysis feature to show that definitely, but it looks to be the case just looking at the rendering progress bar.

All in all, very impressive. I'd been using UTVideo or Cineform until now (each have their pros/cons), but I could see myself using Magic YUV; I assume it's bug free?

So, great work, and no doubt assisted by the valuable feedback of those who could contribute more useful insight and advice than I.

Cheers

[Gravitator]

Hi!
Can we expect a higher compression? Or two passes > sample

[zerowalker]

Originally Posted by Gravitator

Hi!
Can we expect a higher compression? Or two passes > sample

higher compression can most likely be made one way or the other while keeping the performance. It would probably be quite minimal though as the huge optimizations has probably been made already.

2 passes is probably not something for this kind of codec, which is made for speed in both encoding and decoding (especially decoding), and i think the increase in compression efficiency is probably not worth it during these kind of works.

I personally however, would probably want it if it can decrease the size by at least 5%, while keeping the same decoding speed.

(The author is most likely to correct if i have said anything that's incorrect here).

[kolak]

I think you are correct- any compression improvements while keeping speed will be in region 5, best 10%. Quite often this is a huge effort and all what you get is this 5%. I think magyuv is really good with speed ratio/compression.

[zerowalker]

Originally Posted by kolak

I think you are correct- any compression improvements while keeping speed will be in region 5, best 10%. Quite often this is a huge effort and all what you get is this 5%. I think magyuv is really good with speed ratio/compression.

Agree, MagicYUV is doing extremely well, it's competing at UT Video Codec, it's in the middle of the compression choices of the 2 settings (compress for decoding/size or something like that).

Which in itself is very nice, and clearly acceptable in lossless format sizes.

Decoding speed is in a different league, it's extremely fast, especially in cases were it usually is slower (much noise,grain etc).

I don't really see any "Real" reason for it to be smaller, faster is another story, there isn't a thing as too fast, but it's currently clearly enough for what it's supposed to do.


However if you need more speed, the author has shown interest in AMD Kaveri, which is a hybrid CPU and GPU, which could increase the performance, as it decreases overhead and such, how much however is another story, and we will have to wait till/if he decides to do this work.

[Ignus2]

Sorry for being absent, I have been busy with personal matters.

In the meantime, MagicYUV 1.0rc3 is out: Link.

This release includes:

• Option to suggest RGB first on output when decoding in the Decompression Settings (as requested by Ghostlamer).
• Fix for RGBA encoding which was completely broken. An option was added to the encoder dialog, see the tooltip on how to use it.
• Fix for a very rare crash-bug when decoding. Newly encoded videos will have it fixed.
• Support for some new fourccs (2vuy, HDYC, IYUV).

@WorBry Thanks and sorry for the late answer. Nice to hear that the codec finally works with the software you use All insights and testing is welcome. I really missed RGBA testing though, I accidentally found someone having problems on a German forum, and I only began investigating after that.

@Gravitator Not in the near future. It is hard to improve compression ratio without slowing down the codec, especially if we want to keep it intra-only (making it inter is also non-trivial). So for the foreseeable future, it will remain as it is.

Greets,
I.

[zerowalker]

Fix for a very rare crash-bug. Newly encoded videos will have it fixed.

Could you please explain this?

Does videos that are previously encoded contain a bug which causes or crash when decoded or what;S?

[Ignus2]

Originally Posted by zerowalker

Could you please explain this?

Does videos that are previously encoded contain a bug which causes or crash when decoded or what;S?

Basically yes, it MIGHT happen. Actually, it was there since the launch of the codec since February (and even years before, ever since the codec started to take shape), but even I encountered it only once so far with a combination of software AND material (YUV with alpha format converted to RGBA).

So chances are low.

Greets,
I.

[zerowalker]

Okay so i don't have to worry about my current files having a chance of being corrupt?
It's basically, a crash MAY occur if conditions are met, but at the same time if you redo it, it may not crash? (Or is it constant?).

And well what i have is simply YV12 YV16/YUY2 YV24 or RGB, have no memory of ever using YUV with Alpha, didn't even know it had that option.

[Ignus2]

Originally Posted by zerowalker

Okay so i don't have to worry about my current files having a chance of being corrupt?
It's basically, a crash MAY occur if conditions are met, but at the same time if you redo it, it may not crash? (Or is it constant?).

And well what i have is simply YV12 YV16/YUY2 YV24 or RGB, have no memory of ever using YUV with Alpha, didn't even know it had that option.

It's constant, not sporadic. For example, I had it happen for one specific frame of one specific file in a specific format with After Effects, while VDub and Media Player Classic and all my test tools were fine with the same file.

Furthermore, some clarification: Any file encoded with any release before 1.0 final is reached should be considered corrupt in one way or another, not specifically because of this bug but because it is beta software and as such, bugs may be present, even ones that I'm not aware of. This is a general thing for all software not being reached 1.0 stable status.

Anyway, if your files open now correctly in VDub, why worry?

Greets,
I.

[zerowalker]

Okay that explains it

Thanks

[WorBry]

Originally Posted by Ignus2

@WorBry Thanks and sorry for the late answer.

No problem