Kodi Community Forum

There was a thread here : http://forum.kodi.tv/showthread.php?tid=275260 which covered requests to reinstate some of the functionality removed from the 'Codec Info Overlay' in Krypton. It is the OSD generally brought up pressing 'o' on a keyboard (or 'Guide' on an MCE remote)

Historically this overlay had information on it that was useful (or not useful) for a number of different use cases and situations. Some of the functionality that has currently gone is missed, and there are some requests to improve this.

So can I pose some questions :

A. Can a single overlay satisfy all use cases ? The previous mix of information was daunting for some, and had a mix of very technical, and quite non-technical information on it. Should we have two different overlays - or can we combine the two in a more user-friendly manner for multiple user-groups?

B. What do we need to be displayed and how ?

Suggestions :

1. Audio and Video file codecs currently being played back (possibly also subtitle source and type?). These are unambiguous descriptions of the codecs currently being played - NOT how they are being played - but instantaneously reflect what is being fed into Kodi. Broadly speaking this is "INPUT"

e.g.
Video Codec : H264 8-bit : 1920 x 1080 : 23.976fps or H265 10-bit : 3840x2160 : 50 fps (Also an Interlaced / Progressive flag and flagged aspect ratio could be useful here - and aspect ratios can change on the fly with some SD TV sources) (*)
Audio Codec : AC3 : 5.1 : 48kHz 16 bit or DTS-HD MA : 7.1 : 96kHz 24 bit (This needs to be constantly updated as audio formats can change on the fly) It could also have a Language field e.g. English or Narrative though this could be deemed blurring the line between codec and content information - personally I'd go with codec only - but that's a discussion isn't it?)

(*) If this could also have an Advanced/Expert setting that displayed Level, Profile, Chroma Subsampling (so 4:2:2 was clearly different to 4:2:0), additional info like MBAFF, PAFF and No of Reference frames - that could be really useful, though I realise some of this might be better suited to Media Info. (4:2:2 flagging would be useful though)

2. Audio and Video playback paths - i.e. how these video and audio streams listed above are currently being decoded. Broadly speaking this is "OUTPUT" :

e.g.
Video Playback decoder/path : omx-h264 or omx-mpeg2
Audio Playback decoder/path : ac3 or dca
(These could be merged with the above - and a simple hw vs sw flag used before them to reflect CPU or VPU/GPU decode, a decode or PCM or bitstream or passthrough could be displayed to indicate audio output mode?)

It might also be worth putting an

Output resolution and refresh rate : 1920x1080 : 50Hz or 3840x2160 : 24Hz so that you can see mismatches where output refresh rates don't match input frame rates (i.e. 23.976 is being played at 24, or 23.976 is being played at 59.94?, or to confirm that they do - where 25Hz interlaced content is output at 50Hz etc. and confirm that you are running at the right output resolution, now that both refresh rate rate and resolution can switch dynamically?)

Also useful to display whether deinterlacing is activated and what method is being used Deinterlace ON, VAAPI-MCDI or YADIF 2x (again a hw or sw flag could also be displayed?) These are distinct from the Video settings menu where you select things like AUTO etc. as that doesn't tell you whether they are enabled or not, and doesn't tell you which mode is being used if you leave it on AUTO. (Some platforms use different levels of deinterlacer for different resolutions and frame rate - with HD not getting as good deinterlacing as SD for instance)

3. What bitrate these audio streams are running at (this could be merge with 1. as it is effectively "INPUT" :

e.g.
Audio bitrate : 128kb/s or 640kb/s (this reflects the instantaneous source bitrate, not the bitrate of the decoded audio, and this can also change on the fly with some sources - particularly Live and Recorded TV)
Video bitrate : 3.69 Mb/s or 50 Mb/s (this will reflect the instantaneous source bitrate - as many sources have VBR)

4. CPU load and possibly temperature if that is available?

There are other useful things that I don't use that I'm sure others do - like details about dropped/skipped frames, buffer levels etc. that could be added to this.

I also readily accept that my 'under the hood' understanding as to how Kodi works may mean that some of this information is difficult or impossible to generate.

+1 for the above.

I think we all appreciate that none of this is absolutely vital but it sure is a massive help in lots of little ways. Dropped/skipped frames happens to be my most looked at part with framerate a close second.

Dont think temperature (already in the sys info of the skin) and Chroma are really usefull, for the rest it matches my exceptations.
Hope it will be possible.

CPU load is useless without including the CPU freq. Too many times I have seen users complaining about high CPU percent only to discover that the OS has cycled down the freq and turned off CPUs. 10 percent at 500kHz is very different than 10 percent at 2GHz.

Having CPU load on the same screen as codec info makes no sense. If someone gets to the stage of looking at CPU loads she/he should be aware of the type of content playing.

(2016-05-29, 20:09)FernetMenta Wrote: [ -> ]Having CPU load on the same screen as codec info makes no sense. If someone gets to the stage of looking at CPU loads she/he should be aware of the type of content playing.

It's very useful when software decoding stuff and it begins to drop frames. If you can see CPU load hitting close to 100% you get a good indication of the reason the frames are being dropped. Particularly useful if you can correlate it with high bitrates on VBR sources.

40Mbs H264 or MPEG2 4:2:2 1080i with software decoding and deinterlacing can push a CPU - it's useful to see how bad things are...

(2016-05-29, 17:32)bibi Wrote: [ -> ]Dont think temperature (already in the sys info of the skin) and Chroma are really usefull, for the rest it matches my exceptations.
Hope it will be possible.

Chroma has been quite useful for me in the past - and the older OSD did it (displaying yuv420 or yuv422 I think) - as some of us have content that isn't all 4:2:0. I accept it's niche though - and I can flag in file names (not sure the library has support for 4:2:2 , 4:4:4 etc. flagging?)

I suspect as we start to get a mix of 601, 709 and 2020 content, plus HDR10, HLG and possibly Dolby Vision, flagging the colour space of the incoming file and the output may also be quite useful in fault finding terms.

(2016-05-29, 21:32)noggin Wrote: [ -> ]

(2016-05-29, 20:09)FernetMenta Wrote: [ -> ]Having CPU load on the same screen as codec info makes no sense. If someone gets to the stage of looking at CPU loads she/he should be aware of the type of content playing.

It's very useful when software decoding stuff and it begins to drop frames. If you can see CPU load hitting close to 100% you get a good indication of the reason the frames are being dropped. Particularly useful if you can correlate it with high bitrates on VBR sources.

40Mbs H264 or MPEG2 4:2:2 1080i with software decoding and deinterlacing can push a CPU - it's useful to see how bad things are...

Requirements are not just wishes and I expect you to give reasons why this is usefull. Don't hesitate to give examples how this helped you in the past.
I have been doing VideoPlayer development for quite some time now and never found CPU load values of any interest when looking at codec info.

Dropped/skipped frames won't be on the new dialog. Those values will stay where they are now.

(2016-05-29, 21:34)noggin Wrote: [ -> ]

(2016-05-29, 17:32)bibi Wrote: [ -> ]Dont think temperature (already in the sys info of the skin) and Chroma are really usefull, for the rest it matches my exceptations.
Hope it will be possible.

Chroma has been quite useful for me in the past - and the older OSD did it (displaying yuv420 or yuv422 I think) - as some of us have content that isn't all 4:2:0. I accept it's niche though - and I can flag in file names (not sure the library has support for 4:2:2 , 4:4:4 etc. flagging?)

I suspect as we start to get a mix of 601, 709 and 2020 content, plus HDR10, HLG and possibly Dolby Vision, flagging the colour space of the incoming file and the output may also be quite useful in fault finding terms.

I agree that chroma can be of interest and it fits into a codec info dialog

(2016-05-29, 23:17)FernetMenta Wrote: [ -> ]

(2016-05-29, 21:32)noggin Wrote: [ -> ]

(2016-05-29, 20:09)FernetMenta Wrote: [ -> ]Having CPU load on the same screen as codec info makes no sense. If someone gets to the stage of looking at CPU loads she/he should be aware of the type of content playing.

It's very useful when software decoding stuff and it begins to drop frames. If you can see CPU load hitting close to 100% you get a good indication of the reason the frames are being dropped. Particularly useful if you can correlate it with high bitrates on VBR sources.

40Mbs H264 or MPEG2 4:2:2 1080i with software decoding and deinterlacing can push a CPU - it's useful to see how bad things are...

Requirements are not just wishes and I expect you to give reasons why this is usefull. Don't hesitate to give examples how this helped you in the past.

I often play content that can't be hardware accelerated and thus needs to be software decoded, and usually software deinterlaced (most of my content is interlaced). The nature of what I do for a loving is that I work with content in non-consumer codecs, and quite like the ease of use of Kodi as a front end for that at home (I don't use Kodi much at work - but I do use it at home for watching content I've worked on creating) I accept that this is niche - though I quite like pushing Kodi in this direction. (The core UI and surrounding player experience is so good. I keep meaning to try 4:2:2 and 4:4:4 ProRes HQ and DNXHD .mxfs and .movs in it... )

When evaluating new hardware, or new Kodi builds, I try to push things - and the CPU load figures help me at least start to work out whether video artefacts that shouldn't be there are lack of CPU horsepower, lack of multithreading (when you see 1 CPU at very high level but the rest very low) or something else.

Quote:I have been doing VideoPlayer development for quite some time now and never found CPU load values of any interest when looking at codec info.

For hardware acceleration I can see it wouldn't be that useful - but some codecs don't get hardware acceleration - and seeing that problems co-incide with high CPU usage can mean you discover the source of your problem (content that is too CPU hungry for your platform) very quickly.

Quote:Dropped/skipped frames won't be on the new dialog. Those values will stay where they are now.

Out of interest - where have they moved to? (Debug log?)

(2016-05-29, 23:29)noggin Wrote: [ -> ]Out of interest - where have they moved to? (Debug log?)

They were not moved. They are on the debug screen currently accessible by pressing the o key. When looking at this screen you know what you are playing and rendering static info just does harm to real-time processing.

I would say that one overlay is enough because then the user can simply pick out the information that they are specifically looking for but still have the additional information that may have relevance when changing settings or trying to resolve issues.

However, if there was a thought process that was looking at 2 different overlays then I would say that this could potentially be of satisfaction to everybody by utilising 2 key presses.

One for non technical.
One for all information.

At one point or another, all of the information that I have seen in the past when pressing the O key has been of use (CPU usage being one of them that can have great value that I discovered when changing a linux kernel, where a new er version caused a significant increase in CPU load), so useful in keeping the power bills as low as possible.

I would suggest separating video, audio, subtitle info parameters and for each detailing the input and output so it's clear what's the video player is doing under the hood and how a specific setting change the rendering path:
Video Codec: H264 -> DXVA decoder
Video Resolution: 1280x720 -> 1920x1080 (Lanzcos3)
Video Framerate: 50 interlaced -> 50 progressive (yadif).
Video Color space: YUV 4:2:0 8bits BT709 Limited range -> RGB 8 bits Full range (pixel shaders)
Audio Codec: DTS -> PCM (dcadec)
Audio channels: 5.1 -> 2.0 (normalized)
Audio samplerate: 48 KHz -> 44 KHz (optimized)
Audio output: DirectSound

I think it'd also be useful if the audio information listed what is happening on the audio front. As in, is it bitstreaming? Is it decoding to PCM? Is it transcoding to AC-3 and bitstreaming the AC-3 transcode? Kodi currently give the user no real feedback on that whatsoever. Oh and this would also apply for extracting lossy DTS from the lossless DTS-MA source.

(2016-05-29, 23:17)FernetMenta Wrote: [ -> ]I have been doing VideoPlayer development for quite some time now and never found CPU load values of any interest when looking at codec info.

You think too much as a dev

IMO either you add the advanced user needs to that screen that have a default mapping. Or remove the default mapping and say the information are now dev only. And devs add a mapping manually.

But having pure dev info without users info in a screen that users can see by pressing the menu button on any remote does not sounds good and will trigger whining.
A lot of users have discovered that function since menu button is on every remote.