- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Oct 2020 07:16:00 +0000
- To: public-webrtc-logs@w3.org
Consider the concrete use case of capturing a primary source document, in this case an historic document [Denying Free Blacks the Right to Vote (1724, 1735)](https://www.encyclopediavirginia.org/Denying_Free_Blacks_the_Right_to_Vote_1724_1735), and adding an audio track that reads the document, to reproduce the primary resource, without addition or subtraction. Use technologies shipped with the browser, `getUserMedia()`, `getDisplayMedia()`, `speechSynthesis.speak()` to provide audio reading of the tet displayed on screen. Simple enough. The technology exists to achieve the requirement. Do the API's exist and have the capabilities to work together within the single browser to produce a clinical reproducation of the primary resource? Will leave it to the reader to explore such a project for themselves to determine the simplicity in the field. After multiple attempts to record the document with audio track, found that Chromium was firing `mute` and `unmute` events at "Tab" and "Application" capture selections when no user action was taking place on the page. Recall that the requirement is to read the document as an audio track with the document being captured. That means to synchronize the video with the audio the document must remain displayed until that page of the document is read. That ultimately resulted in `MediaRecorder` not producing correct output. For this use case including animation in the document to satisfy Chromium muting the track when no activity on renderer is spurrious. The requirement is to reproduce primary source documents precisely by audio and visual tracks as a single media, not to create activity on the page that is not remotely related to reading the document by means of sight and sound. The track from `getDisplayMedia()` at "Entire screen" capture does not toggle `mute` and `unmute` events. The user must expect the capture of application and tab to be captured in same algorithm steps as entire screen capture; same frame rate, until instructed to do otherwise. Downstream what happens what a `MediaStreamTrack` communicated via `RTCPeerConnection` mutes and unmutes every N seconds, even when the use case is to display N frames necessary to complete reading a page of a document (scientific; historic; academic; etc.)? Toggling mute and unmute of `MediaStreamTrack` at `getDisplayMedia()` eliminates the use case of audio books, narration. The developer would need to create some form of animation on the page, which is extra, unnecessary code. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/141#issuecomment-706015175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 October 2020 07:16:06 UTC