Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow calling track.restart() on local tracks created using constructors #2045

Open
jpodwys opened this issue Mar 11, 2024 · 5 comments
Open

Comments

@jpodwys
Copy link

jpodwys commented Mar 11, 2024

Twilio employee Donal Toomey requested that I create this issue.

Today, calling const videoTrack = new LocalVideoTrack(mediaStreamTrack) results in being unable to call videoTrack.restart(). Today, we're bypassing this by passing the following into the constructor's options object.

// @ts-ignore
isCreatedByCreateLocalTracks: true,

We'd like to request one of the following two solutions

  1. Allow calling track.restart() on local tracks created via constructors (this is our preferred solution)
  2. Make isCreatedByCreateLocalTracks public (this is a reasonable fallback solution)
@jpodwys
Copy link
Author

jpodwys commented Jun 26, 2024

@donaltoomey is there any update here?

@luisrivas
Copy link
Collaborator

Hi @jpodwys, could you please elaborate on your use cases? We only support restarting local media tracks because we know how to reacquire them using getUserMedia(). For other tracks, we cannot determine how they were created.

@luisrivas luisrivas added the needs more information Issues that require more information to resolve, such as Room SIDs, SDK versions, etc. label Dec 13, 2024
@jpodwys
Copy link
Author

jpodwys commented Dec 13, 2024

Hi, thank you for the response!

We only call track.restart(constraints) when switching devices. With that in mind, we always provide constraints. Perhaps a reasonable update would be to allow local tracks created via constructors to call restart so long as constraints are provided. If, however, constraints is absent, throw an error.

@luisrivas
Copy link
Collaborator

Thank you for the feedback. We will review your comments and get back to you.

Out of curiosity, why do you prefer acquiring the track and calling the new LocalVideoTrack instead of using the createLocalTracks method?

@luisrivas luisrivas removed the needs more information Issues that require more information to resolve, such as Room SIDs, SDK versions, etc. label Dec 13, 2024
@jpodwys
Copy link
Author

jpodwys commented Dec 13, 2024

Great question!
We support local and remote control of PTZ cameras and we use the track.name field to inform remote participants that a track is of type PTZ. However, even when we provide PTZ in our constraints object, we can't know for certain whether a MediaStreamTrack supports PTZ until after we've acquired it.

Manually acquiring the track allows us to determine whether it's a PTZ-capable track prior to creating a LocalVideoTrack. This is important because the LocalVideoTrack constructor requires a name property.

If we used createLocalTracks, we would have to provide the track's name before acquiring the underlying MediaStreamTrack and therefore before knowing whether the track supports PTZ.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants