[pandy71]

Originally Posted by meynaf

That sounds very interesting, I'd like to attempt coding something in this area.
As ISO specs are difficult to find and not exactly straightforward to read, is it possible to find some reference code that would compile on Amiga ?

Link to latest published and freely available spec provided above, yes, fully agree it is difficult to read - this is a price for well standardized and truly specified codec (when compared to VP9 from Google this is huge difference).

For code that can be compiled on Amiga... my first shot would be or official reference decoder http://iphome.hhi.de/suehring/tml/ (but it will be terrible slow as it is pure unoptimized C) or ffmpeg software decoder (this one should be at least partially optimized for speed - some ASM intrinsic exist but mostly for x86 and ARM).

Originally Posted by buggs

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.

IMHO if it can help Amiga to improve decoding performance then why not using it?

Originally Posted by buggs

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.

It is less nerdy than it looks - YCgCo to RGB can be easily made with few fast (video) OPAMP's and activated by ZD signal (so pseudo overlay YCgCo on RGB is possible).
For future (dreaming) Amiga graphics HW this can be easily implemented as programmable 3x3 matrix so YCbCr and YcgCo possible fully at HW.
Partially this is also idea expressed by Jay Miner - primary idea for HAM was to use YIQ(US version YUV) color space - problem was that on Denise silicone was no place for this 3x3 matrix to perform HW 'YCnCm' to RGB conversion - it will be nice to analyze if HAM will behave better when data will be coded in YCgCo space than in RGB.

Originally Posted by buggs

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.

I would sacrifice full compliance if it can improve performance, also HP may be a bit of overkill - i think that baseline profile is perfectly fine - IMHO if Amiga will be capable to decode video created with bellow script then it will highly satisfactory from my perspective.

@setlocal
@set FFMPG=D:\Media\FF
@set PATH=%PATH%;%FFMPG%
@set FC_CONFIG_DIR=%FFMPG%\conf
@set FONTCONFIG_FILE=%FFMPG%\conf\fonts.conf
@set FONTCONFIG_PATH=%FFMPG%\conf

@set OUTDIR="out"
@if not exist %cd%\%OUTDIR% (mkdir %cd%\%OUTDIR%)

@rem H.264 bitrate and x264 config
@set vbitrate=200
@set /a vbuffsiz=%vbitrate%*1
@set /a vmaxrate=%vbitrate%*1
@set qf=16
@set gop=60

@set x264opts="crf=%qf%:vbv_maxrate=%vmaxrate%:vbv_bufsize=%vbuffsiz%:level=4.0:8x8dct=0:bframes=0:me=esa:subme=9:keyint=%gop%:qpmin=4:cabac=0:threads=auto:sliced_threads=0:interlaced=0:no_psnr=1:no_ssim=1:open-gop=0:pic_struct=1:aud=1:nal_hrd=vbr:force_cfr=1:fullrange=on:overscan=show:colorprim=undef:transfer=undef:colormatrix=YCgCo:stitchable=1"

@rem possible samplerates are for example: 28604, 23646, 22883, 22168, 15977, 11260
@set samplerate=24000

@rem possible audither are: 0,1,2,3 ('none'?‘rectangular’‘triangular’‘triangular_hp’‘lipshitz’‘shibata’‘low_shibata’‘high_shibata’‘f_weighted’‘modified_e_weighted’‘improved_e_weighted’)
@set audither=0

@rem audio signal processing
@set aproc="pan=stereo|FL < FL+1.414FC+0.5BL+0.5SL+0.25LFE+0.125BR|FR < FR+1.414FC+0.5BR+0.5SR+0.25LFE+0.125BL,firequalizer=gain='if(gte(f,20),0,-INF)+if(lte(f,11500),0,-INF)',dynaudnorm=p=1/sqrt(2):m=100:s=12,firequalizer=gain='if(gte(f,20),0,-INF)+if(lte(f,11500),0,-INF)',aresample=resampler=soxr:osr=%samplerate%:cutoff=0.990:dither_method=%audither%"

@rem video signal processing
@set vproc="pp=ac/dr,hqdn3d=5,eq=contrast=256/220:brightness=0/255:saturation=256/224:gamma=1,zscale=d=ordered:f=spline36:r=full:w=320:h=-2,xbr=2,scale=s=320x256:force_original_aspect_ratio=decrease:sws_flags=spline+accurate_rnd:sws_dither=a_dither:in_range=1:out_range=1,tblend=all_mode=average,format=pix_fmts=yuv420p"

@ffmpeg.exe -y -color_range 2 -i "%1" -sn -c:v libx264 -preset fast -tune fastdecode -profile:v high -level:v 4.0 -x264opts %x264opts% -x264-params %x264opts% -vf %vproc% -color_range 2 -colorspace 8 -c:a opus -b:a 48k -af %aproc% -f matroska "%OUTDIR%\%~n1_ycgco.mkv"

@endlocal
@pause

IMHO Amiga community should push for Opus audio codec as main modern codec capable to deal with Amiga unique audio system capabilities (Paula sample rates).

Originally Posted by buggs

P.396 "matrix_coefficients equal to 8". Still unchanged in comparison to the 2004/2005 spec I had around.

I see, indeed - missed this but... to be honest i believe it is important for broadcast usage but not for few hundreds hobbyist pursuing some FMV with 1/4 SD resolution

Originally Posted by buggs

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).



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.

I fully agree - baseline maybe with B frames but IMHO P frames only are able to deliver high quality (for 200kbps 320x180 average qp for I frames somewhere between 16 - 20 - very good IMHO) - with error introduced by HAM i don't think that this is (bit depth and fully reversible transformations) so important - QCIF FMV on 120+ MIPS - this is impressive.

Originally Posted by buggs

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.

Well - i will be happy with QCIF and 25fps + stereo 24kHz audio - on normal Amiga (ICS/OCS/ECS) this will take practically all available CHIP RAM bandwidth.

EDIT: The script below provides MPEG-1 with YCgCo color space encoding.

@setlocal
@set FFMPG=D:\Media\FF
@set PATH=%PATH%;%FFMPG%
@set FC_CONFIG_DIR=%FFMPG%\conf
@set FONTCONFIG_FILE=%FFMPG%\conf\fonts.conf
@set FONTCONFIG_PATH=%FFMPG%\conf
@set OUTDIR="out"
@if not exist %cd%\%OUTDIR% (mkdir %cd%\%OUTDIR%)

@rem MPEG-1 bitrate config
@set vbitrate=150
@set /a vbuffsiz=%vbitrate%*1
@set /a vmaxrate=(%vbitrate%*3)/2
@set qf=16
@set gop=24

@set intra="8,16,19,22,99,99,99,99,16,16,22,24,99,99,99,99,19,22,26,27,99,99,99,99,22,22,26,27,99,99,99,99,22,26,27,29,99,99,99,99,26,27,29,32,99,99,99,99,26,27,29,34,99,99,99,99,27,29,35,38,99,99,99,127"
@set inter="16,17,18,19,99,99,99,99,17,18,19,20,99,99,99,99,18,19,20,21,99,99,99,99,19,20,21,22,99,99,99,99,20,21,22,23,99,99,99,99,21,22,23,24,99,99,99,99,22,23,24,26,99,99,99,99,23,24,25,27,99,99,99,127"

@rem possible samplerates are for example: 28604, 23646, 22883, 22168, 15977, 11260
@set samplerate=24000

@rem possible audither are: 0,1,2,3 ('none'?‘rectangular’‘triangular’‘triangular_hp’‘lipshitz’‘shibata’‘low_shibata’‘high_shibata’‘f_weighted’‘modified_e_weighted’‘improved_e_weighted’)
@set audither=0

@rem audio signal processing
@set aproc="pan=stereo|FL < FL+1.414FC+0.5BL+0.5SL+0.25LFE+0.125BR|FR < FR+1.414FC+0.5BR+0.5SR+0.25LFE+0.125BL,firequalizer=gain='if(gte(f,20),0,-INF)+if(lte(f,11500),0,-INF)',dynaudnorm=p=1/sqrt(2):m=100:s=12,firequalizer=gain='if(gte(f,20),0,-INF)+if(lte(f,11500),0,-INF)',aresample=resampler=soxr:osr=%samplerate%:cutoff=0.990:dither_method=%audither%"

@rem video signal processing
@set vproc="pp=ac/dr,hqdn3d=5,eq=contrast=256/220:brightness=0/255:saturation=256/224:gamma=1,zscale=d=ordered:f=spline36:r=full:w=320:h=-2,xbr=2,scale=s=320x256:force_original_aspect_ratio=decrease:sws_flags=spline+accurate_rnd:sws_dither=a_dither:in_range=1:out_range=1,tblend=all_mode=average,format=pix_fmts=yuv420p"

@ffmpeg -y -color_range 2 -i "%1" -sn -c:v mpeg1video -profile:v 4 -level:v 8 -b:v %vbitrate%k -maxrate %vmaxrate%k -g %gop% -bufsize:v 112k -bf 0 -qcomp 0.7 -qblur 0 -qmin 2 -qmax 31 -dc 8 -lmin 0.75 -mblmin 50 -sc_threshold 0 -sc_factor 4 -me_method dia -dia_size 7 -pre_dia_size 7 -preme 5 -bidir_refine 4 -mbd rd -cmp satd -subcmp satd -mbcmp satd -precmp satd -skipcmp satd -intra_matrix %intra% -inter_matrix %inter% -vf %vproc% -color_range 2 -colorspace 8 -c:a opus -b:a 48k -af %aproc% -f matroska "%OUTDIR%\%~n1_mpeg1_ycgco.mkv"
@endlocal
@pause