View Single Post
Old 12 November 2016, 18:22   #79
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 44
Quote:
Originally Posted by pandy71 View Post
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.
Frankly, I see the most prominent use for YCgCo in lossless applications. At least, that was the rationale behind it's inclusion into JPEG2000, IIRC.

The idea of putting an external conversion HW to the RGB port is very nerdy, if I may say so (if not pls accept my apologies). As a side note that doesn't necessarily coincide with your particular interests, YCbCr output would work with the same approach, even leading back to the good old YUV. I'd expect some artifacts having to be addressed cleverly when thinking of colorful images by means of HAM. I'd be interested to hear about such projects going forward.

Quote:
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 happen to have a functional High Profile (=100) H.264 decoder on my Amiga. Please mind my wording, though. In it's current state, it's not of much use as FMV on the classic Amiga platform. It works flawlessly (bit accurate decoding) with my test suite but as of now not in the desired time frame.

Quote:
I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?
https://www.itu.int/rec/T-REC-H.264-201602-S/en
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.
P.396 "matrix_coefficients equal to 8". Still unchanged in comparison to the 2004/2005 spec I had around.

The consideration towards bit depth boils down to the question whether one is able to handle the necessary bit rate where such details become truly relevant. The sheer abundance of computing power and storage capacity on the usual platforms these days allow that for interested parties, for sure. The classic Amiga is "a little" handicapped in this department (see below fo an example, please).

Quote:
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.
The subset I'm personally aiming for (in the long run, read: not this year) is Baseline+B-Frames. This is coincidentally the same subset used by a certain popular VOD platform. In terms of H.264, I don't see much room for compromising on the algorithms. As you of course well know, H.264 was the first standard allowing (and per se demanding) bit-accurate reproduction of the bit streams and I very much honor that as IMHO the best feature of it.

At this point, my experience on a constrained platform like 68k (even the modernized interpretation that caused some stir in Amiga-land) is that you can ill afford algorithms that have become "usual" on the modern platforms.

Just today I had to step back a bit and re-calculate on performance figures. An algorithm that just takes an average 5 cycles per pixel amounts to quite some numbers when it comes to video. So when you run video in a by current standards modest resolution of 640x360, this amounts to 1152000 cycles per frame or 28.8 MHz at a desired rate of 25 FPS. Oops. My poor A500.
buggs is offline  
 
Page generated in 0.07416 seconds with 9 queries