- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2019 19:36:23 +0000
- To: public-webrtc-logs@w3.org
@Pehrsons > is what asynchronous to setting enabled? At `pause` event of `<video>` element, where `ReadableStream` `pull()` method has `if` condition which checks if the current `MediaStreamTrack` of kind `"video"` is `enabled`. > Media flow turning video black/non-black or audio silent/audible? In this case a video track captured from an `HTMLVideoElement`. The initial motivation was to use `mute` event to pause `MediaRecorder`, set next `MediaStreamTrack`s (specifically derived from `captureStream()`) to be recorded, which given your feedback, is not appropriate; neither is `ended`. `pause` event of `<video>` is the one event from which other events related to processing (recording) multiple `MediaStreamTrack`s at the same `<video>` element where the `src` is changed (without using WebRTC). Which is ok to be aware of. > For a bug in Chromium, ask the Chromium folks what is the best workaround. (Resolved the issue by setting the `ReadableStreamDefaultController` as a property of a `Map` outside of `pull()` then executing `close()` outside of `pull()`. Am still interested in becoming aware of the exact expected control flow between async functions, `DOM` events (`addtrack` of `MediaStream` returned from `captureStream()`; `pause` event of `HTMLVideoElement` where the captured `MediaStreamTrack` media source is derived from, where the `src` of the `HTMLVideoElement` is subsequently changed, which fires `addtrack` again) as to why two versions of the code output different (and variable; perhaps related to garbage collection, "event loop" (`DOM` events), task queues, microtasks (`async/await`; `Promise`?) results, which have asked Chromium developers about) -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-fromelement/issues/80#issuecomment-499224998 using your GitHub account
Received on Wednesday, 5 June 2019 19:36:25 UTC