- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Oct 2020 12:28:28 +0000
- To: public-webrtc-logs@w3.org
> > > These values may only be available asynchronously as encoders may leave in a different thread/process. > > > > > > If needed I'm sure that could be worked around in the spirit of [w3ctag/design-reviews#439](https://github.com/w3ctag/design-reviews/issues/439) > > I do not really see how autoplay sync vs. async relates to bit rate values. > In general, I think we like async getters for things attached to OS resources. > Can you clarify this? In a case of sync vs async w3c seems to prefer sync if at all feasible. I am not sure I see how deciding a default bitrate is an async getter attached to an OS resource. Are there hardware encoders one may not configure the bitrate of? > > Note that mimeType is only set async because of the changes for passthrough codecs > > Then the intent of this part of the spec is not clear to me at all and is worth clarifying if that is really the goal. See https://github.com/w3c/mediacapture-record/pull/190 > As the spec currently stands, it seems that UA is free to provide more accurate information whether the track is a capture track or a remote track. This might be handy to developers. > > Also, is there anybody implementing passthrough codecs? See https://crbug.com/1013590 -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/205#issuecomment-712122677 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 12:28:30 UTC