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 1st April 2014, 01:29   #41  |  Link
Ignus2
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:
  • Selectable Rec.601/Rec.709 conversion parameters for YUV input (used when doing direct RGB output)
  • Interlaced input option
  • Color space conversion on the encoder side (direct compression from RGB to YUV)

Feature requests and bug reports are always welcome.

Greets,
I.
Ignus2 is offline   Reply With Quote
Old 1st April 2014, 13:02   #42  |  Link
Gargamel
Registered User
 
Gargamel's Avatar
 
Join Date: Aug 2010
Location: Bretagne, France
Posts: 48
Thank you, Ignus2, and congratulations.
But take care of your health... at least till the v.1.0 !
Gargamel is offline   Reply With Quote
Old 8th April 2014, 07:31   #43  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by Gargamel View Post
Thank you, Ignus2, and congratulations.
But take care of your health... at least till the v.1.0 !
Thanks, I'll try!

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.
Ignus2 is offline   Reply With Quote
Old 8th April 2014, 08:19   #44  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Hi,

Is it possible to have different FourCCs ? I mean, one FourCC for YUV streams and another one for RGB ?

Thanks in advance.

Last edited by Kurtnoise; 8th April 2014 at 12:19.
Kurtnoise is offline   Reply With Quote
Old 8th April 2014, 12:16   #45  |  Link
EncodedMango
Registered User
 
Join Date: Jun 2013
Posts: 65
Quote:
Originally Posted by Ignus2 View Post
My question is what YUV444 format should I support? AYUV, YV24, IYU2?
YV24 vote here.
EncodedMango is offline   Reply With Quote
Old 8th April 2014, 14:23   #46  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Kurtnoise View Post
Hi,

Is it possible to have different FourCCs ? I mean, one FourCC for YUV streams and another one for RGB ?

Thanks in advance.
+1 for this.

YV24 I think is most common.
kolak is offline   Reply With Quote
Old 8th April 2014, 15:36   #47  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
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).
Kurtnoise is offline   Reply With Quote
Old 8th April 2014, 17:14   #48  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
OK, YV24 will be first then, AYUV later.

@Kurtnoise:
What would be the benefit of having a separate FOURCC for RGB and YUV streams?
Ignus2 is offline   Reply With Quote
Old 8th April 2014, 19:02   #49  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Kurtnoise View Post
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).
This is what I ment.

Because it's cleaner and RGB is 'different' than all YUV.
Utvideo has different fourcc for each format.
kolak is offline   Reply With Quote
Old 8th April 2014, 19:06   #50  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
This is what I ment.

Because it's cleaner and RGB is 'different' than all YUV.
Utvideo has different fourcc for each format.
Apart from being "cleaner", any practical reasons?
Ignus2 is offline   Reply With Quote
Old 9th April 2014, 07:30   #51  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
to have an easy way to distinguish each streams when you parse them to retrieve some infos...
Kurtnoise is offline   Reply With Quote
Old 15th April 2014, 19:14   #52  |  Link
Ignus2
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:
  • Support for new formats: YV24, Y8/Y800/GREY, AYUV
  • Support for selectable YUV color matrices: Rec.601 and Rec.709. This option is used when compressing RGB --> YUV. It is also saved in the encoded stream and used when decompressing YUV --> RGB.
  • Added encoder-side color space conversion. Only converting to a "lower" color space is allowed. Color spaces are ordered:
    RGB > YUV 4:4:4 > YUV 4:0:0 for regular formats
    RGBA > YUV 4:4:4 with alpha for alpha formats.

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...
Ignus2 is offline   Reply With Quote
Old 16th April 2014, 23:01   #53  |  Link
kolak
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.
kolak is offline   Reply With Quote
Old 17th April 2014, 18:10   #54  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by kolak View Post
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.
And having it flagged in the metadata so that downstream processing knows what it's getting!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 17th April 2014, 20:00   #55  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
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.
I see. There are some questions here.
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
I would be interested which ones of the above should be supported and how should the user be able to specify what he wants?

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.
Ignus2 is offline   Reply With Quote
Old 17th April 2014, 20:19   #56  |  Link
kolak
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.
kolak is offline   Reply With Quote
Old 17th April 2014, 20:51   #57  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by kolak View Post
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 setting used during encoding. If someone wants RGB for YUV encoded file than you do proper conversion, taking into account infomation stored during encodeing, 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.
So there should be 2 settings on the encoder side? One for "RGB range" and one for "YUV range"? I summarized the possibilities, but the ones marked with "???" are not clear to me:
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
("N/A" means that path is not possible)

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
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:05.
Ignus2 is offline   Reply With Quote
Old 17th April 2014, 21:31   #58  |  Link
kolak
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 ☺
kolak is offline   Reply With Quote
Old 17th April 2014, 21:45   #59  |  Link
Ignus2
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.
Ignus2 is offline   Reply With Quote
Old 17th April 2014, 23:33   #60  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
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.
foxyshadis 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 09:04.


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