Login at Kodi Home

**negge** · (This post was last modified: 2014-01-05, 21:31 by negge.)

Moving the discussion about https://github.com/xbmc/xbmc/pull/3964 and https://github.com/opdenkamp/xbmc-pvr-addons/pull/259 here.

@FernetMenta could you elaborate on "You are about to ruin lots of things improved over time with this changes"?

amet · 2014-01-05, 21:51

just as an info, I run tvheadend without any buffer and caching and it opens channels in 1/3 of the time.

<pvr>
<minvideocachelevel>0</minvideocachelevel>
<minaudiocachelevel>0</minaudiocachelevel>
<maxvideocachelevel>0</maxvideocachelevel>
<maxaudiocachelevel>0</maxaudiocachelevel>
<cacheindvdplayer>false</cacheindvdplayer>
</pvr>

xxxnelly · (This post was last modified: 2014-01-05, 22:06 by xxxnelly.)

Is that without @Jalle19 changes? or just putting that in advancedsettings.xml?

**negge** · (This post was last modified: 2014-01-05, 22:20 by negge.)

(2014-01-05, 22:01)xxxnelly Wrote: Is that without @Jalle19 changes? or just putting that in advancedsettings.xml?

You can do that with stock XBMC.

@amet I believe you only need that last statement (<cacheindvdplayer>).

xxxnelly · (This post was last modified: 2014-01-06, 00:02 by xxxnelly.)

setting the advance setting has the issue @FernetMenta/@xhaggi suggested where the audio streams are different between switches and require manual audio change.

I think @Jalle19 changes have looked at this fixing this, I will test his change,

**negge** · 2014-01-06, 00:16

Yeah that shouldn't be a problem with this code, I think I fixed it earlier today.

opdenkamp · 2014-01-06, 02:32

CACHESTATE_PVR is needed for people with a slow/bad connection to the backend, and iirc for proper a/v sync with some streams too. while it may work fine with your setup, it will definitely not work for everyone.

the reason for settings being loaded and stored like that is for channel switches, and when you don't have streams yet after the call to OpenLiveStream(). it will not select the correct stream in that case.

it may happen to work for your setup, but it will definitely not work for everyone.

@amet: cacheindvdplayer set to false is enough Smile

amet · 2014-01-06, 06:31

More settings, the better it is Smile

FernetMenta · 2014-01-06, 09:45

You risk audio stalls when you disable caching. clocks on server (broadcaster) and client are never 100% in sync. If your audio device is clocked a little faster it's only a matter of time until audio stalls. We intend to implement a mode which observes cache level and resamples audio accordingly. (won't work with passthrough audio). Only in this mode pre-caching can be skipped.

btw: the default value of 10% (of 8 seconds) for audio is only slightly above max cache level of audio engine + audio device. That means once playback gets started almost all cached audio packets go into audio engine.
On my living room system I have set minaudiocachelevel to 15

**negge** · 2014-01-06, 11:35

(2014-01-06, 02:32)opdenkamp Wrote: the reason for settings being loaded and stored like that is for channel switches, and when you don't have streams yet after the call to OpenLiveStream(). it will not select the correct stream in that case.

The call is done in almost the same place as before, I haven't managed to make it not work yet. Are you saying the call absolutely has to be in HandlePlaySpeed()?

In either case the channel settings should be loaded regardless of the <cacheindvdplayer> setting, at the moment it is only called when the caching state is CACHESTATE_PVR. If we could fix this then perhaps the commit that drops the cache state could be omitted.

FernetMenta Wrote:You risk audio stalls when you disable caching. clocks on server (broadcaster) and client are never 100% in sync. If your audio device is clocked a little faster it's only a matter of time until audio stalls. We intend to implement a mode which observes cache level and resamples audio accordingly. (won't work with passthrough audio). Only in this mode pre-caching can be skipped.

What could I do to simulate this? Introduce jitter and/or high latency?

(2014-01-06, 09:45)FernetMenta Wrote: btw: the default value of 10% (of 8 seconds) for audio is only slightly above max cache level of audio engine + audio device. That means once playback gets started almost all cached audio packets go into audio engine.
On my living room system I have set minaudiocachelevel to 15

I'm afraid I don't really understand this. How could the client cache 8 seconds of audio when it certainly doesn't take 8 seconds for the channel to start playing? Furthermore I've always been under the impression that you can't cache live streams since there's no way of reading faster or further into the future. You can also not re-read a packet that you missed. All you can do is delay the start of playback. This is why you need a jitter-free WAN connection to be able to use tvheadend over the internet.

Could you guys comment on the first three commits that concern the demuxer? Those play a pretty big part in speeding things up.

FernetMenta · (This post was last modified: 2014-01-06, 11:48 by FernetMenta.)

Quote:I'm afraid I don't really understand this. How could the client cache 8 seconds of audio when it certainly doesn't take 8 seconds for the channel to start playing? Furthermore I've always been under the impression that you can't cache live streams since there's no way of reading faster or further into the future

Max level of message queue is 8 seconds, 10% is 0.8 seconds. Means that playback starts after min 0.8s of audio data is in the queue. After start most of the packets fill the buffers of audio engine. Correct, once started the level of the cache won't rise. IMO it is silly to reduce the pre-caching below 10%. The most stable state of the system is to wait for a free buffer of audio renderer. If cache runs dry it waits for a new audio packet always at risk that audio stalls.

**negge** · 2014-01-06, 11:58

Sorry, I misunderstood the 8 vs. 0.8 seconds.

I still don't see the point of caching 0.8 seconds of audio if there is no way to increase the buffer once playback has started. Won't that just postpone eventual hiccups? Once 0.8 seconds of audio have been missed (thus not making it into the buffer) you're back in the same situation where you never buffered anything.

FernetMenta · 2014-01-06, 12:01

Quote:What could I do to simulate this? Introduce jitter and/or high latency?

sync playback to display with audio resample. then tweak video reference clock to run slightly faster or create a modeline which results in slightly more than 50hz. Now the system consumes more audio data than it gets from input stream.

**negge** · 2014-01-06, 12:04

Is that really a reasonable scenario to prepare for? And like you said yourself, if you consume more audio packets than you "produce" it is only a matter of time until you're screwed anyway. An initial buffering only delays the inevitable. Do I have this all backwards or what?

FernetMenta · 2014-01-06, 12:05

(2014-01-06, 11:58)negge Wrote: Sorry, I misunderstood the 8 vs. 0.8 seconds.

I still don't see the point of caching 0.8 seconds of audio if there is no way to increase the buffer once playback has started. Won't that just postpone eventual hiccups? Once 0.8 seconds of audio have been missed (thus not making it into the buffer) you're back in the same situation where you never buffered anything.

having 0.8s of buffered audio is better than having nothing, right.

Quote:Won't that just postpone eventual hiccups

Yes, in general long enough to be save as long as you stay on a channel.