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. |
18th April 2014, 00:15 | #61 | Link |
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. |
18th April 2014, 02:06 | #62 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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. |
|
18th April 2014, 12:23 | #64 | Link |
Registered User
Join Date: Dec 2007
Location: Enschede, NL
Posts: 301
|
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 |
18th April 2014, 13:05 | #65 | Link |
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. |
18th April 2014, 13:14 | #66 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
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. |
|
18th April 2014, 14:03 | #67 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
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... |
18th April 2014, 18:06 | #69 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
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... |
20th April 2014, 18:37 | #71 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
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. |
24th April 2014, 02:18 | #72 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
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. |
|
24th April 2014, 10:17 | #73 | Link |
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?
|
27th April 2014, 11:42 | #74 | Link |
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). |
28th April 2014, 04:56 | #75 | Link |
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:
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. |
28th April 2014, 09:46 | #77 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
Currently manual. Is automatic needed?
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
28th April 2014, 21:01 | #79 | Link |
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... |
28th April 2014, 21:43 | #80 | Link |
Registered User
Join Date: Nov 2005
Posts: 693
|
Practise shows us it's more like ≤576p: BT.601, >576p: BT.709.
__________________
My hobby website |
Thread Tools | Search this Thread |
Display Modes | |
|
|