Project

General

Profile

Bug #5098

Playback does not start with a GOP and as a result the video stream is not valid at the biginning of playback.

Added by sebastian s. over 6 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
HTSP
Target version:
-
Start date:
2018-05-02
Due date:
% Done:

0%

Estimated time:
Found in version:
4.2
Affected Versions:

Description

This issue appeared in the last nightlies of Kodi v18 Leia. Team Kodi says it's TVH related and this was always the behaviour but with the recent player improvements in Kodi it's possible that some strange UI issues will happen.

https://www.youtube.com/watch?v=1LW8QuOcNlg

It's hard for me to describe the problem, since this is all rocket science to me, so please take a look with my report and discussion with FernetMenta (the Kodi video dev guru):
https://forum.kodi.tv/showthread.php?tid=331306

To quote him:
-----
The issue is related to tv headend. Playback does not start with a GOP and as a result the video stream is not valid at the biginning of playback.
The issue has ever been there but now it manifests itself differently.
It is an issue of the demuxer. In this case most likely the server. At the time the first packet is read from demuxer, the streams should be ready. I placed an extra log into the code indicating demuxer reads. This is a sequence recored with vnsi: https://pastebin.com/EkGEG4kh
-----

History

#1

Updated by Joe User over 6 years ago

A little help with the "rocket science" -> [[https://vanillavideo.com/blog/2012/a-quick-intro-to-i-frames-and-gop-in-video-codecs]]

This is NOT a tvheadend problem. ALL normal players discard initial data until a valid "i-frame" (start of GOP) is received.

Of course this is a little simplified because there is not just video in a stream. Inter-mixed in the stream (muxed) is also the audio data. When you tune to a stream, you have no way of controlling exactly where you start. The first thing you see may be audio data. But again, any player should not assume that just because it first receives audio data that there is no video data coming.

And to add more complexity, also inter-mixed into the stream can be things like EPG data, teletext data and other information about the stream. Everything in a stream has a specific standardized "start code" receivers can look for to know when to begin paying attention.

#2

Updated by Jaroslav Kysela over 6 years ago

Try to turn off 'parser backlog' in the base config (tvheadend). With this settings, the first frame will be the first frame of GOP (I-frame). But VLC can decode also incomplete frames, so it's a bit pitty that some players insist to have full info from the first frame (the playback will be delayed).

#3

Updated by sebastian s. over 6 years ago

Joe User wrote:

A little help with the "rocket science" -> [[https://vanillavideo.com/blog/2012/a-quick-intro-to-i-frames-and-gop-in-video-codecs]]

This is NOT a tvheadend problem. ALL normal players discard initial data until a valid "i-frame" (start of GOP) is received.

Of course this is a little simplified because there is not just video in a stream. Inter-mixed in the stream (muxed) is also the audio data. When you tune to a stream, you have no way of controlling exactly where you start. The first thing you see may be audio data. But again, any player should not assume that just because it first receives audio data that there is no video data coming.

And to add more complexity, also inter-mixed into the stream can be things like EPG data, teletext data and other information about the stream. Everything in a stream has a specific standardized "start code" receivers can look for to know when to begin paying attention.

Thanks for clearing it up.

Jaroslav Kysela wrote:

Try to turn off 'parser backlog' in the base config (tvheadend). With this settings, the first frame will be the first frame of GOP (I-frame). But VLC can decode also incomplete frames, so it's a bit pitty that some players insist to have full info from the first frame (the playback will be delayed).

Thanks, but it's already disabled.

#4

Updated by sebastian s. over 6 years ago

Jaroslav Kysela wrote:

Try to turn off 'parser backlog' in the base config (tvheadend). With this settings, the first frame will be the first frame of GOP (I-frame). But VLC can decode also incomplete frames, so it's a bit pitty that some players insist to have full info from the first frame (the playback will be delayed).

CvH told me to try enabling it (because it's disabled by default) ...and that seems to work. No more issues in Kodi Leia via remote.

#5

Updated by sebastian s. over 6 years ago

sebastian s. wrote:

Jaroslav Kysela wrote:

Try to turn off 'parser backlog' in the base config (tvheadend). With this settings, the first frame will be the first frame of GOP (I-frame). But VLC can decode also incomplete frames, so it's a bit pitty that some players insist to have full info from the first frame (the playback will be delayed).

CvH told me to try enabling it (because it's disabled by default) ...and that seems to work. No more issues in Kodi Leia via remote.

I was wrong.

At home I've tried to reproduce the issue in the local network and simulated my downstream to 8-10 mbit with NetLimiter (https://www.netlimiter.com/). The sympton appears again with and without enabled backlog parsing.
So this issue COULD also appeear in bad LAN configurations (ethernet over power cable, bad and slow WiFi connections, etc).

Also available in: Atom PDF