[FernetMenta]

There is a lot of crappy hacks done in the past and I am going to trash them one after another. If some interlaced material is not detected as interlaced, there is a root cause for this that needs to be fixed. Forcing deinterlacing and presenting it as as user option is wrong.

[willemd]

Somehow I feel the de-interlacing discussion is off-topic in this thread, but here are my €0,05.

I have some TV channels that 'need' forced de-interlacing. Sometimes Kodi correctly detects it's interlaced material, but sometimes not. Sometimes it helps to change channels back and forth for Kodi to enable de-interlacing. This is with tvheadend and mostly noticable with those '24h news channels' (CNN, Bloomberg etc.), with rolling text bars in the bottom the ones with news, stock prices, etc. They're pretty unintelligible when they're not de-interlaced.

Maybe that's a bug in tvheadend, in the pvr plugin, in the TV data from my satellite LNB, I dunno, but the 'force de-interlacing' button is pretty handy in those cases. And sure, the from upstream the video data should always be presented correctly, but since apparently it's not, I hope you'll not remove the option before the auto detection works better from a user's perspective. If you need anything like debug logs or something, let me know.

[ironic_monkey]

educated guesses and faint memories;

it's due to the nature of transport streams. they are designed so you can hop in at regular intervals but not all info is in the local headers. if you are unlucky none of the full-info headers end up in the early buffers. with the new reconfiguration capabilities this should be fairly doable. need to monitor for flag changes in the headers and reconfigure if the flag is suddenly enabled.

the second problem, if i recall correctly, is harder to fix. some sources only set the flag at the start of the program and if you hop in midway you are SOL. this is a problem at the source that has to be dealt with at the destination sadly. thus dropping the option will cause unsolvable regressions. we all agree it sucks that is has to be there.

[noggin]

educated guesses and faint memories;

it's due to the nature of transport streams. they are designed so you can hop in at regular intervals but not all info is in the local headers. if you are unlucky none of the full-info headers end up in the early buffers. with the new reconfiguration capabilities this should be fairly doable. need to monitor for flag changes in the headers and reconfigure if the flag is suddenly enabled.

the second problem, if i recall correctly, is harder to fix. some sources only set the flag at the start of the program and if you hop in midway you are SOL. this is a problem at the source that has to be dealt with at the destination sadly. thus dropping the option will cause unsolvable regressions. we all agree it sucks that is has to be there.

Also - some channels use dynamic encoder format switching. The Freeview HD platform in the UK uses dynamic switching between 1080/25p and 1080/50i encoding (on a GOP-by-GOP level at the encoder - where it tries to detect 25psf content and send it 25p rather than 50i) on the fly (not on a show-by-show basis)

[noggin]

There is a lot of crappy hacks done in the past and I am going to trash them one after another. If some interlaced material is not detected as interlaced, there is a root cause for this that needs to be fixed. Forcing deinterlacing and presenting it as as user option is wrong.

In an ideal world I'd agree - but until the world is ideal, having the ability to force deinterlacing has some merit. Or to put it another way - if it's a choice between unwatchable and watchable I'd go with watchable.

[popcornmix]

In an ideal world I'd agree - but until the world is ideal, having the ability to force deinterlacing has some merit. Or to put it another way - if it's a choice between unwatchable and watchable I'd go with watchable.

Sample files would be useful.
e.g. a file where auto deinterlace doesn't engage, but the file requires it.
Or a file where auto deinterlace engages but doesn't need it (and so looks poorer as a result).

Perhaps there is a way of improving auto detection. If there is no way of auto-detecting then that is an argument for being able to override auto deinterlace.

[FernetMenta]

If there is no way of auto-detecting then that is an argument for being able to override auto deinterlace.

Not the crappy hacky way as it is implemented currently. If a stream is interlaced, the deinterlacer needs further information, i.e. top/bottom field first. Do you want to force this too by another setting? Leaving the user in a try and error game?

Note that there are cases this setting did more harm than any good. Users did force deinterlacing without knowing what they actually did.

[FernetMenta]

The first iteration is done (code merged). VideoPlayer exposes some video and audio info for skins. Now its on the skinners to give us something to play with.

[willemd]

I think this is a wise approach.

Is it already in Estuary?

[Gade]

Cooked this up for Rapier:

Episodes:


Live TV:

[Ed76]

very good, thanks fernetmenta

[willemd]

First of all, this looks really neat. It seems complete and is presented in a way nicer fashion than the 'O' debug info!


I'm not sure if my questions are related to the skin or to the data that's fed into the skin, but here goes:

* Is it possible to round to more decimals? The aspect ratio (which is 1.78:1) is shown as rounded 1.8: but 1.78:1 (and often 1.85:1) are the usual denominations for 16:9 videos.

* The same goes for the FPS. Is it possible to change the rounding? It says 24.0 fps, but that makes it unclear whether this is 23.976 fps or 24.000 (or even 23.980). Could it be rounded to 3 digits?

* Are (current or nominal) bitrates (video and audio) still listed in the 'O' information?

[willemd]

Something I just thought about:

Maybe, would it be possible that under the Audio info, the amount of available audio streams is shown?

Such as:

Code:

Decoder: AC3
Channels: FL, FR
Language: ENG (1 of 2)

Several movies and also some PVR tv channels have more than 1 language or codec. E.g. our local TV channels air with both stereo and 5.1 soundtracks.


Is it possible to add the same info about subtitles?



I think that if the other skin developers also start adding this info dialog, it will be used a lot more compared to the current 'O' information. Therefore, it would be nice to show all 'user relevant' static stream information in a single dialog. Do you see what I mean?

[Roby77]

could not be useful also to have a/v bitrate and cpu/gpu usage ? (in case of lag to check if it's cpu/gpu load problem )

like :







Edit: sorry saw later that wasn't 100% completed
https://github.com/xbmc/xbmc/pull/10069

[FernetMenta]

Something I just thought about:

Maybe, would it be possible that under the Audio info, the amount of available audio streams is shown?

Such as:

Code:

Decoder: AC3
Channels: FL, FR
Language: ENG (1 of 2)

Several movies and also some PVR tv channels have more than 1 language or codec. E.g. our local TV channels air with both stereo and 5.1 soundtracks.


Is it possible to add the same info about subtitles?



I think that if the other skin developers also start adding this info dialog, it will be used a lot more compared to the current 'O' information. Therefore, it would be nice to show all 'user relevant' static stream information in a single dialog. Do you see what I mean?

I would not mix things up. The new info exposed by player is some processing parameters how audio/video stream players see it. This is not metadata of input streams. Hence providing information about additional not currently played streams would not fit into this category.


I will look into formatting and precision of float values.


@Gade, looks great!