Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

HLS live streaming

hi there ... I'm testing HLS streaming on JWPlayer 6 Premium for live streams.
I noticed bufferings that I don't get on devices that support HLS like IPAD or Roku player, using same streams.
I sniffed the traffic and found an strange behaviour for an HLS player.
My .m3u8 manifest has 4 chunks listed, but the player instead of start downloading and playing the first of the list, it starts from the 3rd one (2nd from the end of the list).
As per HLS definition, it should do it from third from the end (as IPAD does). Ideally for my case would be it starts playing from the first chunk of the list, and try to download as many chunks as possible to fill up buffer.
Is there a setting to modify this behaviour?
Are there settings to control buffers of the player, like, how much video before start playing, etc? ...


Thanks!!!

40 Community Answers

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Do you have a link?

Up Down

JW Player

User  
-1 rated :

Sure ... see below 2 links. One is for a stream that publishes only 3 chunks in the playlist, and the other one publishes 4 chunks.
On both cases, if you debug the traffic, you'll see that first chunk downloaded for the player is not the first one in the list, but the second from the end.

http://38.113.164.99:1935/toronto/eurosport/playlist.m3u8


http://d20ick8mze9ahh.cloudfront.net/canal13/canal13live/playlist.m3u8

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Can I see where the player is being run, I mean?

Up Down

JW Player

User  
0 rated :

yes, it's a demo site

http://www.glidertek.com/support/hls/jwplayertest.html

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Firebug seems to think that jwplayer.js is in Chinese? The player is not loading at all here because of this.

Up Down

JW Player

User  
0 rated :

no idea about that ... the code is just a copy of the sample from documentation site

I've uploaded a simpler one at
http://www.glidertek.com/support/hls/player_tv2.html

do you want me to send you the html file I'm using?

Up Down

Ethan Feldman

JW Player Support Agent  
-1 rated :

This one works fine. I would recommend updating to 6.3 though – https://account.longtailvideo.com/sign-in

Up Down

JW Player

User  
0 rated :

thanks, but I don't think you follow my original question.
I'm evaluating the product in order to decide subscribing to premium service for HLS streaming.

I don't say it doesn't work. I'm saying it doesn't follow the specification for HLS streaming, and I just want to know why (if it's a bug or a setting or it has being designed that way)

For instance, some of my live streams manifest have 4 chunks in the list.
Let's says it's like following

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:7339
#EXTINF:8.96,
media-001.ts
#EXTINF:7.56,
media-002.ts
#EXTINF:10.16,
media-003.ts
#EXTINF:12.839,
media-004.ts


In this example, most HLS player would start downloading and playing the media-001.ts file, and continue down the list. The HLS specification says at least, it should start downloading media-002.ts to start (that's the way Apple devices does)

On this example, JWplayer starts playing from media-003.ts ... which is not a normal behaviour on live HLS stream as it's losing the chance to fill up cache faster, take advantage of CDN caching, etc.

So, my questions is why and if there's a setting that can change that behaviour or what is the explanation. Not starting from the begining of the manifest playlist is a risk of buffering.

Thanks in advance

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Got it, will ask…

Up Down

JW Player

User  
0 rated :

thanks ... looking forward to the answers

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

np

Up Down

JW Player

User  
0 rated :

Eagerly awaiting an answer on this...

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

I sent it along…

Up Down

JW Player

User  
0 rated :

Sorry to bug you, but any ETA on this? I'd like to make a decision on buying the player or not, and this issue is holding me

Thanks

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Sorry, will ask.

Up Down

JW Player

User  
0 rated :

It's very important for us too. So awaiting an answer.

Up Down

JeroenW

JW Player Support Agent  
-1 rated :

There is no issue with the way JW Player is downloading fragment N-2 for live streaming. I’m not sure what you want fixed here?

Up Down

JW Player

User  
0 rated :

What I'm posting since the beginning is that the way JWPlayer is doing HLS playback of live streams doesn't follow the HLS specification.
There's no problem downloading the fragments. The problem is which is the first fragment the player starts downloading

Every player in the market that support HLS has their own way to playback. Same stream is not played same way by Roku or IPAD or VLC.
But all of them follow the specs on the IETF draft for HLS. JW Player is not following it.
As per specification by IETF, on a 3-chunk-playlist, the player should start from the first of the list, not the second.

from the Pantos Draft
"
6.3.3. Playing the Playlist file

The client SHALL choose which media segment to play first from the
Playlist when playback starts. If the EXT-X-ENDLIST tag is not
present and the client intends to play the media regularly (i.e. in
playlist order at the nominal playback rate), the client SHOULD NOT
choose a segment which starts less than three target durations from
the end of the Playlist file. Doing so can trigger playback stalls.
"
this means that each target duration is 10 secs, it should start 30 secs from the end of the playlist, which is the thirs chunk from the end, not the second from the end.
This lets player to have enough cache in memory to avoid latency and throughput variations. And not starting for at least three chunks from the end, can cause issues with reloads of playlist as it's defined on the draft as well.

My guess is this isn't a complex fix in the player to be complaint with the IETF definition. Otherwise, JWPlayer shoud state why they don't follow that.


Up Down

JeroenW

JW Player Support Agent  
0 rated :

The player indeed loads N-1 instead of N-2 in certain situations. That’s weird – I was quite sure we did N-2. We’ll fix this.

Up Down

JW Player

User  
0 rated :

Thanks ... I'm glad to hear that
My demo license expires soon. I'll stay tuned for this fix to move forward for buying the premium license

Cheers

Up Down

JeroenW

JW Player Support Agent  
0 rated :

Here’s the ticket we created, for tracking purposes:

http://developer.longtailvideo.com/trac/ticket/1948

Up Down

JW Player

User  
0 rated :

Hi there ... just a follow up on this as I've seen tickets opened after that have been assigned while this one still has no owner.
Any time estimation for when it will be fixed? Will it be part of version 6.5 (I was wishing it to be fixed on 6.4 though)

Up Down

JeroenW

JW Player Support Agent  
0 rated :

This one will be part of the 6.6 update late July, which will include a list of other HLS enhancements.

I would love to get everything fixed fast as well, but unfortunately we’re 3 engineers and there’s just so much to do … :).

Up Down

JW Player

User  
0 rated :

Thanks Jeroen for the answer ... good to know the roadmap and dates
I guess you'll have to get used to pressure when customers are paying for the product now :) :)

Cheers

Up Down

JeroenW

JW Player Support Agent  
0 rated :

As long as they’re paying for it, I’m fine with that :p

Up Down

JW Player

User  
0 rated :

Hi,

We also use JW for a premium service and HLS support it's simply subpar compared to OS native behavior and I think this could be one of the reasons. With varying network conditions it's common to see JW buffer a bit while iOS provides a smoother experience. We got to the point of restarting the stream if an error or buffer is encountered. Full support for HLS it's still in beta for us (we own and manage a CDN) only because of JW's not-as-good-as-iOS HLS support still need ironing.
Don't take this as a troll post, it's just that personally I would LOVE to see those HLS fixes before 6.6 as it has a direct impact in our business (but well, we are not your only customers).

Cheers.

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Hm, do you have an example?

Up Down

JeroenW

JW Player Support Agent  
0 rated :

Cristin, we are aware of our HLS support not being so robust as iOS yet, and are working hard on improving this. With standard Wowza/Adobe media servers, I’d say our HLS support is robust, but with many other types of servers/segmenters there’s still ways to go.

The issue is we first have to reverse-engineer how every server does his HLS segmenting/muxing, then adding support for it. If you see issues with your CDN, we’d love to have one or two test streams to check them out…

Up Down

JW Player

User  
0 rated :

Hi Jeroen,

I'd be more than glad to provide access to one of our streams for you guys. Actually we sent a testing account for a premium service a couple of months ago (a soccer OTT).

I have your email on record, will send you a link. The thing is that HLS support isn't bad per-se, it's just subpar (yet) compared to iOS, meaning that unless you dedicate some serious viewing time and test under non-optimal network conditions you probably won't see any big problems.

JW's HLS support it's quite important for us, not only it doesn't allow us to enable this for a premium (hence paid) OTT service, but we, as a CDN, want to get rid of RTMP/T as soon as possible. An HLS only (+RTSP for Android) CDN allows us to lower our costs dramatically (less servers per user, caching, etc) and provide a better experience for our final users (no more firewall problems), but without a top grade HLS flash player this isn't possible.

As you can see I would really-really be a happy man seeing HLS changes coming in the next release.

btw, we use Wowza 3.5+

Cheers.

Up Down

JeroenW

JW Player Support Agent  
0 rated :

We’re always interested in additional test streams, so please send some to me if you have them.

For version 6.6 (July), we have a story on the backlog to extensively test / fix overall robustness of our HLS implementation with 2h+ live/test streams.

Up Down

JW Player

User  
0 rated :

guys, if you need help testing HLS, I'm glad to help out. We use JWPlayer premium for HLS, and an improvement on HLS performance will benefit our service.
So, don't hesitate to reach out for testing help

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Thanks, can you email some then? :)

http://www.longtailvideo.com/contact-us

Up Down

JW Player

User  
0 rated :

what do you need/prefer? I've live streams coming out of Wowza 3.1.2, Wowza 3.5.2 and encoding appliances directly (this last ones don't have crossdomain.xml, so a tweak is needed to have them working)
I also have Live with DVR, purely DVR content (extracts of DVR that look like VOD) and Time delays streams (recoding content published as live)

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Anything :) Anything will help us test / debug / fix.

Up Down

JW Player

User  
0 rated :

check this out, and compare it with default provider :
https://github.com/mangui/HLSprovider

Up Down

JW Player

User  
0 rated :

I believe iOS devices start at the first segment, not N-2. The HLS spec does not dictate where the player should start only that "the client should not choose a segment which starts less than three target durations from the end of the Playlist file".

For my purposes, starting at the first segment would be ideal. I'm using a feature from Zencoder called "instant play", which allows you to transcode video and start playing it before it is finished transcoding. It does this by delivering an incomplete EVENT type playlist before the video is finished transcoding. In this case, it is not a "live stream" and it is preferable to start at the first segment.

It would be great if JWPlayer had the ability to start at the first segment for EVENT playlists.

Up Down

JW Player

User  
-1 rated :

I checked iOS behavior with event based playlist, and it does not start from first segment. it always starts with N-2 or N-3.

However it would be possible to have a different behaviour and distinguish between live playlist (sliding window) and event playlist, using #EXT-X-MEDIA-SEQUENCE
if it stays to 0, then it would mean Event Playlist
if it is different from 0, it would mean live playlist (sliding window)

then using this trick, the media provider could choose from where to start the playback from.

Up Down

Ethan Feldman

JW Player Support Agent  
-1 rated :

Sorry, I meant a JW example ?

Up Down

JW Player

User  
-1 rated :

We are also interested in playback of event streams from 0, and not N-2.

Is there a way to engage jwplayer via a professional services engagement to get this feature done sooner?

Up Down

Ethan Feldman

JW Player Support Agent  
-1 rated :

We don’t do custom work, sorry.

This question has received the maximum number of answers.