Hls.js in react application is not working

[ThayalanGR]

What version of Hls.js are you using?

"hls.js": "^0.12.2"

What browser and OS are you using?

chrome and windows 10 64 bit

Test stream:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2149280,CODECS="mp4a.40.2,avc1.64001f",RESOLUTION=1280x720,NAME="720"
url_0/193039199_mp4_h264_aac_hd_7.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=246440,CODECS="mp4a.40.5,avc1.42000d",RESOLUTION=320x184,NAME="240"
url_2/193039199_mp4_h264_aac_ld_7.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=460560,CODECS="mp4a.40.5,avc1.420016",RESOLUTION=512x288,NAME="380"
url_4/193039199_mp4_h264_aac_7.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=836280,CODECS="mp4a.40.2,avc1.64001f",RESOLUTION=848x480,NAME="480"
url_6/193039199_mp4_h264_aac_hq_7.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=6221600,CODECS="mp4a.40.2,avc1.640028",RESOLUTION=1920x1080,NAME="1080"
url_8/193039199_mp4_h264_aac_fhd_7.m3u8

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page

• The issue occurs in the latest client on https://hls-js-latest.netlify.com/demo and not just on my page

• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Please provide clear steps to reproduce your problem
2. If the bug is intermittent, give a rough frequency

import React, { Component } from "react";
import Hls from "hls.js";

class Player extends Component {
state = {};

componentDidMount() {
if (Hls.isSupported() && this.player) {
const video = this.player;
const hls = new Hls();
hls.loadSource(
"https://video-dev.github.io/streams/x36xhzz/x36xhzz.m3u8"
);
hls.attachMedia(video);
hls.on(Hls.Events.MANIFEST_PARSED, function() {
video.play();
});
}
}

render() {
return (

<video
preload="none"
className="videoCanvas"
ref={player => (this.player = player)}
autoPlay={true}
/>

);
}
}

export default Player;

Expected behavior

What you expected to happen

Actual behavior

What actually happened

Console output

blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:42 Uncaught TypeError: Cannot read property 'call' of undefined
    at __webpack_require__ (blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:42)
    at Object.srcDemuxDemuxerWorkerJs (blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:184)
    at __webpack_require__ (blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:42)
    at webpackBootstrapFunc (blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:170)
    at blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:173
__webpack_require__ @ blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:42
srcDemuxDemuxerWorkerJs @ blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:184
__webpack_require__ @ blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:42
webpackBootstrapFunc @ blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:170
(anonymous) @ blob:http://localhost:3000/51643d91-38fb-43d1-bd0d-53ac0df82ee3:173

For media errors reported on Chrome browser, please also paste the output of chrome://media-internals 

[ThayalanGR]

after downgrading the hls.js version to 0.8.8 it runs now smoothly.

runs smoothly

[johnBartos]

@ThayalanGR Are you re-webpacking the hls dist file? That may be the cause of the issue you're seeing

[ThayalanGR]

@johnBartos No I am not re-webpacking , however downgrading the version helps me to get rid of that error , and it now runs smoothly

[kpfromer]

I am also experiencing this issue.

[haywirez]

Same problem, issues start with release 11.1 🤔

[ThayalanGR]

@haywirez try downgrading the version to 0.8.8

[CyanoFresh]

this is not normal I think. Why issue is closed?

[michaelcunningham19]

I'm also curious about this and why it seems to be happening on 0.11.1 and after (according to @haywirez)

Does someone have a Codepen or similar with a minimal setup that reproduces this issue?

[tamdao]

The same issue with v0.12.2. I use create react app

[igor10k]

As a temporary (hopefully) workaround for create-react-app I added the <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script> to public/index.html and replaced import Hls from 'hls.js' with const Hls = window.Hls. This sucks but it's better than to use a very outdated version.

[michaelcunningham19]

As a temporary (hopefully) workaround for create-react-app I added the <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script> to public/index.html and replaced import Hls from 'hls.js' with const Hls = window.Hls. This sucks but it's better than to use a very outdated version.

This tells me that this isn't an Hls.js issue, but an issue with the build system provided by create-react-app, as suggested previously by @johnBartos

I recognize the reports of "downgrading to 0.8.8 works", however, if we can tweak create-react-app's build system to not transform any of Hls.js' distributable code, that would be the ideal solution.

If such a solution is discovered, we can document it as part of the README, considering how popular create-react-app is.

I am curious if Angular has this same issue with it's CLI angular-cli

Thoughts?

cc @itsjamie

[igor10k]

It is the first time I encounter a plugin's incompatibility with create-react-app's build system. You can not edit its config without ejecting and this is definitely not the case that should require ejecting. So I think it all comes down to two possible choices:

1. Figure out what made hls.js incompatible with CRA in recent versions and fix that.
2. If it is an issue with webpack config in create-react-app create a PR there.

[michaelcunningham19]

@igor10k

So just to confirm to help narrow down the cause in this lib, you're seeing that it breaks with version 0.8.9? But works on 0.8.8

[igor10k]

@michaelcunningham19 I haven't tested older versions, too close to the deadline to waste time on that. I'll revisit that in a few weeks if it's not solved by then.

@ThayalanGR mentioned 0.8.8, not sure why he chose that specific version.

[tjenkinson]

for some reason webworkify-webpack behaves slightly differently in the build when running in the react app. didn’t get to the bottom of it now but in the webworkify part of the build there is

var requiredModules = options.all ? { main: Object.keys(sources.main) } : getRequiredModules(sources, moduleId)

and in the react app it is not finding the modules to include for some reason. If you set the all option to true meaning it includes every module in the blob it injects into the worker, it works fine

all - bundle all the dependencies in the web worker and not only the used ones. can be useful in edge cases that I'm not aware of when the used dependencies aren't being resolved as expected due to the runtime regex checking mechanism or just to avoid additional work at runtime to traverse the dependencies tree.

A workaround for now to make it work in react is to set enableWorker: false in the config object.

new Hls({ enableWorker: false });

[tjenkinson]

I opened a PR on webworkify-webpack to fix this: borisirota/webworkify-webpack#40

[tjenkinson]

opened this pr on hlsjs to use the patched version for now if we don't want to wait for the fix in the official package: #2163

[tjenkinson]

This should be fixed now. Please try with 0.12.3-canary.4258 and let us know if there is still a problem.

[michaelcunningham19]

Awesome @tjenkinson !

[gnarr]

This should be fixed now. Please try with 0.12.3-canary.4258 and let us know if there is still a problem.

This is still broken in 0.12.4, does that have the 0.12.3-canary.4258 fix?

[tjenkinson]

This fix is not in a stable release yet. On 19 Mar 2019, at 14:12, Gunnar Cortes Heimisson <notifications@github.com<mailto:notifications@github.com>> wrote: This should be fixed now. Please try with 0.12.3-canary.4258 and let us know if there is still a problem. This is still broken in 0.12.4, does that have the 0.12.3-canary.4258 fix? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#2064 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADG-WWTCLQ5g824sSdw7A-VanCfJMnngks5vYOIngaJpZM4Zlir_>.

[konstantin-mohin]

is there a chance that it will be included in next release ?

[timrogers]

👍 on that - I am stuck on this canary version because the fix hasn't been added to a stable release.

[igor10k]

The canary build works great. Any reason why it's not released yet?

[johnBartos]

@igor10k Resources - I have been busy working on Hls.js 1.0.0, and haven't put as much time into the next patch. I will try and get a release son so we can begin regression testing.

@konstantin-mohin Yes, this will be in the next release.

[nitin2dixit]

When we are using HLS versions 0.11.0 or 0.12.4 then we are getting below error:
SyntaxError: missing ] after element list

OS: KaiOS (Based on Firefox OS)

We found out that we are facing this issue beyond HLS version 0.7.6.

After some debugging we found out that the issue somewhere around below code in HLS Library:

**src = src + '(' + webpackBootstrapFunc.toString().replace('ENTRY_MODULE', JSON.stringify(moduleId)) + ')({' + requiredModules.main.map(function (id) { return '' + JSON.stringify(id) + ': ' + sources.main[id].toString() }).join(',') + '})(self);'

var blob = new window.Blob([src], { type: 'text/javascript' })**

We found out that the source 'src' is not getting formed properly. Below is the 'src' formed:

(function webpackBootstrapFunc() {
[sourceless code]
})({13: function () {
[sourceless code]
}})(self);

[sourceless code] is getting generated.
Please help regarding the same.

Is there any restriction for the same in Firefox OS? If Yes how can we bypass it.?

Note: In chrome browser scenario the 'src' is getting formed of about 5000 lines of JavaScript code.

[nitin2dixit]

In addition to this if I set enableWorker: false in HLS.js then it is working for me.
I would like to understand what are the implications of setting enableWorker: false

[djnorrisdev]

In addition to this if I set enableWorker: false in HLS.js then it is working for me.
I would like to understand what are the implications of setting enableWorker: false

I'd like to know also.

[ghost]

has this been fixed? can I use it with react 16

[ca-miked]

has this been fixed? can I use it with react 16

I can confirm this issue persists - the only workaround that was successful for me was the enableWorker:false in the constructor

[jackguoAtJogg]

It's not working on Next.js as well. I'm getting this error.

TypeError: hls_js__WEBPACK_IMPORTED_MODULE_5___default.a is not a constructor

[DomenicoCammarota]

It's not working on Next.js as well. I'm getting this error.

TypeError: hls_js__WEBPACK_IMPORTED_MODULE_5___default.a is not a constructor

Is there a way to get this working in next.js projects?

[morizmatik]

It's not working on Next.js as well. I'm getting this error.

TypeError: hls_js__WEBPACK_IMPORTED_MODULE_5___default.a is not a constructor

Is there a way to get this working in next.js projects?

Hi! I have same problem in next.js. downgrading to 0.8.8 not helps me. Can you solve this problem in your project?

[Fiorello]

Hi, I have the same problem. Any news on this issue?
It works only with enableWebWorker: false

[TroyKomodo]

Mine player also threw this error. But it was notin react.

[robwalch]

Please read the comments #2064 (comment)

This issue was closed with a fix merged almost a year ago. If you have a similar issue, please file a new issue using the Bug Report Template and provide steps to reproduce the problem including the version of hls.js you are using and a stripped down project setup. Only issues against the latest version will be considered for a patch.