adapter: Should adapter detect this as a constraints error?
Referring to this issue: https://github.com/webrtc/samples/issues/955
I’m running into this same problem with my macbook air and chrome 67. On this webrtc-samples demo page: https://webrtc.github.io/samples/src/content/getusermedia/resolution/ If I select “Full HD”, it comes back with a black 2x2 video.
I’m posting here because I was about to file this as a bug with Chrome (I dunno – is it a bug with the browser or with my macbook itself?), but I realized that also it seems like this could/should be detected and “fixed” (ie, exception thrown) by the adapter?
My work-around is to try the video on a hidden <video> element, and wait for its dimensions meta data, and if it’s not what I requested (1920x1080), like instead 2x2, assume it was a constraints error, and move on.
It would be helpful if maybe the adapter (call to getUserMedia(..)) could just do that, though, patching up what is either a Chrome or device bug in this respect. I suspect there are a lot of people with macbook airs and chrome, for whom this is happening.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (4 by maintainers)
The 2x2 black frame appears because Chrome’s video element implementation always plays a 2x2 frame after the track is closed in order to clear the last frame from the closed track. When it’s a functional device that has produced frames with the requested resolution, the black frame in the video element will appear with the same dimensions as the previous frames. In this case we just have a faulty device that never produced a single frame, the track was closed and the 2x2 frame was the only frame played by the element, hence the 2x2 dimension of the element. This is working as intended in Chrome and I think it’s not against the spec since the 2x2 frame is played by the element after the track is closed. Firefox uses a different mechanism, but to me, both implementations seem to be working as per the spec.
Also, the point of this bug I’ve filed is only to track whether if, for whatever reason, a browser/OS/machine hands out an invalid video stream, adapter should “fix” that as it does other cross-browser inconsistencies?
As I said, I’ve filed bugs to track whether it’s ultimately a Chrome (or OSX or Macbook Air) bug. But regardless of that, I’d still like it if adapter handled this “test the video stream to see if it’s legit” thing. Perhaps there are other odd cases besides mine where invalid videos are returned, and such a feature would “fix” all of them.