Changing channels causes audio to skip

[hugegreenbug]

This is a great plugin. Thanks.

I've noticed that when changing channels the audio may skip for a little and then stabilize. This issue seems identical what was described in this thread: https://forum.kodi.tv/showthread.php?tid=306231 .

[djp952]

There is both a short and long explanation for this one (of course!)

The SHORT version is: this is a Kodi/ffmpeg concern and there really isn't anything I can do about it in the PVR client.

The LONG version is (caution: will be replete with inaccuracies, hopefully the general gist is accurate enough):

Back in ye olden days TV signals were broadcast using multiple frequencies for the audio and video and they were sent at the same time and in sync. The tuner/receiver would receive both signals simultaneously and convert them to output realtime, so there was never really an issue with synchronization.

Nowadays we have digital video, of course, and it's delivered via a 'multiplexed' stream of bits. There is only one series of 1s and 0s to go around, so what they do is intersperse the video data stream and audio data stream together something like this:

VVVVVAAVVVVVVAAVVVVVAAVVVVVAAVVVVVAA

The receiver/decoder takes the multiplexed data and breaks it apart into separate Video and Audio streams, this is called demultiplexing or 'demuxing' for short.

As part of the stream data, time points (the pts you see mentioned in the Kodi thread) are provided so that the decoder can synchronize the video and audio. An ideal decoder would be able to keep everything in sync all the time for you, but as always nothing is ever ideal :)

What I think is happening here is that the synchronization points aren't included constantly in the data (I think, anyway), and that when you switch to a new stream or seek on the same stream the decoder (ffmpeg in this case) is making a mistake. It may be from a lack of this pts information or it could be a defect in the implementation. When enough information is present, it can resync everything.

My best guess here is that Kodi/ffmpeg is estimating what the sync should be in order to start playback as quickly as possible and the estimation is off. If it's only happening when channels are switched, it could even just be a small glitch in how Kodi is (re)initializing ffmpeg when the stream switches.

Unfortunately for us, all the PVR client does is take the raw multiplexed stream data from the tuner and hands it off to Kodi; all the demultiplexing and synchronization happens outside of the PVR client, so currently there isn't going to be anything I can specifically do. It would be possible to use a custom demuxer rather than relying on Kodi, but that's extremely ambitious and is very likely to be riddled with bugs, the Kodi guys and gals have been doing this a long time now I have little to no confidence I could do something better than what they have.

I think the best bet here is to reply to the thread on Kodi's forums and ensure the problem maintains visibility. I think they upgraded ffmpeg in Kodi 17.4, so it really may just be something simple they can tweak for Kodi 17.5 or 18.0.

Sorry if my details are inaccurate here and there, I didn't want to just drop a "sorry not my problem" on you, I really hate when people do that!!

[hugegreenbug]

Ok, thanks for the explanation. I noticed that unofficial pvr plugin included with kodi: https://github.com/kodi-pvr/pvr.hdhomerun does not have this problem.

[djp952]

The addon that comes with Kodi accesses the streams directly from the Tuner device(s) as opposed to the DVR engine. The streams from the tuners are lacking a series of padding bytes that the DVR engine inserts, which likely explains the difference -- Kodi needs to read more data before it finds the sync info.

You can change the setting on this PVR "Stream Live TV channels directly from Tuner device(s)" (https://github.com/djp952/pvr.hdhomerundvr/wiki/Options#stream-live-tv-channels-directly-from-tuner-devices-version-105) to get the same behavior to test that out. Note that if you enable that option, you lose timeshifting (seek) capabilities since the buffering is all done on the DVR engine.

It makes sense that you'd have more luck with the tuner streams than the DVR streams with a problem like this, but sadly there still isn't much of anything I can do to manipulate the stream to make it go away. One (remote) possibility would be to delay sending any data to Kodi at all until the necessary sync information has been detected, but if you delay too long Kodi assumes the stream is bad and gives up completely. I also really wouldn't know what to look for, at least not right now. If this gets really bad with no hope in sight for a Kodi-side fix, I'm game to try.

[djp952]

Marking this one as closed due to inaction on my part. If the explanation was unsatisfactory or you have additional concerns that I might be able to help with, please don't hesitate to open a new one! I disappeared for a couple months on you guys, but I'm back now :)

[hugegreenbug]

Changing the "Stream Live TV channels directly from Tuner device(s)" setting did solve the issue. Would it be possible for the plugin to disable timeshifting when this option is selected, since timeshifting doesn't work when it is selected and causes the stream to stop?

[djp952]

Funny you should ask! It does disable timeshifting when tuner-direct streaming is enabled on Jarvis and Leia, but not Krypton :) There is a bug in Krypton that also disables Pause, which technically still works since Kodi buffers internally.

The irony here is that I fixed that bug in Kodi and submitted a patch to them months ago. They accepted the patch but put it in Leia rather than Krypton. It was their call to make, I assume the problem wasn't deemed widespread enough to deal with the testing required for what I think at the time was v17.4.

I can fix that in Krypton very easily, it's a matter of choosing between allowing pause or not. At the time, the folks on the SD board chose to keep pause working and just not press the FF/RW buttons :)

There are like a billion options in there these days, perhaps one more just for Krypton won't hurt then we can have it both ways? Would that be OK?

[hugegreenbug]

Yes, an option would be great. Thanks!

On Jan 18, 2018 6:10 AM, "Michael Brehm" notifications@github.com wrote:

Funny you should ask! It does disable timeshifting when tuner-direct streaming is enabled on Jarvis and Leia, but not Krypton :) There is a bug in Krypton that also disables Pause, which technically still works since Kodi buffers internally.

The irony here is that I fixed that bug in Kodi and submitted a patch to them months ago. They accepted the patch but put it in Leia rather than Krypton. It was their call to make, I assume the problem wasn't deemed widespread enough to deal with the testing required for what I think at the time was v17.4.

I can fix that in Krypton very easily, it's a matter of choosing between allowing pause or not. At the time, the folks on the SD board chose to keep pause working and just not press the FF/RW buttons :)

There are like a billion options in there these days, perhaps one more just for Krypton won't hurt then we can have it both ways? Would that be OK?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/djp952/pvr.hdhomerundvr/issues/15#issuecomment-358641787, or mute the thread https://github.com/notifications/unsubscribe-auth/ABlFSauKMzGhswj2UrswJ5wy55qSTtsbks5tL0K0gaJpZM4Pn3Ih .

[hugegreenbug]

Actually, the last advanced option: "Disable reporting of real-time MPEG-TS streams" has about the same effect as streaming directly from the tuner and it doesn't break timeshifting. So, that is an acceptable solution for me. You don't need to make an option for me then.