MagicYUV - a new fast lossless video codec [Archive] - Page 7

zerowalker

3rd February 2015, 19:24

In my tests it's not (recorded for 24 hours), was some time ago but haven't seen any difference in the changelog.
Remember there is a huge difference per system, it all depends on Audio Clock / PC Clock. Even though Afterburner seems to do something as it's not offsync in the order it should be, which is the difference between the two clocks.
So they are using something to sync the tracks, i don't know how. But it's not perfect as it gets offsync but on a much smaller scale (may have to do a new test as it was quite a while ago).

Hmm didn't know about that it closes Audio earlier that much, but did now it recorded every track independently, dxtory doesn't (All tracks are always the same as Video track, even if it's offsync, so something is wrong in the coding there).

16bit sound noise floor is not something a sane man would complain about. It's only noticeable when it's no sound at all, then there is this Hiss. (I am not sane;P).
(It won't matter on a Mic as there is no such thing as Silence with that).

Nice setup though, i myself got a USB Mic, but would like to have a external Sound Card and a Mic + Mic amplifier. All to prevent dependence and also internal interference (PC Chassis is a noisy place).

Wait so what does it do, append videos the correct way to prevent offsync?
Cause i don't really append recorded videos, i Trim and add intro/outro in Avisynth and with that it's always correct as long as i don't mess something up.

Orivaa

4th February 2015, 13:42

That's because the program itself you use is 32 bit. If you use a 64 bit program, then it will use the 64 bit version.
And yes, the 64 bit version of the codec is much faster (especially for decoding).

The reason why they don't "recognize" it is because they probably use ffmpeg, which is a monolithic collection of codecs, and obviously MagicYUV is not in it.
I might write a reference decoder sometime in the future for ffmpeg, though that sometimes could lead to confusion, like currently in the case of UT looking like it is slow, while in fact sometimes the installed inferior ffmpeg implementation (through Lav filter for example) does the decoding instead of the optimized official decoders.

In the meantime, you can use Avisynth with "AVISource()" to open MagicYUV encoded files and feed that to an h264 encoder.

Greets,
I.

Noob question (As if the previous ones weren't, lol.) but does decoding play a factor when recording at all?

Also, I'm not very good with the very technical stuff like Avisynth (NOOOOOOOB), so is there a program with an interface that I could use instead?

Also, different question. I tried seeing if recording with Afterburner could be an option, but it also only showed the 32-bit version of MagicYUV. So I went and checked, and, as far as I can tell from the install location, I'm using a 32-bit version of Afterburner. However, I can't find a 64 bit version of the newest version anywhere, as it keeps wanting to install it to my 86 bit folder.
It may be that the newest version simply includes both 32 and 64 bit versions, but then how come only the 32 bit version of MagicYUV shows up?

De-M-oN

4th February 2015, 16:11

Also, I'm not very good with the very technical stuff like Avisynth (NOOOOOOOB), so is there a program with an interface that I could use instead?

If you can live with their shitty encoders and almost no settings - yes.

Also, different question. I tried seeing if recording with Afterburner could be an option, but it also only showed the 32-bit version of MagicYUV. So I went and checked, and, as far as I can tell from the install location, I'm using a 32-bit version of Afterburner. However, I can't find a 64 bit version of the newest version anywhere, as it keeps wanting to install it to my 86 bit folder.
It may be that the newest version simply includes both 32 and 64 bit versions, but then how come only the 32 bit version of MagicYUV shows up?

It isnt necessary that the whole program runs at 64bit.

A seperate process for encoding is enough - which the checkmark for dedicated encoding server does (look at my image gallery).

zerowalker

6th February 2015, 05:14

Just did a test with Afternburner (though it fails almost all the time, but was able to save a long file).

Me and the Audio is in sync with each other as far as i can tell.
However The video is out of sync with the audio.

Here is a file that shows it: https://www.sendspace.com/file/6uluwg - 97.5MB LAGS

EDIT: Made a topic at the right place: http://forums.guru3d.com/showthread.php?p=5008541#post5008541

zerowalker

6th February 2015, 12:00

If i decode MagicYUV using Avisource in Avisynth 64bit it gets corrupted (The image is distorted, like it's stretched diagonal).
Any idea what's going on?

Ignus2

6th February 2015, 17:19

If i decode MagicYUV using Avisource in Avisynth 64bit it gets corrupted (The image is distorted, like it's stretched diagonal).
Any idea what's going on?

I've encountered a similar bug once, and it was on Avisynth's side, somewhere it got the stride wrong, but I forgot to file a bug-report, and now I don't remember exactly how to reproduce it. I think it was resolution dependent.
What resolution?
Does the video open correctly in VirtualDub?
Do you have a sample of the video?

Greets,
I.

zerowalker

7th February 2015, 04:29

Well i get it with pretty much every resolution, cause i first thought it was the problem.

Resolution i tried after 2 weird ones was 640x480 (which should be as normal as it can get?).
All failed.

It was RGB32(or 24, no Alpha, not sure what you save as).

I tried opening it with x264 first and it failed, then virtualdub and it failed, then MPC-HC x64 and it failed.
Failed = it's corrupted.

Also noticed it's not just MagicYUV, happens with Lagarith as well, so may be just RGB that's the problem?

Here is a file: https://www.sendspace.com/file/ohpp7o

This file will fail if decoded with Avisynth 64bit.

Ignus2

7th February 2015, 14:45

Yes, this is a bug in Avisynth, at certain resolutions decoding to RGB32/RGB24 it gets the stride wrong. It's wrong for both 32/64 bit editions BTW.

Greets,
I.

zerowalker

7th February 2015, 14:47

32bit works for me.
Though 32bit is 2.6 and 64bit is Avisynth+.

Orivaa

8th February 2015, 01:35

I did some testing with Afterburner, and the codec would work wonderfully for the entire recording. (Solid 60 fps when not recording, and solid 50 when recording. This is on decently high settings and 1080p, 60fps.)

The video works fine, right up to the moment I decide to actually move my character, in which case the player crashes.

zerowalker

8th February 2015, 05:30

Wait, Afterburner fails for you?
Player crashes, do you mean the Media Player or EncoderServer?

Orivaa

8th February 2015, 14:09

Ignus2

8th February 2015, 14:24

I don't know if it's Afterburner or the codec.

I use MPC-BE, and it works fine until I move my character. All other plays couldn't play the files at all, and the program I used to re-encode my last MagicYUV file (XviD4PSP 5) failed to read the file.

What do you mean by moving the "character"?
Does VirtualDub open the file?
Can you send a sample, which exhibits the failure?

Greets,
I.

Orivaa

8th February 2015, 14:57

Ok, I tried again with a different game, and the same thing happened. However, I then tried again using the AVI container option instead of the MKV, and now it works.

Orivaa

8th February 2015, 15:01

What do you mean by moving the "character"?
Does VirtualDub open the file?
Can you send a sample, which exhibits the failure?

Greets,
I.

I was doing it on Far Cry 4, and when I started the recording, I'd stand still for a while and observe the framerate. However, once I actually began to move my character, the video would fuck up. The game showed no sign, but it was the same on all my videos.

And no, Virtualdub wouldn't open the file. Said it was unsupported, but that might be because of the MKV container.

As I said in my post above, changing the container to AVI fixed the problem.

zerowalker

8th February 2015, 15:53

Still weird, MKV should work as well.

Mystery Keeper

8th February 2015, 18:03

Any hope for P010 and P016 support? All essential VapourSynth plugins already can work with 8-16 bit planar video, and we need a codec for intermediate encoding.

Ignus2

8th February 2015, 23:06

Still weird, MKV should work as well.

I'd be surprised if it did. But then again, miracles can happen ;)

@Orivaa: Good to hear you got it working.

Greets,
I.

Ignus2

8th February 2015, 23:24

Any hope for P010 and P016 support? All essential VapourSynth plugins already can work with 8-16 bit planar video, and we need a codec for intermediate encoding.

Mochiron, it would be almost trivial to implement it in the current architecture of the codec. But note that P016 would also be only up to 10 bits precision.
However, above-8-bit compression is unreleased as of yet. I can't give dates yet (there's just mountains of work to do nowadays), but that part of the codec will not be free. Is that suitable for you?
BTW, how does VapourSynth interface with codecs? VFW/DShow/other(custom)?

Greets,
I.

Mystery Keeper

9th February 2015, 12:25

But note that P016 would also be only up to 10 bits precision.Then why do it at all?
but that part of the codec will not be free. Is that suitable for you?Depends on price.
BTW, how does VapourSynth interface with codecs? VFW/DShow/other(custom)?It doesn't. It is a library that outputs raw uncompressed frames, which can be passed anywhere. Since VirtualDub can open VapourSynth scripts, they can be encoded with VfW codecs.

Ignus2

9th February 2015, 13:24

P016 would only have a meaning if P010 is not recognized or the whole internal processing is 16-bit, then it's better if the codec provides P016 (needs no further conversion), but in the case of VapourSynth, P010 would probably be fine.
Another case would be if the codec encodes at 12 bit precision (planned), that can be encoded/decoded to/from P016.

I assume you would need to both encode output from VapourSynth and decode input for VapourSynth. How does video enter VS? AviSynth has AVISource(), DirectShowSource(), etc., what is the equivalent in VS?
Also, can VirtualDub handle P016/P010?

Greets,
I.

Mystery Keeper

9th February 2015, 17:15

How does video enter VS? AviSynth has AVISource(), DirectShowSource(), etc., what is the equivalent in VS?
AviSource, FFMS2, other source plugins.
Also, can VirtualDub handle P016/P010?Looks like it can't =/ I'm going to implement VfW encoding in VapourSynth Editor when I have time. Also should request high depth handling in VD.

foxyshadis

10th February 2015, 01:57

Even in the absence of real support, there's always the stack16 hack that works just as well with MagicYUV as anything else. Stack16 isn't really interoperable to other editors, but tools like avs4x264mod and Avs2YUV will convert back to normal 16-bit for command-line encoders' sake.

Are_

10th February 2015, 02:38

Long time ago I did try to encode to lossless using stack16 and the encoder crashed. Did you try to actually encode to lossless with it and succeed or is it just a wild guess (was I unlucky?)?

Ignus2

25th February 2015, 03:10

After a long hiatus, the 1.1 version of the codec is here!
The major new feature of the codec is that it now includes a QuickTime encoder/decoder component and VLC decoder plugins and adds support for Mac OS X (through QuickTime and VLC) and Linux (through VLC). The QuickTime and VLC plugin is also available in the Windows version.
Get to the website for details and download: http://magicyuv.com

The QuickTime and VLC plugins are considered beta, though I've made the best effort to make them as stable as possible. So if you encounter any crashes or glitches, reports are welcome.

Greets,
I.

zerowalker

25th February 2015, 07:31

Great work as always!

ceth

25th February 2015, 08:02

Thank you !

kolak

25th February 2015, 15:27

Codec uses about 2x less CPU during playback than ProRes :)

Gargamel

25th February 2015, 15:42

Thank you again, Ignus2 !

TCmullet

26th February 2015, 20:40

I just discovered the existence of this codec today, and am very glad! Thank you for it!

I've installed it twice. On one system, installation bombs with the message, "Internal error: Cannot install files to 64-bit locations on this version of Windows."

When I first saw that I said to myself, "That's okay, this is not a 64-bit Windows anyway, and I was already planning on running 32-bit editions of everything. Surely the 32-bit installation must have finished." But when I went to encode in Vdub, MagicYUV does NOT appear in the list of available codecs!

I have a 64-bit hardware, but have to run 32-bit Windows XP for the time being.

I really really need to get this running asap. Any chance you can get it fixed quickly, hopefully TODAY??

Ignus2

26th February 2015, 22:17

Ignus2

1st March 2015, 21:29

Revision 1 for Windows is out which fixes the installer bug for 32-bit editions of Windows, which prevented installation on 32-bit Windows if the VLC component was selected.

Also, the download links for 1.1 have been modified, so anyone who hard-linked the site should update the links.

Greets,
I.

Ignus2

4th March 2015, 04:08

Revision 2 for Windows and Revision 1 for Mac OS X have been released, adding VLC 2.2.x plugins. There were no other changes.

Greets,
I.

benwaggoner

5th March 2015, 19:34

When do you anticipate a public release of 10-bit support?

kolak

8th March 2015, 19:46

This won't be free for public.

10bit in AVI has almost 0 support in applications. Only things like avs, vapoursynth can make some use of 10bit in this codec.

10bit in MOV already works well on Mac. MOV on PC is different and needs some work.
The best is to use API for 10bit.

Ignus2

9th March 2015, 10:51

When do you anticipate a public release of 10-bit support?

As kolak said.

10-bit is mainly done now through QuickTime, but you have to be super careful and know what you're doing to really retain 10-bit (and not dithered 8-bit or similar).

Also, plugins for various apps are currently under development, that should work better than QuickTime.

Greets,
I.

TCmullet

9th March 2015, 15:52

As a workaround, try to install without the VLC component, I think that's the culprit.

I unchecked the VLC component, and the installer worked without errors. Thanks.

I did try running the codec on the different machine here where the full install worked. I left all settings at their defaults. The output file was huge, much bigger than I expected. Is there some combination of settings that will minimize the file size?

Ignus2

9th March 2015, 16:28

I unchecked the VLC component, and the installer worked without errors. Thanks.

I did try running the codec on the different machine here where the full install worked. I left all settings at their defaults. The output file was huge, much bigger than I expected. Is there some combination of settings that will minimize the file size?

The rev1 and rev2 Windows installers should work on 32-bit machines with VLC too.

You can expect a compression ratio around 2:1 - 4:1 (depending on the material), there isn't much you can do about it.
But it depends a lot on what you are trying to do, what color space is your source, etc.

Greets,
I.

kolak

9th March 2015, 21:46

I unchecked the VLC component, and the installer worked without errors. Thanks.

I did try running the codec on the different machine here where the full install worked. I left all settings at their defaults. The output file was huge, much bigger than I expected. Is there some combination of settings that will minimize the file size?

It lossless codec, so you can't predict final size.
If source is clean, full of flat areas it may compress it 8x, but if source has eg. loads of random noise than it may not compress at all, so your file may be as big as uncompressed.

The one thing which you known that after decoding your video has 100% the same quality as original (if no 422, 420 etc conversion is happening).

As Ignus2 said- typical value for compression are between 2-4x.

TCmullet

9th March 2015, 21:50

True, you can't predict final size. But compared to Lagarith, it was much larger (but less buggy). I was able to get it smaller via x264vfw-lossless for now. Will keep MagicYuv in mind for other things.

kolak

9th March 2015, 23:16

Was it the same color sampling: 4:4:4, 4:2:2 or 4:2:0 for both cadecs?
Was it normal footage or some with repeated frames?
There shouldn't be massive difference.

TCmullet

9th March 2015, 23:25

Was it the same color sampling: 4:4:4, 4:2:2 or 4:2:0 for both cadecs?
Was it normal footage or some with repeated frames?
There shouldn't be massive difference.
If you're talking to *me*, it's 4:2:0 (had to figure out MediaInfo). "Normal" footage, not a slide show. In fact, it's so normal that in Lagarith I'm inclined not to bother allowing null frames. It's video camera footage of sports.

kolak

10th March 2015, 10:38

And what is the size difference between magicyuv and Lagarith ?

If you can post 10sec samples fro both- cut in Vdub.

benwaggoner

16th March 2015, 19:40

10bit in AVI has almost 0 support in applications. Only things like avs, vapoursynth can make some use of 10bit in this codec.
The Adobe products like After Effects and Premiere can use 10-bit in AVI and QuickTime on both Windows and Mac. Internally they can render at up to 32-bit float, and output as "Trillions of colors" to a codec that supports >8-bit per channel.

There really aren't any good free interoperable compressed 10-bit codecs today that support a wide range of frame sizes. ProRes is okay, but only can encode via QuickTime on Mac. DNxHD has a 1920x1080 frame size cap. You need to pay for the Cineform encoder.

For my internal workflows I can make it all work, but for collaboration between companies/teams having a high quality, flexible, compressed 10-bit codec would be a big deal.

kolak

17th March 2015, 00:51

AE will never ask for 10bit pixel format in AVI when you import file. Only v210 is supported, but this is hard coded.
If you want to do it you have write a plugin, like Cineform use to have.

Magicyuv may have very good support in Adobe software if all goes well.
Mov already works well, but native/direct support in Adobe engine or over plugin would be even better.

The ”issue” is that this is lossless codec, so saves bits, but not as much as eg. Cineform.

De-M-oN

18th May 2015, 19:45

foxyshadis

19th May 2015, 00:05

Please add RGB24 conversion.

"as is" would record pc video capture like games as RGB32 - but RGB32 has no use for pc game capture, there is RGB24 enough.

Sure I could use YUV 4:4:4 but thats not supported by the Spline100 Scaler.

Unless you have serious memory pressure, RGB32 is usually faster than RGB24, and it won't be any larger. The alpha plane is empty, so it'll be compressed to no more than a byte or two.

Ignus2

19th May 2015, 02:45

Please add RGB24 conversion.

"as is" would record pc video capture like games as RGB32 - but RGB32 has no use for pc game capture, there is RGB24 enough.

Sure I could use YUV 4:4:4 but thats not supported by the Spline100 Scaler.

The codec supports RGB24 as both an input and output format, so I don!t really understand what do you mean by "RGB24 conversion".
From the compressed data point of view, there is no such thing as RGB32 or RGB24. There is 3-channel RGB or 4-channel RGBA. Both RGB32 and RGB24 INPUT is compressed as 3-channel RGB (for RGB32: if "Enable RGBA compression" is disabled), and presented when decoding as either RGB24 or RGB32 (depending of what the decoding app asks).

So recording "as-is" results in compressed 3-channel RGB for both RGB24 and RGB32 input (if "enable alpha" is disabled), so the compressed data will be the same.

(As a side note: YUV 4:4:4 can also be presented by the codec as either RGB24 or RGB32 btw.)

Greets,
I.

benwaggoner

19th May 2015, 18:30

Unless you have serious memory pressure, RGB32 is usually faster than RGB24, and it won't be any larger. The alpha plane is empty, so it'll be compressed to no more than a byte or two.
The main problem with having a "blank" alpha channel is that a compositor doesn't have any way to know if the channels are blank. So it might wind up doing per-pixel transparency calculations for every frame even though it all winds up as a NOOP.

I've seen it happen, with a deadly perf hit.

I only turn on an alpha channel when there's actually alpha data to avoid downstream confusion. Even if the codec acts just the same with every forth byte zeroed out.