Posts by noggin

Quote from Gareth1121

Solution: Either buy a Powered USB box or have Wi-fi built in; Whatever you do avoid the raspberry Pi Zero Non-W.

I don't know where you got 'Powered USB box' from. If your case gives you access to the Pi Zero's Micro USB port, and the power solution for the case is suitable, then you can use a cheap, non-powered USB hub with integrated Ethernet, such as this :

Three Port USB Hub with Ethernet (micro B) - Pimoroni

shop.pimoroni.com

Or you can use a Micro USB to USB-A dongle like the one supplied with this kit to allow you to connect a WiFi dongle alone :

Raspberry Pi Zero Adaptor Kit - Pimoroni

shop.pimoroni.com

Both are bits of kit I have in my 'useful dongles' box at home for getting non-W Pi Zeros set-up and configured.

Quote from maxi

Hello,

Is it possible to improve the performance in order to be able to reproduce the type of video that I will put the link, I already talked about it in the post above.

Thanks

Video file

If you are talking about decoding and deinterlacing high bitrate 4:2:2 1080i25 MPEG2 (or h.264) on a Pi 4B - then no - I don't think it is currently possible.

The only ARM platform I know that can currently handle software decode and deinterlace of 4:2:2 1080i stuff is the Apple TV 4K. I've not seen any other ARM SoC handle it. (As an added benefit the ATV 4K has hardware accelerated decode of 4:2:2 and 4:4:4 HEVC/h.265 - as a side-effect of that codec being used for Mac Airplay desktop mirroring, though 4:2:2 MPEG2 and AVC/h.264 is done in software.)

It may be possible for the MPEG2 decode and deinterlace to be further optimised for the Pi to allow for it using techniques like GPU-assisted decode (rather than VPU hardware acceleration) - but for such a niche codec I'm not sure that the developers will have the inclination to do so.

https://rpilocator.com is a good site to keep across stock levels in various countries.

Quote from kaibenn

chewitt So, you do not think it has something to do with TVHeadend and the USB SAT tuner. I thought about testing to access the TVHeadend server on the CoreElec box instead. But this will not happen soon (needing switch to connect both boxes to the ethernet and being away next week).

Is the support for SD channels planned until release?

Are you able to test on a Windows or Mac laptop running Kodi over a network connection to your TV Headend + DVB-S capture solution box Or by running VLC and taking the http streams from TV Headend's UI?

(To test in VLC you copy the link from the play icon - by right clicking and copying the link - next to the channel in the Services tab and then paste the link it into the Open Network option in VLC)

That way you can confirm whether the issue is with TV Headend and the DVB Reception, or your Kodi playback environment.

If you can't network stream - then you could copy a recording to a USB stick and try to play that on another platform?

The fact that you get audio but not video with SD content suggests the issue is probably with your playback option (Audio and Video are all received as part of a single data stream - so the fact you're getting audio suggests the issue isn't with TV Headend or your DVB-S reception solution probably)

Quote from kaibenn

I have now tested with TVH 4.3.

It works indeed better. The long boot delay vanished. Start-up time is fine now.

The video is not buffering (time icon) anymore, but I still see 'artefacts'.

I tested:

1) The public TV channels in Germany (e.g. Das Erste) 1280x720, 50Hz

2) Some free HD channels (e.g. BBC World News) 1920x1080, 25 Hz

3) Some commercial SD channels (e.g. RTL Television) 720x576, 25 Hz

For 1) I have seen 'artefacts', but seldom

For 2) I see 'artefacts' more often.

3) does not work at all (only audio)

Additionally I tried streaming from TVHeadend server to my notebook. This works for 1), 2) and 3). I have seen artefacts, but less than in Kodi.

Display More

Assuming you're looking 19.2E Astra 1 then

1) and 2) are h.264 (aka 'MPEG4') compression - with 1. being 720p50 "progressive' and 2. being 1080i25 (aka 1080/50i) "interlaced"

3) is 576i25 (aka 576/50i) "interlaced" using MPEG2 compression.

So it sounds like there are issues with both deinterlacing and MPEG2 decoding?

Quote from atoulmin

I disagree, the best device is the Intel NUC. much faster than a RPI4. Just as capable and well supported

How is the NUC with 2160p50 and 59.94 UHD HDR10 and HLG output now ?

That would explain an issue I've seen with one of my 4Bs in an Argon One case with Micro HDMI...

Quote from popcornmix

This issue can also be caused by the Argon One case which does a similar thing with cable extenders.

Is this the case with all versions of the Argon One cases do you know? They switched from Micro-HDMI to Fullsize-HDMI on their Pi 4B cases - do both have issues with lack of Hotplug, SDA and SCL pass-through on their extenders?

Quote from dan.h

You are obviously right,
I didn't removed the repos /add-ons because it was obvious to me that it is a general issue and not related to any add-on

The Kodi and LibreElec forums have a policy of not supporting those who use banned repos/add-ons, due to the bad reputation that they have given Kodi (to the extent that some online auction sites now treat 'Kodi' as a banned word in listings).

Doesn't matter whether the issue is related to them or not.

Quote from chewitt

Kodi always and only outputs progressive. Interlaced 25/29.97/30 media requires 50/59.94/60Hz modes from the TV so that each interlaced frame (two half frames) can be rendered progressively (in two progressive frames). Hence the highest resolution Kodi can output is 720p (mode 4) and there is no 1080i to select.

I've run LibreElec on a Pi via an HDMI->HD-SDI converter in 1080i25 output mode as a 1080i25 file player for broadcast TV. Kodi is presumably deinterlacing any interlaced media to 1080p50 and then the Pi is interlacing its output to 1080i25 (retaining the 50Hz motion), so it's not 1080i25 native - but it does retain the 1080i25 50Hz motion on its output?

(1080i25 = 1080/50i)

Also worth adding that Kodi has never really been optimised for 'interlaced in, interlaced out' replay - as preserving field order, field dominance etc. is tricky and now a pretty niche requirement.

If you configure Kodi on any platform for 480i output, and play 480i source files, chances are you'll be deinterlacing 480i to 480p and then reinterlacing to 480i for output - rather than preserving 480i. This may be fine for your use case - but a 480i 'straight through' workflow is not straightforward.

Quote from jeancozer

Unfortunately it didn't work, and I've already tried all these command lines.

In different ways.

#dtoverlay=vc4-fkms-v3d,cma-512

#hdmi_mode:0

#hdmi_group:1

#hdmi_enable_4kp60=1

#hdmi_force_hotplug=1

#config_hdmi_boost=9

#gpu_mem=320

#force_turbo=0

#hdmi_ignore_edid=0xa5000080

#disable_overscan=1

#framebuffer_width=1920

#framebuffer_height=1080

#hdmi_force_hotplug=1

#hdmi_group=1

#hdmi_mode=16

#dtparam=audio=on

#dtoverlay=vc4-fkms-v3d

#max_framebuffers=2

#hdmi_safe_1

#hdmi_force_hotplug=1

#config_hdmi_boost=9

Display More

This may be pointing out the obvious - but you are removing the # sign before each one aren't you? The presence of a # sign means the OS ignores everything after it on that line (it's designed for human readable comments that the OS ignores)

Quote from HiassofT

Yes, this is done independently.

The logic inside kodi is quite simple:

If the video driver supports the colorspace property it'll set it to "BT2020" for BT2020 videos or "Default" (i.e. usually BT709) for other content.

HDR metadata is handled in a similar way (set if driver supports it and we have it, unset or untouched otherwise).

If the video bit depth is higher than 8bit and the video driver supports the max_bpc property it'll set it to 12 - so you'll usually get 12bit RGB or YCbCr 4:2:2 both for SDR and HDR 10bit content.

By default (eg in GUI) max_bpc is set to 8 so we get 8bit RGB output (YCbCr 4:2:2 won't be considered by the RPi video driver as it's a 12bpc mode).

The Kodi PR that adds this logic is in LE RPi builds but still under discussion at Kodi side - see https://github.com/xbmc/xbmc/pull/20006 - so there might be changes or extensions in the future.

The various video drivers work slightly differently or don't support all combinations (eg due to hardware limitations/bugs).

For example Intel doesn't support YCbCr 4:2:2, only RGB, YCbCr 4:4:4 and YCbCr 4:2:0 so it might be an option to set max_bpc to 10 to get 10bit output or don't set it at all (IIRC Intel defaults to 12) to let the driver choose some supported format.

Or, eg on RPi, maybe an option to always keep it at 12 to avoid mode switches between GUI and 10bit video playback.

I guess in the end we might see some config setting to control behavior, similar to "adjust refreshrate on playback".

so long,

Hias

Display More

That's now made me question how Rec 601 output is handled (given the very different RGB<->YCbCr matrices that Rec 709 and Rec 601 have) wrt 'default'?

Quote from giannia

My Yamaha RX-V6A AVR reports this compatibility table. The default setting is mode “4K Mode 1” and for this mode the best compatibility in the range 4K 60-24Hz is YCbCr 4:2:2

https://ibb.co/vYWb7RQ

Yes.

4K Mode 2 = 'Enhanced HDMI Mode support' on some platforms. This allows the higher bandwidth HDMI 2.0 modes to be used that allow HDR support at >4:2:0 subsampling with >8 bit depth.

4K Mode 1 only supports the lower bandwidth HDMI 2.0 modes that are based around 4:2:0 at 2160p50 and above for >8 bit depth.

My Sony UHD TV, with the enhanced modes enabled, is equivalent to 4K Mode 2 on HDMIs 2 and 3, but 4K Mode 1 on HDMIs 1 and 4. My Denon AVR required enhanced modes to be enabled too, to pass through 2160p50 and above 4:2:2 12 bit inputs.

(4:2:0 was initially added to the HDMI 2.0 spec to allow HDMI 1.4 physical hardware in TVs etc. to support 2160p50 and above modes as it squeezed into an HDMI 1.4 bandwidth signal. ISTR nVidia and Sony both added support for 4:2:0 2160p50 and above modes as upgrades to hardware that was otherwise limited to HDMI 1.4)

Quote from HiassofT

The summary you posted is correct.

While there's some support for YCC4:4:4 in the video driver (I noticed a function checking if it'd be valid), it doesn't make use of it.

The linux drm subsystem is a bit limited in that regard, there's no connector property that would let you force eg RGB or YCC - it's all up to the driver.

The only drm connector property we can play with is the max_bpc which let's us limit component depth to max 8/10/12 bits per channel.

max_bpc defaults to 8 (so that on desktops you'll get RGB instead of falling down YCC 4:2:2, sharp text is usually more important there than 12bit which might not even be used by the software running on the desktop) and in LE/kodi on the RPi we lift that to 12bit in case of 10bit video content so we can make use of the higher output bit-depth (which is more important here than potential loss in chroma resolution - subtitles and GUI are usually up-scaled from 1080p anyways).

so long,

Hias

Display More

Thanks - that all makes sense - and totally understand why desktops would favour RGB over a subsampled 4:2:2 or 4:2:0 mode to avoid chroma smearing on fine detail (whereas video is already encoded in 4:2:0 usually so it's a moot point for video replay)

Out of interest is bit-depth checked irrespective of EOTFs - i.e. does a 1080p50 10-bit HEVC SDR Rec 709 file get output in a 10-bit or 12-bit mode?

Quote from HiassofT

For 10bit content the driver will check in the order RGB 4:4:4 12 bit -> YCbCr 4:2:2 12bit -> RGB 4:4:4 10bit -> RGB 4:4:4 8bit if both the sink and the RPi support that format.

It takes max TMDS bandwidth, YCbCr 4:2:2 and 10/12 (30/36) bit flags from EDID and also max TMDS rate from RPi into account (4kp60 / 600MHz TMDS is opt-in in config.txt) and picks the first supported format.

so long,

Hias

Ah - so on every format change it checks for support of the various flavours - so on most modern UHD HDR displays it will be :

2160p30 and below - RGB 12 bit

2160p50 and above - YCbCr 4:2:2 12 bit, or it has to fall back to RGB 8-bit (as there is no support for RGB 10-bit at 2160p50 and above, and the Pi doesn't support YCbCr 4:2:0)?

Does the Pi ever output YCbCr 4:4:4 ?

Quote from HiassofT

mathmath51 can you test with hdmi_enable_4kp60=1 in config.txt (you also need to enable HDMI Ultra HD Deep Color support in your TV's setting - this is usually HDMI-port specific) on LE 10.0.2?

LE10.0.2 supports outputting at 10 and 12bit, LE10.0.1 only sent 8bit HDMI.

So on LE10.0.1 your 4kp23.97 file is transmitted as RGB 4:4:4 8bit, 10.0.2 without 4kp60 enabled transmits at YCbCr 4:2:2 12bit, with 4kp60 enabled it transmits RGB 4:4:4 12bit - all that could make a difference.

so long,

Hias

What is the logic in the latest LE for 2160p 10-bit HEVC SDR/HDR10/HLG replay and YCbCr 4:2:2 vs RGB / YCbCr 4:4:4 at 30fps and lower and 50fps and higher?

• 4:2:2 12-bit is the only >8-bit format supported at all 2160p frame rates isn't it? This format often requires additional settings to be enabled in TVs and/or AVRs. (There is no 4:2:2 10-bit option in HDMI 2.0)
• RGB/4:4:4 YCbCr >8-bit is only supported at 30fps and below (and 8-bit at 2160p50 and above) but normally works OOTB on TVs and AVRs.
• 4:2:0 is supported only at 2160p50 and greater and on some TVs is the only >8-bit format supported at 2160p50 and above (and worked OOTB). However it's not supported by the Pi 4B?

Thinking about it, if I can find the time, I should be able to capture the 4K output from the two boxes using a BlackMagic 4K HDMI capture solution I have, and look at the content (alongside the original file) in Davinci Resolve Studio to compare the digital outputs with the source file.

Quote from giannia

The “Samsung Travel With My Pet HDR UHD 4K Demo.ts” is darker on the colums at 1:19, compared with same video played on Nvidia Shield using same version of Kodi, LG TV infos says both playbacks are 4K UHD bt.2020.

I'll see if my HD Fury Vertex reports the same static HDR 10 metadata being sent via both platforms - can you link to the content if it's in the public domain and not copyright?

I have an RPi 4B and an nVidia Shield TV Pro 2019.

It's important also to remember that some TVs will do an internal tone map to reflect the capabilities of the display - and this will be informed by the MaxCLL (Maximum Content Light Level) and MaxFALL (Maximum Frame Average Light Level) static metadata sent, which is part of the HDR10 standard (and carried by the HEVC codec, and in some cases additionally by the wrapper I believe) (This is assuming no HDR10+ is in play)

Some platforms don't passthrough MaxCLL and MaxFALL metadata - and this situation is informally referred to as PQ10 rather than HDR10 (as are TVs that ignore the static metadata - though that wouldn't be relevant to this discussion)