Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Videojs: 0.4.1.1 results in 64k-aac while 0.3.5 results in 2040K-video #351

Open
tommyh opened this issue Aug 4, 2015 · 11 comments
Open

Comments

@tommyh
Copy link

tommyh commented Aug 4, 2015

Hi,

I'm working on integrating flashls into videojs. First of all, thanks for all the hard work - we really appreciate it, :).

Issue: When using the forked version of video-js.swf, I get drastically different behavior from release version 0.4.1.1 and 0.3.5. I have a "soccer" video which in 0.4.1.1 plays the 64k audio stream (ie no video), and in 0.3.5 it plays the 2040K video stream.

Expected behavior: In 0.4.1.1 the 2040K video stream should play.
Actual behavior: In 0.4.1.1 the 64k audio stream plays.

Steps to reproduce:

  1. Go to my page for 0.3.5 with my soccer video: http://rawgit.com/tommyh/602b085e5f973b09c411/raw/8b439e84ce85ec61dedb294731336d810514b54b/version_0-3-5_with_soccer_video.html
  2. Click play and notice how you see video content.
  3. Look at the developer console and you should see this:
INFO:https://github.com/mangui/flashls/releases/tag/v0.3.5
INFO:HLSProvider: new level index 0 bitrate=64000, width=0, height=0
INFO:HLSProvider: new level index 6 bitrate=2040000, width=0, height=0
INFO:video size changed to (1024,576)
  1. Go to my page for 0.4.1.1 with my soccer video: http://rawgit.com/tommyh/602b085e5f973b09c411/raw/8b439e84ce85ec61dedb294731336d810514b54b/version_0_4_1_1_with_soccer_video.html
  2. Click play and notice how hear the audio but see no video content.
  3. Look at the developer console and you should see this:
INFO:https://github.com/mangui/flashls/releases/tag/v0.4.1.1
VM334:1 INFO:HLSProvider: new level index 0 bitrate=64000, width=0, height=0

For reference, I also made test pages with your sample video, but your sample video plays fine in both versions:
http://rawgit.com/tommyh/602b085e5f973b09c411/raw/8b439e84ce85ec61dedb294731336d810514b54b/version_0-3-5_with_demo_video.html
http://rawgit.com/tommyh/602b085e5f973b09c411/raw/8b439e84ce85ec61dedb294731336d810514b54b/version_0_4_1_1_with_demo_video.html

Environment: Mac OS X 10.8.5, Chrome 44.0.2403.125 (64-bit), Good internet connection

Can you reproduce this behavior as well? Or is it just me?

Note: For right now I am sticking with version 0.3.5 and that looks good to me. But wanted to reach out with this issue as soon as I could to put it on your radar.

Thanks,
Tom

PS: I've started to make a videojs plugin for flashls to make the integration slightly easier. The main thing it does is register a source handler w/ videojs, so the developer can set the content type of their m3u8 source to "application/x-mpegURL": https://github.com/tommyh/videojs-flashls/blob/master/videojs.flashls.js. Do you think you'd want to put this into the flashls readme?

@hparra
Copy link

hparra commented Aug 4, 2015

Is your first rendition audio only? I've had problems with hls_capleveltostage enabled and staying stuck on the first rendition.

RE: application/x-mpegURL, been wondering where change really belongs.

@hparra
Copy link

hparra commented Aug 4, 2015

@tommyh I've confirmed it's staying on level 0, which is audio only. Setting hls_capleveltostage to false allows auto level switch to work as expected.

@tommyh
Copy link
Author

tommyh commented Aug 4, 2015

@hparra, when i view the m3u8 for my soccer video, I see this:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
272deb0e2c488b98-2040k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
272deb0e2c488b98-1540k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
272deb0e2c488b98-1040k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
272deb0e2c488b98-640k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
272deb0e2c488b98-440k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
272deb0e2c488b98-240k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
272deb0e2c488b98-64k.m3u8

So wouldn't the first stage be "2040000"? Or am I reading the m3u8 playlist wrong?

@hparra
Copy link

hparra commented Aug 4, 2015

Level indexing goes by sorted bandwidth, so in this case the 64k is 0. That is traditional bitrate for audio-only.

FlasHLS Levels vector also retains the original (file) indices as well, in case you ever needed that.

@tommyh
Copy link
Author

tommyh commented Aug 4, 2015

In regards to "application/x-mpegURL", if you register a source handler with videojs for m3u8, then it allows you to have both a m3u8 and an mp4 source in your video tag. Then when videojs wakes up, it will loop through the sources for the first tech (in this case techOrder[0] => "Flash"). The source handler says that the Flash tech can play an m3u8 file, so videojs won't look at the mp4 resource or the Html5 tech.

<video id="my-player" preload="none" class="video-js vjs-default-skin" width="{{ width }}" height="{{ height }}" poster="{{ poster_url }}">
  <source src="{{ video_hls_url }}" type="application/x-mpegURL" />
  <source src="{{ video_url }}" type="video/mp4" />
</video>

All the end user has todo is invoke the flashls plugin for videojs: videojs.flashls({swfUrl: "http://localhost:3000/path/to/flashls/video-js.swf"});

Not sure if that's what you were asking or not, but hoping to add context. :)

@tommyh
Copy link
Author

tommyh commented Aug 4, 2015

@hparra - gotcha on the indexing being sorted by bandwidth. :) Very new to HLS, so still trying to get my bearings.

As far as setting hls_capleveltostage, I'm assuming based on my interpretation of these lines, that I need to set a <param> for capLevelToStorage on the object. I'll try that out. If you know of any documentation/examples that'd be super helpful too.

@hparra
Copy link

hparra commented Aug 4, 2015

Pass them in as flashvars via VideoJS. See https://github.com/pivotshare/videojs-levels/blob/master/example.html for example.

@tommyh
Copy link
Author

tommyh commented Aug 4, 2015

@hparra - very cool. thanks!

@tommyh
Copy link
Author

tommyh commented Aug 4, 2015

confirmed that changing the configuration value fixes it:

    videojs.options.flash.flashVars = {
      hls_capleveltostage: false
    };

Does that mean that 0.4.1.1 is broken for "hls_capleveltostage=true" and my soccer video is a reproducible case? Or is there something broken with my m3u8 file in regards to width/height?

@hparra
Copy link

hparra commented Aug 4, 2015

I've had problems with this feature and my streams as well. It's part of FlasHLS itself, so I figure that is doesn't work properly with VideoJS. I am unsure if the feature in FlasHLS proper requires the RESOLUTIONs in the manifest file. That's a good question for @mangui

@mangui
Copy link
Owner

mangui commented Aug 17, 2015

you should use configuration params if you want to tweak the start level, please refer to https://github.com/mangui/flashls#configuration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants