Posts by noggin

Quote from smp

4K 4:2:0 with Deep color is not a part of HDMI spec. It should always be 8-bit.

No idea how to force YCbCr 4:4:4. Intel driver knows what's best for you and use RGB.

That's not correct, if by Deep Color you mean >8-bit bit depth. In fact it's quite the opposite.

4:2:0 is supported in 8, 10, 12 and 16-bin 2160p50/60 modes - it's the only sub-sampling format supported in all bit-depth outputs for 2160p50/60 modes. 4:2:0 was added to HDMI 2.0 - and is only supported for 2160p50/60 modes, with no support in 2160p24-30.

RGB/4:4:4 are only supported in 8-bit at 2160p50/60 - so whilst you may be able to flag an HDR EOTF with 2160p50/60 RGB/4:4:4 output - you can't output 10-bit sources in 10-bit or 12-bit in an RGB or 4:4:4 mode with a 2160p50/60 output format. (RGB/4:4:4 is only an option for HDR at 2160p24-30)

4:2:2 is the only >8 bit format supported for all 2160p frame rates - from 24p-60p. It is supported with 12-bit bit depth only. (So 8-bit SDR and 10-bit SDR or HDR (*) video is padded - there are no 8-bit, 10-bit or 16-bit onions for 4:2:2 output at any frame rate in the spec)

4:2:2 is thus the ideal preferred mode for 2160p HDR output - as it is supported at all frame rates. (This is why it is used by a lot of consumer products)

4:2:0 is the second best option for 2160p HDR output at 2160p50/60 - but can't be used for 2160p24-30.

4:4:4/RGB is only an option for 2160p HDR in 2160p24-30 modes.

Therefore if you can't use 4:2:2 for HDR output of 10-bit HDR material properly (i.e. without truncating to 8-bit) you have to use RGB/4:4:4 output for 2160p24-30, and 4:2:0 output for 2160p50/60. The only format supported in all frame rates is 4:2:2

See attached HDMI 2.0 timings chart downloaded from the HDMI site. HDMI 2.0b or HDMI 2.1 may have added >8-bit depth support for RGB/4:4:4 in 2160p50/60 modes - but it certainly wasn't supported in HDMI 2.0 (or 2.0a AFAIK)

(*) I watch quite a lot of self-mastered HD SDR 10-bit content - it looks so much nicer than 8-bit content covered in quantisation banding

Quote from donbrew

My pi3b can handle 10 bit HEVC files with MMAL disallowed, has trouble with it allowed but tries. No codec license.

My pi4b 1gb handles the file fine no MMAL.

I don't know what paying for the license would do on a pi3 or pi4.

You can't purchase codec licences for the Pi 4B - they are only available for the Pi 3B+ and below. It's assumed that MPEG2 and VC-1 (the two licensable codecs) can be decoded in software on the Pi 4B.

On the Pi 3B+ and below the MPEG2 and VC-1 software licences can reduce the CPU load on content that could otherwise be decoded in software, and for interlaced MPEG2 and VC-1 this can be significant. I'm not saying you need the licences - just that having them will reduce your CPU load (which in some cases may be desirable). On the single core Pis (Original A and B, A+ and B+, Zero, CM1 etc.) the hardware licences are even more important if you want to decode MPEG2 or VC-1 (particularly interlaced HD)

Quote from smp

4K 4:2:0 with Deep color is not a part of HDMI spec. It should always be 8-bit.

No idea how to force YCbCr 4:4:4. Intel driver knows what's best for you and use RGB.

That's not correct. Image below from the HDMI.org website (Had to go to wayback machine as they have updated to HDMI 2.1)

HDMI :: Manufacturer :: HDMI 2.0 :: FAQ for HDMI 2.0

The HDMI 2.0 spec supports the following formats and bit depths :

2160p24-30 :

• RGB 8-bit, 10-bit, 12-bit, 16-bit.
• 4:4:4 YCbCr 8-bit, 10-bit, 12-bit, 16-bit.
• 4:2:2 YCbCr 12-bit only.
• (NO 4:2:0 support at 2160p30 and below)

2160p50-60 :

• RGB 8-bit only
• 4:4:4 YCbCr 8-bit only
• 4:2:2 YCbCr 12-bit only
• 4:2:0 8-bit, 10-bit, 12-bit and 16-bit.

So for 2160p24-30 4:2:0 is not supported at all and RGB, 4:4:4 and 4:2:2 are all supported at >8-bit depth. (4:2:2 is 12-bit only)

For 2160p50-60 RGB and 4:4:4 are only supported at 8-bit, so not suitable for HDR, whereas 4:2:0 supports all bit-depths, and 4:2:2 is 12-bit only.

For a single, fixed, chroma subsampling format at UHD for all frame rates , that supports HDR, 4:2:2 YCbCr 12-bit is the only option. (No problem outputting 10-bit content padded to 12-bit - that's what a lot of consumer electronics devices do)

Quote from donbrew

Why do you need licenses for pi3 pi4? Mine work fine without. Only needed in the Dark Ages of pi1b maybe pi2 (don't recall on pi2 didn't have one).

Something wrong with hardware decoding?

I think it's fine for SD MPEG2 interlaced content - but decent deinterlacing of HD MPEG2 on a 3B may be pushing it. 4B will be fine I think (which is why they don't include an MPEG2 licence option for the 4B)

Quote from chewitt

Software deinterlaced media will play terribly if forced to 25/29.97/30 modes as Kodi currently renders each half-frame as a whole frame, so you need the "double" refresh rate to get all the frames rendered. If you force 25Hz content to play on a (4k)30Hz mode you're probably missing 50% of the half-frames in the video stream. I have Kodi set to 1080p60 and I whitelisted the 4K resolutions and 1080p 23.976/24/50/59.79/60 modes. The GUI plane is rendered at 1080p by default so you won't see any real-world difference from having the resolution at 4k but the GUI takes less effort to render so navigation is a little snappier and Kodi will still switch to 4k modes if you play 4k media. If you mostly watch deinterlaced 1080p PAL media 1080p50 may be a better default as this avoids the 60>50 mode change.

Absolutely spot on - I have pretty much every LibreElec and CoreElec Kodi device I run configured like this, and watch a lot of interlaced content, but also quite a lot of 23.976/24Hz stuff, and some UHD/4K.

Quote from simpz

I have nothing in my whitelist and the "resolution" is 4096x2160p, "refresh rate" 30, "limit gui size 1080p.

If I whitelist 1920x1080p the TV switches resolution when I watch HD TV and it works, but is obviously slow to switch as it renegotiates.

But my TV won't take SD content like DVDs so can't pull the whitelist trick. Or any SD TV channels.

If you want decent deinterlacing of broadcast TV you need to ensure your refresh rate includes 50 and/or 59.94 modes (50 if you are in a 50Hz territory - Europe/Aus/NZ, most - if not all? - of Africa and lots of Asia and bits of South America, 59.94 if you are in a 60Hz territory like North America, Mexico Japan, Korea, Brazil and some other bits of Asia and South America)

2160p 30Hz modes are going to be very juddery for native interlaced content - which will be running at a higher rate than can be displayed cleanly at 30Hz.

Quote from eribu

I’m having this exact problem with an LG C9 and a Raspberry pi 4. Did anyone figure out what to look for when buying a cable/converter? Would appreciate not having to buy a bunch of different cables

A few posts earlier an Amazon Basics cable is said to be working when a Pimoroni Micro HDMI adaptor was not previously.

Apologies for necro-posting again - but I've been running both add ons listed here - KodiDisplayInfo (which uses web access to Kodi, but has far less advanced display functionality) and Kodisplay (which is the main topic of discussion here - but seems to be an internal add on only)

The advantage of KodisplayInfo using web access is that the SPI display and display code can be running on a small and cheap Pi Zero W or similar and SPI display, independent of your Kodi platform - which could be anything that supports LibreElec, CoreElec or Android Kodi I guess - and the Kodi device itself doesn't need to have SPI support and the code to drive SPI or similar displays.

The advantage of Kodisplay is that it has far, far more functionality and is far more extendible.

A question to those who know - is all the functionality available to an add-on, in Kodi status terms, available to an IP connected device via IP calls (JSON? http?) allowing an external device to be set-up as a comprehensive second display?

I've played with Frontvew+ on Windows on a little Windows tablet - and it also offers a lot of functionality - but doesn't quite do what I'd hoped.

(My aim is to have a bit more detail than the OpenVFD/LCDProc or similar displays - so PVR Channel logo and programme name, time elapsed/left bar graph for Live TV, Album art for Music - along with track number, track title and album title, time elapsed/left, movie name and art along with time elapsed/left etc. on a 2-3" display, possibly even something bigger like a DPI-connected Hyperpixel?)

Quote from kavi

Thanks for the prompt reply, Klojum. Makes sense, lightning symbol and all. Would never have thought so because I sent for the complete package from Amazon just so as I would get the proper PSU with it. Ah well, live and learn!

That's just a bunch of bits that a third party re-seller has collected to sell as a bundle. It's not an official complete package, and chances are the USB PSU they're bundling isn't particularly good, and it's not capable of delivering the required current and voltage.

I'd always recommend people to buy the Raspberry Pi official PSUs. They are good value and 'just work'.

https://www.amazon.co.uk/raspberry-pi-power-adapter-uk/dp/b01ccr5p8u/

Quote from Freestyler

Hi,

thanks for answer. I always had enabled audio passthrough and wanted to do all decoding in my receiver.

So passthrough isn't supported at all?

Is there any time window when it will be supported?

Thanks.

Only DD, DTS (and possibly DD+) passthrough is currently supported (same as original Pi models)

The new Pi 4B hardware supports 8 channel 192KHz PCM (so full lossless decode of all Dolby True HD and DTS HD MA/HRA HD Audio tracks) - and should support HD Audio passthrough when the software / firmware is written to support it (which is needed for True HD + Atmos and DTS:x support)

No timescale that I'm aware of. Until then it's lossless decode (which should be audibly the same unless your AVR does metadata driven processing - after all you're just moving the PCM decoding process from your AVR to your Pi - it has to happen somewhere in the chain)

Quote from Freestyler

Hi, I tried to play something in DTS HD MA and i got it decoded to 5.1, but i got 7.1. Dolby Atmos Home Cinema. When i play something in Atmos it is decoded to weird formats like 3.1 Theatre Dimensional.

My settings in audio are 2.0., enable passthrough and enabled formats under it like DTS, AC3 and E-AC3. This works for DTS-HD MA in most of the time. Weird thing is when i set 7.1 in audio setting I got a 5.1.2 sound in output which should be right, but my receiver getting no Atmos (there is a LED which should be lit if Atmos is detected (working in old box S905x).

If you have a 7.1 speaker set-up - you want 7.1 not 2.0 enabled in your sound settings.

Also if you want DTS HD MA and Dolby True HD to be losslessly decoded, you will need to disable DD and DTS passthrough, as otherwise I think it will bitstream passthrough the lossy DD/DTS core/secondary streams rather than decode the lossless DTS HD MA or Dolby True HD losslessly to PCM 5.1/7.1.

You won't get Atmos until HD Audio bitstreaming/passthrough is supported on the Pi 4B - PCM lossless decode is only for Dolby True HD and DTS HD MA - not Dolby True HD with Atmos or DTS:x. (You may - possibly - get DD+ with Atmos - but that's not intentional and usually only used for secondary language audio streams on BD/UHD BD)

If you must have Dolby True HD with Atmos, the Pi 4B isn't currently for you.

However if you want the best quality audio possible with a Pi 4B currently - disable passthrough, configure for 7.1 if you have 7.1 speakers (i.e. Front R,L, Centre, Side R, L and Rear R, L + Sub) or 5.1 if you have 5.1 speakers (note I'm ignoring 7.1.2. or 5.1.2 Atmos in this - if you have 7 speakers but 5.1.2 then configure for 5.1, if you have 9 speakers in 7.1.2 then configure for 7.1)

Sorry - yes - people are absolutely right - it is MPEG2 not h.264 4:2:2. I can't think why I jumped to that conclusion as I opened it in MediaInfo. It's probably because I assumed it was recent - and I don't know of anyone in broadcast in the UK still using MPEG2 rather than h.264 for broadcast uplinks (as it's basically a waste of bandwidth to use MPEG2 these days)

Quote from maxi

Hi,

I tried to see a recording file where I can only get sound…

PI4 2GB RAM

sample record.ts file

That's a broadcaster uplink feed (31Mbs 4:2:2 h.264 video with 384k MP2 stereo audio) not aimed at consumers.

Consumer video (DVB/ATSC/ISDB, DVD, Blu-ray and UHD Blu-ray) is 4:2:0 - and that's what consumer devices have hardware acceleration for. As a result consumer devices - set top boxes, PC GPUs (**), ARM SoCs designed for consumer media playback etc. don't support it in hardware.

4:2:2 is only used in the broadcast/professional environment - and you need a broadcast/professional device to decode it with hardware acceleration (*).

For h.264 4:2:2 decode on a consumer device you need something with the CPU power to support software decoding (and probably software deinterlacing if the source material is 1080i25) This puts you in the Intel/AMD camp for realtime playback - not consumer ARM SoCs.

If you want to watch this stuff on a Pi - you will need to transcode to 4:2:0. If you want to retain chroma resolution then 4:2:2 1080i25 -> 4:2:0 1080p50 may be your best route. (ffmpeg with a -vf "w3fdif=complex:all" deinterlace is my go to for that when converting broadcast 4:2:2 sources - h.264/ProRes/DNX/AVCi100 etc. to h.264 or h.265 4:2:0 consumer video)

Personally I usually do this from the command line rather than in handbrake as I found handbrake would often deinterlace 1080i25 to 1080p25 not 1080p50 (and thus threw away 50% of the temporal - i.e. motion - resolution)

(*) When MPEG2 4:2:2 was used for satellite uplink, a couple of oddball consumer devices did have unadvertised 4:2:2 MPEG2 decoding (one version of the WDTV Live did it I discovered). However I've yet to find any consumer devices with unadvertised 4:2:2 h.264 decode.

(**) Some Non linear editors like FCPX, Prem Pro etc. will support GPU accelerated decode within their workflow - but this is bespoke within those packages.

Quote from Freestyler

Hi,

I haven't tested it yet, but big thumb up for no tearing GUI, if it's true.

Did someone tested if HBR audio is fully supported (DTS HD MA and Dolby Atmos)?. That's what I want so bad on my RPi4. My home theatre just crying.

DTS HD Master Audio is losslessly decoded to PCM 5.1/7.1 (and the Pi4B supports 192k/24bit at 5.1/7.1 and isn't limited to 4.0 at 192k as previous models are, I believe) - so it's only Atmos that your Home Theatre is crying for? (Or is stream metadata vital for your use case??)

It looks like the OP should DISABLE 4kp60 in config.txt as the receiver specs confirm that it only supports 4:2:0 video at 2160p50 and above which the Pi doesn't output (at least currently - and probably won't)

If 4KP60 output is disabled in config.txt the Pi will output up to a max 4K30 output - which the receiver should be compatible with.

What happens if you run the Pi with 4Kp60 disabled?

Yes - 2160p50 and 2160p59.94/60 support on some AVRs and TVs is limited to 4:2:0 which is a format the Pi 4 doesn't support (4:2:0 is only an HDMI standard for 2160p50 and above)

Your Pi 4B will output RGB (which is the same bandwidth as 4:4:4) 8-bit at 2160p50 and above - not all AVRs and TVs support this.

(4:2:0 8-bit support for 2160p50 and above was added to the HDMI 2.0 spec so that HDMI 1.4b hardware could be used to carry a 2160p50 and above signal - as the bandwidth just squeaks into HDMI 1.4b hardware limits. This was a way for manufacturers to 'upgrade' existing hardware that was HDMI 1.4b only to support HDMI 2.0. Just. However 4:2:0 is the only HDMI output spec that requires both horizontal AND vertical chroma subsampling - and the Pi doesn't support vertical subsampling - only horizontal - AIUI)

I've just installed the latest Public Alpha Release (not a nightly) and my Pi4B CEC works fine from a Sony XF9005 and Denon AVR X2400H if I start the Pi whilst the TV and AVR are both routed to the Pi. TV Remote controls Pi, Pi controls Denon volume.

However if I switch away from the Pi 4 routed through my AVR to another HDMI input on my TV (not my AVR) - where my TV will automatically switch the Denon AVR to ARC Audio - and then switch back to the AVR HDMI input (and the AVR switches back to the Pi 4B input on the AVR), the CEC control from the TV has stopped working, but the CEC control of the Pi4B to the AVR continues to work.

Quote from bbro_spo

Looking at that last post, I have a question. Is this the same as the official firmware that is supposed to lower the voltage and temps of the pie?

I think this is where people are getting confused.

The above is the firmware for the VideoCore I believe - the same type of firmware as was used by previous Pis. This firmware is loaded on boot every time and handles a lot of the Pi's configuration and operation - specifically for the SoC.

The firmware that is being discussed that reduces temperatures a little (by reducing the temperature of the PCI-E->USB3.0 bridge) is firmware specifically for the USB 3.0 bridge device - and this is stored in separate EEPROM (I think) and not loaded each boot.