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 18th April 2014, 00:15   #61  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
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.
kolak is offline   Reply With Quote
Old 18th April 2014, 02:06   #62  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by foxyshadis View Post
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 18th April 2014 at 02:10.
Ignus2 is offline   Reply With Quote
Old 18th April 2014, 12:06   #63  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
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.
kolak is offline   Reply With Quote
Old 18th April 2014, 12:23   #64  |  Link
jmartinr
Registered User
 
jmartinr's Avatar
 
Join Date: Dec 2007
Location: Enschede, NL
Posts: 301
Quote:
Originally Posted by kolak View Post
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?
__________________
Roelofs Coaching
jmartinr is offline   Reply With Quote
Old 18th April 2014, 13:05   #65  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
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.

Last edited by kolak; 18th April 2014 at 13:10.
kolak is offline   Reply With Quote
Old 18th April 2014, 13:14   #66  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Code:
[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.

Last edited by kolak; 18th April 2014 at 13:44.
kolak is offline   Reply With Quote
Old 18th April 2014, 14:03   #67  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
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
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 18th April 2014, 16:34   #68  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
In the meantime UtVideo got 422 10bit support.
kolak is offline   Reply With Quote
Old 18th April 2014, 18:06   #69  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
In the meantime UtVideo got 422 10bit support.
Great work by the developer! I hope I can do it better
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 18th April 2014, 20:06   #70  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
It's quite slow and single thread at the moment I think.
kolak is offline   Reply With Quote
Old 20th April 2014, 18:37   #71  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
Quote:
Originally Posted by kolak View Post
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
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 20th April 2014 at 18:41.
WorBry is offline   Reply With Quote
Old 24th April 2014, 02:18   #72  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Ignus2 View Post
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. 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.
foxyshadis is offline   Reply With Quote
Old 24th April 2014, 10:17   #73  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
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?
kolak is offline   Reply With Quote
Old 27th April 2014, 11:42   #74  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
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).
pandy is offline   Reply With Quote
Old 28th April 2014, 04:56   #75  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
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.

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

Last edited by Ignus2; 28th April 2014 at 04:58.
Ignus2 is offline   Reply With Quote
Old 28th April 2014, 09:42   #76  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
What is your rule to use REC601?

Width<=720 or you need to set manually?
kolak is offline   Reply With Quote
Old 28th April 2014, 09:46   #77  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
What is your rule to use REC601?

Width<=720 or you need to set manually?
Currently manual. Is automatic needed?
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 28th April 2014, 09:48   #78  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
I would say so.
Automatic by default with possibility to overwrite.
I think the rule is Width<=720 use 601, otherwise 709.

Last edited by kolak; 28th April 2014 at 10:24.
kolak is offline   Reply With Quote
Old 28th April 2014, 21:01   #79  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 28th April 2014, 21:43   #80  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 693
Quote:
Originally Posted by kolak View Post
I think the rule is Width<=720 use 601, otherwise 709.
Practise shows us it's more like ≤576p: BT.601, >576p: BT.709.
__________________
My hobby website
Reino 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 21:40.


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