No Error Event Attempting to Play Unsupported Video

[mattzucker]

What version of Hls.js are you using?

v1.2.4

What browser (including version) are you using?

Chrome Version 106.0.5249.91 (Official Build) (64-bit)

What OS (including version) are you using?

Linux CentOS 7

Test stream

https://raw.githubusercontent.com/mattzucker/hls-test-data/main/bigbuckbunny.m3u8

Configuration

{debug:true, enableWorker:true}

Additional player setup steps

No response

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 (latest release) on https://hls-js.netlify.com/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hls-js-dev.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. Load a stream with a video format that is not supported, for example an MPEG2 video.

Expected behaviour

An error event is triggered that explains the video format is not supported.

What actually happened?

With enableWorker:true, I see the same error as reported here #4958. As suggested in that ticket, I updated to the latest version from master. Now I am seeing this error:

ERROR {details: "internalException",
error: Error: Uncaught TypeError: Getter must be a function: d (blob:http://localhost:8080/7a252a65-61f3-4214-8d7d-b5b4326dc7da:8393) at TransmuxerInterface.worker.onerror (http://localhost:8080/VAT/vendor.d7a240a89f75d44bc2e6.js:18625:20)
message: "Uncaught TypeError: Getter must be a function: d  (blob:http://localhost:8080/7a252a65-61f3-4214-8d7d-b5b4326dc7da:8393)"
stack: "Error: Uncaught TypeError: Getter must be a function: d  (blob:http://localhost:8080/7a252a65-61f3-4214-8d7d-b5b4326dc7da:8393)\n    at TransmuxerInterface.worker.onerror (http://localhost:8080/VAT/vendor.d7a240a89f75d44bc2e6.js:18625:20)"
event: "demuxerWorker"
fatal: true
type: "otherError"}

To get more information, I set enableWorker:false. Now I do not see any error, and the video fails to play.

Console output

With `{debug:true, enableWorker:false}` and using the latest from master, the output is:

[log] > Debug logs enabled for "Hls instance"
hls-dev.js:18092 [log] > stopLoad
hls-dev.js:18055 [log] > loadSource:https://localhost:8443/VAWS/current/rest/mission/93555/m3u8
hls-dev.js:9985 [log] > [stream-controller]: Trigger BUFFER_RESET
hls-dev.js:18026 [log] > attachMedia
hls-dev.js:4118 [log] > [buffer-controller]: Media source opened
hls-dev.js:4042 [log] > [subtitle-stream-controller]: STOPPED->IDLE
hls-dev.js:8506 [log] > [level-controller]: manifest loaded, 1 level(s) found, first bitrate: 0
hls-dev.js:4215 [log] > 1 bufferCodec event(s) expected
hls-dev.js:18081 [log] > startLoad(-1)
hls-dev.js:8881 [log] > [level-controller]: switching to level 0 from -1
hls-dev.js:4042 [log] > [stream-controller]: STOPPED->IDLE
hls-dev.js:4042 [log] > [subtitle-stream-controller]: IDLE->STOPPED
hls-dev.js:4042 [log] > [subtitle-stream-controller]: STOPPED->IDLE
hls-dev.js:10049 [log] > [stream-controller]: Level 0 loaded [0,29], cc [0, 29] duration:884.8639999999999
hls-dev.js:4719 [log] > [buffer-controller]: Updating Media Source duration to 884.864
hls-dev.js:3320 [log] > [stream-controller]: Loading fragment 0 cc: 0 of [0-29] level: 0, target: 0
hls-dev.js:4042 [log] > [stream-controller]: IDLE->FRAG_LOADING
hls-dev.js:15310 [log] > [transmuxer-interface, main]: Starting new transmux session for sn: 0 p: -1 level: 0 id: 1
        discontinuity: true
        trackSwitch: true
        contiguous: false
        accurateTimeOffset: true
        timeOffset: 0
        initSegmentChange: true
hls-dev.js:15970 [warn] > Failed to find demuxer by probing frag, treating as mp4 passthrough
hls-dev.js:4042 [log] > [stream-controller]: FRAG_LOADING->PARSING
hls-dev.js:3085 [log] > [stream-controller]: Loaded fragment 0 of level 0
hls-dev.js:15852 [log] > [transmuxer.ts]: Flushed fragment 0 of level 0
hls-dev.js:4014 [warn] > [stream-controller]: Found no media in fragment 0 of level 0 resetting transmuxer to fallback to playlist timing
hls-dev.js:4042 [log] > [stream-controller]: PARSING->PARSED
hls-dev.js:4578 [warn] > Fragments must have at least one ElementaryStreamType set. type: main level: 0 sn: 0
hls-dev.js:4915 [log] > [buffer-controller]: Blocking operation requested, but no SourceBuffers exist
hls-dev.js:3205 [log] > [stream-controller]: Buffered main sn: 0 of level 0 
hls-dev.js:4042 [log] > [stream-controller]: PARSED->IDLE
hls-dev.js:3320 [log] > [stream-controller]: Loading fragment 1 cc: 1 of [0-29] level: 0, target: 27.868
hls-dev.js:4042 [log] > [stream-controller]: IDLE->FRAG_LOADING
hls-dev.js:15310 [log] > [transmuxer-interface, main]: Starting new transmux session for sn: 1 p: -1 level: 0 id: 1
        discontinuity: true
        trackSwitch: true
        contiguous: false
        accurateTimeOffset: true
        timeOffset: 27.868000000000002
        initSegmentChange: true
hls-dev.js:15970 [warn] > Failed to find demuxer by probing frag, treating as mp4 passthrough
hls-dev.js:4042 [log] > [stream-controller]: FRAG_LOADING->PARSING
hls-dev.js:3085 [log] > [stream-controller]: Loaded fragment 1 of level 0
hls-dev.js:15852 [log] > [transmuxer.ts]: Flushed fragment 1 of level 0
hls-dev.js:4014 [warn] > [stream-controller]: Found no media in fragment 1 of level 0 resetting transmuxer to fallback to playlist timing
hls-dev.js:4042 [log] > [stream-controller]: PARSING->PARSED
hls-dev.js:4578 [warn] > Fragments must have at least one ElementaryStreamType set. type: main level: 0 sn: 1
hls-dev.js:4915 [log] > [buffer-controller]: Blocking operation requested, but no SourceBuffers exist
hls-dev.js:3205 [log] > [stream-controller]: Buffered main sn: 1 of level 0 
hls-dev.js:4042 [log] > [stream-controller]: PARSED->IDLE

Chrome media internals output

No response

[mattzucker]

To clarify, there are 2 issues I see. The first is a bug that only occurs when enableWorker is true. The second is a request to add an error event for unsupported video formats.

From the 3 warning logs I see, I would like if one of those could throw an error that I can respond to and gracefully tell the user that the video format is not supported. Perhaps the last one is the best place to do it?
Fragments must have at least one ElementaryStreamType set

Suggest changing that from warning to error and throwing an appropriately typed event.

[robwalch]

To clarify, there are 2 issues I see. The first is a bug that only occurs when enableWorker is true.

See comments in #5015, and please direct worker related failures to that issue.

second is a request to add an error event for unsupported video formats.

Please provide a sample stream that reproduces the issue.

The player supports empty segments since v1.2.0 with #4800. I agree that in this case we should produce a fatal error if there are no alternate renditions available - but only if:

1. Both Failed to find demuxer by probing frag, treating as mp4 passthrough AND Found no media in fragment occur (probing failing is a sign that this is an unsupported container)
2. More than 1 (how many TBD?) segments have no media (so that we continue to support the use-case Emit FRAG_PARSED when parsed fragment has no media #4800 was added for but don't let the free pass on empty results run indefinitely)

[mattzucker]

Sample stream: https://raw.githubusercontent.com/mattzucker/hls-test-data/main/bigbuckbunny.m3u8

Thank you for the link to the other issue. I didn't see it when I looked through open bug tickets.
The sample stream that I posted has the behavior of the warning message Fragments must have at least one ElementaryStreamType set without any additional configuration (besides debug:true).

More than 1 (how many TBD?) segments have no media (so that we continue to support the use-case #4800 was added for but don't let the free pass on empty results run indefinitely)

I don't expect any segments to have no media. I suppose HLS.js thinks it has no media because the format is not supported. In that case, I don't understand the reasoning behind #4800 because it seems like no media should be an error, but perhaps you could throw a non-fatal error instead?

That would support gracefully handling segments with no media but also give an option for a convenient hook where I might want to put up a warning to tell the user something may be wrong with their video stream.

[robwalch]

I don't expect any segments to have no media. I suppose HLS.js thinks it has no media because the format is not supported.

Failed to find demuxer by probing frag, treating as mp4 passthrough means HLS.js is treating the segment data as fragmented mp4 even though it couldn't identify it as an mp4 fragment.

In that case, I don't understand the reasoning behind #4800 because it seems like no media should be an error,

A user had a library of legacy streams with MPEG2-TS segments where occasionally a segment would not contain any media samples. Other popular HLS players made it across this content without failing so #4800 was implemented to do the same.

but perhaps you could throw a non-fatal error instead?
That would support gracefully handling segments with no media but also give an option for a convenient hook where I might want to put up a warning to tell the user something may be wrong with their video stream.

In that case we would just emit a non-fatal FRAG_PARSING_ERROR when logging Fragments must have at least one ElementaryStreamType set.

The difference here is that the segment type could not be identified, AND we could not find any media in it. Either case should be allowed exclusively, but when both occur a fatal error must be raised.

[ellermister]

I'm not sure about the cause of this problem, but I had a similar phenomenon and it resolved.

For others to refer to

• Please check if your project uses mock.js
• The blob file created by hls for m3u8 file does not exist (ERR_FILE_NOT_FOUND)
• Hls write warn message is "Blocking operation requested, but no SourceBuffers exist"

Try it

If there is, please remove it and it will be resolved!

Or consider replacing with better-mock!

mock.js is wasting too much of my time!

[robwalch]

Not a Contribution

You can preview the fix here https://deploy-preview-5241--hls-js-dev.netlify.app/demo/

The player will produce several FRAG_PARSING_ERRORs (up to fragLoadPolicy maxNumRetry) with the last one being fatal and stopping loading (this allows level switching and on the lowest level skipping of bad fragments before failing after several unsuccessful attempts).

[bondipathshala]

the issue is persist and happend with encryption and decryption