Twilio-video.js: track.disable() Freeze Frame on Remote Participant

[HeyWrecker]

Hello,

Not so much a bug as a quirky behavior that my QA guy found regarding "pausing" video via:

video_tracks.forEach(function(publication) {
    publication.track.disable();
 });

It appears that in testing, when Device A pauses their video their local preview goes to black, as expected. However, their stream on Device B freezes on the last frame before the track was paused (ie. disabled) and does not go to black as one would expect. I reviewed the sample code for localmediacontrols in the video-quickstart-js-master repo, cloned it and ran it locally as well. It appears that in that example, the video track is actually removed and then reattached via the following code if I read through everything correctly even though there is also a function performs a publication.track.enable() and publication.track.disable():

  roomP2.on('trackSubscribed', (track => {
    if (track.isEnabled) {
      if (track.kind === 'audio') {
        audioPreview.appendChild(track.attach());
      } else{
        videoPreview.appendChild(track.attach());
      }
    }

    participantMutedOrUnmutedMedia(roomP2, track => {
      track.detach().forEach(element => {
        element.remove();
      });
    }, track => {
        if (track.kind === 'audio') {
          audioPreview.appendChild(track.attach());
        }
        if (track.kind === 'video') {
          videoPreview.appendChild(track.attach());
        }
      });
  }));

I guess my question is- is track.disable() for video supposed to go to black on the remote participant or is it supposed to leave the last frame? It is correctly stopping and starting the video when toggled between the two functions and I inspected the data object and the isEnabled flag is updated correctly.

[manjeshbhargav]

Hi @HeyWrecker ,

Thanks for writing in with your question. Judging by your description, I'm guessing you are using Group Rooms? Please confirm. If so, this is expected behavior because the media server stops sending bytes for disabled VideoTracks rather than sending black frames. That is the reason you see the frozen most recently received frame.

That is why, in the quickstart example you have shared here, we recommend listening to the "disabled" and "enabled" events on the RemoteVideoTrack to hide or show the video element respectively. When the video element is hidden, you can show some type of avatar icon.

Please let me know if this clarifies things for you. I will close this issue since I've answered your question, but we can continue our discussion here if you need more clarification.

Thanks,

Manjesh Malavalli
JSDK Team

[HeyWrecker]

Hi Manjesh,

Thank you very much for taking the time to write out a easy to understand response. Yes, that is exactly my situation with group rooms. Your answer has been very helpful!

Best,
Rick Zawadzki