"Continuum Mode" for video playback

[sghall]

"Continuum Mode" for video playback

[sghall]

Unfortunately you can't do that. The slider is based on breaking the domain into steps. To do what you want to do, you would need to round the values to fit your step.

[thunderkid]

I was afraid you'd say that. Rounding the values is precisely what breaks the compatibility with my video player setup. To fix it I've rounded as you suggest, and stuck in a test to see whether the player's actually playing to prevent a slider -> player backreaction. It basically seems to work, but it'll be more robust when I can incorporate in the #42 changes.

Also, I'm still getting a few console warnings about invalid values - my rounding is sometimes 1E-8 different from your internal one. To fix this, I'm wondering whether it would be a good idea either to allow a flag to turn off these warnings, or to expose your valueToStep or DiscreteScale so these could be used for external rounding. Reproducing DiscreteScale with its d3-array dependencies seems cumbersome just to avoid rounding errors.

[sghall]

Ok. Yeah, we can wait for that PR to come in. In the mean time I took a crack at doing a video player to understand the issue. I don't know much about the HTML 5 video tag but this make sense to me...

https://codesandbox.io/s/1z51zn6q23

Does that do what you want it to do?

[thunderkid]

Hi, yes that works. Thanks. But I'm a bit confused about your use of videoCursor. Seems you can achieve the same results without using videoCursor at all, and just setting values in onUpdate():

https://codesandbox.io/s/4jqk9ywwj9

Or am I missing something? It seems to give the same behavior as your version in both chrome and safari.

[sghall]

You're right! Yep, I had it continue to play while seeking before and then changed it, so that's not needed. This is much cleaner and mimics the controls on YouTube I think. Nice.

[thunderkid]

What do you think about the issues I mentioned above about providing a 'snap-to-nearest-rounding' option or exposing the internal rounding functions? In your solution you've reproduced it with Math.round but that might not reliably reproduce the internal calcs, depending on the user's choice of domain and precision.

[sghall]

Yeah, to me, because of the issues with floating point numbers the method I used there is very safe and you can dial up or down to get more precision. It will always work and the reality is there's only so many pixels on the screen so you can't get infinite precision in a slider. In the video I did a hundredth of a second and it seems pretty fluid to me.

Have any ideas on what to do? Or maybe an example that you couldn't do this way?

[thunderkid]

Right, in cases where the slider's being used as a timeslider for a few minutes in real time, then simply always setting the step size to a nice number like 0.01 seconds probably gives no rounding issues. But perhaps the user wants to set the stepsize to be domain/1000 so that he doesn't need to worry about very long or short intervals giving unusable numbers of steps on the slider. In this case you can start getting rounding errors if you externally use Math.round vs the internal DiscreteScale class.

I think the most conservative proposal would be to expose Slider.valueToStep as a function, then anyone having rounding issues can just apply this function rather than their own home-grown rounding. Alternatively (or even additionally), allow a silentSnap option to be passed to the slider, which just turns off the rounding console warnings. I'd actually argue that this should be the default, since other sliders don't seem to give these types of console warnings.

[sghall]

I see. Yeah, I like the idea of just being able to turn off warnings. You want to do a PR for exposing the valueToStep?

[sghall]

I think this one is done. Open it back up if not.