MagicYUV - a new fast lossless video codec

[Kurtnoise]

to have an easy way to distinguish each streams when you parse them to retrieve some infos...:)

[Ignus2]

Hi!

I'll ponder on the MAGR fourcc.

In the meantime, a new release is out: 0.9.2 beta (https://magicyuv.com/index.php/download/magicyuv/magicyuv-0-9-2beta).
New features include:

Support for new formats: YV24, Y8/Y800/GREY, AYUV
Support for selectable YUV color matrices: Rec.601 and Rec.709. This option is used when compressing RGB --> YUV. It is also saved in the encoded stream and used when decompressing YUV --> RGB.
Added encoder-side color space conversion. Only converting to a "lower" color space is allowed. Color spaces are ordered:
RGB > YUV 4:4:4 > YUV 4:0:0 for regular formats
RGBA > YUV 4:4:4 with alpha for alpha formats.


If someone could test the alpha formats that would be nice, I couldn't really do it so far :)

The encoder side conversion list is quite limited for now but all options (including YUV 4:2:2 and 4:2:0) will come soon with the next release.
I'll do these, and support for interlaced encoding, and that should hopefully finally cover 1.0 :)

--
Greets,
I.

[kolak]

To make it even more 'full' you can add Full range and Limited range settings.
There are cases when RGB data has YUV range (or opposite), so it's good to have such an option and being able to set it manually when needed.

[benwaggoner]

To make it even more 'full' you can add Full range and Limited range settings.
There are cases when RGB data has YUV range (or opposite), so it's good to have such an option and being able to set it manually when needed.
And having it flagged in the metadata so that downstream processing knows what it's getting!

[Ignus2]

To make it even more 'full' you can add Full range and Limited range settings.
There are cases when RGB data has YUV range (or opposite), so it's good to have such an option and being able to set it manually when needed.

I see. There are some questions here.
What settings would you like to have exactly (what controls with what values and how many)? Because we have to consider 24 cases in total here. Also, there must be some global setting for decoding, as a Limited Range YUV for example could be decompressed as both Full Range RGB and Limited Range RGB (not to mention also as limited YUV and full YUV), and it wouldn't be the best to store the "how to decode this video if they request RGB (or YUV)" setting in the compressed stream. Using a decoder setting, both could be done. But decoder options are global.

I'm asking, as I don't know exactly what controls to provide so it doesn't become overly confusing.

The 24 cases to consider:

When encoding (12):
Input format -> Compressed Format
Full RGB -> Limited YUV
Full RGB -> Full YUV
Full RGB -> Limited RGB
Full RGB -> Full RGB
Limited RGB -> Limited YUV
Limited RGB -> Full YUV
Limited RGB -> Limited RGB
Limited RGB -> Full RGB
Full YUV -> Limited YUV
Full YUV -> Full YUV
Limited YUV -> Limited YUV
Limited YUV -> Full YUV

When decoding (12):
Compressed format -> Output Format
Full YUV -> Limited YUV
Full YUV -> Full YUV
Full YUV -> Limited RGB
Full YUV -> Full RGB
Limited YUV -> Limited YUV
Limited YUV -> Full YUV
Limited YUV -> Limited RGB
Limited YUV -> Full RGB
Full RGB -> Limited RGB
Full RGB -> Full RGB
Limited RGB -> Limited RGB
Limited RGB -> Full RGB


I would be interested which ones of the above should be supported and how should the user be able to specify what he wants?

EDIT: corrected. I also got confused %)

Greets,
I.

[kolak]

RGB always should be full range, untill you manually set in encoder that its limited range. YUV opposite. Settings on encoder are for manual overwrite.
On decoding stage decoder reads settings used during encoding. If someone wants RGB for YUV encoded file than you do proper conversion, taking into account infomation stored during encoding, eg that file was YUV, but full range.
Same applies to HD and SD conversion matrixes (rec709/rec601). They should be set based on resolution with possibility to overwrite manually and this info should be passed to decoder also, so if RGB<->YUV conversion is needed than its done properly.

On the encoder side you need just 4 settings:
- force limited range
- force full range
- force REC709
- force REC601

If you want you can have the same for decoder, but automatically it uses info from encoding stage.
You dont need all those cases to expose to user, this is just for you to programme ☺
These 4 options on encoding and maybe decoding are enough in my opinion- they will generate all cases which you mentioned.

[Ignus2]

RGB always should be full range, untill you manually set in encoder that its limited range. YUV opposite. Settings on encoder are for manual overwrite.
On decoding stage decoder reads setting used during encoding. If someone wants RGB for YUV encoded file than you do proper conversion, taking into account infomation stored during encodeing, eg that file was YUV, but full range.
Same applies to HD and SD conversion matrixes (rec709/rec601). They should be set based on resolution with possibility to overwrite manually and this info should be passed to decoder also, so if RGB<->YUV conversion is needed than its done properly.

So there should be 2 settings on the encoder side? One for "RGB range" and one for "YUV range"? I summarized the possibilities, but the ones marked with "???" are not clear to me:

[Input] [Compressed as] [RGB setting] [YUV setting] [Input treated as] [Decoded as RGB] [Decoded as YUV]
RGB RGB FULL FULL FULL FULL N/A
RGB RGB FULL LIMITED FULL FULL N/A
RGB RGB LIMITED FULL LIMITED FULL N/A
RGB RGB LIMITED LIMITED LIMITED FULL N/A

RGB YUV FULL FULL FULL FULL ???
RGB YUV FULL LIMITED FULL FULL ???
RGB YUV LIMITED FULL LIMITED LIMITED ???
RGB YUV LIMITED LIMITED LIMITED LIMITED ???

YUV YUV FULL FULL FULL ??? FULL
YUV YUV FULL LIMITED LIMITED ??? LIMITED
YUV YUV LIMITED FULL FULL ??? FULL
YUV YUV LIMITED LIMITED LIMITED ??? LIMITED

("N/A" means that path is not possible)

EDIT: Using the setting you mentioned (apart from Rec601/709):

[Input] [Compressed as] [Force range setting] [Input treated as] [Decoded as RGB] [Decoded as YUV]
RGB RGB NONE FULL FULL N/A
RGB RGB FULL FULL FULL N/A
RGB RGB LIMITED LIMITED FULL N/A

RGB YUV NONE FULL FULL ???
RGB YUV FULL FULL FULL ???
RGB YUV LIMITED LIMITED LIMITED ???

YUV YUV NONE LIMITED ??? LIMITED
YUV YUV FULL FULL ??? FULL
YUV YUV LIMITED LIMITED ??? LIMITED


Greets,
I.

[kolak]

Its a good question: should RGB always be delivered on decoding stage as full range? In one way this is the 'correct' way and many software expect RGB being always full range.

YUV should be always limited, but does it mean we will always clip super whites/blacks?

Iam confused now also ☺
Maybe limited/full range should be only on encoding stage and on the decoder side YUV should be always converted to limited and RGB full range. Having info from encoding stage and using correct matrix would always produce correct output data. The downside is that YUV mode would never pass super whites/blacks.
We need more opinions ☺

[Ignus2]

Great, so I'm not the only one who got a bit confused :)
What is your experience BTW? I am totally inexperienced with this stuff, I don't really know workflows and situations about what range is used and when, and what is the most common need of users.

EDIT: And another question? Is it common, that users bring RGB source, compress it as YUV and need it back as RGB again? Or bring YUV source, compress, and then want it back as RGB?
For me, RGB->YUV conversion on the encoder side is the most useful, as it allows better compression ratio but I don't know about others...

Greets,
I.

[foxyshadis]

RGB restricted to 16-235 should be considered broken and faulty, not treated as a first-class option. The only time it's ever produced is by mistake, and no systems expect or correct for it (aside from generic autolevels filters). I'd advise not to include or even acknowledge it.

On the other hand, YUV video is almost always TV range, whereas YUV still pictures are almost always full range, so either is acceptable as long as it's signaled. Some MJPEG recordings use full range, for instance, as do some advanced users.

Some people do round-trip back to RGB to do compositing and other effects, since many NLEs only work in RGB; hard drive pressure means that greater compression is sometimes more important than accumulated roundoff errors. Once converted, don't pretend the video is RGB to decoders, just offer up the YUV as-is properly signaled and let the client convert back how they want, unless the client can't understand YUV at all.

I would add an option to dither to YUV, because of the banding problems straight conversions always have and to minimize round-trip losses. Optional mainly because dithering is slower.

[kolak]

Makes sense.
So, maybe just full range for RGB and both for YUV is the way to go.

If you have RGB source, but you want compress it as YUV it's fine as long as your output is 100% the same as source.

Dithering is also good idea and very important for 8bit+ formats.

Most people deal with YUV, where RGB (444) is for high end work. Once you convert RGB to YUV you hardly ever want to go back to RGB.
I work for a company where all work is done with DPXs and than this is used to create final YUV 'delivery' master for broadcadt, web etc. If anything needs to be change it's done on DPX and converted to YUV again.
Broadcast stays away from RGB. 3D, VFX, grading, keying rather stays away from YUV ☺
For this reason good RGB <-> YUV conversion is still needed.
The problem is that so often it's done badly or even wrong.

[Ignus2]

RGB restricted to 16-235 should be considered broken and faulty, not treated as a first-class option. The only time it's ever produced is by mistake, and no systems expect or correct for it (aside from generic autolevels filters). I'd advise not to include or even acknowledge it.

On the other hand, YUV video is almost always TV range, whereas YUV still pictures are almost always full range, so either is acceptable as long as it's signaled. Some MJPEG recordings use full range, for instance, as do some advanced users.

Some people do round-trip back to RGB to do compositing and other effects, since many NLEs only work in RGB; hard drive pressure means that greater compression is sometimes more important than accumulated roundoff errors. Once converted, don't pretend the video is RGB to decoders, just offer up the YUV as-is properly signaled and let the client convert back how they want, unless the client can't understand YUV at all.

I would add an option to dither to YUV, because of the banding problems straight conversions always have and to minimize round-trip losses. Optional mainly because dithering is slower.

Great! Thanks for the explanation!

About the signaling: how do you signal when decoding YUV, that it is full range? Is it even needed? If the codec gets YUV input, it just compresses bytes, it doesn't really care if it's full range or not. Up until RGB is explicitly requested when decoding, in that case of course it has to know if the original input was full or limited (the same is true for the conversion matrix).

My question is, that when compressing RGB as YUV and then decoding as YUV, what to output: full or limited? Currently it is limited, and that is what I would expect in most cases, I'm just curious if it's a valid use-case that someone would want full range YUV decoded from an originally RGB source, which was converted to YUV by the codec during compression?

Greets,
I.

[kolak]

I would keep full range. YUV full range is 'less broken' than limited RGB in my opinion. Some people like if YUV preserve super whites/blacks.

[jmartinr]

I would keep full range. YUV full range is 'less broken' than limited RGB in my opinion. Some people like if YUV preserve super whites/blacks.

That's not a good reason. For super whites/blacks you need TV range. Also, if the compression source is rgb, would you get super whites/blacks?

[kolak]

What I want is to preserve data outside 16-235 range in YUV signal. Some solutions always clip incoming data, other pass it even if format is YUV based. As you said in case of RGB source you won't get it ( at least by my logic).
In this case the only time when you get full range YUV is when source is full range YUV.
It means for any RGB source encoded as YUV we should get limited range on output.

[kolak]

[Input] [Compressed as] [Force range setting] [Input treated as] [Decoded as RGB] [Decoded as YUV]
RGB RGB NONE FULL FULL N/A
RGB RGB FULL FULL FULL N/A
RGB RGB LIMITED LIMITED FULL N/A

RGB YUV NONE FULL FULL LIMITED
RGB YUV FULL FULL FULL LIMITED
RGB YUV LIMITED LIMITED FULL LIMITED

YUV YUV NONE LIMITED FULL LIMITED
YUV YUV FULL FULL FULL FULL
YUV YUV LIMITED LIMITED FULL LIMITED



Is this what everyone is happy with?
Everything got simplified a lot:
RGB output is always full
YUV is always limited except time when YUV source is already full range.
This also means we don't need settings for decoder stage, just on encoder side.

[Ignus2]

Is this what everyone is happy with?
Everything got simplified a lot:
RGB output is always full
YUV is always limited except time when YUV source is already full range.
This also means we don't need settings for decoder stage, just on encoder side.

Great, this is what I also had in mind finally :)

[kolak]

In the meantime UtVideo got 422 10bit support.

[Ignus2]

In the meantime UtVideo got 422 10bit support.

Great work by the developer! I hope I can do it better ;)

[kolak]

It's quite slow and single thread at the moment I think.

[WorBry]

In the meantime UtVideo got 422 10bit support.

Good news ! I thought they had reached an impasse on that.

Still, looks like MagicYUV is coming on nicely :)

[foxyshadis]

About the signaling: how do you signal when decoding YUV, that it is full range? Is it even needed? If the codec gets YUV input, it just compresses bytes, it doesn't really care if it's full range or not. Up until RGB is explicitly requested when decoding, in that case of course it has to know if the original input was full or limited (the same is true for the conversion matrix).

VFW doesn't have any built-in support for that, although some conventions might exist. DXVA, Directshow, and Media Foundation rely on DXVA2_ExtendedFormat, VIDEOINFOHEADER2, or Media attribute GUIDs (http://msdn.microsoft.com/en-us/library/windows/desktop/bb970322%28v=vs.85%29.aspx). The actual values are the same across everything (MF has one extra range restriction for xRGB), and should work with all video renderers and anything else that reads them. Best of all, they have well-defined meanings for 10-bit as well as 8-bit.

Avisynth is pretty much stuck in the VFW world, but other source plugins commonly embed the headers in the LSB of the last few pixels, which can be extracted and interesting things done. (Adding extra lines or an extra frame might make more sense for a lossless plugin.) This is already done for interlace & IVTC decisions mostly. Embedding DXVA2_ExtendedFormat makes sense for those purposes and is only 224 bits long, but how to determine when you would need to isn't simple. There isn't much a standard for how to signal or embed this in Avisynth or any VFW, sadly.

If there is no signal, you just have to pick a default, and 16-235 is the default across the entire video world.

[kolak]

About YUV full range- if we can have processing which does pass it "as it", instead of clipping to 16-235 than we may not need setting for YUV Full Range. Can this be done, so it works fine, even if than we may need RGB on output? Won't it mes up black levels, etc?

[pandy]

Perhaps there is no sense to bother with quantization range (unless it help with compression - not sure what impact is for efficiency between 0 - 255 and 16 - 235).
IMHO lossless codec can be transparent (and quantization range problem can be easily fixed in render/further processing).

[Ignus2]

I'm glad to announce, that 1.0rc1 is finally out :)
New features (among various bug fixes) are:

Encoder-side conversion to YUV 4:2:2 and 4:2:0 formats
Interlaced encoding
Full Range YUV support when converting to/from RGB

This completes the planned features for 1.0 and if no major bugs arise, this will become the final 1.0 version.

Grab it from the Download page (https://magicyuv.com/index.php/download).

Greets,
I.

[kolak]

What is your rule to use REC601?

Width<=720 or you need to set manually?

[Ignus2]

What is your rule to use REC601?

Width<=720 or you need to set manually?

Currently manual. Is automatic needed?

[kolak]

I would say so.
Automatic by default with possibility to overwrite.
I think the rule is Width<=720 use 601, otherwise 709.

[Ignus2]

Hi!

I have a problem, I would like to get a bit of help from someone who is familiar with the workings of DirectShow.

The problem I have:
Using GraphStudioNext, I noticed, that when decoding certain MagicYUV compressed files, a Color Space Converter gets inserted sometimes. The problem is, that not always, and it seems it is resolution dependent.
What makes it really strange, is that for example an RGB compressed stream with 1920x1080 resolution is fine, the codec decompresses as RGB32 and it goes straight to the Video Renderer. But if I take a 1916x1076 resolution file, decode as RGB32, I get a CSC. And the most interesting part is, that looking at either end of the CSC pins, they have EXACTLY the same type. Everything matches, resolution, RGB32, frame size, etc. So it seems like it's there to do nothing, but I still get it.
This happens for other resolutions as well.

I have no idea sadly what might be causing this, so if someone could help me out, I would be really grateful.

Thanks!

I.

[Reino]

I think the rule is Width<=720 use 601, otherwise 709.Practise shows us it's more like ≤576p: BT.601, >576p: BT.709.

[foxyshadis]

Hi!

I have a problem, I would like to get a bit of help from someone who is familiar with the workings of DirectShow.

The problem I have:
Using GraphStudioNext, I noticed, that when decoding certain MagicYUV compressed files, a Color Space Converter gets inserted sometimes. The problem is, that not always, and it seems it is resolution dependent.
What makes it really strange, is that for example an RGB compressed stream with 1920x1080 resolution is fine, the codec decompresses as RGB32 and it goes straight to the Video Renderer. But if I take a 1916x1076 resolution file, decode as RGB32, I get a CSC. And the most interesting part is, that looking at either end of the CSC pins, they have EXACTLY the same type. Everything matches, resolution, RGB32, frame size, etc. So it seems like it's there to do nothing, but I still get it.
This happens for other resolutions as well.

I have no idea sadly what might be causing this, so if someone could help me out, I would be really grateful.

Thanks!

I.

You're decoding to an unaligned stride and not responding to a stride-change request via QueryAccept. Here's MSDN's docs. (http://msdn.microsoft.com/en-us/library/dd388901%28VS.85%29.aspx) This doesn't show up in GraphStudioNext because that biWidth is only passed during the graph creation; only the real biWidth is seen after that. There may not be anything you can do about this from the AVI decompressor, I don't know VFW well.

[Ignus2]

You're decoding to an unaligned stride and not responding to a stride-change request via QueryAccept. Here's MSDN's docs. (http://msdn.microsoft.com/en-us/library/dd388901%28VS.85%29.aspx) This doesn't show up in GraphStudioNext because that biWidth is only passed during the graph creation; only the real biWidth is seen after that. There may not be anything you can do about this from the AVI decompressor, I don't know VFW well.

That was my suspicion after searching for a while, in the meantime I also found that article.
Sadly, the AVI Decompressor doesn't seem to pass down the stride info, it always passes biWidth as the real width.
Maybe it has compatibility reasons, probably VFW was never meant deal with aligned strides :/

Thanks for the help!

Greets,
I.

[foxyshadis]

Do you plan on releasing a DirectShow or Media Foundation codec? You should be able to put all the interfaces within the same dll, too, and it would be handy for some scenarios, like DShow video capture.

[Ignus2]

Do you plan on releasing a DirectShow or Media Foundation codec? You should be able to put all the interfaces within the same dll, too, and it would be handy for some scenarios, like DShow video capture.

For the near future, no. VFW is like a common base for a lot of applications. Very old, very inflexible, but for an intraframe lossless codec, it is sufficient. It would be nice to have native DShow filter, but it is not among the plans for the foreseeable future.

BTW, can't DShow capture use AVI Compressor filter for compression the same way as AVI Decompressor is used for decompression?

Greets,
I.

[zerowalker]

Does VFW in itself do any limitations to Codecs, i mean performance wise etc?
Cause i always read that it's ancient and no good, but as it's always used i can't imagine there to be anything directly wrong with it, except that perhaps it's hard to adapt to stuff, but also hard to replace as it's so common (Like DirectX in the Graphic world).

A bit off topic, but as it was mentioned, also i mean to direct this towards Lossless rather then lossy which often has it's own design.

[Ignus2]

Does VFW in itself do any limitations to Codecs, i mean performance wise etc?
Cause i always read that it's ancient and no good, but as it's always used i can't imagine there to be anything directly wrong with it, except that perhaps it's hard to adapt to stuff, but also hard to replace as it's so common (Like DirectX in the Graphic world).

A bit off topic, but as it was mentioned, also i mean to direct this towards Lossless rather then lossy which often has it's own design.

Apart from the performance problem above, like not being able to efficiently decode to specially allocated buffers, the biggest limitation of VFW is the one frame in one frame out mechanism. It is not possible to do pipelinig with that, which is not a concern for CPU processing, but could be very handy for GPU encoding.

It is easy to develop for VFW and it is widely supported, but basically those are it's only advantages.

Greets,
I.

[zerowalker]

Ah so it has performance issues, not sure how it works, but all in all that doesn't bode to well, especially as VFW is currently as common as anything can be, like mp3 for Music i guess.

Don't even know applications that use other interfaces, though i primary use Virtualdub, and then again i only know how to use VFW.

Thanks for telling, hopefully you can add other interface support sometime you think it matters, as the codec itself is probably the main focus as that increases performance/usefulness overall.


Edit:

Oh also, Lagarith is another lossless codec which you probably know of, and it has some extremely well compression when it comes to Pixelated videos, like old games, where the resolution is low, and even if you increase it, as long as it's "Nearest Neighbor" it still compresses very well.

Can MagicYUV do this as well, i doubt it can as it's probably to do with the bitstream or something, but if possible it would be great, else Lagarith itself fit's into that of course.

[zerowalker]

Noticed talk about Rec.709 etc and how some want it to go with the width < 720 = Rec.601, so would like to put a suggestion to this.

UT Video Codec has Rec.601/709 separate (it also has it's formats separate, which may be handy), and i find that pretty appropriate, as for example, there is no actual rule that says when it's Rec.601 or 709,
you normally just say, "If it's Not HD, than it must be Rec.601", this is in most cases true, but not always.

In the TV world, i think that term is always true (may be wrong), but in the PC world it's not,
if you record something on the PC (not talking capture cards here), it will always be Rec.709 as far as i know, doesn't matter the resolution.

While separate Devices, Webcams, Capture cards etc probably follow the rule more or less.

That's why it may be handy to have Rec.709 and Rec.601 separate, if you record on the PC (Gaming etc) you always want Rec.709, and it would be quite messy to always change the settings if you also use Virtualdub,
to capture Webcam or other stuff that may use Rec.601.

Well, think i went overkill with the wall of text, but hope it makes some sense, at least it does to me;P

[STaRGaZeR]

PC is RGB, not YUV, so neither 709 nor 601.

[zerowalker]

Oh, skipped some lines there.

Yes PC is RGB, i meant that when you encode it to YUV Rec.709 produces the correct color.

However, i tried MagicYUV after this, and both 601/709 look identical, so this just get's me confused.
Pretty sure that all other codecs, at least Lagarith and UT Video produces wrong colors if they are Rec.601 (Lagarith is forced at that).

[kolak]

It makes sense, but if we have rules, possibility to ovewrite and info is stored in the headers for the decoding stage than there is no need for a separate fourCC.
601/709 looks very similar and on some frames you can't really tell the difference, untill you flip between them.

[STaRGaZeR]

Yes PC is RGB, i meant that when you encode it to YUV Rec.709 produces the correct color.

It's not like you're implying. If you have RGB you have RGB, there is no "correct" way to convert it to YUV. You're probably referring to the fact that Fraps (a specific codec) converts that RGB to YUV using always 709 when encoding in YUV mode, regardless of resolution. This is true, but it's a Fraps thing, nothing general.

[zerowalker]

Hmm, i really don't get it anymore;S

I mean, sorry for a bit off topic, but, let's say i have something that's RGB, anything at all.

If both Rec.601/701 is "correct" when downsampling, why does different versions even exist?

I thought that Rec.601 is and old version, and Rec.709 is an updated, meaning it contains, more colors or information etc, and then Rec.2020(or what the name was) is the latest and greatest?
But if all achieve the same thing, and the information is only there to tell it (Decode it with this and it will look correct), it doesn't make sense to have more than one?

Am i missing something here, or can you just skip and use one of them for everything?

[ChiDragon]

Rec.601 and Rec.709 describe slightly different "triangles" in the whole space of all possible colors, and Rec.2020 describes a vastly expanded one (this page (http://www.soundandvision.com/content/podcast-45-david-reisner) has a diagram representing the gamut of 601 vs 709 -- elsewhere you can find ones comparing 709 to 2020). To see a difference between an RGB image correctly matrixed to/from 601 vs 709, I believe you would need to pick one with colors that are encompassed by only one of those two triangles and a display capable of rendering them correctly.

There is a lot of debate about the reasoning behind Rec.709 and whether the benefits outweigh the issues, but 2020 has the clear goal of being able to represent a larger color gamut.

[kolak]

601 was chosen with CRT technology in mind, where 709 for Plasmas/LCDs. Small differences are due to different nature of display technologies.
Rec2020 is very new and currently there is not a single publicly available display which can cover its whole spectrum.

[zerowalker]

But if you take an image from your PC, then convert it to YV12 or something.
The Recxxx doesn't even matter, the result will be the same as long as you decode it to RGB with the correct flag.

This is what i don't get, they look identical.

If the only way to see the differences is playing around with color triangles etc, then that doesn't make any sense, at least when it comes to simple RGB-> YUV.

EDIT:

Okay actually looked more carefully, there is a difference that is viewable, so forget the "Identical" part.
Can't say which one looks best though, both get gradients of different kinds and handle some parts differently,

But, i am guessing Rec.709 should be overall better as it's an improved Rec.601?

The point of them is to increase the colors right, meaning it get's closer to RGB?

[STaRGaZeR]

If you convert RGB to YUV with a specific rec and then back to RGB with the same rec you shouldn't see any significant difference between both RGBs. At least I am yet to meet someone that can tell which matrix was used in a conversion, or that there was a conversion in the first place, when faced with both the original RGB and the properly reconstructed RGB after the RGB->YUV->RGB conversion. If you see significant differences, then you're probably doing something wrong. Use 4:4:4 for comparisons obviously.

[zerowalker]

Yeah did that just now, and as said, the only thing that's really different, are dark areas, where gradients show, these parts will alter.
I can't however tell which is right or which is wrong, but it differs, but in bright normal colors, the difference is pretty much non-existent to what i can see.

However, as discussed before, though with Lagarith if i remember correctly, it would be interesting to see support for YCoCg, it's an interesting format, however it's never really used.
But if my memory serves correctly, it's like YUV but losslessly reversible to RGB, or something along the line?

[kolak]

But, i am guessing Rec.709 should be overall better as it's an improved Rec.601?
The point of them is to increase the colors right, meaning it get's closer to RGB?

If you watch it on LCD/Plasma than in theory yes. If you want to watch it on old CRT TV than in theory 601 is better for it. In practice difference is very small and covered by compression :)

[zerowalker]

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":)