The Future: Odroid N2

Sorry I don’t have Avatar.

I meant something with small text on the screen so we can check if it is just this encode.

Just have a look at the end credits of something. I can’t see anything wrong here.

I kinda get a feeling that this is color bleeding.
Maybe the video is 10bit HEVC but flagged as 8bit?

Ok so I dusted off my blu-ray copy of Avatar and used Handbrake to encode the same section using h265 at 3 different quality levels and they all playback perfectly on my N2 with no bluring of the text.

Avatar_RF_25_LQ.mkv (1.4 MB)
Avatar_RF_22_Default.mkv (2.2 MB)
Avatar_RF_19_HQ.mkv (3.6 MB)

1 Like

Good man. Non-issue as expected, just a dodgy encode.

Well no not exactly a non-issue… There’s still the fact that the sample @supersnail provided plays back perfectly fine on both PC and my TV’s internal media player so I thinks there’s definitely some issue with that particulate encode that only affects amlogic hardware.

That’s the big question. Some feature is either not supported or there is a bug regarding these encodes. It’s gonna be a bitch to debug. If we could find out how the sample with this issue was encoded maybe we find the reason.

Mediainfo :
Encoding settings : cpuid=1111039 / frame-threads=1 / numa-pools=none / no-wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=19.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=1071:1072 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei

These are the encoder differences between the problem sample and my working Handbrake encode

Capture

was incorrectly encoded, probably on purpose IMO.

Have you playbacked this N2_TV_weird_sample.mkv I uploaded two days ago?

No sorry. Day doesn’t have enough hours.

I uploaded another N2_sttuer_Sample_ 2160p Atmos TrueHD7 1 x265 10bit-4.mkv
and theDebug log

Yeah it skips like hell

Yes, A lot of UHD movies in my nas playback with N2 stutters

We will look into it. It is definitely a bug. Thanks for reporting it.

This seems to play fine on mine.
I wonder if this is related to dynamic_buf_num_margin value. I’ve set mine to 16.
Iirc, default value on N2 is 7 (?)

/sys/module/amvdec_h265/parameters/dynamic_buf_num_margin

Good idea.

I think that some encoder settings just don’t play very well with the hardware decoding block in AML chips. I think that the decoder in G52 is the same as older chips or similar.
I seen a couple of H264 encodes that pixelate and stutter with hardware decoding, but work fine on a PC (with HW decoding), the TV player or on the N2 with SW decoding. Not sure what the solution for this is, but it’s a real problem I believe.