Three.js: Initially muted video breaks videoTexture

[EliasHasle]

I am doing some experiments using webcam input and saving processed video with audio to a local file. I have encountered a strange problem, that _may be a browser bug_. I am using one of the most recent versions of Chromium for Windows. Below is a simple script (with no image processing) to reproduce the problem. The record button starts and stops a recording. Without muting the audio, there will be feedback. Therefore I want to mute the audio for the video element that is being used as a texture, but keep the audio for the recording.

Setting muted:true during the Object.assign (remove _//_ from _//muted: true,_ in the script below) causes this error message:
WebGL: INVALID_VALUE: tex(Sub)Image2D: video visible size is empty
and afterwards setting mute to false does not help.

Strangely, letting muted be false initially, it can be toggled using dat.GUI and achieve the desired effect.

I can work around the problem by creating a new pure video stream for the video element, but it would be better to understand why muted:true does not work.

````html

````

[Mugen87]

I am using one of the most recent versions of Chromium for Windows.

Do you have the same problem in other browser, too. For example in Firefox? If not, I suggest you close this issue and file a bug right here: https://bugs.chromium.org/p/chromium/issues/list

[EliasHasle]

I will test that later today. Thank you. :-)

[EliasHasle]

@Mugen87 It works in Firefox. In standard updated Chrome it fails under the same conditions as in the standalone Chromium installation I used, but without the WebGL warning.

I suppose we cannot rule out 100% that Three.js is involved (due to browser compatibility fallbacks etc.), unless I make a pure WebGL demo that replicates the behavior.

[Mugen87]

Please don't get me wrong but you should not have created the issue in the first place. Only if you can clearly demonstrate a three.js bug. So I think it's better to close the issue and only reopen if it is not a browser issue.

[WestLangley]

Please use the three.js forum for help requests. If you can demonstrate a three.js bug, you may reopen this.

[EliasHasle]

I confirmed the bug in pure WebGL, and filed a report here: https://bugs.chromium.org/p/chromium/issues/detail?id=898550

@WestLangley It wasn't exactly a help request (I found and documented workarounds), and @Mugen87 for all I knew at the time it could have been a three.js bug. I have spent a lot of time on my own replicating the bug in WebGL. Before that, there could be a chance one of you knew something. I guess, had I submitted a bug report to the Chromium team using only three.js code, they could have closed the bug and told me to go to you first. But thanks to both of you for responding to my report. :)

[mrdoob]

I confirmed the bug in pure WebGL, and filed a report here: https://bugs.chromium.org/p/chromium/issues/detail?id=898550

@EliasHasle thanks for doing that!

[WestLangley]

@EliasHasle Thanks.

I have encountered a strange problem, that may be a browser bug.
...for all I knew at the time it could have been a three.js bug

Please understand that we do not have the resources here to debug user's code (or the interest, for that matter), so we ask users to limit postings here to feature requests and demonstrated three.js bugs.

[jufa]

Followup in case anyone finds their way here: setting the video playhead to > 0 seemed to have resolved this in my application using an mp4 in a VideoTexture instance, i.e. video.currentTime = 1;

[EliasHasle]

@jufa Hm, I wonder whether that somehow applies to a live camera stream too...