MagicYUV - a new fast lossless video codec

[Ignus2]

Ah, don't get it fully, but think i at least follow the idea;P

How is Rec.2020 then, some kind of killer or pretty much the same, And will support be added for it in MagicYUV?
I know it doesn't exist a real interest except experimentation and enthusiasm, but still it never hurts to be on the edge of things, especially since it aims to be the "4K Lossless era Codec":)

Rec.2020 is 10-12 bit AFAIK. Though the Rec.2020 RGB coefficients could be used to convert RGB 8 bit to YUV 8 bit, but I don't know if it would have any meaning.

Greets,
I.

[zerowalker]

Oh, well that really turns of the heat. If it's meant for that i guess using it for 8bit will just cause rounding errors or something, would be quite interesting to see though.

[zerowalker]

There seem to be a bug i have encountered.

When i have YV12 content i save it with MagicYUV, it will be saved as YV24 or YUY2, or at least decoded that way in Avisynth,
Avisource = YV24, DirectShowSource = YUY2.

My settings are - As Is, so no internal conversion should be done, input-output should be the same.

Is it supposed to be like that, am i missing out something, or is this a bug?

[Ignus2]

There seem to be a bug i have encountere.

When i have YV12 content i save it with MagicYUV, it will be saved as YV24 or YUY2, or at least decoded that way in Avisynth,
Avisource = YV24, DirectShowSource = YUY2.

My settings are - As Is, so no internal conversion should be done, input-output should be the same.

Is it supposed to be like that, am i missing out something, or is this a bug?

Upscaling during compression (and downscaling during decompression) is not supported, so if the source is really YV12, it is definitely encoded like that.
However, YV12 can be decoded as both YUY2 and YV24 if explicitly requested. By default the codec will report YV12 though.
To make sure you really encoded YV12, set Input Colorspace (restrict) to YV12.
If you really encoded YV12 but get something else, that means, that something converts or requests upscaled formats explicitly.
Try the pixel_type option of AviSource and see if it helps. (Ntote: downscaling will not happen, as downscaling during decompression is not supported by the codec.)

Greets,
I.

[zerowalker]

Well that's good to hear.
I used Virtualdub Fast Recompression and made sure that it does not do any conversion, meaning MagicYUV get's feeded YV12 in this case.

I know you can restrict, but would prefer not to, as it should work anyway, but of course a safety mechanism isn't wrong.

Actually did that, and it seems to work, pretty sure i tried that before on another clip, and it reported something like "Decoder can't give that format" or something, but this time it worked.

Problem is though, if i want to feed this clip to, let's say x264, it would normally get decoded to YV24/YUY2 and then downsampled to YV12 again, unless i force the Pixel_type.

How come it doesn't decode it correct automatically?

Also, in Mediainfo there is no way to find out what pixel type it is, which is quite troublesome, as i can't figure out afterwards what the true format is, unless i know it of course.

[kolak]

I assume it will be added at some point. It makes perfect sense, specially for "4K codec". New TVs started supporting Rec2020.

http://www.theasc.com/asc_blog/thefilmbook/files/2013/10/gamut_rec_2020_dci.jpg

It shows way more colors than Rec709 (or DCI, which is used in cinemas) assuming your TV is capable of displaying all of them.

[Ignus2]

I assume it will be added at some point. It makes perfect sense, specially for "4K codec". New TVs started supporting Rec2020.

It shows way more colors than Rec709 (or DCI, which is used in cinemas) assuming your TV is capable of displaying all of them.

Rec.2020 is relevant only when doing conversion to/from RGB. Rec.601 and Rec.709 (as well as sRGB) use the same color primaries (well, almost), while Rec.2020 does not, allowing a larger color gamut. Also, Rec.2020 is for 10-12 bit.
So the question is whether it makes sense to support conversion from 8 bit RGB to YUV (Y'CbCr) using Rec.2020 coefficients, which would imply that the RGB input uses different primaries (than the usual sRGB).

EDIT: Adding the coefficients is easy, so I can add an option next to the current Rec.601 and Rec.709, but the question is whether it makes sense.

Greets,
I.

[Rumbah]

Rec. 2020 uses more than 8 bits because you'll be in danger of getting banding with 8 bits as the triangle is that large.

[kolak]

Rec.2020 is relevant only when doing conversion to/from RGB. Rec.601 and Rec.709 (as well as sRGB) use the same color primaries (well, almost), while Rec.2020 does not, allowing a larger color gamut. Also, Rec.2020 is for 10-12 bit.
So the question is whether it makes sense to support conversion from 8 bit RGB to YUV (Y'CbCr) using Rec.2020 coefficients, which would imply that the RGB input uses different primaries (than the usual sRGB).

EDIT: Adding the coefficients is easy, so I can add an option next to the current Rec.601 and Rec.709, but the question is whether it makes sense.

Greets,
I.

Nothing stop most of the panels being 10bit in a year time. It's visible trend that more and more panels support 10bit, as technology is getting cheaper and more advanced.
MagicYUV may not be only 8bit in the future neither :)
Support may show up when it makes sense, no need to be there now.

[Ignus2]

There seem to be a bug i have encountered.

When i have YV12 content i save it with MagicYUV, it will be saved as YV24 or YUY2, or at least decoded that way in Avisynth,
Avisource = YV24, DirectShowSource = YUY2.

My settings are - As Is, so no internal conversion should be done, input-output should be the same.

Is it supposed to be like that, am i missing out something, or is this a bug?

I have found the reason for this BTW. Actually it is the "fault" of AviSynth. In the AviSource docs (http://avisynth.nl/index.php/AviSource) it is stated:

"
The pixel_type parameter allows you to choose the output format of the decompressor. Valid values are "YV24", "YV16", "YV12", "YV411", "YUY2", "RGB32", "RGB24", "Y8", "AUTO" and "FULL" (default value). If omitted or set to "FULL", AviSynth will use the first format supported by the decompressor (in the following order: YV24, YV16, YV12, YV411, YUY2, RGB32, RGB24 and Y8). If set to "AUTO", AviSynth will use the old ordering: YV12, YUY2, RGB32, RGB24 and Y8. This parameter has no effect if the video is in an uncompressed format, because no decompressor will be used in that case. To put it in different words: if you don't specify something it will try to output the AVI as YV24, if that isn't possible it tries YV16 and if that isn't possible it tries YV12, etc ...
"

So AviSource doesn't ask the codec about the preferred format but always tries YV24 first. This is why you get YV24 even if the compressed form is YV12.
In my opinion, this is quite incorrect to do, but that's how it's done.

Greets,
I.

[zerowalker]

Hmm, well that really is quite problematic.
As i assume many are as me and just use Avisource and think that it will be done correctly.
I find it weird however that UT Video Codec and others are decoded correctly, but i guess that don't allow upsampling?

If that's the case, there is 2 solutions i can think of:

1: Fix Avisource (Probably most problematic as Avisynth is in the state it is).
2: Add option to prevent Upsampling on Decoding, pretty sure Lagarith has this, but i think it also introduces problems, like being unable to playback videos as they must be RGB32 for that.

hmm, do you have any ideas if it can be solved from the Codecs and like that?
As i find it quite bad (not the codec but the problem), as if i hadn't noticed it, i would have done another Downsampling losing even more Chroma for no reason.

Thanks!

[Ignus2]

Hmm, well that really is quite problematic.
As i assume many are as me and just use Avisource and think that it will be done correctly.
I find it weird however that UT Video Codec and others are decoded correctly, but i guess that don't allow upsampling?

If that's the case, there is 2 solutions i can think of:

1: Fix Avisource (Probably most problematic as Avisynth is in the state it is).
2: Add option to prevent Upsampling on Decoding, pretty sure Lagarith has this, but i think it also introduces problems, like being unable to playback videos as they must be RGB32 for that.

hmm, do you have any ideas if it can be solved from the Codecs and like that?
As i find it quite bad (not the codec but the problem), as if i hadn't noticed it, i would have done another Downsampling losing even more Chroma for no reason.

Thanks!

The reason UT "works" is because it cannot do YV24 output at all.
A solution could be to provide options on the GUI like these:
Prevent upsampling on decoding:
- Prevent YV12 -> YV24
- Prevent YV12 -> YUY2
- Prevent YUY2 -> YV24
by default all checked.

That would still allow decoding to RGB, and this way AviSource would also work correctly.

Thanks for reporting. BTW, what you encountered (getting YV24 out of YV12) is exactly the case of "this is not a bug, it's a feature" :) And now I have to workaround it...

Greets,
I.

[zerowalker]

Ah, okay, i guess it goes to YUY2, but then again it has separate codecs so it somewhat prevents "misuse", which has it's own flaws.

Hmm didn't think of that, forgot that RGB was of low priority even though you wrote it.
That indeed would solve any upsampling and playback and everything will work as expected, and making it a choice prevents cases where it may interfere.

No problem, one of those rare cases, glad it could be solved, and very thankful for you taking time investigating it, having a developer listening to it's users is worth a lot:)

Thanks!

[zerowalker]

Another thing i noticed, my Webcam can output RGB and I420, and I420 is Not supported by MagicYUV.
Now i am guessing it's because it's Interleaved and not Planar.

But even though it's rare, i think it would be handy to support that input, even if you would need to convert it to Planar (As far as i know it's lossless).

[Ignus2]

Another thing i noticed, my Webcam can output RGB and I420, and I420 is Not supported by MagicYUV.
Now i am guessing it's because it's Interleaved and not Planar.

But even though it's rare, i think it would be handy to support that input, even if you would need to convert it to Planar (As far as i know it's lossless).

Just did a quick lookup and I420 is identical to YV12, just the U/V planes are reversed. It is trivial to add support for that. Thanks for mentioning, I'll include it for the next release (rc2) along with the prevent settings, which should hopefully be released in the next days.

Greets,
I.

[zerowalker]

Splendid, grateful as always:)

[zerowalker]

Another thing i have wanted to ask, is it possible to add Null Frames in MagicYUV?
From my understanding, i guess it's not quite optimal as it uses prediction, and Lagarith(it has null frame, hence the reference) uses "Zip" on each frames if i remember correctly.

However thought it was worth asking about it, it's quite a neat thing in some rare cases.

EDIT:

Noticed something that may be important.

I noticed that MagicYUV can produce 2 identical files, while the difference in size is quite huge, like 50% more or less while still having the same settings.

I did like this.

I used Dxtory to record with MagicYUV, the settings are Default, RGB and Adaptive Dynamic etc.
The file recorded will be, let's say 1gb.

Now, i then open that file with Virtualdub and resave it with identical settings, the resulting file will be about 1.8gb (in this test), and even YV24, YUY2 won't beat it.
The files are identical in settings and looks.

I also tried to manually override the settings to see if i could produce the smaller file, but to no avail.

Perhaps it's obvious, but to me i can't conclude what the reason may be, other than MagicYUV acting differently depending on how the data to it is feeded.

Here is a link to a Direct Stream Copy of 3 sec from the file: http://www.sendspace.com/file/sj04fy

Try yourself to compress it better with MagicYUV, my tests fails only making it about 100mb.

[Ignus2]

Hmmm..., this is extremely weird. Thanks for the file, that is very helpful! I can reproduce it, I analyzed the compressed data, I can see what is happening, but I have no idea yet as to what is causing it. I'll investigate...

Greets,
I.

[zerowalker]

Great that i wasn't mistaken.

Not sure if it's a good thing or not though.
It's really interesting that it's quite smaller in size, and the decoding seems to be on par, and the looks are identical.

Logically it would only mean that normally MagicYUV isn't optimized.
And that itself doesn't even make any sense, it's like the data arrives in a way that makes the algorithm do it's work better.
But as far as i know, that shouldn't be possible except if it alters the image.

If you discover anything please tell, quite fascinated with this case.

[Ignus2]

OK, sorry, I mistook, I analyzed the file wrongly. I see what is happening. Actually dxtory is probably smart, and it automatically creates NULL frames if it sees that the codec produced the same compressed data as before (or maybe it can know that it actually fetched the same frame from the video card). As your sample has many identical frames, this is why it is happening.
You can also see in VirtualDub, that in the original compressed file, some frames are marked in the status bar as [K] (key frame) and some as [D] (null frame).
If you check "Video"->"Preserve Empty frames" and do a recompress, you will get the same size file.

This leads back to your initial question of null frames :)
The answer to that is no, the codec itself doesn't detect null frames, but as it seems, some capture software can detect it anyway. I'll think about it if it makes sense to integrate into the codec too.

Greets,
I.

[zerowalker]

Ah, both good and bad news there, explains the situation at the very least.

This leads back to your initial question of null frames

Fun fact that it indeed brings it back to my initial question which wasn't intended.
Didn't know that codecs could have null frames except if the codec itself accept it as a feature.

Please do, the only reason i see not to include it is that it can cause decoding issues in editing softwares.
But then again, that may be prevented in the decoding part, but worth noting, Lagarith does have this issue, but from my mind i know it occurs at certain cases.

For example.

You edit a file with After Effects, and in the beginning you have an image that shows for, 3 sec perhaps, and then you render it and save it with Lagarith - Null Frame.

The rendered file will be "corrupted", it will display the first frame 1 time, and then go on with the video, leaving the audio out of sync.

Now i haven't done any deep tests in this, but i have stumbled upon similar issues with other codecs, and it seems to occur if the first frame is repeated (not sure if 1 is enough).

So if you look into it, it can be worth looking into that case.


Thanks

[Ignus2]

I took a look at null frames, and based on websites and forum posts it seems it gives more trouble than advantages. Most software doesn't support it properly.
So for now I think it is not worth the trouble, I think most of the time it would be disabled anyway. Also, capture software usually detect null frames anyhow, and software which support null-frames properly (like vdub) doesn't need codec support too.
So for 1.0 final, it will definitely not be included, but if there is more need for it, I'll consider implementing it later.

Thanks for your time testing btw, if you encounter any other problems, feel free to tell me.

Also, the things we discussed about preventing upscaling of YUV formats is on the way, so stay tuned :)

Greets,
I.

[zerowalker]

Ah, true enough. It's only in rare cases it's useful, and MagicYUV isn't really aimed for that, it's usually Game captures or Photos in editing softwares etc, which you normally would encode or something, leaving the lossless part out.

Thanks for looking into it though.

Still find it hard to understand how an application can put null frames into a codec and it can be handled, even when the codec itself doesn't support it, to me it's like having Stereo sound in the middle of a Mono file;P

No problem from my part, i like playing around and testing, and if it can somehow help in your development, it's a Win/Win situation:)
So if you need some testing done, just ask;)

That's great, a feature i really need!


PS: A question i have been thinking about.

My CPU doesn't support AVX, and the latest SIMD is SSE4.2.

I am wondering, does this Codec use anything beyond that, and if so, what is the performance increase in the instructions alone?
If that can be answered at all of course.

Thanks

[Ignus2]

As for null-frames, it is a feature of the AVI, and it just tells the software to use the previous frame, whether compressed or not. So it should work with any codec.

The codec uses SSE2 only. SSE2 is nice, as almost any CPU commonly in use nowadays support that.
The next logical option would be to use AVX. I would skip anything between SSE2 and AVX. AVX might give some speed increase, but not much.
Another interesting path would be Kaveri, but I guess it's not widely popular yet.

Greets,
I.

[zerowalker]

As for null-frames, it is a feature of the AVI, and it just tells the software to use the previous frame, whether compressed or not. So it should work with any codec.
Ah, that explains it better, it's pretty much like a Monitor, if the next image hasn't come yet, it just displays the previous.

The codec uses SSE2 only. SSE2 is nice, as almost any CPU commonly in use nowadays support that.
Okay, can't believe how many applications optimize for SSE2.

The next logical option would be to use AVX. I would skip anything between SSE2 and AVX. AVX might give some speed increase, but not much.
I have no idea how good it is or anything, just find it fascinating that it's been there for a lifetime, and it's still used, while the other newer are pretty much only used in Emulators and such things.

Hmm, thought AVX would give better speed increase than that, seeing the time between the instructions and the "talk" about AVX using 128-bit or what it was that has been awaited for ages, not that it tells me much;P

Another interesting path would be Kaveri, but I guess it's not widely popular yet.
Kaveri, searched on it just to be safe, it's the AMD CPU architecture right?
Isn't that the CPU/GPU thing that AMD aims for.

Not really sure what you mean with path there, does it have something that can be used, and if so wouldn't that leave the other CPUs alone?

Thanks

[Ignus2]

AVX is good if you have lots of vectorizable code and the algorithm spends most of it's time there. The codec only spends a part of it's time in vectorizable code, and SSE2 is a very good common ground for that.

Yes, Kaveri is the new AMD hybrid CPU/GPU with unified memory. Which is very nice, as no time is spent uploading/downloading data for GPU processing (which is usually a major bottleneck of performance when doing GPGPU processing), it remains in the same place. GPU is unbeatable for vectorizable code, and the regular CPU part can be used for the rest. It's just not widespread (yet).
Implementing support for it would simply mean that for people with Kaveri CPU the codec would have better performance.

Greets,
I.

[zerowalker]

AVX is good if you have lots of vectorizable code and the algorithm spends most of it's time there. The codec only spends a part of it's time in vectorizable code, and SSE2 is a very good common ground for that.

Ah, okay, so it's like a middle ground.

Yes, Kaveri is the new AMD hybrid CPU/GPU with unified memory. Which is very nice, as no time is spent uploading/downloading data for GPU processing (which is usually a major bottleneck of performance when doing GPGPU processing), it remains in the same place. GPU is unbeatable for vectorizable code, and the regular CPU part can be used for the rest. It's just not widespread (yet).

Certainly hope it get's more well known and used with Intel etc as well, as it will benefit more of everything, GPGPU is barely used cause of the bottleneck.

Thanks for the explanation, sorry for bringing into a bit of an off topic course, happens a lot, never seems to be able to predict my own actions.

To point it towards the main goal, may i ask when you expect a release for the 1.0?

Thanks

[Ignus2]

I'm pleased to announce that MagicYUV 1.0rc2 is out.

Some minor features were added, like support for I420 format and compatibility options for Avisynth.

Decoder-side conversions can now be disabled on a per-format/per-target basis. This way YV12 can be prevented to be decoded as YV24 for example, while still keeping YV12-->RGB decoding.

This release can be considered final in terms of 1.0 features, only bug-fixes are expected (if any is found) for 1.0.

Link: http://magicyuv.com

Greets,
I.

[zerowalker]

Much Appreciated!

Good work:)!

(Decompression Settings is Grayed?)

[Ignus2]

Much Appreciated!

Good work:)!

(Decompression Settings is Grayed?)

From VirtualDub and the like, it wouldn't be persistent from there anyway (Vdub store settings temporarily).
It can be set from the start menu "MagicYUV" -> "MagicYUV codec configuration"

EDIT: Normally I would never do this, but as only you downloaded it so far, I pulled it back and uploaded a new version with a tooltip on the button to avoid confusion.

Greets,
I.

[zerowalker]

Ah, okay.


Checked it, but wondering, should it be set to YV12 -> YV12 and RGB, YUY2 -> YUY2 and RGB etc?

[Ignus2]

Ah, okay.


Checked it, but wondering, should it be set to YV12 -> YV12 and RGB, YUY2 -> YUY2 and RGB etc?

The no-conversion path (same format like YV12->YV12) are by default always on and cannot be prevented (there is no checkbox for it), as those don't count as 'conversion'. Would be quite funny if you could disable it for a lossless codec I think :-)

Greets,
I.

[zerowalker]

No didn't mean that, i meant, isn't YV12 set by default to allow upsampling to YUY2?
Or am i misreading the settings?

[Ignus2]

No didn't mean that, i meant, isn't YV12 set by default to allow upsampling to YUY2?
Or am i misreading the settings?

Ah, sorry. Yes, thats allowed, but not a problem, as avisynth tries YV12 before YUY2, so it will not upsample.

[zerowalker]

Ah, seem to have forgotten, thought it went YV24 - > YUY2 -> YV12.
But that explains it, then everything is as it should:)!

Thanks

[Gargamel]

Thank you, Ignus2 !

[Jeroi]

I would vote for null frames and delta frames as well! The main advatages are compression benefits. You will only save first or xorred image data which is full of null pixels. These are really good benefits for Lossless encoder since reduced image data affects directly to filesize. How ever there is the MSU codecs successos ScreenPressor which costs like 25$ and can compress quite good screens and game data with lossless capture.

[zerowalker]

I would like to benchmark MagicYUV in comparison to other similar codecs, is there a recommended way for this?
As playing in a media player can only do so much, would be easier with some number crunching instead.

[Ignus2]

I would like to benchmark MagicYUV in comparison to other similar codecs, is there a recommended way for this?
As playing in a media player can only do so much, would be easier with some number crunching instead.

For benchmarking codec speed, it is best to eliminate all other factors, like:
- Disk access
- Other frame processing
- Rendering
- CPU frequency scaling
etc.

So I would use a ramdisk at minimum, and preferably some command line app, like vdub with sylia script, or my avibench tool or similar. Make sure to avoid comparing apples to oranges, I mean set up all codecs the same way regarding color spaces and conversion (so to avoid situation where one codec compresses YV12 because of implicit conversion, while another YUY2, etc.)
Also, make sure to set your PC to performance mode (max CPU freq) to get consistent results.
For starters... :-)

Greets,
I.

[zerowalker]

Ah, quite much that needs to be taken into account.

Will see if i get around to trying it out, i have only done some fast testings, and with that i saw pretty much that MagicYUV as expected is very lightweighted, but doesn't waste space as to boldly put it.
This is very attractive to the point you are making for the codec to be primary for Editing software.

Thanks

[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]

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]

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 (http://imgur.com/jBqf6Lc), 2 (http://imgur.com/tul47uL).
Video editing software (Magix Video Pro X6) - useless (http://imgur.com/V28YjEs).

[Ignus2]

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


Make it optional.

Сurrent decoding options:
For player - 1 (http://6g6.eu/sih0-2257.png), 2 (http://6g6.eu/sih0-1477.png). http://simplest-image-hosting.net/
Video editing software - useless (http://6g6.eu/sih0-3175.png).

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 :o > sample (https://mega.co.nz/#!EEE31ZoT!FTY2fmkgIBhJqy0UhFP-QAiDwvu5vhUVMJY-2LFMVA8)