View Single Post
Old 12 November 2016, 13:57   #77
Registered User
Join Date: Jun 2010
Location: PL
Posts: 1,532
Originally Posted by buggs View Post
Well, the YCgCo color space is certainly appealing, not only for the lossless properties but also decorrelation abilities along with simple computation.
It is not so popular but i see some benefits using it especially on systems without modern multimedia instructions and/or without HW processing capabilities. De-correlation chroma from luma is quite frequently noted when you read about YCgCo but somehow it is used rarely (mostly in modern desktop real time capture and compression - gaming recording etc).
Side to this i think about building OCS/ECS VIDIOT (aka Video DAC) to support HW YCgCo to RGB conversion (in AGA as external module) - it can operate on analog signal so it will be possible to remove YCgCo to RGB conversion step - maybe similar principle as Archos AVideo.

Originally Posted by buggs View Post
In terms of H.264, I'm not sure whether it would really help to save cycles on a humble 68k. Correct me if I'm wrong and missed an amendment to AMD 1, but FRExt states that YCoCg is legal only with chroma_format_idc=3, i.e. 4:4:4 and at least 9 Bit for Chroma in H.264. So when the effective pixel count doubles and 8 BPP is no longer sufficient for storage, the resulting tradeoff might well swing in an unfortunate direction (when staying standards-compliant).
Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.

I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?

Additionally - YCbCr is more lossy (RGB -> YCbCr -> RGB) than YCgCo -YCbCr require between 1 - 2 bits more than YCgCo to perform fully reversible RGB conversion.
Finally i would say that we should not stuck with perfect compliant decoder for Amiga - i see no problem to create Amiga optimal format based on widely accepted standards and if possible use those standards as much as possible but in Amiga every CPU cycle count so... we can anyway pre-code videos on PC (resizer quality will be always higher quality on modern CPU - Amiga probably can do real time bilinear or cubic at best without de-gamma when PC easily may precode linearized/de-gamma video with spline + something like MSAA/FXAA to reduce aliasing and improve visual quality on low res Amiga screen).

I agree - it should be standard as much as possible but to squeeze all possible cycles perhaps it is good to select subset of codec functionality to keep healthy balance between quality\speed\compatibility.
pandy71 is offline  
Page generated in 0.07324 seconds with 9 queries