I think you're correct when you place the origin at the center. Basically, you're setting a baseline value from which you can go up and/or down.
However, the baseline is merely symbolic, since you can say it is
1 (and ... 1 what?),
normal, as other answers say. Therefore, this is not a real measure, but a reference for relative magnitudes.
On this basis, the important thing is the audience you're targeting. For example, for a common user (as I would be), knowing that the video will be 3 times faster or slower will surely be enough.
However, for more sophisticated users, it's going to be confusing. What is the baseline? 24FPS? 30 FPS? any FPS that the video player identifies? And on top of that we have to add fractional magnitudes:
7.8x * (x FPS) = ????? .
The problem is clear: the user will surely know what speed she needs, because she's used to that. But doing it this way means adding a great level of friction.
Then, again: if your application is for ordinary users, the use of magnitudes relative to a symbolic baseline may not be a problem (however, you must test it). For specialized users, it is not a good idea, because it will be very imprecise and the user will have to take out accounts.
For all this, I think my recommendation would be that you first define who your user base is (I suppose you already did it, of course!) And then apply the best option, that of common users or more sophisticated users.
Regarding the choice of common users, you should also consider how to represent the direction. If 0 does not make sense as a baseline and you use 1, it will bring other considerations to the table, see below:
IN the first case, baseline is
1. So, 2x should be... half of the time? Quick math tells me that
1*-2x= -1 .
Also... how do you translate -2x to 0.5 in users mind? It's really counterintuitive (let alone something as -7.8x. I'd spend hours trying to figure what speed is that!)
So you can see second case: it start from
1 on load, in the middle of the screen. But the line starts at
0.1, 0.2, 0.3 and so on. This is a very clear method:
0 is no speed, 0.1 is 1/10 a, 0.2 is 2/10 and so on. But well, having
1/16 would make it really confusing, not to mention 0.5 is not the negative value of 2x which would be its counterpart in a number line. However, if you're OK with going from 0 to 1 and then to 2, this would be perfect.... but I guess you need to go to 16x rather than 2x. You could use a logarithmic scale for faster than baseline measures, but again: you'll need to test this out.
Getting to a solution
In summary, most representations are inaccurate or confusing. Then, a proposal that could solve all these conflicts of visualization of the information for both common and specialized users would be the use of absolute scales of frame rate per second (FPS).
This way, your app could read the FPS of the video source and define the baseline from there, then it could offer different FPS values. In my opinion, better than using a slider is to use a series of preset values, but if you want to use a slider, no problem, it would work too. Of course, this is in the case that users can upload videos, otherwise you can add the base line artificially with the frame rate that your app uses. See examples below:
Protools + Video