MagicYUV - a new fast lossless video codec

[Ignus2]

Hi!

As I mentioned in the Intermediate Video Format survey thread, I've been developing a new fast lossless video codec (named MagicYUV) for Windows, it's been basically ready since a year ago, I just never got the time to release it.

But now it's here, I've fixed some remaining bugs I've known and I guess it's ready for an alpha release.

I've set up a website, you can grab it from there: http://magicyuv.com

I've also uploaded a command line tool avibench there, that can measure codec compression/decompression performance through AVI files.

Any kind of suggestions, comments, bug and crash reports, feature requests can come here. The target is to make it to 1.0 stable :)

Greets,
I.

[LoRd_MuldeR]

Thank you. I will definitely give that one a try.

Do you have any graphs on how this one compares to other lossless video Codecs (HuffYUV, Lagarith, FFV1, x264) in terms of speed and compression?

BTW: Can't really see anywhere which license this is released under. So I assume it's ClosedSource, right?

[Ignus2]

Thank you. I will definitely give that one a try.

Do you have any graphs on how this one compares to other lossless video Codecs (HuffYUV, Lagarith, FFV1, x264) in terms of speed and compression?

BTW: Can't really see anywhere which license this is released under. So I assume it's ClosedSource, right?

Well, I do have some graphs, but it would be best if the users could test it ;)
As a quick reference: for decompression in Dynamic mode it "should" be considerably (2-3x) faster than Ut Median with around same comp. ratio and faster (1.4x) than Ut Left with better (10%) comp. ratio. Without Disk I/O of course (measured with ramdisk/fully cached avi). At least on my machine... And I'm really curious about other machines...
Against FFV1 and x264 I didn't compare yet.

About the license: well, I'm not a lawyer, so I can't come up with licenses, so I'll just say that the version you can download from the site is free to use for whatever you want and the sources are not included :)

Greets,
I.

[EncodedMango]

Seems interesting, gonna try it out.

EDIT:Okay so I just tried it using Dxtory(so 32bit version) and I must say the results seem impressive, I had(edit2) some FPS loss when recording but it didn't feel incredibly laggy. This beats Lagarith for me in this test atleast great job Ignus2.

[hello_hello]

Recompressing a 3min, 49sec 704x384 AVI with VirtualDubMod (fast recompress). No audio. Output written to the first partition of a RAID-0 volume to take hard drive speed out the equation as much as possible. YV12 -> YV12. Total time as displayed by VirtualDubMod.
Old E6750 dual core CPU, 3.2GHz. For Lagarith and MagicYUV there's two time and CPU usage figures. Without and with multi-threading enabled. CPU usage is a fairly rough average anyway.

Huffyuv (ffdshow variant), 16 seconds, CPU 62%, 990.8MB
Huffyuv (ffdshow variant, adaptive huffman tables enabled), 16 seconds, CPU 62%, 587.2MB

FFV1, 62 seconds, CPU 58%, 432.6MB

Lagarith, 18/15 seconds, CPU 60%/73%, 503MB

MagicYUV, 17/12 seconds, CPU 60%/83%, 586.8MB

For a hard drive speed reference..... copying the largest file (990.8MB) from the location of the source file to the same location as the output files took around 6 seconds.

And for fun:

Uncompressed YV12 (Avisynth script/Direct Stream Copy), 15 seconds, CPU 45%, 2.1GB
Uncompressed RGB, 30 seconds, CPU 45%, 4.3GB

[LoRd_MuldeR]

About the license: well, I'm not a lawyer, so I can't come up with licenses, so I'll just say that the version you can download from the site is free to use for whatever you want and the sources are not included :)

You don't need to be a lawyer. If you ever decide to "open" your sources, you could just put them, for example, under a (L)GPL license - which would make it possible to integrate your Codec into FFmpeg (libavcodec), thus making it available in pretty much any OpenSource tool. Currently it's tied not only to the Windows platform but also to the (deprecated) VFW interface, which limits its applications, of course. And it has every user to rely on you to provide "free" decoders in the future (the last point might not be that critical for an "intermediate" Codec though)

[Ignus2]

Recompressing a 3min, 49sec 704x384 AVI with VirtualDubMod (fast recompress).
...


The codec is not yet tuned optimally for such small resolutions (on my TODO list), if you could try the same test with HD (1920x1080) or higher, that would be nice :-)

Greets,
I.

[Atak_Snajpera]

I've just updated my old test http://forum.doom9.org/showthread.php?t=165745

I don't know why but file is larger than source .y4m !?

General
Complete name : G:\job1.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 859 MiB
Duration : 10s 0ms
Overall bit rate : 721 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : MAGY
Codec ID : MAGY
Duration : 10s 0ms
Bit rate : 721 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Bits/(Pixel*Frame) : 13.903
Stream size : 859 MiB (100%)


General
Complete name : G:\job1.y4m
Format : YUV4MPEG2
File size : 742 MiB

Video
Format : YUV
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Scan type : Progressive
Compression mode : Lossless

[Ignus2]

I've just updated my old test http://forum.doom9.org/showthread.php?t=165745

I don't know why but file is larger than source .y4m !?


That's a colorspace issue I guess (or something similar). I think the stream actually gets encoded as RGB probably.
MagicYUV actually compresses what it gets without colorspace conversion, and it is currently not possible to force or restrict what colorspace the codec accepts, so if VirtualDub is set up or decides to give MagicYUV RGB input, it will compress like that.

--
Greets,
I.

[Atak_Snajpera]

i will redo test tomorrow then.

[Ignus2]

i will redo test tomorrow then.

That would be great, I'm very interested in the results :)

[hello_hello]

5 minute, 1920x1040 MKV with Avisynth/ffmsindex/VirtualDub (fast recompress). ffms in single threaded mode. No audio. Output written to the first partition of a RAID-0 volume to take hard drive speed out the equation as much as possible. YV12 -> YV12. Total time as displayed by VirtualDub.
Old E6750 dual core CPU, 3.2GHz. CPU usage is a fairly rough average. Encoding the first 15 to 30 seconds indicated multithreaded mode was slower for both Lagarith and MagicYUV so I disabled it.

Huffyuv (ffdshow variant), 4 min 23 sec, CPU 85%, 9542MB
Huffyuv (ffdshow variant, adaptive huffman tables enabled), 4 min 1 sec, CPU 80%, 5897MB

FFV1, 11 min 4 sec, CPU 70%, 4935MB

Lagarith, (no mulltithreading, enabling it slowed encoding speed by 2 or 3 fps), 4 min 7 sec, CPU 90%, 5451MB

MagicYUV, (no mulltithreading, enabling it slowed encoding speed by 2 or 3 fps), 4 min 23 sec, CPU 97%, 5823MB


Uncompressed YV12, (Avisynth/ffmsindex/VirtualDubMod/Direct Stream Copy), 4 min 14 sec, CPU 65%, 20572MB


I ran most of the above encodes twice to check them, given the next results weren't what I expected.......

As an experiment I thought I'd take Avisynth and ffmsindex out of the equation and reduce the CPU usage (hopefully) required for decoding. I took the second huffyuv encode and put it on the same drive as the original MKV. The 5897MB file took about 1 minute to move, so obviously hard drive speed wasn't a bottleneck. I then opened it directly with VirtualDub and re-compressed it (fast recompress). Same output file location as before. This time multithreaded mode was a little faster than single threaded mode for MagicYUV and Lagarith.

MagicYUV, (mulltithreading enabled), 4 min 02 sec, CPU 70%, 6683MB
I run the encode twice. With huffyuv as the source MagicYUV was faster. It also compressed less.

Lagarith, (mulltithreading enabled), 4 min 54 sec, CPU 65%, 5404MB
With huffyuv as the source Lagarith slowed down quite a bit. The file size decreased a tiny bit. I don't understand why. I tried again without multithreading:
Lagarith, (no mulltithreading), 5 min 29 sec, CPU 55%, 5404MB

Huffyuv (ffdshow variant, adaptive huffman tables enabled), 4 min 38 sec, CPU 55%, 5897MB
And with huffyuv as the source, huffyuv slowed down too. No file size change though. Input and output file sizes were exactly the same.

Someone will have to explain the speed/compression changes for me. Maybe the huffyuv version isn't YV12, although as best as I can tell it is. I even encoded it again using the "force input colorspace option" and setting it to YV12 and the file size after encoding (from the original video) still remained unchanged. When viewing the huffyuv encode with MPC-HC, ffdshow reports the output as NV12 (as it usually does when decoding YV12 with MPC-HC). But enough for today.....

[Ignus2]

5 minute, 1920x1040 MKV with Avisynth/ffmsindex/VirtualDub (fast recompress).
...


Thanks.

What codec and size is the original MKV?

The file becoming bigger for MagicYUV from huffyuv source in fast recompress is due to (I believe) the fact, that huffyuv tends to ouput YUY2 even if it is compressed YV12. And as it is not yet possible to restrict what input MagicYUV accepts, and it doesn't do any colorspace conversion of the input, it probably actually compressed YUY2 (instead of YV12).

I probably need to an option to restrict accepted colorspaces, that would eliminate these hidden colorspace inconsistencies that others are also experiencing...

Greets,
I.

[hello_hello]

It was annoying me, so I tried again. Same 1920x1040 video, but I decoded it to uncompressed video using Avisynth/ffmsindex/VirtualDubMod/Direct Stream Copy. Then I compressed the 20GB version. I didn't bother with FFV1. I think it's fairly established it's very slow.

Huffyuv (ffdshow variant, adaptive huffman tables enabled), 2 min 33 sec, CPU 70%, 5897MB

Lagarith, (mulltithreading), 3 min 1 sec, CPU 80%, 5451MB

MagicYUV, (mulltithreading), 2 min 17 sec, CPU 70%, 5823MB

Now the results are what I'd expect. Faster compression using the uncompressed video as the source (compared to the original video and Avisynth). Same file sizes.
I'm not sure what that means in respect to the ffdshow version of huffyuv being lossless for YV12. I thought it was supposed to be?

[Ignus2]

Nice :)

BTW, what MagicYUV really should excel at is decompression speed. If you could do a decompression test, that would be nice too (dunno where to put output though, maybe use avsmeter?). Or better yet, do a recompress cycle using the same codec for input and compression.

Also, suggestions are welcome, especially about the colorspace things. Is restriction enough (simple to do) or should I implement conversion?

Greets,
I.

[hello_hello]

Thanks.

What codec and size is the original MKV?

x264, 415MB

The file becoming bigger for MagicYUV from huffyuv source in fast recompress is due to (I believe) the fact, that huffyuv tends to ouput YUY2 even if it is compressed YV12. And as it is not yet possible to restrict what input MagicYUV accepts, and it doesn't do any colorspace conversion of the input, it probably actually compressed YUY2 (instead of YV12).

I think you're correct but I'm not sure who's fault it is. I'm pretty sure the huffyuv version is encoded as YV12 and I'm pretty sure when it's opened in a player and decoded via directshow it's decoded as YV12. Create an AviSource script to open it and add Info() and it's reported as YV12. Whether it's opened by MPC-HC or VirtualDub it's YV12.
Open the AVI containing huffyuv directly with VirtualDub though and the output is YUY2. Unless..... you disable YUY2 and UVYV as output clolrspaces in the ffdshow VFW decoder configuration.

After a fair bit of playing around I'm fairly confident that's what's happening, and while I don't know why, it appears VirtualDub's Fast Recompress option is to blame. Why it seems to only want to convert YV12 to YUY2 when the input codec is huffyuv I don't know, and I don't know why disabling YUY2 and UVYV in the ffdshow list of out output colorspaces stops it from happening. It's kind of like Fast Recompress decides "when it can be decoded as YUY2, it should be".....

Fast recompress: Video is decompressed and then recompressed using the desired output codec. VirtualDub automatically chooses a intermediate video format to use between the codecs for quality and speed.

VirtualDubMod's fast recompress doesn't seem to do the same. For it, if it's huffyuv YV12 in, it's YV12 out.

[Atak_Snajpera]

Test updated! http://forum.doom9.org/showthread.php?t=165745

[kolak]

Did you use 32bit?
64bit MagicYuv is way faster, at least for decoding.

[kolak]

Nice :)

BTW, what MagicYUV really should excel at is decompression speed. If you could do a decompression test, that would be nice too (dunno where to put output though, maybe use avsmeter?). Or better yet, do a recompress cycle using the same codec for input and compression.

Also, suggestions are welcome, especially about the colorspace things. Is restriction enough (simple to do) or should I implement conversion?

Greets,
I.

I think the speed is great, so we are fine here.

Next things to do:
Mac version,
Ffmpeg integration

Also as I mentioned before- 16bit is what it would make it stand out from others. Ffv1 is great, but way to slow, specially for 4K. 8bit is starting to be 'not enough' and not just for pro solution, but also for home users.

Once you have 16bit, than next thing is to add good dithering as an option .

[WorBry]

I did quite extensive testing of a pre-release version of Magic YUV several weeks back using his benchmark tool (no-one seems to be testing with it). I'm not sure what modifications he might have made in the interim and, since I don't really have time to repeat the tests with this alpha release, it would seem inappropriate to post the results.

Suffice it to say that when testing Magic YUV against other lossless codecs, it would pay to compare like-with-like - that is, for the Huffman-based codecs to include and compare the different prediction modes (Left and Median, at least) and not just the defaults.

Magic YUV defaults to a 'balanced' mode that is designed to automatically select (on a per-frame basis) the optimum balance of compression ratio and decompression speed - or as Ignus2 explained it to me:

Dynamic basically just selects the best it thinks per frame, but it is recommended to select it, because if median and left doesn't make a big difference in compression ratio, left is selected, which decodes faster. Dynamic makes a very quick and accurate decision, so there shouldn't be a big difference in speed between dynamic and median on the compression side, but it usually makes a big difference on the decompression side (in favor of dynamic).

If one applies the 'conventional wisdom' that median prediction generally makes for higher compression than left, then arguably 'balanced' mode, in prioritizing compression ratio, could be viewed as favoring Median prediction. Maybe Ignus2 would want to elaborate on that.

UT-Video, by contrast, defaults to Left prediction - being prioritized for decompression speed. So, to my mind, comparing only the default configurations is a bit 'apples and oranges'.

I won't comment further on the pattern of results I obtained (for the reasons stated), but it would be interesting to see what other people find when comparing the decompression and compression rates obtained with the different prediction modes, and including both YV12 and YUY2 sources. And as Ignus2 suggested, maybe look at 're-compression' rates also.

Anyhow, now that the alpha release is out, I don't think anyone could dispute that Magic YUV is indeed a very VFW fast lossless codec, at least on par with UT-Video. As Kolak has emphasized however, what would set Magic YUV apart would be the higher bit-depth support. I hope the positive reports that have been coming back encourage Ignus2 to press forward with that.

[Ignus2]

If one applies the 'conventional wisdom' that median prediction generally makes for higher compression than left, then arguably 'balanced' mode, in prioritizing compression ratio, could be viewed as favoring Median prediction. Maybe Ignus2 would want to elaborate on that.


Well, that conventional wisdom can be wrong sometimes :)
An important thing to mention here is that decoding time doesn't only depend on the prediction method. Bad prediction can slow down other parts of the codec. This is exactly why we cannot outright say Left prediction makes the codec fast.
Dynamic combines the best of both worlds. Use the simplest prediction method giving good compression.
For a tiny bit of more work on the encoder side we can get big wins both in compression ratio and decoding speed.

This is also why I explicitly don't recommend in the codec config dialog selecting Left because the results might not be what people expect (file will be bigger AND slower to decode).
Actually I'm considering to remove the prediction method selector altogether, as it might confuse people thinking Predict Left is equal to a some kind of "Fast Mode", where in reality it isn't.

As for the immediate future, I'll probably do color space conversion built-in to the encoder side (to allow direct RGB->YUY2/YV12 compression), and after that, 10-bit might come along (or Mac, but I never coded a Mac so far...).
But again, as I already mentioned in the original Intermediate Video Format Survey thread, 10-bit is a bigger step, and that might fork into a non-free version (IF I'll ever have the time to do it). (But I will add that the current and every coming 8-bit version will always be free.)

Greets,
I.

[WorBry]

Well, that conventional wisdom can be wrong sometimes :)
An important thing to mention here is that decoding time doesn't only depend on the prediction method. Bad prediction can slow down other parts of the codec. This is exactly why we cannot outright say Left prediction makes the codec fast.
Dynamic combines the best of both worlds. Use the simplest prediction method giving good compression.
For a tiny bit of more work on the encoder side we can get big wins both in compression ratio and decoding speed.


Fair enough, but as you will recall from the last set of test results with the pre-release version; in 32-bit mode, Magic-YUV, set to Left Prediction, did decode faster (12%) than Dynamic (sorry I called it 'Balanced' before) and Median, (which were basically on par in terms of decode rate and compression ratio) and faster (12% again) than UT-Video in default Left prediction mode. When tested in 64-bit mode, however, the Magic-YUV encodes (Left, Median, Dynamic) all decoded at similar rates, but UT-Video (Left) was faster (7%) than them all. This would reflect the improvements that had been made in 64-bit decompression rate in the last update of UT-Video. That said, UT-Video encoded with Median prediction decompressed the slowest of all, at around half the rate of UT-Video (Left) in 32-bit and 64-bit. That was using YV12 sources.

With YUY2 source, a different picture emerged. In that case, Magic-YUV Left, Median and Dynamic encodes decompressed at similar rates in 32-bit mode, with UT-Video (Left) decoding a tad faster. In 64-bit mode, UT-Video Left again was the fastest, but then Magic-YUV encoded in Dynamic mode decoded the fastest and Left prediction the slowest. So, quite the opposite of the results obtained in YV12.

As for compression rates; Magic-YUV in Dynamic mode consistently encoded the slowest of all the prediction modes, and UT-Video (both Left and Median) was consistently faster than Magic-YUV in all prediction modes. That pattern was evident in both 32-bit and 64-bit test modes and with both YV12 and YUY2 (raw) sources. All using your bench mark tool.

As for compression ratios. Yes, with YUY2 sources, Magic-YUV 'Dynamic' did yield marginally higher compression ratios than 'Median', but with YV12 sources they were basically the same. That said, with YUY2 and YV12 sources, UT-Video compressed marginally better in both Left and Median modes than the corresponding modes in Magic-YUV, and on par with HuffYuv (FFDS version).

So, where Magic-YUV did shine in comparison to UT-Video was (in my tests at least) in the decode rate of 'Median' configured encodes (in 32-bit and 64-bit), where UT-Video was significantly slower, and 'Left' configured encodes in 32-bit. But in all other respects UT-Video was faster and compressed slightly better. And yes, it did appear that the 'Dynamic' mode has a bias to Median prediction, as overall the results were not that different. And that was how I understood your explanation. If it's more complex than that, all well and good.

Granted, these tests were performed with a pre-release version on one PC system (Hex-core AMD cpu, Win7 64-bit) using your benchmark tool, and others could well obtain a different results with this alpha release, on different PC's, with different source material and using different performance test criteria - as is already evident from the the several early reports.

All I am suggesting, really, is that to make a fair comparison, one should test with UT-Video in both Left (default) and Median modes in order to best judge how Magic YUV (in default Dynamic mode) performs on the balance of speed and compression.


As for the immediate future, I'll probably do color space conversion built-in to the encoder side (to allow direct RGB->YUY2/YV12 compression)


Although the vfw api is an antiquated/deprecated interface, the reality is that many NLE's still use vfw with third party codecs and operate (at the edit level) in RGB color-space. Given that one potential use of Magic-YUV would be as a lossless edit intermediate in such a system, I think the integrated RGB input would be worthwhile. As you know, when I tried Magic-YUV as an edit intermediate in the (consumer level) NLE I use (Corel Video Studio "Pro" x6) it crashed, but 'magically' worked when I installed the Helix YUV codecs pack, which presumably served as an RGB to YUV interface for Magic YUV - you were going to look into that. UT-Video works perfectly.

[Atak_Snajpera]

how does multithreading encoding work in magicyuv? does it work on frame level or does it use slices?

[Ignus2]

how does multithreading encoding work in magicyuv? does it work on frame level or does it use slices?

Slices. VFW is one frame in one frame out, so slices are the best option.

[Atak_Snajpera]

I wonder why MagicYUV and UT VIDEO do not use more than 2 cores in my tests? RAMDISK + uncompressed source and still no more than 50% during encoding.

[Ignus2]

I wonder why MagicYUV and UT VIDEO do not use more than 2 cores in my tests? RAMDISK + uncompressed source and still no more than 50% during encoding.

Maybe a color space conversion happening somewhere in the background on a single core?
What is the test setup/pipeline for the benchmark?

[Atak_Snajpera]

avs script has only rawsource("video.y4m")

i get 130 fps using avsmeter with this script.

virtualdub is set to fast recompress mode. according to process explorer virtualdub.exe does not use more than 2 cores ( 50% - Q6600@3GHz)

[kolak]

I wonder why MagicYUV and UT VIDEO do not use more than 2 cores in my tests? RAMDISK + uncompressed source and still no more than 50% during encoding.

How fast is your disk?
How fast is reading raw file?
These codecs should be using around 100% CPU, if not than there is some bottleneck.
The fact that both codecs are stucked at 50% means something.

[Atak_Snajpera]

ramdisk amigo! DDR2-666 mhz

[kolak]

Try avibench tool to check if you have same results.
Vdub is good but not always that transparent.

I was able to saturate 24 threads with Utvideo, which gave 1200fps and 2 GByte/sec reading. This was raid box.
Not sure why you have only 50% CPU usage.

[pandy]

Are You consider to support YCoCg color space to support reversible RGB color space conversion?

[Ignus2]

Are You consider to support YCoCg color space to support reversible RGB color space conversion?

I've read about that some time ago, though I don't really see the benefit.
Do you have some source that produces YCoCg?
Or do you consider RGB input and want to store it in YCoCg internally? In this case, what is the benefit (a bit more compression for RGB maybe)?
Also, to be reversible, it requires 2 extra bits.

Greets,
I.

[HulkHoganRules]

I'm really into video game capturing so I wanted to see how it performed. I honestly got lost in this thread but I have some questions if you don't mind.

If I supply this codec a YUY2 source, will it stay YUY2 or will it convert to YV12? The reason I ask is I captured the same frame in MagicYUV and then with Lagarith YUY2 and then YV12. I ran objective video quality tests (MSU) using the MagicYUV frame against both Lagarith YUY2 and then YV12. The comparisons were 99.?% similar. If MagicYuv is in YUY2, I think this is wrong right? I.e. it should be 100% similar since it's a lossless codec?

Many months ago I remember comparing Lagarith YUY2 to x264vfw Lossless mode and that gave me a perfect 100% identical reading. I guess I can only assume that MagicYUV does convert YUY2 to YV12 slightly differently to Lagarith's YV12?

One thing that did surprise me and is really awesome about this codec. Both Lagarith and UT Video completely crumbled under my 1080p60 Xbox 360 tests. I captured with MagicYuv perfectly fine at 1080p60! Picture: http://puu.sh/7jSui.jpg

Thank you.

[pandy]

I've read about that some time ago, though I don't really see the benefit.
Do you have some source that produces YCoCg?
Or do you consider RGB input and want to store it in YCoCg internally? In this case, what is the benefit (a bit more compression for RGB maybe)?
Also, to be reversible, it requires 2 extra bits.

Greets,
I.
Yes - RGB converted internally to YCoCg and back on decoding to RGB, all pros and cons but for example for screen capture especially on 4:4:4 it can be beneficial and provide fully reversible if necessary RGB back conversion. At minimal speed loss (YCoCg can be very fast - i assume perhaps faster than RGB to YCbCr) potential compressibility comparable to YCbCr (ie higher than on RGB).
I would say it can be nice as none of commonly used lossless codecs support this feature.
And as you consider 16 bit depth then perhaps 12 bit (for 10 bit RGB) is not a problem. Not sure as I've said previously - you can be first with such feature.

Big ThX and also greetz.

[raffriff42]

Harping again on this 10-bit thing, Ignus2... suppose you added 10-bit support by compressing the 8 most significant bits in the usual way, and the 2 least significant bits using a separate, simple method, eg run-length or zlib? Compression would not be "optimal," but you would have the only fast, lossless 10-bit encoder around.

[Ignus2]

Thanks for all the suggestions!

A bit of status report:
Currently I'm in the middle of refactoring the code, the result of which will allow much easier development in the future, also adding new colorspaces and internal color space conversions will be much easier. This should also pave the way for 10bit+ (but that's a plan only for after 1.0).

Sadly this also means that I had to change the compressed stream format, which is incompatible with the current one (of 0.9alpha), so the next release will not be able to decode videos encoded with 0.9alpha. This will absolutely not happen after 1.0 is released, I do this now, as I don't intend to keep backward compatibility with alpha releases.

Stay tuned :)

Greets,
I.

[Asmodian]

Very interesting stuff, looking forward to it. :)
:thanks:

[Gargamel]

+1
Thanks and congratulations, maybe (we hope so) the birth of a reference codec !

[Ignus2]

Thanks!

The refactoring is now done, some smaller things remain, so a release is to be expected soon (next week at the latest probably).
Performance-wise there isn't really a big difference, though the new version might be faster in some cases :)

The stream format had to be changed, as I mentioned, though I'm quite satisfied with it now, so if all goes well, it will stay for 1.0 and beyond.

The next release won't see any major new features, though I added an option to restrict the kind of colorspaces the codec will accept (useful to make sure you really give the codec the colorspace you work in and expect - so conversion don't silently happen somewhere). Built-in encoder-side colorspace conversions (direct encoding from RGB to YV12 for example) are expected after this release, and I hope to include them in 1.0.

More to come soon!

Greets,
I.

[Gargamel]

Many are waiting for... and salivating !
May the compiling Force be with you ;-)

[Ignus2]

After many sleepless nights and long hours of coding, the next release 0.9.1 beta is finally here.
Actually, those small things that remained after the refactoring were not so small after all :) But now I'm really satisfied with the result.
Feature-wise, there isn't anything spectacularly new, as I mentioned I only added an option to restrict the input color space.
Performance-wise I measured a 5-10% increase in encoding and 10-15% increase in decoding speed (depending on CPU type).
Also, some compatibility issues were fixed with Windows 8/8.1 64 bit.

As I mentioned I had to change the stream format, so videos encoded with 0.9alpha cannot be decoded with this release. I guess it has reached it's final form now, so I really hope it will stay as it is for 1.0 too.

The immediate plans for/before 1.0 are:

Selectable Rec.601/Rec.709 conversion parameters for YUV input (used when doing direct RGB output)
Interlaced input option
Color space conversion on the encoder side (direct compression from RGB to YUV)


Feature requests and bug reports are always welcome.

Greets,
I.

[Gargamel]

Thank you, Ignus2, and congratulations.
But take care of your health... at least till the v.1.0 !

[Ignus2]

Thank you, Ignus2, and congratulations.
But take care of your health... at least till the v.1.0 !

Thanks, I'll try!

Some progress report since the last release:
RGB can now be compressed as YUV444, giving much better compression ratio (at the cost of the RGB->YUV conversion loss). What follows is downsampling to YUV422 and YUV420 directly. After that, I'll do interlaced video support, and that should cover the features of 1.0.

My question is what YUV444 format should I support? AYUV, YV24, IYU2?

--
Greets,
I.

[Kurtnoise]

Hi,

Is it possible to have different FourCCs ? I mean, one FourCC for YUV streams and another one for RGB ?

Thanks in advance.

[EncodedMango]

My question is what YUV444 format should I support? AYUV, YV24, IYU2?
YV24 vote here.

[kolak]

Hi,

Is it possible to have different FourCCs ? I mean, one FourCC for YUV streams and another one for RGB ?

Thanks in advance.

+1 for this.

YV24 I think is most common.

[Kurtnoise]

This is not I asked...I meant the MAGY FourCC which is in the current streams.

I would like to have a FourCC dedicated to YUV streams (let's say MAGY) and another one for RGBs (for example, MAGR).

[Ignus2]

OK, YV24 will be first then, AYUV later.

@Kurtnoise:
What would be the benefit of having a separate FOURCC for RGB and YUV streams?

[kolak]

This is not I asked...I meant the MAGY FourCC which is in the current streams.

I would like to have a FourCC dedicated to YUV streams (let's say MAGY) and another one for RGBs (for example, MAGR).

This is what I ment.

Because it's cleaner and RGB is 'different' than all YUV.
Utvideo has different fourcc for each format.

[Ignus2]

This is what I ment.

Because it's cleaner and RGB is 'different' than all YUV.
Utvideo has different fourcc for each format.

Apart from being "cleaner", any practical reasons? :)