- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jan 2017 09:56:36 +0000
- To: public-media-capture-logs@w3.org
What I don't understand is how this would help with c). It wouldn't smooth out the bursts. Yes, if you look at timestamps in the produced video track they would have a perfect, fixed rate. But the perceived frame rate would be much lower during a burst (e.g., 120 fps turned to 30 fps) than during normal operation (e.g., 60 fps turned to 30 fps), and IMHO that is not (always, perhaps) something the application would want. If you think of a function that takes `wallclockTimestamp` as input and returns the timestamp that should be used in the muxer it would be up to the application to decide how to handle high framerate, low framerate, variations in framerate, bursts, and so on. Re-using it in a larger context of offline recording is perhaps a bit naive, but I like the idea of giving power to the application to handle use cases we don't understand yet. -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/114#issuecomment-275065618 using your GitHub account
Received on Wednesday, 25 January 2017 09:56:42 UTC