[Proposal] Add getWallClockOffset API
#1601
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
from
199f964 to
6f029dc
Compare
|
Automated performance checks have been performed on commit Tests results✅ Tests have passed. Performance tests 1st run outputNo significative change in performance for tests:
If you want to skip performance checks for latter commits, add the |
peaBerberian
force-pushed
the
dev
branch
2 times, most recently
from
00fc806 to
b7216b4
Compare
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
2 times, most recently
from
03842b9 to
d45a3f2
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
from
d45a3f2 to
621fb0a
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
from
621fb0a to
d8a4701
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
Comment on lines
+1622
to
+1664
| getWallClockOffset(): number { | ||
| if (this.videoElement === null) { | ||
| return 0; | ||
| } | ||
| if (this._priv_contentInfos === null) { | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
Can you add a documentation for this new method?
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
2 times, most recently
from
7c26dd6 to
8cd4088
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
I was lately working on an application relying on the RxPlayer at Canal+, and
trying to see how our upcoming thumbnail API could be integrated in their
projects.
I found out that this application relied only on `getWallClockTime` for storing
the current playback position.
The value returned by this method is basically the current position
offseted so it corresponds to the unix timestamp at which the corresponding
media data was intended to be broadcasted.
In other words, doing `new Date(wallClockTime * 1000)` will translate that
position into the corresponding date, whereas our `getPosition` API,
returns a more arbitrary timestamp without special meaning, that we will
call here the "media position" (it is the actual position advertised by
the HTML video element in the page).
Applications like to use the `wallClockTime` for live contents as this
allows to display a seeking bar with the date in an e.g.
`hours:minutes:seconds` format which is much more useful to a final user
than a timestamp without any special meaning.
We even also rely on `wallClockTime` ourselves on the demo page.
However, most other RxPlayer API rely on the media position instead.
For example, `getAvailablePeriods`, `getMinimumPosition`, `getLiveEdge`
and future thumbnail API all will provide timestamp in the "meaningless"
media position format.
---
Converting from the `wallClockTime` to the "media position" and
vice-versa was awkward before, you basically had to re-call
`player.getWallClockTime() - player.getPosition()` to obtain the
difference and thus to convert the `wallClockTime` you're using in your
application into a media position you can use more easily with the
RxPlayer API.
Instead, I propose here to add the `player.getWallClockOffset()` API,
which returns that difference in a more explicit way.
You can then do something like:
```js
function compareWithMaximumPosition(wallClockTime) {
const wallClockOffset = rxPlayer.getWallClockOffset();
const currentPosition = wallClockTime - wallClockOffset;
const maximumPosition = rxPlayer.getMaximumPosition();
const deltaFromMax = maximumPosition - currentPosition;
console.log(
`We are ${deltaFromMax} seconds behind the maximum seekable position`,
);
}
```
Which makes more sense and seems feels more stable than randomly
re-obtaining the same offset by doing:
```js
const wallClockOffset = player.getWallClockTime() - player.getPosition();
```
Note that we could have added a `rxPlayer.toMediaPosition(wallClockTime)`
method instead, which may be even more easily discoverable, but I found
`getWallClockOffset` more useful and still approachable.
peaBerberian
force-pushed
the
feat/getwallclockoffset
branch
from
8cd4088 to
45766be
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
Florent-Bouisset
approved these changes
Aug 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was lately working on an application relying on the RxPlayer at Canal+, and trying to see how our upcoming thumbnail API ( #1496 ) could be integrated in their projects.
I found out that this application relied only on
getWallClockTimefor storing the current playback position.The value returned by this method is basically the current position offseted so it corresponds to the unix timestamp at which the corresponding media data was intended to be broadcasted.
In other words, doing
new Date(wallClockTime * 1000)will translate that position into the corresponding date, whereas ourgetPositionAPI, returns a more arbitrary timestamp without special meaning, that we will call here the "media position" (it is the actual position advertised by the HTML video element in the page).Applications like to use the
wallClockTimefor live contents as this allows to display a seeking bar with the date in an e.g.hours:minutes:secondsformat which is much more useful to a final user than a timestamp without any special meaning.We even also rely on
wallClockTimeourselves on the demo page.However, most other RxPlayer API rely on the media position instead. For example,
getAvailablePeriods,getMinimumPosition,getLiveEdgeand future thumbnail API all will provide timestamp in the "meaningless" media position format.Converting from the
wallClockTimeto the "media position" and vice-versa was awkward before, you basically had to re-callplayer.getWallClockTime() - player.getPosition()to obtain the difference and thus to convert thewallClockTimeyou're using in your application into a media position you can use more easily with the RxPlayer API.Instead, I propose here to add the
player.getWallClockOffset()API, which returns that difference in a more explicit way.You can then do something like:
Which makes more sense and seems feels more stable than randomly re-obtaining the same offset by doing:
Note that we could have added a
rxPlayer.toMediaPosition(wallClockTime)method instead, which may be even more easily discoverable, but I foundgetWallClockOffsetmore useful and still approachable.