Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th May 2014, 19:15   #101  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by zerowalker View Post
Ah, don't get it fully, but think i at least follow the idea;P

How is Rec.2020 then, some kind of killer or pretty much the same, And will support be added for it in MagicYUV?
I know it doesn't exist a real interest except experimentation and enthusiasm, but still it never hurts to be on the edge of things, especially since it aims to be the "4K Lossless era Codec"
Rec.2020 is 10-12 bit AFAIK. Though the Rec.2020 RGB coefficients could be used to convert RGB 8 bit to YUV 8 bit, but I don't know if it would have any meaning.

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 6th May 2014, 19:22   #102  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Oh, well that really turns of the heat. If it's meant for that i guess using it for 8bit will just cause rounding errors or something, would be quite interesting to see though.

Last edited by Guest; 6th May 2014 at 19:57. Reason: remove OT content
zerowalker is offline   Reply With Quote
Old 7th May 2014, 08:44   #103  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
There seem to be a bug i have encountered.

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

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

Is it supposed to be like that, am i missing out something, or is this a bug?
zerowalker is offline   Reply With Quote
Old 7th May 2014, 09:16   #104  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by zerowalker View Post
There seem to be a bug i have encountere.

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

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

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

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 7th May 2014, 09:22   #105  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Well that's good to hear.
I used Virtualdub Fast Recompression and made sure that it does not do any conversion, meaning MagicYUV get's feeded YV12 in this case.

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

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

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

How come it doesn't decode it correct automatically?

Also, in Mediainfo there is no way to find out what pixel type it is, which is quite troublesome, as i can't figure out afterwards what the true format is, unless i know it of course.
zerowalker is offline   Reply With Quote
Old 7th May 2014, 10:54   #106  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
I assume it will be added at some point. It makes perfect sense, specially for "4K codec". New TVs started supporting Rec2020.



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

Last edited by kolak; 7th May 2014 at 11:06.
kolak is offline   Reply With Quote
Old 7th May 2014, 14:51   #107  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
I assume it will be added at some point. It makes perfect sense, specially for "4K codec". New TVs started supporting Rec2020.

It shows way more colors than Rec709 (or DCI, which is used in cinemas) assuming your TV is capable of displaying all of them.
Rec.2020 is relevant only when doing conversion to/from RGB. Rec.601 and Rec.709 (as well as sRGB) use the same color primaries (well, almost), while Rec.2020 does not, allowing a larger color gamut. Also, Rec.2020 is for 10-12 bit.
So the question is whether it makes sense to support conversion from 8 bit RGB to YUV (Y'CbCr) using Rec.2020 coefficients, which would imply that the RGB input uses different primaries (than the usual sRGB).

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

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 7th May 2014 at 15:06.
Ignus2 is offline   Reply With Quote
Old 7th May 2014, 16:26   #108  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
Rec. 2020 uses more than 8 bits because you'll be in danger of getting banding with 8 bits as the triangle is that large.
Rumbah is offline   Reply With Quote
Old 7th May 2014, 19:52   #109  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Ignus2 View Post
Rec.2020 is relevant only when doing conversion to/from RGB. Rec.601 and Rec.709 (as well as sRGB) use the same color primaries (well, almost), while Rec.2020 does not, allowing a larger color gamut. Also, Rec.2020 is for 10-12 bit.
So the question is whether it makes sense to support conversion from 8 bit RGB to YUV (Y'CbCr) using Rec.2020 coefficients, which would imply that the RGB input uses different primaries (than the usual sRGB).

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

Greets,
I.
Nothing stop most of the panels being 10bit in a year time. It's visible trend that more and more panels support 10bit, as technology is getting cheaper and more advanced.
MagicYUV may not be only 8bit in the future neither
Support may show up when it makes sense, no need to be there now.
kolak is offline   Reply With Quote
Old 8th May 2014, 08:28   #110  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by zerowalker View Post
There seem to be a bug i have encountered.

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

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

Is it supposed to be like that, am i missing out something, or is this a bug?
I have found the reason for this BTW. Actually it is the "fault" of AviSynth. In the AviSource docs (http://avisynth.nl/index.php/AviSource) it is stated:

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

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

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 8th May 2014 at 08:31.
Ignus2 is offline   Reply With Quote
Old 8th May 2014, 10:28   #111  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Hmm, well that really is quite problematic.
As i assume many are as me and just use Avisource and think that it will be done correctly.
I find it weird however that UT Video Codec and others are decoded correctly, but i guess that don't allow upsampling?

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

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

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

Thanks!
zerowalker is offline   Reply With Quote
Old 8th May 2014, 12:14   #112  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by zerowalker View Post
Hmm, well that really is quite problematic.
As i assume many are as me and just use Avisource and think that it will be done correctly.
I find it weird however that UT Video Codec and others are decoded correctly, but i guess that don't allow upsampling?

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

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

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

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

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

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

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 8th May 2014 at 12:19.
Ignus2 is offline   Reply With Quote
Old 8th May 2014, 12:46   #113  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Ah, okay, i guess it goes to YUY2, but then again it has separate codecs so it somewhat prevents "misuse", which has it's own flaws.

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

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

Thanks!
zerowalker is offline   Reply With Quote
Old 8th May 2014, 20:22   #114  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Another thing i noticed, my Webcam can output RGB and I420, and I420 is Not supported by MagicYUV.
Now i am guessing it's because it's Interleaved and not Planar.

But even though it's rare, i think it would be handy to support that input, even if you would need to convert it to Planar (As far as i know it's lossless).
zerowalker is offline   Reply With Quote
Old 9th May 2014, 08:33   #115  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by zerowalker View Post
Another thing i noticed, my Webcam can output RGB and I420, and I420 is Not supported by MagicYUV.
Now i am guessing it's because it's Interleaved and not Planar.

But even though it's rare, i think it would be handy to support that input, even if you would need to convert it to Planar (As far as i know it's lossless).
Just did a quick lookup and I420 is identical to YV12, just the U/V planes are reversed. It is trivial to add support for that. Thanks for mentioning, I'll include it for the next release (rc2) along with the prevent settings, which should hopefully be released in the next days.

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 9th May 2014, 09:48   #116  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Splendid, grateful as always
zerowalker is offline   Reply With Quote
Old 10th May 2014, 10:26   #117  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Another thing i have wanted to ask, is it possible to add Null Frames in MagicYUV?
From my understanding, i guess it's not quite optimal as it uses prediction, and Lagarith(it has null frame, hence the reference) uses "Zip" on each frames if i remember correctly.

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

EDIT:

Noticed something that may be important.

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

I did like this.

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

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

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

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

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

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

Last edited by zerowalker; 10th May 2014 at 16:43.
zerowalker is offline   Reply With Quote
Old 10th May 2014, 17:26   #118  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Hmmm..., this is extremely weird. Thanks for the file, that is very helpful! I can reproduce it, I analyzed the compressed data, I can see what is happening, but I have no idea yet as to what is causing it. I'll investigate...

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 10th May 2014, 17:35   #119  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Great that i wasn't mistaken.

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

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

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

Last edited by zerowalker; 10th May 2014 at 18:03.
zerowalker is offline   Reply With Quote
Old 10th May 2014, 18:51   #120  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
OK, sorry, I mistook, I analyzed the file wrongly. I see what is happening. Actually dxtory is probably smart, and it automatically creates NULL frames if it sees that the codec produced the same compressed data as before (or maybe it can know that it actually fetched the same frame from the video card). As your sample has many identical frames, this is why it is happening.
You can also see in VirtualDub, that in the original compressed file, some frames are marked in the status bar as [K] (key frame) and some as [D] (null frame).
If you check "Video"->"Preserve Empty frames" and do a recompress, you will get the same size file.

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

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 10th May 2014 at 18:58.
Ignus2 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.