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

No Error Event Attempting to Play Unsupported Video #5011

Closed
5 tasks done
mattzucker opened this issue Nov 7, 2022 · 6 comments · Fixed by #5241
Closed
5 tasks done

No Error Event Attempting to Play Unsupported Video #5011

mattzucker opened this issue Nov 7, 2022 · 6 comments · Fixed by #5241

Comments

@mattzucker
Copy link
Contributor

mattzucker commented Nov 7, 2022

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

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 mattzucker added Bug Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. labels Nov 7, 2022
@mattzucker
Copy link
Contributor Author

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
Copy link
Collaborator

robwalch commented Nov 9, 2022

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)

@robwalch robwalch added Enhancement Stream Issue Need sample stream and removed Bug Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. labels Nov 9, 2022
@robwalch robwalch added this to Top priorities in Release Planning and Backlog via automation Nov 9, 2022
robwalch added a commit that referenced this issue Nov 10, 2022
@mattzucker
Copy link
Contributor Author

mattzucker commented Nov 10, 2022

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
Copy link
Collaborator

robwalch commented Nov 10, 2022

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.

robwalch added a commit that referenced this issue Nov 17, 2022
robwalch added a commit that referenced this issue Nov 17, 2022
* Emit and handle FRAG_PARSING_ERROR from transmuxers
Related to #5011
* Switch levels on Key and Fragment parsing errors or escalate to fatal error
robwalch added a commit that referenced this issue Dec 10, 2022
* Emit and handle FRAG_PARSING_ERROR from transmuxers
Related to #5011
* Switch levels on Key and Fragment parsing errors or escalate to fatal error
robwalch added a commit that referenced this issue Dec 15, 2022
* Add support for com.apple.fps keySystem

* Improve support for DRM key-systems and key handling
Resolves #2833 #2737 #4318 #4538

* Update README `licenseXhrSetup` example

* Update api-extractor markdown

* Attach CDM on start when even when initial fragments do not have a key associated with them

* Handle expired key status correctly

* Map key-sessions by key ID and log key ID more often than URI

* Support "clear-lead" key-session creation without new config

* Emit and handle FRAG_PARSING_ERROR from transmuxers (#5018)

* Emit and handle FRAG_PARSING_ERROR from transmuxers
Related to #5011
* Switch levels on Key and Fragment parsing errors or escalate to fatal error

* Route all key-system errors to `onFragmentOrKeyLoadError`

* Populate EMEKeyError.err for better demo error logging

* Remove `useEmeEncryptedEvent` and mark `widevineLicenseUrl` as deprecated in API.md

* Add support for EXT-X-SESSION-KEY tags (for key-system access on manifest loaded)
#4927

* Throw before licenseXhrSetup if key was removed

* Make key session promise chain more consice

* Stop on fatal key system errors

* Only request access to key-systems for keys matching those found in the config one at time (to avoid gaining access to WV and PR on Edge)

* Modify key-system helpers so that it's easier to support additional key-system strings

* Add undocumented `generateRequest` ("Content ID") filter

Co-authored-by: Vincent Valot <vincent.valot@bedrockstreaming.com>
@ellermister
Copy link

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 added a commit that referenced this issue Jan 20, 2023
robwalch added a commit that referenced this issue Feb 18, 2023
robwalch added a commit that referenced this issue Feb 18, 2023
robwalch added a commit that referenced this issue Feb 18, 2023
@robwalch robwalch added this to the 1.4.0 milestone Feb 18, 2023
robwalch added a commit that referenced this issue Feb 18, 2023
robwalch added a commit that referenced this issue Feb 18, 2023
robwalch added a commit that referenced this issue Feb 22, 2023
robwalch added a commit that referenced this issue Feb 22, 2023
@robwalch
Copy link
Collaborator

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).

robwalch added a commit that referenced this issue Feb 27, 2023
* Implement ErrorController …
Add Error Handling Integration Tests
Handle missed probe transmux probe with with FRAG_PARSING_ERROR
Handle encrypted init segment and subtitle decryption failure with FRAG_DECRYPT_ERROR
Remove delay when retrying after timeout
Trigger FRAG_LOADING after request is made
ERROR event data type must include an error property
Add stats to network loader error callbacks to allow error handling to use request timing
Remove use of console.warn from mp4-tools
Add missing TypeScript type exports

* Remove console.assert statements
Resolves #5218
Closes #5221

* Remove unused frag buffered monitor

* Add Load Policies and deprecate frag/level/manifest timeout and retry config options

* Switch on FRAG_PARSING_ERROR or continue trying fragLoadPolicy.default.errorRetry.maxNumRetry (6) times
Fixes #5011

* Switch on FRAG_PARSING_ERROR or continue trying fragLoadPolicy.default.errorRetry.maxNumRetry (6) times 2/2
Fixes #5011

* Do not reload level after calling stopLoad() and startLoad()
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref
Fixes #5230

* Implement ErrorActions and Pathway Switching

* Fix part timeout handling
Cleanup frag stats handoff

* Update retry rules to require http status or timeout error (deprioritizes retry on parse errors)

* Retry audio and subtitle playlist loading after failure on level switch when no alternate is available
@robwalch robwalch added the Verify Fixed An unreleased bug fix has been merged and should be verified before closing. label Feb 27, 2023
@robwalch robwalch removed the Verify Fixed An unreleased bug fix has been merged and should be verified before closing. label Apr 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Release Planning and Backlog
  
Top priorities
3 participants