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. |
1st April 2014, 01:29 | #41 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
After many sleepless nights and long hours of coding, the next release 0.9.1 beta is finally here.
Actually, those small things that remained after the refactoring were not so small after all But now I'm really satisfied with the result. Feature-wise, there isn't anything spectacularly new, as I mentioned I only added an option to restrict the input color space. Performance-wise I measured a 5-10% increase in encoding and 10-15% increase in decoding speed (depending on CPU type). Also, some compatibility issues were fixed with Windows 8/8.1 64 bit. As I mentioned I had to change the stream format, so videos encoded with 0.9alpha cannot be decoded with this release. I guess it has reached it's final form now, so I really hope it will stay as it is for 1.0 too. The immediate plans for/before 1.0 are:
Feature requests and bug reports are always welcome. Greets, I. |
8th April 2014, 07:31 | #43 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
Some progress report since the last release: RGB can now be compressed as YUV444, giving much better compression ratio (at the cost of the RGB->YUV conversion loss). What follows is downsampling to YUV422 and YUV420 directly. After that, I'll do interlaced video support, and that should cover the features of 1.0. My question is what YUV444 format should I support? AYUV, YV24, IYU2? -- Greets, I. Last edited by Ignus2; 8th April 2014 at 07:37. |
|
8th April 2014, 15:36 | #47 | Link |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
This is not I asked...I meant the MAGY FourCC which is in the current streams.
I would like to have a FourCC dedicated to YUV streams (let's say MAGY) and another one for RGBs (for example, MAGR). |
8th April 2014, 19:02 | #49 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
Because it's cleaner and RGB is 'different' than all YUV. Utvideo has different fourcc for each format. |
|
15th April 2014, 19:14 | #52 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
Hi!
I'll ponder on the MAGR fourcc. In the meantime, a new release is out: 0.9.2 beta. New features include:
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
16th April 2014, 23:01 | #53 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. |
17th April 2014, 20:00 | #55 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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: Code:
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 EDIT: corrected. I also got confused %) Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... Last edited by Ignus2; 17th April 2014 at 20:13. |
|
17th April 2014, 20:19 | #56 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. Last edited by kolak; 17th April 2014 at 20:36. |
17th April 2014, 20:51 | #57 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
Code:
[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 EDIT: Using the setting you mentioned (apart from Rec601/709): 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 ??? 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 I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... Last edited by Ignus2; 17th April 2014 at 21:05. |
|
17th April 2014, 21:31 | #58 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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 ☺ |
17th April 2014, 21:45 | #59 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... Last edited by Ignus2; 17th April 2014 at 21:49. |
17th April 2014, 23:33 | #60 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|