#17422 new Bugs

Krypton takes 10 seconds to start stream, Jarvis takes 2 seconds

Reported by: primaeval Owned by: FernetMenta
Priority: 4 - Normal
Component: Video playback (inc. audio in video and codecs) Version: 17.1 "Krypton" Final
Severity: Normal Keywords: Krypton, VideoPlayer, delay
Cc: arnova Blocked By:
Blocking: Platform: All


Krypton takes about 10 seconds to display a stream correctly after freezing the video and only playing audio for a few seconds. The same stream takes less the 2 seconds on Jarvis.

This is consistent on Windows and Nvidia Shield.

It is has been happening since the Krypton alpha releases. I just hoped it would be fixed by 17.1 but it isn't. I have been sticking with Jarvis until now.

I know there was a lot of changes to the VideoPlayer in Krypton.

I have tried all variations of Hardware Acceleration and there is no difference.

The timing from starting a stream to it becoming stable can be found for searching for the 2 matches of "OnKey" in the following logs. This example switches from TV Guide Fullscreen, but it is the same straight from a url shortcut in an addon.

Jarvis debug log https://pastebin.com/BPAMQa9W

Krypton debug log https://pastebin.com/Hedj4jbJ

Here is another example using the Danish Live TV addon.

Jarvis https://pastebin.com/KT1Z4j78

Krypton https://pastebin.com/T0xDdUbR

Using vlc as an external player in playercorefactory.xml takes 1 or 2 seconds to become stable.

Change History (65)

comment:1 Changed at 2017-04-03T06:30:30+01:00 by FernetMenta

Please provide a sample file that we can reproduce without any addon.

comment:2 Changed at 2017-04-03T06:40:56+01:00 by primaeval

Here is a direct link to a BBC One stream that is used in the iPlayer WWW addon and my BBC TV addon.


Here it is from favourites.xml if that helps.

    <favourite name="BBC One" thumb="special://home/addons/plugin.video.bbc/resources/img/bbc_one_hd.png">PlayMedia(&quot;http://a.files.bbci.co.uk/media/live/manifesto/audio_video/simulcast/hls/uk/abr_hdtv/ak/bbc_one_hd.m3u8&quot;)</favourite>

Here is the log from playing it from the favourites menu. It took 9 seconds in this case. https://pastebin.com/aBUXdhhN

comment:3 Changed at 2017-04-03T06:48:02+01:00 by FernetMenta

I get a 403 error. Does not seem to be a public url.

comment:4 follow-up: Changed at 2017-04-03T06:50:32+01:00 by primaeval

It is UK only. Where are you based? I'll see if I can find one you can access.

comment:5 Changed at 2017-04-03T06:55:10+01:00 by primaeval

Here are the contents of the files if that helps.




## Created with Unified Streaming Platform(version=1.7.25)
#EXTINF:7.68, no desc
#EXTINF:7.68, no desc
#EXTINF:7.68, no desc
#EXTINF:7.68, no desc

comment:6 in reply to: ↑ 4 Changed at 2017-04-03T07:04:36+01:00 by FernetMenta

Replying to primaeval:

It is UK only. Where are you based? I'll see if I can find one you can access.


comment:7 Changed at 2017-04-03T07:33:48+01:00 by primaeval

This might be a bit hard for you to track down. The German streams I found take about the same time in Jarvis and Krypton. This one for NDR HD took about 4 seconds on each.

http://ndr_fs-lh.akamaihd.net/i/[email protected]/index_3776_av-b.m3u8

I'll keep looking for more examples for you.

comment:8 Changed at 2017-04-03T07:57:08+01:00 by primaeval

ARD HD and some of the other free-to-view channels are consistently slow to load on Krypton compared to Jarvis when going through the German \ Wilmaa section of plugin.video.kodilivetv-2.1.9.zip at https://github.com/vania70/Kodi-Live-TV

comment:9 Changed at 2017-04-03T16:34:28+01:00 by primaeval

Here is another debug log of the original BBC One stream from someone else in London with an Android device. It took about 11 seconds in this case. https://paste.ubuntu.com/24307055/

comment:10 Changed at 2017-04-03T16:45:41+01:00 by FernetMenta

Android media codec serves as a very bad example in this case. In particular when surface rendering is enabled.

comment:11 Changed at 2017-04-03T17:00:40+01:00 by FernetMenta

Also have a look at this: http://forum.kodi.tv/showthread.php?tid=301678&pid=2553940#pid2553940

There is a link with a video of my system playing the provided sample. I was not able to see this huge delay.

comment:12 Changed at 2017-04-03T17:02:31+01:00 by FernetMenta

On my dev branch this 2-3 seconds delay is gone too.

comment:13 Changed at 2017-04-03T19:31:23+01:00 by primaeval

The German streams are much more well-behaved than the UK streams. They only took 4-6 seconds compared with the 10+ seconds for BBC One.

Thanks for your link. At least it is not just me having problems.

I've tried out your build and it halves the delay. It is about 6 seconds now for BBC One. You are definitely on the right track. Here is a log. https://pastebin.com/ZYCmm2BW

It wasn't the Android surface rendering. I asked my friend to try it out on Windows and it gave a similar delay, about 13 seconds. Here is the log. https://paste.ubuntu.com/24307570/

How have the ffmpeg compile options changed from Jarvis to your branch? Is it waiting for longer before chosing a sub-stream?

comment:14 Changed at 2017-04-03T19:36:49+01:00 by FernetMenta

Seems you are able to compile from source. Can you try latest version? https://github.com/FernetMenta/kodi-agile

comment:16 Changed at 2017-04-03T19:51:41+01:00 by FernetMenta

please turn off component logging and post a new log. too much log spam in order to see something reasonable.

comment:17 Changed at 2017-04-03T19:57:38+01:00 by primaeval

Component logging off. https://pastebin.com/6q4ByePm

About 6 seconds. Onkey to Onkey.

Line 483: 20:55:21.944 T:2472   DEBUG: CInputManager::OnKey: return (0xf00d) pressed, action is Select
Line 3018: 20:55:27.114 T:2472   DEBUG: CInputManager::OnKey: x (0xf058) pressed, action is Stop

comment:18 Changed at 2017-04-03T20:26:10+01:00 by FernetMenta

this log spam is still present. did you restart kodi after disabling it?

comment:19 Changed at 2017-04-03T20:32:27+01:00 by primaeval

Yes. Just to be sure here is another. 5 second delay. https://pastebin.com/bQMaZif8

Debug logging ON

Component logging OFF

comment:20 Changed at 2017-04-03T21:08:25+01:00 by FernetMenta

hmm, log spam still there :(


//---- start
21:29:31.932 T:5320   DEBUG: Thread VideoPlayer start, auto delete: false
21:29:31.932 T:5320  NOTICE: Creating InputStream

//---- connect to streaming url
21:29:31.933 T:5320   DEBUG: CurlFile::Open(0EF9F170) http://a.files.bbci.co.uk/media/live/manifesto/audio_video/simulcast/hls/uk/abr_hdtv/ak/bbc_one_hd.m3u8
21:29:32.021 T:5320  NOTICE: Creating Demuxer
21:29:32.067 T:5320   DEBUG: ffmpeg[14C8]: [http] the user-agent option is deprecated, please use user_agent option
21:29:32.431 T:4128   DEBUG: ------ Window Init (DialogBusy.xml) ------
21:29:32.435 T:4128   DEBUG: ------ Window Deinit (Pointer.xml) ------
21:29:32.465 T:4128   DEBUG: ------ Window Deinit (DialogFavourites.xml) ------
21:29:33.314 T:5320   DEBUG: ffmpeg[14C8]: [http] the user-agent option is deprecated, please use user_agent option
21:29:34.077 T:5320   DEBUG: Previous line repeats 3 times.

//----- stream is ready, analyzing
21:29:34.077 T:5320   DEBUG: CDVDDemuxFFmpeg::Open - avformat_find_stream_info starting
21:29:34.320 T:5320   DEBUG: CDVDDemuxFFmpeg::Open - av_find_stream_info finished

//------ actual reading of stream data begins
21:29:34.738 T:5320   DEBUG: CVideoPlayerVideo::OpenStream - open stream with codec id: 28
21:29:34.750 T:5396  NOTICE: Creating audio stream (codec id: 86018, channels: 2, sample rate: 48000, no pass-through)
21:29:34.793 T:5320   DEBUG: CVideoPlayer::HandleMessages - player started 1
21:29:35.771 T:5320   DEBUG: CVideoPlayer::HandleMessages - player started 2

// ------ first video and audio packet was decoded
21:29:35.771 T:5320   DEBUG: VideoPlayer::Sync - Audio - pts: 4031999.000000, cache: 298666.656017, totalcache: 579999.983311
21:29:35.771 T:5320   DEBUG: VideoPlayer::Sync - Video - pts: 7680000.000000, cache: 50000.000000, totalcache: 100000.000000
//------- takes approx 1 sec to fill audio buffers of entire chain

// -------playback started
21:29:36.709 T:4128   DEBUG: CInputManager::OnKey: x (0xf058) pressed, action is Stop

The lower half looks ok to me. mpegts has random access points at least every 5 seconds, but many have every 2-3 seconds. So from starting analyzing the stream until playback begins (including your reaction time) 2.6 secs is ok.

the upper half: 2.2 seconds for establishing the connection. not my area and not sure if this can be done faster.

comment:21 Changed at 2017-04-03T21:18:14+01:00 by FernetMenta

  • Cc arnova added

This other log above:

17:50:53.793 T:4072   DEBUG: CurlFile::Open(0C01F120)
17:51:02.553 T:4072   DEBUG: CDVDDemuxFFmpeg::Open - avformat_find_stream_info starting

It seems to take ages to read from the stream. Looks like a curl issue. @arnova, cold you have a look?

comment:22 Changed at 2017-04-03T21:37:27+01:00 by primaeval

Your new build is quicker to start but the sound drops out for a second or two and the video fast-forwards to catch up after that. Here is an example video capture from Mr BlurryCam. https://goo.gl/photos/tbFW7zz7z7UB9jwA6

Here is the long delay in 17.1 (confluence skin). https://goo.gl/photos/3Gqtwpxisj6EBAfD7

Here is the quick start in Jarvis. https://goo.gl/photos/nPFgMdefjBtX2W2C7

comment:23 Changed at 2017-04-05T07:44:00+01:00 by primaeval

I'm collecting reports of Krypton delays in this thread. http://forum.kodi.tv/showthread.php?tid=311073&pid=2560681

The official Comet TV addon in the main Kodi addon might be a good one for you to test with. It is consistently much slower on Krypton that Jarvis. Right now the stream I tested with is called "The Creeping Unknown". The post refering to it is here in the same thread as above. http://forum.kodi.tv/showthread.php?tid=311073&pid=2562978#pid2562978

I know 5+ seconds doesn't seem long but when you are trying to channel surf in the PVR or a TV Guide 5 seconds seems like an eternity compared to the almost instantaneous Jarvis behaviour.

comment:24 Changed at 2017-04-05T07:46:46+01:00 by arnova

Could you provide a debug log with libcurl component logging enabled?

comment:25 Changed at 2017-04-05T07:55:13+01:00 by primaeval

BBC One stream in Kodi 17.1 with libcurl enabled. Search Onkey to Onkey for start and stop when watchable. About 9 seconds. https://pastebin.com/VdDEXs0Y

Jarvis comparison. Almost instantaneous. https://pastebin.com/g2YPYyh6

comment:26 Changed at 2017-04-05T10:55:47+01:00 by FernetMenta

I don't think more logs will help here. We need something to reproduce the issue

comment:27 Changed at 2017-04-05T11:07:37+01:00 by primaeval

The Comet or Nasa sources might help you.

I have also made builds of Jarvis and Kryton here. I started trying to debug them last night in Visual Studio 2015. If you have something you want me to test out let me know.

I tried some command line versions of ffmpeg on the BBC One stream with the same version numbers as used in Jarvis and Krypton. I couldn't spot any signicant delays in the Krypton version of ffmpeg so I am pretty sure the problem is in Kodi.

comment:28 Changed at 2017-04-05T11:14:44+01:00 by FernetMenta

did you pass the entire m3u playlist to ffmpeg?

comment:29 Changed at 2017-04-05T11:16:01+01:00 by primaeval

Yes. Do you want some logs?

comment:30 Changed at 2017-04-05T11:40:53+01:00 by FernetMenta

more logs don't help.

comment:31 Changed at 2017-04-05T11:50:56+01:00 by primaeval

Something that stood out that was in the Krypton logs but wasn't in the Jarvis logs was

CRenderManager::WaitForBuffer - timeout waiting for buffer

I don't know if that was a cause or a symptom of the delay.

comment:32 Changed at 2017-04-06T06:28:03+01:00 by arnova

I can't spot anything obvious in the log that seems to suggest it's an libcurl issue (but that also doesn't indicate it's not). Like fernetmenta says we unfortunately need an url to reproduce with (I'm located in the Netherlands).

comment:33 Changed at 2017-04-06T06:36:25+01:00 by primaeval

Thanks for looking.

Did you try the Comet addon and Nasa streams?

comment:34 Changed at 2017-04-06T09:12:16+01:00 by primaeval

Here is a stream that consistently takes about 6 seconds to load in Krypton compared to almost instantaneous in Jarvis. http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/sl.m3u8

It came from this page of hls tests. http://g33ktricks.blogspot.dk/2016/04/list-of-hls-streaming-video-sample-test.html

As the delay is about the length of a ts segment ~6-10 seconds I wonder if something is waiting to read a whole segment before showing the video instead of starting instantly like in Jarvis.

If I capture the streams with ffmpeg or the ts segments with wget they play instantly in Krypton. So I don't think there is any problem with the video itself.

comment:35 Changed at 2017-04-06T19:12:05+01:00 by FernetMenta

My system playing the apple stream: https://goo.gl/photos/2qAptLiVcxj95ni37

comment:36 Changed at 2017-04-06T19:18:08+01:00 by primaeval

Ok. That is not a good test for you.

What system are you running on?

Someone sent me a list of legal German streams which might help. https://www.kodinerds.net/index.php/Thread/49562-So-richtig-legale-m3u/?postID=309082#post309082

comment:37 Changed at 2017-04-06T20:07:36+01:00 by primaeval

Here is a graph from Process Hacker of playing the NDR Hamburg stream from the list above. Jarvis on the left, Krypton on the right. I played the channel 3 times in a row. You can see the start at the bottom of the memory allocation rising slope. The stream is watchable at the top. Memory is getting allocated very slowly in Krypton. In Jarvis it is very quick. I would say the buffer is getting allocated at once in Jarvis and bit by bit in Krypton.

The I/O trace at the bottom shows that the first package seems to be accessed pretty quickly in both cases.


comment:38 Changed at 2017-04-07T17:24:09+01:00 by arnova

Just tested it here, it's pretty slow on my i3 laptop using WiFi. @FernetMenta: Did you use a WiFi or cabled connection?

comment:39 Changed at 2017-04-07T17:31:09+01:00 by arnova

Just ran it in gdb, the problem is certainly not in libcurl since curl is not used for the actual stream, only for m3u8 reading. From the looks of it, the problem seems to be in ffmpeg itself: https://pastebin.com/vFThGwSX

comment:40 Changed at 2017-04-07T17:32:23+01:00 by MikeKL

I quickly tested how long to commence playback from a couple of created strm files on my rpi2 with milhouse nightly leia 0406 installed. (no playback via additional addon)

das erste "Akamai" stream

http://daserste_live-lh.akamaihd.net/i/[email protected]/master.m3u8

Start/Stop lines from log (stopped as soon Audio Video both noted correct)

16:50:43.024 T:1944734160 DEBUG: OnKey: 11 (0x0b, obc244) pressed, action is Select
16:51:12.459 T:1944734160 DEBUG: OnKey: guide (0xe0) pressed, action is Stop

bbc one "Dash" stream


Start/Stop lines from log (stopped as soon Audio Video both noted correct)

16:51:28.204 T:1944734160 DEBUG: OnKey: 11 (0x0b, obc244) pressed, action is Select
16:51:37.041 T:1944734160 DEBUG: OnKey: guide (0xe0) pressed, action is Stop

Link provides full kodi.log (German stream much longer to start than UK stream, neither were very instantanous at time of my test today)


---edit--- rpi2 wired directly to router with reasonable/fast fibreoptic connection to internet at my end.

Last edited at 2017-04-07T17:35:12+01:00 by MikeKL (previous) (diff)

comment:41 Changed at 2017-04-07T19:20:46+01:00 by FernetMenta

The problem is most likely caused by ffmpeg trying to read the fist segment of every stream in the playlist on open.

comment:42 Changed at 2017-04-07T19:22:12+01:00 by primaeval

I think you're right FernetMenta.

I'm getting somewhere with debugging in Visual Studio 2015. It does look like it is ffmpeg after all. There is delay of several seconds when it disappears into the ffmpeg call to avformat_open_input in Krypton which is almost instantaneous in Jarvis. I'm using the NDR Hamburg stream. I'll have to rebuild ffmpeg in debug mode to see why. The line of code is here:


comment:43 follow-ups: Changed at 2017-04-07T23:11:24+01:00 by mglae

The problem is most likely caused by ffmpeg trying to read the fist segment of every stream in the playlist on open.

The delay is larger in Krypton because it passes the complete playlist to ffmpeg while Jarvis selects the most appropriate stream here.

After porting the logic to Krypton the delay decreases from 12s to 2s when playing this ZDF Mediathek stream via my 9Mbit DSL connection .

I cannot tell if this is breaking anything in Krypton but it demonstrates the difference to Jarvis.

comment:44 in reply to: ↑ 43 Changed at 2017-04-08T05:46:28+01:00 by primaeval

Replying to mglae:

The problem is most likely caused by ffmpeg trying to read the fist segment of every stream in the playlist on open.

The delay is larger in Krypton because it passes the complete playlist to ffmpeg while Jarvis selects the most appropriate stream here.

After porting the logic to Krypton the delay decreases from 12s to 2s when playing this ZDF Mediathek stream via my 9Mbit DSL connection .

I cannot tell if this is breaking anything in Krypton but it demonstrates the difference to Jarvis.

That makes a lot of sense. Thanks. Nice work.

Let's hope we can get a fix out for Krypton 17.2. A lot of channel surfers will be very happy. :)

comment:45 in reply to: ↑ 43 Changed at 2017-04-08T06:07:16+01:00 by FernetMenta

Replying to mglae:

The problem is most likely caused by ffmpeg trying to read the fist segment of every stream in the playlist on open.

The delay is larger in Krypton because it passes the complete playlist to ffmpeg while Jarvis selects the most appropriate stream here.

After porting the logic to Krypton the delay decreases from 12s to 2s when playing this ZDF Mediathek stream via my 9Mbit DSL connection .

I cannot tell if this is breaking anything in Krypton but it demonstrates the difference to Jarvis.

There was a good reason why this old code was removed. There were quite a few url that did not work with it. The issue has to be fixed in ffmpeg, not Kodi.

comment:46 Changed at 2017-04-08T06:13:53+01:00 by primaeval

Who has been working on the ffmpeg fix? Have you tried using the latest ffmpeg library from ffmpeg.org? If no-one has the skills for ffmpeg then a switch to enable this behaviour would be better than just leaving the 12 second delay in.

comment:47 Changed at 2017-04-08T06:27:39+01:00 by FernetMenta

Again, there was a reason why I removed this old code, see above. No way that this will be added again. Non working hls streams are worse than this delay. I opened a ticket for ffmpeg:


comment:48 Changed at 2017-04-08T08:07:17+01:00 by primaeval

I've made a windows build with mglae's patch and it works as fast as Jarvis again. Here is just the kodi.exe for Krypton 17.1 https://github.com/primaeval/builds/raw/master/kodi.zip

Looking at the code and the m3u8 files I can see why that solution would fail sometimes. It just checks for the BANDWIDTH= field to choose the sub-stream. There are usually more than one stream in the file with the same bandwidth. If they correspond to different audio languages or sign language versions of the file I can see when they would pick the wrong stream. We have some code in plugin.video.iplayerwww to deal with that.

So, in an ideal world the addon or pvr component should really choose the best stream based on some higher level criteria including audio language etc.

A simpler user solution is to pre-process the m3u8 list of channels that something like PVR IPTV Simple Client takes in and just add the required bandwidth sub-streams.

I think ffmpeg might be doing the right thing: robustly checking the type of each sub-stream rather than relying on the #EXT-X-STREAM-INF information.

There might be a way to speed up ffmpeg by filling in some of the fmt information in the call to avformat_open_input with the information that you can work about the stream type. https://ffmpeg.org/doxygen/3.0/group__lavf__decoding.html#ga31d601155e9035d5b0e7efedc894ee49

comment:49 Changed at 2017-04-08T08:51:03+01:00 by FernetMenta

Not sure if ffmpeg behaves as the inventor, Apple, would recommend. Opening such urls with Safari is lightning fast. IMO ffmpeg should at least provide an option to skip those tasks that takes a long time to finish. Or it should provide an option to pre-select the desired bandwidth.

comment:50 Changed at 2017-04-08T09:39:13+01:00 by primaeval

If you look at Apple's example m3u files for Alternate Media you can see that there are examples for different languages and camera angles. Without quite a few extra flags to ffmpeg there is no way it would know what language, camera angle, subtitles etc the user would want just by looking at the BANDWIDTH.


It is really up to the addon, pvr component or Kodi to choose the sensible sub-stream to pass to ffmpeg. There should at least be a language parameter to choose the language if you are given a choice in the m3u.

I think this is where in the specification document that it discusses the Alternative Renditions. https://tools.ietf.org/html/draft-pantos-http-live-streaming-21#section-

comment:51 Changed at 2017-04-08T10:42:57+01:00 by FernetMenta

Given the fact that ffmpeg can be used as a player itself and it is used by other players like VLC, it make most sense to place this behaviour into ffmpeg.

comment:52 Changed at 2017-04-08T11:40:19+01:00 by primaeval

I'm going to have to disagree although I can see your point that it would be nice for ffmpeg to have the option to be able to start playing based on the m3u8 file information alone.

Things like camera angle and language just seem relatively too high level to me.

According to the HTTP Live Streaming spec:

   Clients should switch between different Variant Streams to adapt to
   network conditions.  Clients should choose Renditions based on user

In my opinion the ffmpeg library is a low level demuxer and decoder, Kodi is the client.

vlc just does a naive sorting too based on bandwidth in httplive.c

    /* HLS standard doesn't provide any guaranty about streams
       being sorted by bandwidth, so we sort them */
    qsort( p_sys->hls_stream->pp_elems, p_sys->hls_stream->i_count,
           sizeof( hls_stream_t* ), &hls_CompareStreams );

    /* Choose first HLS stream to start with */
    int current = p_sys->playback.stream = p_sys->hls_stream->i_count-1;
    p_sys->playback.segment = p_sys->download.segment = ChooseSegment(s, current);

It still takes about 4 seconds to start the NDR Hamburg stream in VLC as it also downloads all the sub m3u8 files. You can see it in the Messages window in vlc with debug log level turned on.

comment:53 Changed at 2017-04-08T12:24:04+01:00 by FernetMenta

This behaviour was once in Kodi core and decayed because it was not maintained. As a result hls broke. This won't happen again, decision is taken.

If advanced features are demanded like camera angle, this can be done by an addon. MPD is done by an addon too.

Basic behaviour should be implemented by ffmpeg. Not opening every item in a playlist is basic behaviour.

comment:54 Changed at 2017-04-09T12:53:28+01:00 by primaeval

I've been talking to JEEB at ffmpeg. There can be some HLS optimisation if someone can be motivated to do it but ffmpeg is designed for accurate transcoding and not responsive streaming. The demuxer needs the information from probing the streams. It is not enough just to read the m3u header. It would be better to probe the streams first and just play the best one. There are some options like "analyzeduration/probesize and friends" that might speed it up.

The final quote was:

[13:20] <JEEB> well the HLS demuxer can be optimized, so if kodi wants to move to utilizing lavf more, they should flag it on lavf's side as an issue, and/or optimize the probe parameters
[13:21] <JEEB> it all depends on kodi's priorities, really

Here is the irc conversation. You can probably understand the lavf information better than me. https://pastebin.com/Hxtq86w2

comment:55 Changed at 2017-04-09T13:17:50+01:00 by FernetMenta

We already set max analyzeduration but this does not help. ffmpeg's hls demuxer spends all the time in avformat_open_input not in avformat_find_stream_info.

comment:56 Changed at 2017-04-09T14:18:17+01:00 by primaeval

I've finally worked out what it is doing.

When you open an hls header file you aren't opening a playlist and chosing one stream. You are opening a parallel stream like a mux on a satellite transponder.

ffmpeg needs to know about all the variants in case you want to record or re-distribute more than one of them at the same time.

The ffmpeg demuxer needs more details than are in the m3u header and therefore has to probe each variant.

If you really only want one of the variants it is up to you to only request that in the first place. Not ask for the whole hls mux at once.

From the top of hlc.c

   51  * An apple http stream consists of a playlist with media segment files,
   52  * played sequentially. There may be several playlists with the same
   53  * video content, in different bandwidth variants, that are played in
   54  * parallel (preferably only one bandwidth variant at a time). In this case,
   55  * the user supplied the url to a main playlist that only lists the variant
   56  * playlists.

comment:57 Changed at 2017-04-09T14:53:32+01:00 by FernetMenta

The substreams should be analyzed in avformat_find_stream_info, not in avformat_open_input. Then an application has more control. From that pov the hls demuxer behaves not as expected.

comment:58 Changed at 2017-04-09T15:04:31+01:00 by primaeval

Either way it is going to take a long time for ffmpeg to probe all the variants.

So I think ffmpeg is doing the right thing (but maybe in the wrong order). Krypton is doing the right thing. Jarvis was compensating for the addons or pvr components not selecting the variant themselves.

It should now be up to the addons or pvr components to ask for the variant they actually want to play, not be greedy and ask for the whole hls "mux" at once.

The only problem is letting all the addon and pvr developers know it is up to them to select the variant now.

comment:59 Changed at 2017-04-09T15:13:42+01:00 by FernetMenta

Don't forget that there are urls where ffmpeg hls fails with its strategy. I don't consider this right. Blocking an application that long in a function call without the ability to set a timeout is an issue too.

I think the problem can easily be fixed in ffmpeg's hls demuxer.

comment:60 Changed at 2017-04-09T16:26:15+01:00 by primaeval

JEEB and others seem to think there are some optimisations that can be done. It might also be possible to trust the information in the m3u header file rather that probing the streams. A codec flag could set the level of probing.

Whether you can convince anyone with the skills, time and energy to fix it is another question.

The consensus still seems to be not to pass the whole hls header to ffmpeg. Choose the variant beforehand.

There are also some problems in the hls code with seeking apparently.

comment:61 Changed at 2017-04-09T20:16:00+01:00 by FernetMenta

I think everybody agrees that the best solution is to pass not the entire header to ffmpeg. With Kodi 17 we introduced inputstream extension point for addons. We should have a hls addon like we have an addon for mpeg dash.

Nevertheless it would be nice to have a minimal working solution with ffmpeg. I pinged Annsi, he is the hls maintainer of ffmpeg's hls demuxer and also team Kodi member.

comment:62 Changed at 2017-04-09T20:58:11+01:00 by primaeval

Thanks. The an HLS inputstream sounds good.

I still can't work out where the video freeze is coming from when you just request a single variant from ffmpeg. The audio is pretty quick to start but the video takes a few seconds to unfreeze. Do you know where it might be?

comment:63 Changed at 2017-04-09T21:37:49+01:00 by FernetMenta

Do you observe this video freeze with my dev branch?

comment:65 Changed at 2017-04-10T06:43:30+01:00 by primaeval

The last problem is what to do when you open up a strm or m3u playlist in Kodi\Files\Video with hls streams in them. If you click on an hls m3u it should really open up the m3u as another playlist so you can select the variant to play.

ffmpeg hls.c uses this check in its hls probe to determine if the m3u is an hls header. https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hls.c#L2110 which tests for:

    if (strncmp(p->buf, "#EXTM3U", 7))
        return 0;

    if (strstr(p->buf, "#EXT-X-STREAM-INF:")     ||
        strstr(p->buf, "#EXT-X-TARGETDURATION:") ||
        strstr(p->buf, "#EXT-X-MEDIA-SEQUENCE:"))
        return AVPROBE_SCORE_MAX;
Note: See TracTickets for help on using tickets.