Thanks erveryone for the reply
Yes that is exactly what I want but apparently there is no way to get that from kodi
The "O" button on libreelec kodi or the other solution mentionned by ghtester, I will basically get the info from the file metadata.My AVR should be able to output that but I can't find how. Maybe I will investigate more there.
My Denon AVR will display some source nformation in the accompanying Denon iOS app.
FYI - look here: https://kodi.wiki/view/Player_process_info
You can also use kodi-remote app from SSH console to invoke the Player Process Info and Player Debug overlays on screen.
Yep - both of those tell you about the content being played (i.e. give you details of the source file), not the format it is being output in (i.e. the video output resolution, frame rate, gamut, EOTF and chroma format and subsampling, nor the audio output format).
What the OP was looking for is more of an 'Output Info' OSD option - which doesn't currently exist in mainline Kodi AIUI.
The Video Debug info is useful as it gives you comprehensive information about the source file - and some information about how it is being processed - but it doesn't tell you what the output format is.
noggin, so if you use the device only to watch movies, the limited colour range mode does not afffect picture quality, right?
Video is produced in the 16-235 (64-940 10-bit) range in broadcast studios and post-production areas, and that is the level space used for DVB/ATSC broadcasts, DVD, Blu-ray and UHD Blu-ray mastering. Most HDMI outputs from set-top boxes and DVD/BD/UHD BD players will also be in the 16-235 (64-940 10-bit and whatever the 12-bit equivalent is)
So in an ideal world you keep everything in the same 16-235 level space - which avoids cropping any <16 and >235 level content that may be present (you can have <16 and >235 content in 16-235 level space video - the 1-15 and 235-254 range are there to avoid clipping transients - which could cause ringing - and to give you a bit of headroom).
HOWEVER - beware the Kodi setting for 16-235 Limited output - that is for a very specific, and increasingly less useful, use case ISTR. I haven't used x86 LibreElec since the days of Chromeboxes, so am not sure what the x86 GPU Limited/Full range driver situation is.
its not just limited color range black is super light grey. Everything is over exposed including the kodi menus. You can watch anything like that
Is that you enabling Limited Colour Range in the Kodi system setting menus? If so that's for a very specific use case - it doesn't enable the Limited output range in your GPU driver settings, it is there to solve a problem in older systems. In many cases this will output a nasty 'double limited range' these days (it was there to bypass video cards/drivers that would only output Full range when people had Limited range displays, and before InfoFrames flagging Limited vs Full were in widespread use).
PC Mode and Gaming Mode can mean different things on different TVs :
1. Gaming Mode on modern TVs usually means that the TV reduces the latency of its processing to the lowest amount it can - to reduce lag in gaming. This will often disable motion smoothing, noise reduction etc. processing that requires multiple frames to be buffered for processing.
2. PC Mode can mean a couple of things :
a) Full range 1-254/0-255 (*) levels are used (or the 10-/12-bit equivalents) rather than the broadcast standard 16-235 levels. (DVI outputs on PCs were historically 0-255/1-254, but HDMI outputs on most DVD players, Blu-ray players, set top boxes etc. were the video standard 16-235, which is the level space used in production and in encoding MPEG2/h.264/h.265 for DVD/BD/UHDBD and DVB/ATSC/ISDB TV). Historically this was a setting that needed to be manually set on an HDMI input - but increasingly most modern sources will signal their level range in an HDMI InfoFrame - which modern displays will interpret and switch accordingly. Games Consoles often offer 0-255/1-254 output as an option as it - in theory - gives you more levels to play with in 8-bit video, potentially reducing banding a bit.
If you feed a display expecting 0-255/1-254 video a 16-235 video source (and that ignores InfoFrames or they have been overridden) you will see black levels that are grey and desaturated colours. If you feed a display expecting 16-235 video a 0-255/1-254 video source (and that ignored InfoFrame or they have been overridden) you will see blacks that are crushed and clipped whites and over-saturated colour.
b) Overscan simulation is disabled and the full width and full height of the source is displayed (by default most displays simulate CRT over scanning and crop an amount from the edges of a picture and zoom in slightly)
HOWEVER - if you are only seeing this issue with 4K material - almost all of which is Rec 2020 ST.2084/PQ/HDR10 then it's likely to be an HDR issue.
1. If your PC is outputting HDR10 video (which is what most UHD Blu-ray content is) but flagging it as SDR - then you will see washed out colours, blacks that are grey, dim whites etc.
2. If your PC is outputting Rec 709 video (which is less common for UHD stuff) but flagging it as HDR10 (or your TV is automatically assuming your UHD source is HDR10) then you will get over saturated colours, crushed blacks, burned out whites etc.
I would take your display out of any custom settings modes for that HDMI input as a starting point (maybe even factory reset it) just to make sure you haven't set any video settings you didn't mean to.
I would like to know the media information that is reaching the AVR, and from there what is being sent to TV in order to trace if some data is being loss/converted during the way.
Regarding kodi/libreelec, do you know where do I check the information that is being output?
I'm not aware of a way of getting output format information (output resolution, frame rate, colour subsampling, colour gamut, EOTF etc.) in mainline Kodi (which is what LibreElec runs). I suspect that is because on some OSs that Kodi runs on (Android?) that information may not be readily available from the OS.
I suspect what you want is something that displays the following HDMI output information?
Video : 3840x2160 23.976Hz 4:2:2 YCbCr 12-bit Rec 2020 ST.2084/PQ HDR
Audio : Dolby True HD+Atmos bitstream
or
Video : 3840x2160 50.00Hz 4:2:2 YCbCr 12-bit Rec 2020 ARIB-B67/HLG HDR
Audio : 48kHz 16-bit 2.0 PCM
or
Video : 1920x1080 50.00Hz RGB 8-bit Rec 709 BT.1886/SDR
Audio : 48kHz 16-bit 5.1 PCM
or
Video : 1920x1080 23.976Hz RGB 8-bit Rec 709 BT.1886/SDR
Audio : DTS HD Master Audio bitstream
CoreElec has a fork of Kodi that is optimised for the AMLogic chipsets it runs on and does have some of that information (when you press 'O' you get the source information on the left and the output format information similar to the above on the right). However this is because the Kodi fork that runs on CoreElec can 'know' this from it's tight integration with one specific vendor chipset?
I get the Video information
I have the latest 10.0.2 kodi running.
When watching a video, where can I check the bitrate/bit depth of the video, to check if somehow I'm losing quality?
Do you want to know the codec format details (video and audio codec, resolution, frame rate, bit depth and chroma subsampling) of the file you are playing?
i.e.
1920x1080 h.264 8-bit 4:2:0 Rec 709 SDR
5.1 AC-3/Dolby Digital 48kHz 16 bit
3840x2160 h.265 10-bit 4:2:2 Rec 2020 PQ HDR
DTS HD Master Audio 48kHz 24 bit
Or more how Kodi is playing it - i.e. what player route (is it software or hardware decoded etc.)
Or how Kodi is outputting it - i.e. what the output format being sent over HDMI is?
Most 4K/HDR TVs have an 'info' option to display that kind of thing on screen. The TV is also the best place since it can display what is actually being sent vs what Kodi thinks it's sending.
Yes - this may tell you what the hardware is sending to the TV (my Sony just says 1920x1080, 3840x2160 - though it will add /24p if the content is 1920x1080/24p, to tell if HDR is being sent I have to go to the Picture Menu and see if the HDR flag is raised. Other TV manufacturers do better than this, as do some AVR manufacturers who have an app or web interface that tells you what they are being fed/passing through)
Alternatively pressing 'O' (the capital letter) or 'CTRL'+'SHIFT'+'O' can tell you some things about what is happening during replay.
This is one nice thing about CoreElec - it shows you the source video details on the left in the 'O' screen, and the output format on the right - but I guess that is easier as it's tied very tightly to AMLogic.
(I have an HD Fury Vertex that tells me quite a lot too)
RE : uSD cards - I've had issues with Sandisk and Kingston. I always use Samsung these days. Have had far fewer issues with them.
That did the trick and it showed up immediately once I did that and a reboot!!
So question, will this option make a difference for me? Will it be better in terms of just upscaling lower content than 1080p? And 10bit files will play at a lower chroma level of 4.2.2? I just care about it looking the best as it possibly can on my 4K TV. I don't care about playing any 4K content obviously.
Thank you guys.
1. It's usually best to leave your TV to upscale content rather than Kodi - so I'd whitelist 720p and 1080p modes along with 2160p modes - so that Kodi outputs 720p, 1080p and 2160p at their native resolution and lets your TV handle the upconversion if required. (i.e. don't get Kodi to upscale, get your TV to)
2. All consumer content (Blu-ray, UHD Blu-ray, Broadcast TV, DVD, Netflix, Prime etc.) is 4:2:0, so you shouldn't be losing quality in playback when you output at 4:2:2 instead of RGB/4:4:4, you are just changing the chroma up-sampling destination. What you do gain is the ability to have 10-bit HDR 2160p50/59.94/60 content output in full bit-depth (4:2:2 is 12-bit), whereas if you output this content in RGB/4:4:4 YCbCr you'd be limited to 8-bit at 2160p50/59.94/60 (an HDMI spec limitation) which would mean you would be losing bit depth (and potentially introducing banding or dither)
RPi defaults to 8-bit RGB 4:4:4 (LE 10.0.2 will also do 8-bit YCC 4:4:4) and will switch to 10 or 12 bit RGB/YCC 4:4:4 (if available) or 12-bit YCC 4:2:2 (as a fallback) only when playing 10bit videos.
so long,
Hias
Yes - though worth also pointing out that 10/12-bit RGB/4:4:4 YCbCr will only be available for 2160p30 and below UHD modes - as it isn't supported in UHD at 50p and above (it's out of spec for HDMI 2.0).
For playback of 2160p50/59.94/60 stuff you'll be in the realms of 8-bit RGB/4:4:4 YCbCr or 12-bit 4:2:2 YCbCr.
I guess this means that when you have Whitelisting or Adjust Refresh Rate on Start or Start/Stop enabled, you end up with the Pi 4B switching between different colour subsampling modes based on the frame rate / refresh rate being output. The vast majority of content will be 2160p23.976 - but for those of us with 2160p50/59.94 stuff this is more likely to be the case, or for those who run the UI in 2160p50/59.94/60?
UHD modes in HDMI 2.0 have some odd limitations due to bandwidth when it comes to chroma subsampling modes.
I ticked the setting on for HDMI 2 and 3 and have it on @ HDMI 3.
Tried the getedid create from SSH and even rebooted when the option wasn't there.
Tried cmdline.txt forcing the resolution. Still nothing.
Does the Pi itself do 4:4:4 @ 4K@60? That's pretty disappointing if it doesn't, because my TV does support it. I'm back to using 1920x1080p60. I just want to know the benefits of the mode and if it does any justice at a higher signal for 1080p content.
The Pi supports RGB (and I think YCbCr 4:4:4) 8-bit at 2160p60 I think - but it can't do >8 bit at RGB/4:4:4 at 2160p60 (It's not supported in HDMI 2.0/2.0a ISTR - and that's not a Pi limitation).
I think 4:2:2 2160p60 at 12-bit is the preferred mode - but I think it should drop back to the lower bit-depth RGB/4:4:4 modes if 4:2:2 isn't supported?
What version of LibreElec are you running?
Just checking that if you have the option to enabled 'Enhanced HDMI' (which enables high bandwidth 4:2:2 at 2160 60Hz inputs) and that you are using one of the HDMI ports that is able to run this. My Sony UHD HDR set only accepts the highest bandwidth 4:2:2 2160p stuff on HDMI 2 and HDMI 3. HDMI 1 and 4 are low bandwidth 2160p 60Hz 4:2:0 only - and the Pi 4B doesn't do 4:2:0 output.
Yep - AIUI OTA PSIP-delivered EPG data in the US is pretty flaky so XMLTV is the way to go usually.
(In Europe 'in band' EPG data delivered OTA, by cable or by satellite is usually pretty good)
Display MoreI have read above something about .deb installers that I don't quite understand, LibreELEC does not support this and installation on Linux machines can create headaches, for this reason and others I suggest the installation of tvheadend docker service.
For those who want to install the tvheadend service in a minute and ready to go, on almost any platform, including LibreELEC, I suggest this installation SSH command:
docker run -d \
--name=9981-tvheadend \
--net=host \
-e PUID=0 \
-e PGID=0 \
-e TZ=Europe/Paris \
-e RUN_OPTS="--satip_xml http://<satip1>:<port>/desc.xml --satip_xml http://<satip2>:<port>/desc.xml --satip_xml http://<satip3 >:<port>/desc.xml" \
-p 9981:9981 \
-p 9982:9982 \
-v /storage/.config/dockers/tvheadend/config:/config \
-v /storage:/storage \
-v /media:/media \
--privileged \
--restart unless-stopped \
linuxserver/tvheadend
Previous requirements:
- SSH access
- Docker service already installed
Characteristic:
- Execution 'root'
- Full access to /storage and /media in LibreELEC
- Configuration directory located at /storage/.config/dockers/tvheadend/config
- Directory for automatic running scripts on tvheadend service startup located at /storage/.config/dockers/tvheadend/config/custom-cont-init.d
Yep - if you're installing in LibreElec you install the TV Headend service, and as you have said, installing debs manually has some limitations.
I used to always build from scratch, and still do on x86 platforms. I've hit occasional issues building natively on Pi 4Bs, so usually install from the repo using ' sudo apt install tvheadend ' but that's probably quite an old build that's being installed (though it does come with a lot more EPG stuff than the standard GitHub builds). It does what I need though - so it's largely in the 'it just works' category.
I mainly use my TV Headends with SAT>IP and HD Home Run IP tuners, though have used Win TV Dual HD tuners in the past (ISTR that you can improve their performance by changing their USB transfer type)
From the description; the .deb package install requires sudo (root/admin) rights to be installed. It's not a backdoor password, but since it can be used to gain root rights on the host it's a credential to protect - hence the security best-practice advice of not using the same password for the admin user in TVH.
Yes - definitely.
When you install tvheadend from a deb or a repo (which adds it to your system services so that it runs on boot etc.), rather than just running it as code from the command line, you can't run it with the 'no access control' flag (which lets you in without a login and password). As a result TV Headend, when installed from a repo or deb, requires you to create an initial admin user, so that after installation you can actually log in to the web interface for user setup, tuner config etc. and to add other users. I believe this may be the 'superuser' you are talking about.
This admin account definitely shouldn't be the same as your login and password for Linux.
Once you are in the web interface you can create individual user accounts with their own logins and passwords (and different rights levels, including admins), including additional accounts with admin rights, and you can create an anonymous user with very basic streaming rights (and no web interface rights) that won't require a login and password ( as it gets boring typing in logins and passwords into VLC when you just want to open a stream)
Separately AIUI there is a superuser file you can create that will let you create a new admin user if you get locked out from TV Headend's web interface (because you've forgotten, or deleted, all the accounts with web interface access for instance). I believe this is referred to as 'the backdoor'. This is stored in :
/home/hts/.hts/tvheadend/superuserIt's only for use if you get locked out AIUI. I've never had to use it. It only works with the English language UI I think.
You can also reset the password, if you installed via deb, by reconfiguring using dpkg-reconfigure I think.
so you support my statement on WTF is the backdoor password. Its a clusterfrack that seriously needs updated docs and thos docs need to conform to what is in the installer and web UI
AIUI development on tvheadend has slowed down quite a lot over the years, as there has been less and less functionality to add, and a lot of the earlier key developers have had less time to devote to the project as their lives have moved on. Installation via a deb package is just one way of installing TV Headend, and is specific to Debian/Ubuntu flavours of Linux. There are numerous other ways of installing and using TV Headend (Docker containers, building from GitHub and running from the command line etc.)
It's an open source project, like Kodi, developed by volunteers largely in their spare time. Like a lot of projects, time has been spent more on developing the software than writing up the documents. A lot of TV Headend is pretty self-explanatory if you understand basic DVB and IPTV - and the forums usually contain a lot of answers to questions that have come up.
I like it, I use it daily, it solves problems for me. There are other solutions such as MythTV, VDR, NextPVR, TVMosaic etc. I don't find them as useful or as easy to use (VDR had no decent support for UK DVB-T2 Huffman EPG compression for instance)
If you don't like TV Headend then nobody is forcing you to use it! If you think the documentation needs to be improved, nothing is stopping you improving it yourself.
You asked for a solution that would allow you to create a PVR back-end with both ATSC 8VSB and IPTV streams. TV Headend is what a lot of us would use to do that. If it's not for you, it's not for you.
while mine seems to use passthrough it is most likely not since I can still adjust the volume in libreelec what should not be possible (at least this was my past experience before 4K)
Your AVR should indicate what audio format it is receiving over HDMI ? (Mine shows me both on the front panel display and via an app on my phone)
Volume control of the audio output within Kodi (rather than Kodi CEC control of your AVR's volume control - which I don't think many NUCs support) indicates that you aren't using passthrough/bitstream and are instead outputting PCM.
Stupid question - but you have enabled passthrough for all the audio formats your AVR supports?
I've been using TV Headend for 10+ years - including building it from source. Never needed the superuser/backdoor option. Where in the web config is it asking you to set-up or use a backdoor username and password?
I don't use the Wizard, other than to set the initial language. I set-up my real TV adaptor, networks and muxes myself, and import IPTV streams similarly. I don't use XMLTV (the IPTV and DVB stream I use have embedded 'in band' EPG data) but there are a lot of options for using it.
There is a learning curve - but it's worth it.
You'll probably find the easiest way to do this is to use TV Headend - adding your IPTV and ATSC HDHomeRun sources to the same TV Headend back-end, which will then present them as a single PVR source to Kodi.
It's quite an involved set-up process - but worth persevering with. TV Headend runs under Linux - and runs fine on a Pi or an x86 box, and is pretty lightweight in CPU terms, as it's just moving around <15Mbs streams without doing any video encoding or decoding.
Thank you for the detailed write-up, this is far more complex than I imagined! My PC is nowhere near powerful enough for this to be done in a relatively decent amount of time.
Currently I have my rpi4 connected via the soundbar which is 4K compatiable but not HDR. When I play 4K HDR files naturally HDR tag is not active but the BT.2020 one is. Is it fair to assume that the soundbar is passing over an accurate image?
Two things :
1. You can use the second HDMI output from your Pi to carry audio to your Soundbar, and the first HDMI output to carry the picture directly to your TV if you have a spare HDMI port on your TV (removing your sound bar from the video path)
2. If you are watching an HDR10 video without your TV in HDR10 (aka PQ/ST.2084) HDR mode, and thus watching it in SDR (but still in Rec 2020) - you will see very nasty pictures indeed - and instantly know something is wrong.
If you are watching an HLG HDR video in SDR mode but still Rec 2020 - you will notice no major differences until you get in to the highlights of the picture - which will just look less bright. However there is very little HLG out there (BBC iPlayer uses it, as does Sky Q)
