Open phloxic opened 8 years ago
Also does not happen when I
wget -O flowplayer.hlsjs.min.js http://cdn.jsdelivr.net/hls.js/0.6.2-5/hls.min.js
uglifyjs -m -c < flowplayer.hlsjs.js >> flowplayer.hlsjs.min.js
Triple checking whether going back to noParse really does not help.
Indeed noParse also doesn't circumvent this.
Maybe it is related to (one of) these webpack warnings:
Side effects in initialization of unused variable enableLogs [./~/hls.js/lib/utils/logger.js:63,4]
Side effects in initialization of unused variable logger [./~/hls.js/lib/utils/logger.js:81,4]
Side effects in initialization of unused variable ErrorTypes [./~/hls.js/lib/errors.js:6,4]
Side effects in initialization of unused variable ErrorDetails [./~/hls.js/lib/errors.js:15,4]
It seems the hls.js error details are spewed out lettter by letter.
currently testing whether the issue has gone with hls.js v0.6.0.2-6 (https://github.com/dailymotion/hls.js/commit/81681373241bd600e4fd53d1db2271effc96b2ba ???)
Definitely still happening. Good time of the day to test http://flowplayer.blacktrash.org/fp6/live.html seems to be 13:00 GMT.
This is the most likely candidant: https://github.com/dailymotion/hls.js/blob/d6fda6236b44cf65d0f32deefcd9a3f9897d2a3a/src/utils/cea-608-parser.js#L166-L179
this.verboseLevel
is read, and this
might be something different when bundled with Webpack and using CommonJS require
s than when directly evaluated from within browser. @mangui can you take a look?
Indeed webpack brings only the symptoms of this problem to the fore. The same happens when one loads the unminified hls.js release. webpack deals with the unminified code, and therefore exhibits the problem, which is not apparent when using the minified hls.js distribution.