MagicYUV - a new fast lossless video codec - Page 5

foxyshadis · 28th April 2014, 23:45

Quote:

Originally Posted by 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.

You're decoding to an unaligned stride and not responding to a stride-change request via QueryAccept. Here's MSDN's docs. 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 · 29th April 2014, 01:37

Quote:

Originally Posted by foxyshadis

You're decoding to an unaligned stride and not responding to a stride-change request via QueryAccept. Here's MSDN's docs. 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 · 29th April 2014, 02:06

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 · 29th April 2014, 18:03

Quote:

Originally Posted by 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.

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 · 30th April 2014, 06:24

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 · 1st May 2014, 17:10

Quote:

Originally Posted by 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.

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 · 1st May 2014, 22:54

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 · 4th May 2014, 03:58

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 · 4th May 2014, 12:35

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

zerowalker · 4th May 2014, 12:42

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 · 4th May 2014, 12:53

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 · 5th May 2014, 08:32

Quote:

Originally Posted by zerowalker

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 · 5th May 2014, 10:37

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 · 5th May 2014, 18:37

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 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 · 5th May 2014, 20:36

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 · 6th May 2014, 08:10

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 · 6th May 2014, 08:42

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 · 6th May 2014, 08:48

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 · 6th May 2014, 17:23

Quote:

Originally Posted by zerowalker

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 · 6th May 2014, 18:10

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"

1st May 2014, 22:54	#87 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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. Last edited by zerowalker; 1st May 2014 at 22:57.

4th May 2014, 12:53	#91 \| Link
kolak Registered User Join Date: Nov 2004 Location: Poland Posts: 2,843	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. Last edited by kolak; 4th May 2014 at 16:04.

5th May 2014, 18:37	#94 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	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 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. Last edited by ChiDragon; 5th May 2014 at 18:41.

6th May 2014, 08:10	#96 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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? Last edited by zerowalker; 6th May 2014 at 08:23.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

29th April 2014, 02:06	#83 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,559	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.

30th April 2014, 06:24	#85 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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.

4th May 2014, 03:58	#88 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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

4th May 2014, 12:42	#90 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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).

5th May 2014, 10:37	#93 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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?

5th May 2014, 20:36	#95 \| Link
kolak Registered User Join Date: Nov 2004 Location: Poland Posts: 2,843	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.

6th May 2014, 08:48	#98 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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?

6th May 2014, 18:10	#100 \| Link
zerowalker Registered User Join Date: Jul 2011 Posts: 1,121	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"