- From: Miguel Casas-Sanchez via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jan 2017 02:16:15 +0000
- To: public-media-capture-logs@w3.org
The use case here would be to force a webm timestamp that is not the wall clock time, which is what MediaRecorder uses now (at least in Chrome). Even if the input to MR came redirected via a <canvas>, this restriction would not be lifted, for example: a) we have an input camera capturing at, e.g., 120fps, but want the recording at 30 fps as an slow motion output. b) we have an input camera capturing at e.g. 0.5fps but would like the recording at 30 fps as an example of time lapse. c) we have a bursty input, e.g. a tab capture, and would like to smooth out the bursts. Surely we could leave this as a post processing step, by retimestamping the produced multiplexed container, or provide a Javascript callback to query for `nextTimestamp()`, but the current option proposal seems to be to cover enough ground with a tiny addition to be worthwhile. wdyt? Alternatively, @Pehrsons could you elaborate on your proposal? -- GitHub Notification of comment by miguelao Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/114#issuecomment-275000687 using your GitHub account
Received on Wednesday, 25 January 2017 02:16:21 UTC