segment files stop downloading but new m3u8 files keep coming

[billybobilly]

video.js version 5.4.4 videojs.hls.min.js version 1.3.1 videojs.css version 4.12.15

LIVE stream All browsers Occurs direct from our origin as well as from our CDN's edge Desktop only. Android does not have same problem.

Video plays for a short time (random, but usually about 5 or six segments) and then stops. The ts files download and play normally for a while, then they stop coming.

m3u8 file continues to be downloaded (and it is not a cached version, each file is fresh) but no additional ts files are downloaded.

Resolved the issue by rolling back to these versions:

video.js version 5.3.0 vidoejs.hls.min.js version 1.2.2

[Tralapo]

I see exactly the same behavior as @billybobilly. Flash did this before (#471) but is now fine.

The stream seems to break the moment the first segment of a new list is downloaded in my case.

[Tralapo]

Tried this again with the latest commits from @imbcmdth and it's still terrible. I get the feeling the stream is even dropping earlier then it did before. No console errors, m3u8-files are downloaded, not the .ts files inside after the first m3u8 ends.

I use contrib-hls v1.2.0 in production(!) for quite I while now and it's working perfectly. Don't know what went wrong after that.

[cowanmax]

have the same problem :((

[campones]

Same here, on last chrome (win7) https://i.gyazo.com/a16a4910a8be914fae04678f16e32688.png On Firefox, also https://i.gyazo.com/5a5915ea925fce6522eee30e1207e89a.png

Plays very well on my android 4.0.4 (xperia)

[campones]

and I did what op did, rolling back to previous version. Now it doesn't stop downloading .ts files but video isn't fluid, there are plenty micro freeze (maybe between each segment). Sound is ok, no cut

[billybobilly]

We don't have any problems with stuttering playback after rolling back to the previous version. Is it possible that your segment length and/or number of segments are causing it for you?

[cowanmax]

which version of videojs-contrib-hls do you use??

[billybobilly]

video.js version 5.3.0 vidoejs.hls.min.js version 1.2.2

[Tralapo]

I use VideoJS v5.2 and contrib-hls 1.2.0 in production without much problems.

[billybobilly]

I wish I was a better js coder so I could look into it - but I'm not.

It seems like a good place to start looking would be if there are any places in the code where it treats or sees an Android client differently than a web client?. My experience with the newest version is that it works on Android but fails on web.

[Tralapo]

Android has native HLS-support just as Microsoft Edge. That browser works fine too, because of that. That's how this plugin works, it kicks in if there's no native support and makes it work through Media Source Extensions like in Chrome or Firefox. It switches back to Flash if there's no support for MSE, like in IE11 on W7 for example.

[raj2569]

I too have the same problem, on Chrome Version 47.0.2526.106 (64-bit) Debian Jessie.

How do I find out the exact version of the Video.js and vidoejs.hls.min.js?

[u0x01]

I have same problem. But I found out that this HLS example is good working on all browser.

http://developer.qiniu.com/resource/FgCBc3IlydY6CFIA8jhe7jIxCt1y

[Tralapo]

@u0x01 I did a test and that one does indeed work in all versions.

But your example looks more like some kind of VOD thing other then a real livestream.

[dobri-dobrev]

Same happens for me. As far as my debugging could show, the this.tech_.currentTime() randomly returns a time significantly earlier than the current time causing the player to crash. The currentTime increases sequentially until it seemingly randomly jumps way back and the player stops loading new segments.

I could only track the issue down to src/videojs-hls.js fillBuffer(). Hope this helps. It is unfortunately a significant blocker for us

[u0x01]

Has any other plugin can substitute videojs to play HLS?

[Tralapo]

I believe not. I'm sticking with videojs-contrib-hls 1.2.0 for now, that one works perfectly fine. Something failed after that.

[u0x01]

@Tralapo It's this of your sticking?

https://github.com/videojs/videojs-contrib-hls

[Tralapo]

Well yes, obviously, just this repo. But I use development version 1.2.0. Not the current one, 1.3.3.

[campones]

yes there is a substitute, based on the flash player https://github.com/mangui/video-js-swf

This is very stable, I m using for over a year. Of course the interest in hls.contrib. is to get rid of flash

[Tralapo]

Problem still there in the most recent version /*! videojs-contrib-hls - v1.3.4 - 2016-01-13

[u0x01]

@Tralapo Where can download your forking repo of 1.2.0?

[Tralapo]

@u0x01 https://gist.github.com/Tralapo/9f2b789b6c5ca28994e4

[u0x01]

@Tralapo Thanks!

[jhumbug]

@Tralapo So you're using hls 1.2.0 and videojs 5.2.0, correct? What version of videojs-contrib-media-sources are you using?

I ask because when I go back to 1.2.0 and 5.2.0 (i'm experiencing this same .ts file bug when you switch tabs) on Chrome, which uses the Flash player, I only get the lowest quality bitrate loading, which for us is an audio only version. It never switches to the higher one.

Here's hls 1.2: http://www.adultswim.com/dev/as-player-1.2/ Here's hls 1.3.4: http://www.adultswim.com/dev/as-player-1.3.4/

[Tralapo]

What version of videojs-contrib-media-sources are you using?

Good question, because I'm still not convinced of the need for that one, maybe @dmlap can comment on that? I test sites with contrib-media-sources loaded and sites without it and I do not experience any difference between the two.

So you're using hls 1.2.0 and videojs 5.2.0, correct?

No, I'm using videojs-contrib-hls 1.2.0 together with videojs 5.4 (CDN loaded) at the moment, without problems.

Chrome, which uses the Flash player

I think something is wrong with your setup then, because Chrome does not fall back to Flash if you use videojs-contrib-hls.

[jhumbug]

@Tralapo Thanks for the clarification.

I'm now using those same versions and got it using the html5 video object for Chrome (had to change something in the options I was passing in) but it's still not switching the bitrate above audio only. Strange...

Maybe it's my m3u8: http://adultswim-lh.akamaihd.net/i/marathon_1@318516/master.m3u8 Any chance you could link the m3u8 that's working for you?

[Tralapo]

@jhumbug No, I'm sorry, I can't share my stream unfortunately. The example you give doesn't work for me either. This one does: http://playertest.longtailvideo.com/adaptive/bipbop/bipbop.m3u8

By the way: videojs-contrib-media-sources is now deleted from the readme, so you indeed do not have to include it anymore.

[Tralapo]

@imbcmdth @dmlap The problem is still there in 1.3.5.

[jhumbug]

@imbcmdth @dmlap In my personal experience this issue only occurs when I switch tabs while letting the stream play on. If you have a network logger open while in another tab, you can watch the m3u8 files download, but not the ts files. As soon as I go back to the tab playing the stream it artifacts and catches back up to where it thinks it should be and starts downloading the ts files again.

Here's a page my stream using 1.3.4: http://www.adultswim.com/dev/as-player-1.3.4/

Note, I'm using Flash first on this page because for some other strange reason it won't switch bitrates when I try to use html and gets stuck on the audio only version in the playlist.

[Tralapo]

@jhumbug No, that's not it. It always fails after the first m3u8 is finished. With or without switching tabs.

[jhumbug]

@Tralapo Well I can't properly test the html tech version, so I can't say for sure what happens there, but what I'm experiencing with my Flash version is definitely happening on all Desktop browsers and seems to at least be somewhat related to this.

[andrewho83]

Can confirm that the latest version also halts when window/tab is not focused. Reverting back to 1.2.1 seemed to fix it.

[temaptz]

It also affects 1.3.6.

[dmlap]

We made a tiny but important improvement to behavior in 1.3.7 which may fix this issue. If anyone has a chance to try that release out and report back, it would be appreciated.

[sirhanshafahath]

Cool..

Working with,

video.js: v5.6.0 & v5.7.0 videojs.hls.js: v1.3.7 techOrder: html5

browser: Chrome v48.0.2564.103 browser: FireFox v44.0

test source type: live stream from flussonic media server

[Tralapo]

@dmlap Tested with 1.3.7 and Video.js 5.4, 5.5 and 5.6: still no luck. Stream still breaking after first .m3u8 list ends.

[dijjit]

We are still finding the same both with the latest and the existing versions recommended above - stream available for testing if it helps isolate this...

http://live.ortana.tv/1280x720_2.m3u8

This is being made using FFMPEG - with the segment length set to 6 seconds, with a 10 second segment history in the M3U8 file

[billybobilly]

Just confirmed issue with 1.3.7 using 5.3

[Tralapo]

Did a new build today and it seems to be working? Finally? More people that can confirm?

[mikeevstropov]

@Tralapo Friend, can u share last build please? I have problem with npm on win. Thank you!

[dijjit]

If someone can share I can retest on the same faulty stream as before.

Sent from my Samsung Galaxy S6 Edge+ - powered by Three

-------- Original message -------- From: mikeevstropov notifications@github.com Date: 19/02/2016 18:15 (GMT+00:00) To: videojs/videojs-contrib-hls videojs-contrib-hls@noreply.github.com Cc: James Gibson james@ortana.tv Subject: Re: [videojs-contrib-hls] segment files stop downloading but new m3u8 files keep coming (#483)

@Tralapohttps://github.com/Tralapo Friend can u share last build please? I have problem with npm on win. Thank you!

Reply to this email directly or view it on GitHubhttps://github.com/videojs/videojs-contrib-hls/issues/483#issuecomment-186342946.

[Tralapo]

@mikeevstropov I can. My working copy of version 1.3.8: https://gist.github.com/Tralapo/94291509f987d0d56e05 . I use it with Video.JS 5.6 now.

[mikeevstropov]

@Tralapo I tried your build 1.3.8 with video.js 5.6 and it's working correctly on live. ps. But i have problem not for this issue. The VoD stream stops on 30sec after 5-7 segments. =/

[raj2569]

Issue still persists:

video.js: v5.7.1 videojs.hls.js: https://gist.github.com/Tralapo/94291509f987d0d56e05 browser: Version 47.0.2526.106 (64-bit) Stream: http://178.63.55.206/live01/test01/index.m3u8 URL: http://178.63.55.206/player1.html

I am using the following ffmpeg cmdline for generating the stream:

~/ffmpeg-git-20160227-64bit-static$ ./ffmpeg -loglevel verbose -re -i ../videos/tears_of_steel_720p.mov -vcodec libx264 -vprofile baseline -acodec libmp3lame -vf scale=640:268 -ar 44100 -ac 1 -f flv rtmp://178.63.55.206/live01/test01

Attached is the screenshot of the chrome inspector.

Please let me know if any additional information is needed or any testing is to be done to isolate this issue.

[billybobilly]

@mikeevstropov I tried the newest build last week and had the same problem as you when source is a VOD. The LIVE stream is now working like @Tralapo says, but when I switch the source of the encoder to a VOD file, I get the same result as @raj2569

Any new work on this problem?

[mikeevstropov]

@billybobilly Hi. I cannot understand what contrib-hls wants to work fine. Now i'm using hls.js (dailymotion) with custom player controls. (mdn reference: https://goo.gl/Y20qNW w3school: http://goo.gl/sYGOul) And it's not so hard like what i thought. But, if you want you can use video.js with hls.js.

[billybobilly]

From what I can tell, dailymotion doesn't use videojs so the plug-ins I'm using from the videojs project won't work there.

[billybobilly]

If you press stop/pause on the stream and then start it again after it stops getting the ts files, then it will start back up. the videojs console note said it attempted to seek to a spot but it was too soon, seeked to a later spot and started streaming again.

[billybobilly]

Finally have it all working. Using latest video.js, videojs-hls.js, .css, etc.

The live from capture card and 'live' from vod are both playing without freezing. The vod problem turned out to be a parameter in the ffmpeg encoder where we had -c copy in the command. removed that and everything is fine.

Unless someone else has a continuing problem, I think this issue can be closed.