[FernetMenta]

I doubt many here are questioning your ability to improve Kodi internals, be it improving the audio engine, sync issues, or more lately, the VideoPlayer core in order for it to be more coherent and better optimized. You've certainly received acknowledgements for those things in the past. However, removing functionality purely for the sake of one's own 'holier-than-thou' delusions can hardly be considered an improvement.

You are so wrong with that. I explained it many times in this forum that this was not done for the sake of removal but with good reasons. The old messy dialog not only has become overloaded but also very inefficient for rendering. Many systems started to drop frames only because the dialog was brought up. That made this screen rather useless. The infos are still there but not on a single screen. The paramters that change in realtime are rendered in a more efficient way.

[jingai]

You guys need to really give programmers more credit. In general, we try very hard not to piss off the user-base, because it leads to crap like this. Usually, when "your favorite feature" is removed, it's for a good reason.. generally, because it was broken and causing problems for others.

Everyone knows you're upset about it, but it can't be helped if no one has the time to replace it with a working version. This is why you get answers like, "well code it yourself then."

No one here is being paid for their work.

[Gade]

I absolutely agree.

Devs of all kind put hundreds if not thousands of hours into this project often in their spare time for free.

The amount of work done for Kodi Krypton is fantastic and the work put into videoplayer is absolutely amazing.

It's negative comments like these which can discourage devs from doing any contributions.
People need to stop whining!


On a smaller scale, I've removed or completely changed features as well used by many people. In the short run it pisses people off, but on a larger scale it's necessary to improve and evolve the product.

[ashlar]

So bug reports have to be filed only by people coding? FernetMenta has got some strange ideas on how this venture succeeded before he came on board...

why don't you compare the versions of video player, now and the time before I came on board. I actuallly started coding and contributing to this project because video playback was all but good at that time. I was not able to watch a whole movie without multiple major a/v issues. what do you think is more important: improving things for the majority or providing some info for a few users who feel happier with some numbers they don't know how to interpret? anyway, there will always be users complaining ...

always glad to see how improvements are honored

As in the past, I'm not questioning your devotion to the project, the amount of time you freely donated to the community, your ability as a programmer. Nothing of the sort.
I am humbly saying that sometimes you come out as too abrasive toward "normal" non coding users. Maybe this is not true for everybody, but there's good people here that even if not coders have a deep respect and devotion to the project as well.

Edit: to be clearer: a deep thank you, FernetMenta, for all you have done for Kodi. This is *always* the spirit with which my posts must be read.

[Drag0nFly]

I doubt many here are questioning your ability to improve Kodi internals, be it improving the audio engine, sync issues, or more lately, the VideoPlayer core in order for it to be more coherent and better optimized. You've certainly received acknowledgements for those things in the past. However, removing functionality purely for the sake of one's own 'holier-than-thou' delusions can hardly be considered an improvement.

You are so wrong with that. I explained it many times in this forum that this was not done for the sake of removal but with good reasons. The old messy dialog not only has become overloaded but also very inefficient for rendering. Many systems started to drop frames only because the dialog was brought up. That made this screen rather useless. The infos are still there but not on a single screen. The paramters that change in realtime are rendered in a more efficient way.

First off; thanks for replying. And thanks for the work you and other devs are doing on Kodi. I also do not intend for my any of my posts to be interpreted in a negative way. However, based on the amount of comments and general reactions from users and developers alike after removing this feature, I somehow feel that the assertion of me being wrong for simply suggesting that it has caused much unneeded work and frustration - both of which could easily have been avoided - is somewhat dubious.

Although I, like others, was skeptical (or you may call it wrong - I have no problem with that) for the reasons this had to be changed - probably due to the fact that I have been running Kodi on a measly i3-based Ivy Bridge system for years now, which is doing all kinds of other tasks, like transcoding video, serving nfs, running bittorrent, ripping Blu-Rays, et al., while playing 1080p AVC & HEVC material through Kodi, without having noticed a negative performance impact, or dropped frames, caused by displaying the codec overlay screen (which I frequently use), I can certainly see that there are more efficient (and cleaner) ways of making this information available to the user.

Where we differ is how this was handled, and the usefullness of the information the screen itself provided being called into question (i.e, 'why would you need cpu usage', 'you should know the formats you are playing/the bitrates/you should ensure sufficient i/o and not rely on the buffer stats', et cetera) and especially comments suggesting that the codec overlay is 'for developers only' that are - IMO - really counterproductive. There is no reason why this screen with its original ('overloaded') information could not have been included in the VideoPlayer rewrite apart from purely ideological reasons - one could even have a flag in advancedsettings.xml to toggle how much would be displayed. This was where my 'holier-than-thou' comment came in, and that overlooking its usefulness, and the users pointing this out was delusional. Not the actual change itself. Based on prior comments, I feel the need to point this out explicitly.

As for discouraging participation in Kodi due to critical comments: we are all aware that work on this project is based on (invaluable) contributions done in spare time, for which nobody draws a paycheck. This is no different from any other FLOSS based project, most of which have channels to deal with users' wishes for the good of the project, and has worked out well in the past. That said, if people feel their voices aren't of any value any more, they are going to be disinclined to contribute; and existing developers might be drawn away also. As a longtime user of Kodi I strongly feel this point has to be made.

So again, I am certainly grateful for the work done by you in cleaning up the VideoPlayer core; I showed this appreciation early on when the 'rounding-magic' was fixed allowing for proper 23.976Hz playback - which basically retired both my standlone Blu-Ray players as a result, as well as quite a few bugs I reported and nagged FernetMenta on while he was working on the audio engine. The project has a wide variety of contributors - coders and non-coders, all of which are important assets to the project, and something I for one am very appreciative of.

[xayide]

I am very sad to see all this good info gone.I used it almost daily, sometime when movie stuttered and sometimes to see if the fresh was right and so on. I can't say it ever made it skip frames even on my measly/slow DN 2820 FYKH nuc. For me it was very useful, missing this made me wonder why my macbook got so hot with krypton and not with jarvis. Thing is I couldn't really compare them in a good way since I hade to look at cpu when kodi was off screen in the not active display since only jarvis has the cpu-info and other stuff while playing in osd. Kyrpton is still inferior to cpu. Like 5 times the cpu usage of jarvis even if the static rendered codecinfo is gone.

Although if this would have used that much cpu on some systems they needed not to use the feature. It's still optional to press O

[Lexridge]

As a Broadcast Television Engineer, I really relied on this status to check the bitrates of our stations off-air signals, and competitors stations as well. It was something unique and very useful in Kodi and many Broadcast Engineers use as a "cheap" tool to use while not at work. I have used it personally to discover our very expensive MPEG2 encoder switched itself from DD5.1 to MP2 audio encoding one evening a few months ago. I am sorry to see it disappear. I will still keep one machine running v16 that has this feature still intact for the foreseeable future. However, on a personal level, PiP would be really useful too, and so awesome! Perhaps someday Kodi might have Multi-Viewer functionality too lol

[ifelsethenend]

Hi, I was refered to this post thread when asking about the video bitrate info in the RPi section.

The final reply I got was that the video bitrate (in kb/s) as opposed to the realtime data transfer (in Mb/s) was removed in Kodi 17 and is simply not present anymore in either the PlayerProcessInfo screen and the PlayerDebug screen.

My request is to return this little piece of helpful info. Reading through this thread, I agree the Kodi 16 codec screen was an unintuitive mess, and spliting it into 2 new screens in Kodi 17 make much more sense. The video bitrate info is still missing though, and I would like to suggest adding it to the PlayerDebug screen instead of the resolution info. The reason is that the resolution info is already displayed neatly in the PlayerProcessInfo screen.

Hopefully this can be implemented in Kodi 18, which I see is under development.

Thank you.

[FernetMenta]

This info is still exposed by videoplayer and skins are free to display it wherever they want. Personally I won't display it with processInfo because it is metadata and belongs to a stream and not to the process of player. You should post your request in a section skinners observe.

[the_bo]

This info is still exposed by videoplayer and skins are free to display it wherever they want. Personally I won't display it with processInfo because it is metadata and belongs to a stream and not to the process of player. You should post your request in a section skinners observe.

Hi Fernet

Do you know the info label used to display the bitrate so i can put it on my skin?

Thanks

[FernetMenta]

This info is still exposed by videoplayer and skins are free to display it wherever they want. Personally I won't display it with processInfo because it is metadata and belongs to a stream and not to the process of player. You should post your request in a section skinners observe.

Hi Fernet

Do you know the info label used to display the bitrate so i can put it on my skin?

Thanks

VideoPlayer.audiobitrate, VideoPlayer.videobitrate

EDIT: only v18

[Hitcher]

@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? 

[FernetMenta]

@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.

[Hitcher]

Thanks for the explanation.

[Yubby]

I have waded through all of the 'threads' dealing with the topic (of the detailed codec information), hoping to find an answer that would satisfy 'me', but although I see that many others share 'my' opinion (as an 'end user', and not just a technical evaluator/implementer) as to the need and advantage of having a more 'detailed' display of video files and streams, there doesn't appear to be a resolution that would satisfy them or myself...

I personally think of the Kodi application as the best 'media portal' available today, after having progressed through all of the contenders over the past 15 years (starting with MythTV).  It has taken the crown from the 'now discontinued' Windows Media Center, as the 'easy to install' user application, and wisely positioned itself as a 'framework' sitting in the center of all the different hardware and O/S's it can be installed on, and the application 'add ons' which make it so much more than the other 'monolithic' products available.

BUT, (if you're caught up on Game of Thrones, you know what's coming)  there appears to be a 'disconnect' between the providers (i.e. developers) of Kodi, and it's end-user base.  One side of the discussion is adamant of what's best for the product, while the other tries in vane to elucidate what value they see the product has (had).  The most striking example (which has been stated by others in this thread to no avail) is 'why' certain details of the video/audio files/streams are seen as so important.  There's an erroneous assumption that 'end users' have no need or interest in evaluating the 'quality' of streams and files and that they should just sit back, relax, and watch them without regard (paraphrased a bit, but actually stated in the thread).  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.

From experience,  I will state that "no two 1080p sources are created equal" (even under the eyes of the law).  The previous 'codecinfo' display made this obvious, with elements such as DAR, SAR, kbps (for both the video and audio portions) enabling me to understand why the image on my screen was 'crap', though the 'Info' screen stated that it was a 1080p stream (this includes streams from addons acquired from the 'base' Kodi repository).

There IS a difference between a 1080 video, that was reformatted (transcoded) from a 360x240 source, with a 54kbps 'mono' audio stream, than that of a 1:1 with a 256kbps 5.1 profile. This difference is now 'hidden' by the new info display format. (the 'debug' window is of little or no help)

The repeated statements of "you must be a 'power user'" or 'developer'" illustrates that the members of the Kodi organization are not aware of 'who' exactly is installing and using their product.  Though I have now deployed 20+ units to friends and family members, who now focus on using it over 'smart' TV apps and web-browser based sources,  'they' would never have known that the product existed, nor how to obtain, install, and/or configure it to their liking.  Such that I would suggest that the vast majority of people who have done so, ARE more knowledgeable than the troglodytes you assume to be using the product, and have done so, because of the granularity of control provided (previously) over other choices (like selecting UNIX/Linux over Apple and Microsoft products).

I'll finish my screed with an example of what happens when a product assumes to 'know best'.

Silicondust engaged in a project to create a DVR application, as a 'back end' to their HDhomerun products (as most know that they have a 'frontend' addon for Kodi).  The developers made a decision 'not' to include the usual 'grid' format of TV guide, resulting in a similar dissertation on the support forums as seen on 'this' topic.  The end users wanted/needed the guide, but the developers said that it wasn't necessary and wouldn't be included.

That opened the door for 'other' products (including the age-old MythTV in its 'back end' variant) to become relevant again, providing the functionality that the end users sought...