Kodi Community Forum

Full Version: What video settings to use
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Video is a great mystery to me. Previous Kodi versions simply ran out the box on my RPi, love things when they just work! But with v17 I have had problems with the picture randomly freezing for a few moments during playback. With help from others I have twiddled with settings and appear to have solved the problem. And that is great, but it leaves me with a big question:

how is a user meant to know what video settings to use?

I have no idea why the settings needed to change from default to what they did, or what the effects were. Without the team support I would have been lost, or left just randonly changing settings for the hell of it.

Is there a user friendly (but technical) guide to what the various settings do, and how they could be applied inteligently? If it doesn't exist then can an expert makes some notes either on here or in Wiki.

I appreciate the miracle of all my media playing on all kinds of hardware, thanks for all the hard vwork that makes that possible. But can I have some help to become an informed user.
I have no idea of what you are talking about. Please share more info i.e. what settings etc.
Those under Settings -> Player -> Video

With v15 playback was perfect with default settings. With v17 beta 3 it seems I need to enable both Adjust display refresh rate and Sync playback to display to avoid glitches where the picture freezes. I am wondering how as a user I am meant to know to do that. Asking the wider community in case they know more than me.

I say "seems to need" because I am still testing and if I can pin down details of an issue then I will feedback more. Meanwhile I know you are busy Fernet so not wasting your time with huge debug logs and unrepeatable error.
(2016-10-23, 11:03)DaveBlake Wrote: [ -> ]Is there a user friendly (but technical) guide to what the various settings do, and how they could be applied inteligently? If it doesn't exist then can an expert makes some notes either on here or in Wiki.
This seems to explain it?
explanation
You are observing platform specific issues. I don't observe problems with default on OSX, Linux X11, and Windows.
This issue is being reported by user of Raspberry Pi and on Android as well.
Anything those two have in common?
(2016-10-25, 16:41)Martijn Wrote: [ -> ]This issue is being reported by user of Raspberry Pi and on Android as well.
Anything those two have in common?
Low processing power?

My TV speaker system can't "keep up" with the audio output from Kodi and it gradually loses sync more and more. If you've got low-specs on your hardware you can get this type of problem? (it's good that Kodi has settings to "fix it", IMO)
(2016-10-25, 16:41)Martijn Wrote: [ -> ]This issue is being reported by user of Raspberry Pi and on Android as well.
Anything those two have in common?

Yes, they have their own hardware decoders which seem to struggle with fine adjustments to clock. With "sync playback to display" enabled the clock is synchronised to the display. As a result there is almost nothing to do for decoder and renderer to adjust to clock.
If "sync playback to display" is disabled, the pace is set by wall-clock. That means that every now and then player needs to skip/drop a frame or display a frame for two cycles.

If a pair of decoder/renderer has not implemented sync methods properly, it may drop two or more frames when player only asks to drop a single frame.
Mmm... How does the renderer ask to drop a single frame? Drop is a state...

PS And it's a decoder state, so I don't see immediately the link with rendering...
(2016-10-26, 08:42)Koying Wrote: [ -> ]Mmm... How does the renderer ask to drop a single frame? Drop is a state...

Renderer can skip frames (render buffers) if attached timestamp is already late. If renderer detects that video is late, it tries to skip already late frames. If it can't manage it to correct lateness within 10 frames, decoder is requested to drop.

The stable and desired state of stream player video is that it waits for a free render buffer. Means the queue is full and skipping can work. Decoder should request as many demuxer packets as necessary to stay busy while video thread waits for buffer.

EDIT: play some 60fps content on a 50Hz screen. This should work smoothly
(2016-10-26, 08:42)Koying Wrote: [ -> ]Mmm... How does the renderer ask to drop a single frame? Drop is a state...

PS And it's a decoder state, so I don't see immediately the link with rendering...

drop is not a state, it is a command. (I did not chose the name of the mothod). SetDropState instructs
decoder to drop a frame, if possible, on next cycle. SetDropState is only called before Decode().
do not treat this as a state. old sins, sorry.
From the debugging I did, seems the renderer is stuck, really.
You see dozen of' "waiting for buffer", with m_queued fully loaded...

Maybe an issue in the "skipping/discarding"?
(2016-10-26, 09:02)FernetMenta Wrote: [ -> ]drop is not a state, it is a command. (I did not chose the name of the mothod). SetDropState instructs
decoder to drop a frame, if possible, on next cycle. SetDropState is only called before Decode().
do not treat this as a state. old sins, sorry.

Ouh... That changed in 17,right?
(2016-10-26, 09:08)Koying Wrote: [ -> ]
(2016-10-26, 09:02)FernetMenta Wrote: [ -> ]drop is not a state, it is a command. (I did not chose the name of the mothod). SetDropState instructs
decoder to drop a frame, if possible, on next cycle. SetDropState is only called before Decode().
do not treat this as a state. old sins, sorry.

Ouh... That changed in 17,right?

This has ever been the case.
(2016-10-26, 09:06)Koying Wrote: [ -> ]From the debugging I did, seems the renderer is stuck, really.
You see dozen of' "waiting for buffer", with m_queued fully loaded...

Maybe an issue in the "skipping/discarding"?

Maybe pts of frames/buffers are not correct. If pts of a buffer is not due, renderer won't pick this buffer and will render the last frame again.
Pages: 1 2