[noggin]

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.

Ah - from your tone I inferred (incorrectly) that they had moved.

Out of interest how do you know what you are playing by this point? Unless you have analysed the file prior to replay - where is this information available? (And obviously some sources have on-the-fly changes to things like aspect ratio - DSat SD in the UK flips between 4:3 full-width and 16:9 full-width using MPEG2 header flags on a show-by-show basis, and audio - where AC3 format and bitrate can change on a show-by-show basis too)

If rendering extra content that is essentially static - or changes only infrequently - causes a processing hit that negatively impacts the debug purposes - then it sounds like two different overlays are ideally needed then ?

"Codec Info" / "Playback Info" or whatever you want to call it - that tells you what you are playing and how it is being played. (I guess there is then a discussion about whether this should be skinned. Personally I'm not sure it needs to be - it's not quite in that area IMO - but others may well have a different view )

"Debug Info" / "Developer Info" which gives you a view optimised purely for developers and only has the minimum information that is required to render it as quickly as possible?

[noggin]

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

Yes - this is another - and equally valid - way of presenting similar information. I'd probably add incoming video and audio bitrates to it as well - as it is really useful to see this information alongside codecs.

(Personally I'd love to see the end of YUV being used to mean YCbCr... U & V are used (technically incorrectly) as shortcuts in computer video-land, but if you want to be correct they are Cb and Cr, as U and V specifically refer to weighted colour difference signals in a PAL composite encoder and decoder... )

[rd1979]

+1 here as well.
Having this sort of info has always been very useful.

[FernetMenta]

First iteration, VideoPlayer (stream player video) exposes this info to GUI

decoder name (string)
pixel format of content, i.e. YUV420 (string)
currently active deinterlacing method (string)
video dimensions (width and height) used by decoder (non cropped), i.e. 1920x1088 (int)
video fps steam player video has detected (string)
isHwDecoder (bool)

Next round will be audio info.

[popcornmix]

currently active deinterlacing method (string)

Whether stream is interlaced would also be useful here (for the case when deinterlace is not automatic).

video dimensions (width and height) used by decoder (non cropped), i.e. 1920x1088 (int)

Aspect ratio would also be useful.

isHwDecoder (bool)

There may be more than one option for hw acceleartion (mmal/omxplayer or mediacodec/mediacodecsurface).
I don't know if a string here would make that explicit? (or should the decoder name indicate this?)

[FernetMenta]

1)
Yes, aspect ratio can be exposed too. It would be the aspect ratio player sees, not necessarily the one from the stream's metadata.

2)
I think about of trashing deinterlace mode. in 99.9999% of all case this make no sense. I never ever have set it to anything other than auto.

3)
you can convey this info in decoder name.

[gjwAudio]

First iteration, VideoPlayer (stream player video) exposes this info to GUI

decoder name (string)
pixel format of content, i.e. YUV420 (string)
currently active deinterlacing method (string)
video dimensions (width and height) used by decoder (non cropped), i.e. 1920x1088 (int)
video fps steam player video has detected (string)
isHwDecoder (bool)

Next round will be audio info.

@FernetMenta
Thank you so much for moving forward on this initiative !

I constantly use the Codec Info display (for reasons stated so well by others above...), and miss "the old display" now that I'm on the Milhouse Testbuild path.

Q: will this information require specific skin support - or does it simply expand the data on the current display ?

[FernetMenta]

Q: will this information require specific skin support - or does it simply expand the data on the current display ?

Yes, skins need to provide the dialog. I don't know yet if we'll make this a mandatory dialog for skins or not.

[gjwAudio]

Q: is it time yet to begin harassing Skin Authors/Maintainers for revised overlay ?

[noggin]

2)
I think about of trashing deinterlace mode. in 99.9999% of all case this make no sense. I never ever have set it to anything other than auto.

There are times when it can be quite useful to compare different modes when trouble shooting - you aren't talking about removing the option to explicitly set the mode are you?

[FernetMenta]

2)
I think about of trashing deinterlace mode. in 99.9999% of all case this make no sense. I never ever have set it to anything other than auto.

There are times when it can be quite useful to compare different modes when trouble shooting - you aren't talking about removing the option to explicitly set the mode are you?

Yes I do. I am around for quite some time and deinterlacing was the first topic I cared about. In all the years there was not a single case where I found this option useful. Forcing deinterlacing on progressive material is maximum nonsense and leads to nothing but unpredictable behaviour.

[sarbes]

Could you add stream informations? The status of the buffer is pretty important to determine the cause of video stutters. The bitrate is also good to know.

[FernetMenta]

What buffer are you referring to?

[Drag0nFly]

I believe he is referring to the caching settings which are activated via advancedsettings.xml–

<network>
<buffermode>1</buffermode>
<readbufferfactor>20.0</readbufferfactor>
<cachemembuffersize>638860800</cachemembuffersize>
</network>

I rely on that information in the codec info as well.

[noggin]

2)
I think about of trashing deinterlace mode. in 99.9999% of all case this make no sense. I never ever have set it to anything other than auto.

There are times when it can be quite useful to compare different modes when trouble shooting - you aren't talking about removing the option to explicitly set the mode are you?

Yes I do. I am around for quite some time and deinterlacing was the first topic I cared about. In all the years there was not a single case where I found this option useful. Forcing deinterlacing on progressive material is maximum nonsense and leads to nothing but unpredictable behaviour.

I think we are at crossed purposes - I was asking if you were removing the option to cycle between different deinterlacing modes - e.g. VAAPI Bob, VAAPI MCDI, VAAPI MADI etc.

However there are times when the other option of On, Auto, Off can be useful too. This is particularly the case when Kodi gets the interlaced/progressive decision wrong... It used to routinely do this with 4:2:2 H264 (and I think MPEG2) 1080/50i which was only deinterlaced when forced ON rather than left in AUTO (where it was treated as progressive) for a long time (Linux + VAAPI) - and in some cases still is I think.