- From: Christoph Guttandin via GitHub <sysbot+gh@w3.org>
- Date: Sun, 12 Mar 2023 16:21:52 +0000
- To: public-webtiming@w3.org
I did make an effort to implement the media element synchronization as well over [here](https://github.com/chrisguttandin/timingsrc). It holds this info internally as well. At least as accurate as it can be when using the media element. However I don't really know how to expose it. I hesitated so far to add a "sync" event or something similar since that would imply that there is a universally valid definition of something being in-sync or not. I guess it means different things for different applications and use cases. On the other hand emitting an event every time the `playbackRate` or `currentTime` of the media element gets tweaked would be very noisy. Therefore I think a getter would be best. It could be called at whatever rate necessary. It could expose the actual offset and each application could decide how to interpret that value. But I have no idea where to put it. Extending the `MediaElement` with another property/method is maybe not the best idea. Similarly adding it to the `TimingObject` isn't possible either because it has no idea about the synchronized `MediaElement`. A different approach would be to use the `bufferedamountlow` event on the `RTCDataChannel` as a source of inspiration here. It can be configured by setting the `bufferedAmountLowThreshold`. Additionally there is also a `bufferedAmount` property to read the current value. Copying the exact same behavior would mean to add an event and two properties to the `MediaElement` and any other object which accepts a `timingsrc`. I'm not sure if that's a good idea. -- GitHub Notification of comment by chrisguttandin Please view or discuss this issue at https://github.com/webtiming/timingobject/issues/33#issuecomment-1465240315 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 12 March 2023 16:21:53 UTC