Posts by noggin

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.

Quote from kalireakaydes

Hi,

For all facing overheat issues, the raspberry foundation released an Alpha Firmware to reduce it :

Download the archive from here: https://drive.google.com/file/d/1PXwrnh ... sp=sharing

With the zip file on the Pi:

Code: Select all

Code

$ unzip vl805_update_0137a8.zip
$ chmod a+x vl805
$ sudo ./vl805 -w vl805_fw_0137a8.bin
$ sudo reboot

The zip file includes the current shipping firmware (013701) in case you want to revert:

Code: Select all

Code

$ sudo ./vl805 -w vl805_fw_013701.bin
$ sudo reboot

You will find the full thread from their forum here :

Raspberry Pi 4 temperature - Page 11 - Raspberry Pi Forums

Hoping this could help.

Regards,

Display More

This is just firmware for the VL805 PCI-E->USB 3.0 bridge isn't it? This is reported to reduce average idle temps by ~3C.

However there are reports that it reduces compatibility with some USB 3.0 devices - so it's worth being aware of that.

(The reason I make the point about it being USB3.0 firmware only is because there is another 'firmware' for the PI 4B - similar to the previous firmwares - that is loaded to the VideoCore before fully booting, which has also been updated to resolve frame drops on video content that played fine on previous Pi models - such as 1080p and 1080i h.264)

Quote from HiassofT

Stuttering and a/v sync problems on very high bitrate files (eg "Sony Surfing 4K Demo", 4kp60, avg 77Mb/sec, peak 118Mb/sec HEVC) are known issues and are being looked into.

Stuttering with interlaced videos is already fixed, either use the updated firmware or wait for the next LE release (which should be out soon).

so long,

Hias

It's not just high bitrate h.265/HEVC stuff that is stuttering.

The 36Mbs Wimbledon 2160p50 h.265/HEVC iPlayer stream is dropping frames continuously (according to the CTRL+SHIFT+O overlay). 36Mbs is a reasonably modest bitrate for 4K50 stuff - but I guess with twice as many frames to process each second, 2160p50 is going to be more challenging than 2160p23.976 (which is what 4K movies will be running at)

The 17Mbs 1440p50 h.265/HEVC iPlayer stream seems to be pretty solid.

I think the default firmware shipping with the LibreElec alpha does have some issues with h.264 streams - but the revised firmware posted elsewhere in this thread fixed those for me.

Quote from lordvader

I had a quick play with libreelec, and some 4k content.

When it boots up, the resolution is 3840x2160 (which is fine for testing). However, when playing some sample 4k content downloaded from here (Sony: Swordsmith HDR UHD 4K Demo | 4K Media), it seems to be trying to play it back at 4096x2160.

This has two side effects:

• The video itself is over-scanned, so is cropped
• When returning to the libreelec ui, it too is cropped - needs a restart to return to normal

Is this a know issue? The TV is a panasonic oled, which is native 3840x2160

Have you whitelisted just the 3840x2160 modes? I never whitelist the 4096x2160 modes.

When I first booted LibreElec connected to my Sony UHD TV (which supports 4096x2160 and 3840x2160 inputs but is 3840x2160 native) it started in 4096x2160/24p mode (with a cropped UI - and slightly washed out picture) However once I whitelisted only 720p, 1080p and 3840x2160p modes, everything is OK.

Quote from doof

Looking at the EDID dump shows that 60hz modes are 420. I also confirmed this w/ the manufacturer (Visio) who unsurprisingly suggested I buy a new TV. The max pixel clock of 300mhz doesn't seem to allow 60hz 422.

On the topic of colorspace the Pi does playback HEVC HDR Rec2020 but the colors are very muted and the black level / gamut is wrong. There is significant frame dropping on high bitrate (~120mbps) files.

Yes - there are a number of HDMI 2.0 displays that only support the lower bandwidth modes - which mean they are 4:2:0 only for 2160p50 and above. They aren't currently compatible with the Pi 4B (and I don't think the Pi developers were that hopeful about future 4:2:0 output support as it requires more processing)

And yes - the Pi plays HEVC stuff fine. In playback terms - the HEVC is 4:2:0 YCrCb compressed video - the Rec 2020 vs Rec 709 doesn't alter how HEVC encoding and decoding work hugely - they are just metadata flags. HOWEVER if you play back HEVC Rec 2020 PQ HDR (i.e. HDR10 ST.2084) stuff flagged as Rec 709 and SDR (i.e. BT.1886 or 2.2-2.4 power law gamma) you will end up with incorrect RGB primaries (Rec 2020 is a wider colour gamut) and very 'flat' dynamic range (which will also desaturate more).

Quote from Stereodude

My understanding is that for HDR content there are flags in the HDMI stream to indicate the color space. I think that takes care of 709 and 2020 for folks with a HDR capable display. The source doesn't have to do any conversions, just enable the right flags in the output. I'm not sure how 601 is handled.

There's going to need to be a lot of LE work done if people are expecting the RPi 4 to play pretty much everything and get reasonably correct results on all display types. That will require handling just about about every possible color space conversion, HDR to SDR tone mapping, and who knows what else.

It's true about gamut flagging in HDMI Infoframes - but that doesn't alter the upstream requirement to ensure you use the right YCrCb relationships.

Annoyingly YCrCb are different in all three ITU standards (601, 709 and 2020)

In Rec 601 : Y = 0.299R + 0.587G + 0.114B

In Rec 709 : Y = 0.2125R + 0.7152G + 0.0722B

In Rec 2020 :Y = 0.2627R + 0.678G + 0.0593B

As you can see - the YCrCb values for each standard are derived totally differently (ignoring the differences in their primaries and gamut). If you just leave YCrCb untouched you can cause carnage. SD content is expected to be in Rec 601, HD content is expected to be in Rec 709, UHD content is expected to be in SDR Rec 709, SDR Rec 2020 (rarer) or HDR Rec 2020 (widespread)

Quote from Stereodude

Well, if the YUV 4:2:2 support on the Pi works anything like a PC everything will be done in RGB colorspace and then be converted to YCrCb right before it's output with a conversion of nebulous quality / correctness.

Most BD & UHD-BD players output in YCrCb color space and play back YUV video content from files without a conversion to RGB and then back to YUV. It would be nice if the RPi 4 could do the same. Unfortunately the BD & UHD-BD players have all sorts of limitations on codecs and containers.

Yep - though I guess you're then in a world of Rec 601 vs Rec 709 vs Rec 2020 YCrCb conversions (as they are all different) if you play back a Rec 601 DVD and output it in Rec 709? (And that's ignoring gamut conversions - which you kind of can with 601/709 tolerably, but you can't with 709 vs 2020)

Arguably taking stuff back to RGB rather than doing YCrCb.601 - > YCrCb.709 conversion in the YCrCb domain is a six and two threes?

Neither 4:2:2 nor 10-bit h.264 video are supported with hardware decode on the Pi (or any other ARM SoC AFAIK (*)), and as they are a very rare formats (4:2:2 is pro-territory only) even software support (which it's unlikely the Pi 3B/3B+ will have the grunt to achieve) is unlikely to be be successful.

(*) Surprisingly the newer Rockchips support 4:2:0 10-bit h.264 hardware decode - but I don't think 4:2:2 support is there.

Quote from Stereodude

If it doesn't support YUV4:2:x it won't be able to do 10-bit 2160p60. If it can only do 8-bit RGB 2160p60 HDR playback is going to be gimped.

However, I don't know if the Videocore VI is capable of decoding YUV video, leaving it in YUV color space, and rending the Kodi GUI/OSD either directly into YUV color space or rendering it to RGB and converting it to YUV for blending and output so that the video can be passed unmolested without two color space conversions.

The Pi Devs have said 4:2:2 support is there - but it looked like they suggested the vertical subsampling for 4:2:0 meant that wasn't an option. If that is the case, then that means 4:2:2 12-bit will be the only HDR HDMI 2.0 output mode for 2160p50-60 supported I guess (as there is no 10-bit 4:2:2 defined for HDMI 2.0 - so 10-bit HDR HEVC content is output at 4:2:2 12-bit not 10-bit)

For 2160p24-30 content you can run RGB or 444 and output HDR, without needing 4:2:2 (though 4:2:2 12-bit is valid at these frame rate resolution / combos as well, whilst there is no 4:2:0 support in HDMI 2.0 at <50p). For the bulk of HDR HEVC PQ content - which is 2160p23.976 movies an tv drama - RGB or 4:4:4 YCrCb output in 10-bit is a supported HDMI 2.0 mode and is fine.

I guess if you render Kodi to YUV-space you'll need to have both Rec 709 and Rec 2020 RGB->YCrCb conversion implemented, unless you mind GUI rendered stuff being a bit out (are photos gui-rendered)

Quote from climberhunt

Thanks, Noggin, That's the change I missed. Problem Solved!

I forgot to do that again when I re-flashed the card.

I still need to adjust the refresh in the display to match the content in order to eliminate any panning judders, but the main problem is gone with the new firmware. Strange that the GUI does not adjust to the content, though.

Thanks for the tip! We can mark the thread as resolved now!

Rgds,,

Dave.

Display More

Have you got the correct HDMI modes whitelisted AND enabled the refresh change on Start / Stop in the Player settings?

I mainly watch 50Hz content and have my GUI set for 50Hz (to avoid re-syncs where possible) - but will check 23.976 or 59.94 stuff when I get a chance later today.

Quote from doof

I'm trying to get 60hz playback but LE doesn't show a 60hz option. The config seems to be read properly and my rockpro64 running LE using the same cable and port runs @ 60hz.

Code

LibreELECpi:~ # cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1 LibreELECpi:~ 

#LibreELECpi:~ # vcgencmd get_config hdmi_enable_4k
hdmi_enable_4k=1

Polling the device doesn't show a 60hz UHD mode on RPI

Code

LibreELECpi:~ # tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 82: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
LibreELECpi:~ # tvservice -m CEA
Group CEA has 11 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
(native) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
mode 63: 1920x1080 @ 120Hz 16:9, clock:297MHz progressive
mode 93: 3840x2160 @ 24Hz 16:9, clock:297MHz progressive
(prefer) mode 95: 3840x2160 @ 30Hz 16:9, clock:297MHz progressive
mode 100: 4096x2160 @ 30Hz unknown AR, clock:297MHz progressive

Display More

How can I enable 60hz UHD on my RPI?

AIUI the Pi 4B doesn't support 2160p50-60 4:2:0 modes - so if your display only supports them - you're likely to be out of luck?

4:2:0 was introduced to HDMI 2.0 specs to reduce the bandwidth required (bringing the 8-bit 4:2:0 2160p50-60 modes within HDMI 1.4b bandwidths avoiding a requirement for HDMI 2.0 full bandwidth support on some 'HDMI 2.0' TVs).

My Sony TV has to have high-bandwidth HDMI 2.0 modes enabled (it's called 'Enhanced' on Denon and Sony) - and even then only 2 of the 4 HDMI inputs on my Sony UHD TV support the higher bandwidth ports - which are required for non-4:2:0 2160p50-60 inputs.

My Pi 4B currently runs 2160p60-60 at RGB 8-bit - and I believe 4:2:2 is supported or will be. However 4:2:0 output requires vertical chroma subsampling as well as horizontal subsampling (4:2:2 is horizontally subsampled only) and I think I read one of the Pi devs comment that may be tricky for the Pi to implement?

In other words - 2160p50-60 isn't supported by the Pi in all HDMI 2.0 flavours.