[Hitcher]

The 'details' are 'not' used necessarily for debugging purposes, but for deciding on the choice between files and streams to identify a better version or source.

If you can't tell by just watching then there's little point in the info.

[Lexridge]

The 'details' are 'not' used necessarily for debugging purposes, but for deciding on the choice between files and streams to identify a better version or source.

If you can't tell by just watching then there's little point in the info.   

Why do you have to be such a smartass? Just because you personally do not need that feature anymore does not mean that it was not useful. I used that feature on nearly every over-the-air broadcast that ran through Kodi, and trust me, if it were not for other reasons, I would revert back to 16 because this feature is such an important one, to me. Yubby is right, you devs are completely disconnected from your own user base and it seriously shows. You guys are adding unneeded or even unwanted and useless features just because you have nothing better to do. Please, stop FIXING things that are not broken!

[FXB78]

Wow the use of apostrophes in that post made it painful to read

Nearly all the info from the old codec info screen is still available, you just need to use the default playerprocessinfo (O) & the new playerdebug screen (CTRL+SHIFT+O). Using these two should give you enough information to deem why your stream is crap quality or whatever else you need to see.

I was initially against the removal of the old codec info screen but honestly I don't miss it now, I just moved with the times & mapped a button to playerdebug. Job done.

[FXB78]

You guys are adding unneeded or even unwanted and useless features just because you have nothing better to do. Please, stop FIXING things that are not broken! 

I'm guessing you didn't read through the thread, the video player was completely re-written for the first time in many years... do you think that was done because people have nothing better to do? Of course not.

[Karellen]

Why do you have to be such a smartass? Just because you personally do not need that feature anymore does not mean that it was not useful. I used that feature on nearly every over-the-air broadcast that ran through Kodi, and trust me, if it were not for other reasons, I would revert back to 16 because this feature is such an important one, to me. Yubby is right, you devs are completely disconnected from your own user base and it seriously shows. You guys are adding unneeded or even unwanted and useless features just because you have nothing better to do. Please, stop FIXING things that are not broken!

@Lexridge

Your comments and attitude are uncalled for. This is your first warning

Show respect to your fellow users and Team Members. @Hitchers statement is accurate. Do you really need some numbers on a screen to convince you that what you are seeing is "good". Do you have such little trust in your own powers of observation? Instead of concentrating on the technical accuracy of the video, maybe enjoy the movie instead.

You do realise this is a FOSS development? That means the developers don't have to lift an iota to please you. In fact they can choose to stop all development today if they so desire without any repercussions to them.

If you are not happy with Kodi, please, please use another product, or you can contribute to the development code. Failing those two, then just accept Kodi as is distributed.

[Memphiz]

From a psychological point of view - having to look at those numbers might just be an obsession. That would also be a reason why people have such a hard time to accept that it is gone or changed now. I don't mean it offensive in any way. Just looking at psychology from time to time really helps a lot.

[Lexridge]

Why do you have to be such a smartass? Just because you personally do not need that feature anymore does not mean that it was not useful. I used that feature on nearly every over-the-air broadcast that ran through Kodi, and trust me, if it were not for other reasons, I would revert back to 16 because this feature is such an important one, to me. Yubby is right, you devs are completely disconnected from your own user base and it seriously shows. You guys are adding unneeded or even unwanted and useless features just because you have nothing better to do. Please, stop FIXING things that are not broken!

@Lexridge

Your comments and attitude are uncalled for. This is your first warning

Show respect to your fellow users and Team Members. @Hitchers statement is accurate. Do you really need some numbers on a screen to convince you that what you are seeing is "good". Do you have such little trust in your own powers of observation? Instead of concentrating on the technical accuracy of the video, maybe enjoy the movie instead.

You do realise this is a FOSS development? That means the developers don't have to lift an iota to please you. In fact they can choose to stop all development today if they so desire without any repercussions to them.

If you are not happy with Kodi, please, please use another product, or you can contribute to the development code. Failing those two, then just accept Kodi as is distributed. 

I apologize for my words. Some people just assume things for the wrong reasons sometimes and I should not have gone off about it.

As I mentioned before I am a broadcast television engineer. I don't like to just look at pretty bit rates in a row. Seems rather boring I think. I was using the data to compare the various broadcast encoders in local television markets and comparing between Harmonic, Adtec and Wilcox encoders. The Harmonic encoders are very efficient and can encode up to 3 HD streams in the allocated 19.4Mb/s which is amazing. By comparison the Adtec encoder (older model I assume) can only do one HD and one SD simultaneously. Something odd too, one local broadcast station is actually exceeding the 19.4Mb/s limit by quite a bit (no pun intended), which is not legal and would/should not be passed by the multiplexer, so I would assume Kodi has a bit rate bug in it somewhere or the FCC would have already shut down their transmitter months ago.

[Martijn]

Last I looked kodi wasn't designed to be a video stream analysis tool. Also not everyone reads history to see who does what for a living.

OK so you have a special use case which is certainly not generic. There's still the advanced shift+on overlay that's useful?

[noggin]

Would it be possible to add colour-space and EOTF reporting to the codec OSD?  Now we are in the realms where we have at least three colour-spaces, plus additional EOTFs in HDR-land, to worry about, it would be great if the codec OSD indicated what flavour (colour space, EOTF) the source media was, rather than just resolution and frame rate? 

At the moment we have the following in widespread use (there are other, less common, standards that are much rarer) :

• ITU-R BT.601 (SD norm)
  
• ITU-R BT.709 (HD norm, but also used for some UHD)
  
• ITU-R BT.2020 (UHD - used for SDR and HDR, and also for SD and HD in adaptive streaming)
  

 

• ITU-R BT.1886 (HD standardised SDR EOTF)
  
• ITU-R BT.2100 (HD and UHD standardised HDR EOTFs in both PQ and HLG flavours) - so BT.2100 - PQ (SMPTE 2084) (which is used for HDR10 among others) and BT.2100 - HLG (aka ARIB STD-B67)
  

Displaying bit-depth of the source video codec would also be useful.

Additionally - showing the output format (if that is possible) would also be potentially useful?

I was playing a 3840x2160/25p UHD Rec 2020 HDR HLG source in Kodi last night, and realised I had no real way of knowing what was going on in any detail.

ffmpeg reported :

Code:

Stream #0:1: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67), 3840x2160 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 25 tbc (default)

Media Info reported :

Code:

Video
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main [email protected]@Main
Codec ID                                 : V_MPEGH/ISO/HEVC
Bit rate                                 : 21.5 Mbps
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0 (Type 2)
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.103
Stream size                              : 8.71 GiB (99%)
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : BT.2020 non-constant
Matrix coefficients                      : BT.2020 non-constant
colour_primaries_Original                : BT.2020
transfer_characteristics_Original        : HLG / BT.2020 non-constant
matrix_coefficients_Original             : BT.2020 non-constant

When compared to a 3840x2160/24p UHD Rec 2020 HDR PQ/HDR10 source :

ffmpeg :

Code:

Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

MediaInfo :

Code:

ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main [email protected]@High
Codec ID : V_MPEGH/ISO/HEVC
Bit rate : 59.7 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.300
Stream size : 45.9 GiB (91%)
<snip>
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 500 cd/m2

Having some of this information in the Kodi codec OSD would be useful? As would having the output format too?

[rafikW]

@Fernet

Code:

VideoPlayer.videobitrate

doesn't return anything for me in v18. Also, isn't the video bitrate the second number (M/bs:nn.nn) in the second line of the ProcessInfo screen? 

VideoPlayer.videobitrate is metadata belonging to the stream. If it is not set, we don't get anything from demuxer. What you see on ProcessInfo is NOT metadata, it is a measured avaraged value. 
I won't mix metadata with process parameters. If you do, you'll get the same crap we had on the old screen. Some values but nobdy on the planet who knows what they really mean.

I'm running Kodi 18.9 on Odroid-N2 with CoreELEC.
Videobitrate is presented only for mpeg-4 content. Is not presented for h264 nor h265.
Audiobitrate is presented for DTS and AC3 audio streams but is not presented for EAC3, Opus and True HD (this is only what I was able to confirm)
Of course all those streams are having "Bit Rate" set so the statement that it is not displayed because it is missing isn't a true.
I'm using the following label in DialogPlayerProcessInfo.xml:

<label fallback="1446">$INFO[Player.Process(videowidth),,x]$INFO[Player.Process(videoheight),, px]$INFO[Player.Process(videodar),$COMMA , AR]$INFO[Player.Process(videofps),$COMMA , FPS]$INFO[VideoPlayer.VideoBitrate,$COMMA , kb/s]</label>

<label fallback="1446">$INFO[Player.Process(audiodecoder)]$INFO[Player.Process(audiobitspersample),$COMMA , bit]$INFO[Player.Process(audiosamplerate),$COMMA , Hz]$INFO[VideoPlayer.AudioBitrate,$COMMA , kb/s]</label>

Interesting result that for some stream types bitrate is presented and for other type it isn't.