Posts by noggin

  • Intel true 10bits/HEVC/HDR support... ?

    Quote from pletopia

    chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

    So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

    Off topic - but the initial support I've seen for HDR on the Pi 4B means that it detects an ST.2084/PQ or ARIB-B67/HLG EOTF flagged (i.e. HDR10 or HLG) in a video file and correctly flags this over HDMI.

    However at the moment it doesn't correctly detect and/or flag Rec 2020 video - so Rec 2020 content is output flagged as Rec 709 (or not flagged as Rec 2020). I've not been able to check whether a Rec 2020 or Rec 709 YCbCr->RGB conversion matrix is used for Rec 2020 video (They aren't the same)

    At the moment I believe video output is restricted to RGB 8-bit too - so no 10-bit replay path yet.

    So you get the correct EOTF flagged, but not the correct Colour Gamut, and with 8-bit not 10-bit or 12-bit output.

    It's very early days - and the Pi Developers work through things methodically to deliver the best results they can with their available effort.

    Quote from smp

    On Gemini Lake 2160p60Hz is only possible with RGB 8-bit (default), YCbCr 4:4:4 8-bit (with a driver hack).

    I'm not sure if YCbCr 4:2:0 12-bit could be enabled with a hack or otherwise. 4:2:2 is not supported by the driver.

    It is possible to enable GPU dithering for 8-bit modes (with a driver hack). It certainly eliminates the banding on my test videos and looks ok to me.

    Good news that 2160p60 is now supported.

    YCbCr in 4:2:0 10-bit or 12-bit would be a good route to full 10-bit HDR output I guess. Dithering is a compromise that adds noise to hide banding. (Is the dithering done at output frame rate or source frame rate?)

  • Intel true 10bits/HEVC/HDR support... ?

    Quote from lrusak

    It's very unlikely you can hear a difference between HD audio formats and LPCM :)

    However it's entirely possible that you can hear the difference between an AVR decode that also has the right metadata available to it to assist in additional processing (DialNorm, dynamic range compression information etc.) that is present in the bitstreamed version and an upstream decode to PCM where that metadata is discarded and not available to the AVR.

    Dolby and DTS audio streams contain that metadata to allow the AVR to 'know' more about the audio than just the basic audio stream content.

    The other big difference is that Atmos and DTS:x aren't carried as basic PCM - so that's another major reason to favour bitstreaming/passthrough over PCM decode upstream.

  • RPi4 testbuild with HDR support

    Quote from mfleigle

    All of my HDR content is washed out. Is there a setting I need to get hdr working? I've tried the nightlies from the last few days only.

    EDIT: I just noticed its a known problem, but I don't understand why it works for some people and not others.

    I think some people may not see the gamut mismatch - where Rec 2020 content (which is pretty much all the HDR10 and HLG out in the wild apart from DIY stuff) designed for much wider gamut primaries is displayed with Rec 709 primaries (giving you far less vibrant colours)

    If you aren't comparing with the content displayed properly - you may not see it as an issue. (Or maybe some TVs automatically go into Rec 2020 mode, incorrectly, when they see an HDR EOTF flagged over HDMI, even if there isn't a Rec 2020 flag present)

  • RPi4 testbuild with HD audio passtrhough (Atmos etc)

    Quote from lolek

    Froggy please read this topic and also this one:

    Nightly builds Rpi4 Audio passthrough TrueHD/Master HD not working (huge stutter) anymore

    In general, the test builds of libreelec are capable of handling 4k uhd, atmos passthrough but there are still some issues.

    Yes. Worth pointing out that the only codec supported at 4K UHD is h.265/HEVC (h.264/AVC is still only supported for 1080p (*)) and that a lot of UHD h.265/HEVC content is also HDR10.

    HDR replay is still very much a work-in-progress on the Pi 4B. They have HDR modes being triggered on TVs (i.e. the HDMI signals an HDR10 or HLG EOTF) but they have still got issues flagging Rec 2020 instead of Rec 709 primaries (so images look less colourful), and the output of 10-bit video is still 8-bit RGB (so you will potentially see banding, which 10-bit is designed to minimise)

    (*) h.264/AVC decoding is handled by the legacy video decoder module that is largely the same as that on the previous generations of Pi, h.265/HEVC support was added via a separate module. (MPEG2 and VC-1 support is now software only, as the Pi foundation don't offer hardware decode licences for these codecs for the Pi 4B)

  • Nightly builds Rpi4 Audio passthrough TrueHD/Master HD not working (huge stutter) anymore

    Quote from chook55

    The encode option wasn't displayed in advanced or expert profile in the passthru section until I did a return to default values. To my surprise it appeared. bug maybe? Anyhow The transcoding works well. Just an observation. the screen blanks momentarily when changing settings.

    Thanks again.

    Chook

    The Enable Transcode option may only appear if you have 2.0 output configured - as otherwise it is assumed that you'd prefer the higher quality PCM 5.1 output option I think. (The 2.0/5.1/7.1 output setting is really your PCM/analogue output config and isn't related to your passthrough/bitstream speaker config).

    If you are using Toslink or ARC which is similarly limited to PCM 2.0 and SPDIF/Toslink bandwidth DD/AC3 (and in some cases DTS) then configuring for 2.0 should bring up the option for transcoding to DD/AC3 underneath the Bitstream DD/AC3 option.

  • RPi4 testbuild with HDR support

    OK - have installed the latest nightly LibreELEC-RPi4.arm-9.80-nightly-20210220-f768c9b downloaded this morning.

    Running in 1080p mode (to allow >30fps content to be output) my 2160p50/59.94 files largely play - and HDR10 Rec 2020 stuff is played with a PQ ST.2084 EOTF (aka HDR10 HDR) but the output is 8 bit RGB and it looks as if it is being flagged as Rec 709 gamut (so colours are less vibrant as they are using the narrower primaries).

    Content I have that flags 1000, 4000 and 10000 nit mastering displays correctly sends this metadata (as confirmed by my HD Fury Vertex)

    I'm playing the content from a Samsung Evo+ 64GB uSD card and I'd say I'm getting some dropped frames on p50 and p59.94 content - though whether this is throttling because of high bitrate on the storage or on the HEVC decode and scale down to 1080p I can't say.

    I've yet to see any YCbCr 4:2:2 output at any bit depth - I don't know if there is a config.txt or LibreElec setting (or something I can type in at command line level via SSH) to enable YCbCr 4:2:2 output?

    HLG content appears to correctly trigger an HLG EOTF (i.e. ARIB B-67 EOTF) - though AIUI BBC iPlayer 1080p SDR and 720p-2160p HDR streams (iPlayer uses HLG for HDR) may now be DRMed preventing playback on non-certified devices.

    I can force my TV into Rec 2020 gamut and that makes things look quite a lot better - though I can't say whether Rec 709 or Rec 2020 YCbCr->RGB matrices are being used (the differences are quite small between the two)

    I can also only play a couple of files before playback stops working (I get left in the GUI with a play icon top of frame with the name of the file being played, but no video and have to reboot)

  • RPi4 testbuild with HDR support

    If your AVR has HDMI 2.0 support but only supports HDCP 1.4 (and not HDCP 2.2) then that could mean it was one of the first gen UHD AVRs that had HDMI 1.4 inputs and outputs in hardware terms but that got very basic HDMI 2.0 support added (in the same way nVidia added HDMI 2.0 support to their HDMI 1.4 Graphics cards and Sony added HDMI 2.0 to existing HDMI 1.4 UHD TVs via a software upgrade)

    The way they did this was to add support for just the 4:2:0 HDMI 2.0 mode for 2160p50 and 2160p60 modes - as HDMI 1.4b already supported 2160p23.976-30 at 8-bit in SDR using 4:4:4/RGB and 12-bit using 4:2:2 (though this mode may not have been supported).

    Using the 4:2:0 subsampling introduced with HDMI 2.0 allowed HDMI 2.0 4:2:0 2160p50 and 60 modes to fit into the hardware restrictions of an HDMI 1.4b connection (i.e. you could add HDMI 2.0 basic compatibility using HDMI 1.4b hardware). AIUI this was 8-bit SDR only, and that may also have been true of the HDMI 1.4b 2160p30 and below support also supported. (i.e. you get UHD support at all frame rates in 8-bit, but you don't get HDR support as that would require 10 or 12-bit support - which may not be implemented)

    The Pi 4B doesn't support 4:2:0 HDMI output as I understand it (as it would require both vertical and horizontal subsampling of chroma - and the Pi can only really do horizontal (?)

    This may also mean your AVR is not HDR compatible ("passthrough" in AVRs isn't helpful in that regard)

    The lack of HDCP 2.2 support is a strong suggestion that your AVR is one of those early HDMI 1.4 models that got a partial upgrade to HDMI 2.0 - though I may be wrong.

  • RPi4 testbuild with HDR support

    Quote from HiassofT

    noggin thanks a lot for testing, this is in line with my suspicion (video driver using the wrong transformation matrix). Not 100% sure why 10/12bit output isn't automatically enabled, could be that we need to explicitly request it.

    Regarding subsequent playback issues: Which testbuild did you use? The one from the first post (from Feb 5) or the one from here RE: RPi4 testbuild with HDR support (Feb 10)? The later build contains some important fixes that may be related.

    If you got that issue with the newer build please post a log (ssh in, run "pastekodi" and post the URL) and ideally a link to a sample file so I can try to reproduce that locally.

    so long,

    Hias

    I was using the one from the first post (5th Feb) in this thread. I'll download the new one you linked to and see what happens.

  • RPi4 testbuild with HDR support

    Disabling 2160p output modes in the whitelist and playing back a 2160p HDR10 file I get 1080p RGB 8bit output for HDR 10, with an ST 2084 EOTF flagged. I haven't seen >8 bit depth or YCbCr output so far.

    Without doing a bit more digging I can't easily see on my HD Fury OSD whether Rec 2020 or Rec 709 gamut is being signalled - but looking at the output it looks like it's in the wrong gamut as expected. (i.e. Rec 709 primaries rather than Rec 2020 are being flagged or assumed by my display). It's also not instantly easy to tell whether Rec 2020 or Rec 709 YCbCr->RGB matrix co-efficients have been used for the YCbCr to RGB conversion (Rec 2020 has different YCbCr<->RGB conversion matrix values to Rec 709, just as Rec 709 HD and Rec 601 SD (*) differ from each other)

    (WRT to Rec 2020 - I don't think much content uses YcCbCCrc which is the constant luminance-based option - I think all mainstream content, other than DV single-stream, which isn't going to be relevant here, is 4:2:0 YCbCr - output on most consumer players as 4:2:2 12-bit YCbCr)

    Also - only the first 2160p HDR file I play correctly plays. Subsequent files fail to play (I get audio but only see the file list GUI and have to reboot)

    (*) Rec 601 even, technically, has different RGB primaries, and thus gamuts, for the 525/480i and 625/576i variants due to the NTSC and PAL legacies before them... (And Japanese NTSC and North American NTSC have different white points...)

  • RPi4 testbuild with HDR support

    I'll see what Gamut (Rec 709 vs Rec 2020) the HD Fury reports.

    I'll also see what bit depth I get if I remove 2160p modes from the whitelist.

    I've got test signals with various CLL values so can also check those when I get a chance.

    Is HLG HDR flagging supported too - or is it just PQ HDR currently?

  • RPi4 testbuild with HDR support

    Just tried the .tar linked in the first post here. I get 2160p23.976 HDR10 HEVC stuff playing back with an HDR PQ EOTF flagged and HD Audio bitstreamed.

    However the video output is only 8-bit not 10-bit according to my HD Fury Vertex, so although the TV is in HDR mode and displaying HDR video content with the correct EOTF - there will potentially be banding as the 10-bit source video is being truncated to 8-bits? (If dithering is used this might be partially masked though)

    Is there supposed to be 10-bit 4:4:4/RGB or 12-bit 4:2:2 output implemented, to allow 10-bit content to be output in 10 or 12-bit - or is this test build just to get correctly flagged EOTFs?

    I notice I'm not offered 2160p50 or 2160p59.94 output options in Kodi and when I play 2160p50/59.94 content rather than output it 1080p50/59.94 - I get no video replay at all. (I understand the Pi can't output 2160p50/59.94/60 with 4:2:0 - so for HDR 10-bit content at p50 and higher 4:2:2 12-bit will be the only option for preserving 10-bit?)

  • Raspberry Pi 4: Audio problems playing TS streams

    Quote from NJPUSA

    Yep, fixed it for me, TV was unwatchable with interlacing enabled - juddering and out of sync mess. Rpi4 + TVHeadend. Switched to a totally different system (Xbian) because it was driving me nuts. Didn't make any sense at all that it could play a 160GB 4k video but not 1080i/480i TV. Tried three different PVR backends/frontend over the last few days!

    :thumbup::thumbup::thumbup::thumbup::thumbup:

    Worth remembering that h.264 and interlaced content are handled by totally separate parts of the Pi4B SoC to h.265/hevc. The h.264/interlaced stuff is decoded and deinterlaced by the legacy VPU that remains the same as the Pi 3B+ and before, whereas the hevc/h.265 decoder is a separate unit and handled separately. I believe some builds at the moment are not handling stuff particularly effectively using the old decoder?

  • Intel true 10bits/HEVC/HDR support... ?

    Quote from powerarmour

    I still find it admirable that folks are persisting with these technically dead Intel platforms when there are fully functional ARM alternatives available, waiting for working HDR on x64 is like waiting for this pandemic to end.

    I guess the benefit of Intel in speed terms is worthwhile - I switched to AMLogic platforms as my main daily driver and miss the snappiness of my Intel boxes. That said - the Apple TV 4K SoC is a beast - it software decodes stuff that the other ARM platforms just choke on (38Mbs 1080i25 4:2:2 h.264 with deinterlacing is do-able on an ATV 4K in software)

  • RPi4 testbuild with HD audio passtrhough (Atmos etc)

    My understanding is that HDMI 1.4 audio has a max spec of 8 channels of 192kHz / 24 bit uncompressed PCM audio - which gives a max audio output bit rate of :

    8 x 192000 x 24 = ~ 36.9Mbs

    I guess any buffering for HDMI audio should be considering that as the top audio bitrate that HDMI can carry?

    My understanding is that 8 x 192 x 24 is also the spec that is required for lossless compressed HD Audio to be carried over HDMI - which is why the Raspberry Pi 3B+ and earlier can't carry HD Audio - as they could only carry 4 x 192 x 24 bit (or 8 x 96 x 24 bit) which doesn't guarantee enough bitrate for the peaks of HD Audio lossless compressed content (which may not compress hugely on very complex content?)

    Dolby True HD and DTS HD MA sound tracks are usually lossless compressed 8 channels at 48k 24 bit (some are 96k and a very small number are 192k) which gives an uncompressed bitrate of around 9Mbs (or 18Mbs if 96kHz is used), however releases like Akira can contain 6 channel 192k 24 bit tracks (and 8 channel is theoretically allowed).

    For very complex audio the lossless compression used by DTS HD MA and Dolby True HD may not deliver huge bandwidth savings - and if you add in Atmos and DTS:x data as well on newer tracks this will also increase the bitrate a bit I guess?

  • Compute Module 4 for Slice in the near future?

    Quote from chewitt

    I think it was a "timing" problem more than anything else. Not long after Slice launched (late) RPi2 came along, and the lack of CM2 card meant the specs looked weak, and then RPi3 arrived to drive nails further into the coffin. CM3 eventually caught up, but that was some time later again and by that point the day-jobs of the "Five" had also multiplied via Pi success and the company they'd formed hadn't sold enough product volume to really be viable. These days the Pi Foundation owns the IP/designs, but while I think having them create/release an "official" HTPC box would be good for their own sales it would also put them into competition with their ecosystem in a negative way.. but I should ask Gordon anyway :)

    That all makes sense - the CM1 vs Pi 2 was very unfortunate timing - and the CM1 was just a little bit underpowered (though with the MPEG2 and VC-1 licences it was still a very capable HD and SD media player).

    ISTR there was an issue with the continued use of the original Slice skin in Kodi - but hadn't realised that the Pi Foundation now owned the IP and designs. I totally understand why the Pi foundation wouldn't want to compete with others in the ecosystem. However they do make the DVB-T2 HAT - and that integrated into a modern Pi 4-based Slice (once the HDR and HD Audio stuff is implemented) would be lovely.

  • Compute Module 4 for Slice in the near future?

    None of these after market cases really come close to looking as well designed as the Slice though :( - though the Argon cases are some of the nicest looking out there at the moment IMO.

    I think the Slice was very much a passion project from the developers - the fact it didn't evolve and continue to be manufactured suggests it didn't make that much money (and it was very much a premium product).