User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36

Steps to reproduce:

1. Have a WebRTC test tool with features that demonstrate replaceTrack method
   (For example, https://rtcmulticonnection.herokuapp.com/demos/replaceTrack.html)
2. Connect Firefox 65 to Safari 12 (Safari 12 does not support VP8, so H264 is selected)
3. Test replaceTrack from Firefox 65, and observe the received video from Safari.

Actual results:

video received from Safari was cropped unexpectedly.

Expected results:

video received from Safari shall not be modified.

When I click replaceTrack on Firefox I get asked to share my screen. After that the screen sharing appears in the list of video. But the aspect ratios of all video appear to be fine.

Does one of the video need to be in full screen mode to make this visible?

I can't reproduce with the steps as listed.

Could you provide additional steps on what to do? Including what to open on Safari, the room to join, which button to click on, then what to do on Firefox.

Thank you

I have reproduced this issue with the following steps:

1. Connect to https://rtcmulticonnection.herokuapp.com/demos/replaceTrack.html from Firefox 65 on Windows 7
   1a. Click "Open Room" and allow camera/microphone access.
   1b. See that local loopback is shown.
   1c. Copy link from the "Hash URL" and send to a Mac OSX with Safari 12.
2. Open the link from Safari 12 on Mac OSX.
   2a. Allow camera/microphone access.
   2b. See that the local and remote video is shown.
3. Go back to the Firefox on Windows.
   3a. See that the local and remote video is shown.
   3b. Note the image of the remote video.
   3c. Click "replaceTrack"
   3d. Select a window to share and allow it.
   3e. Note that the image of the remote video is now cropped to the upper left corner of what it was before.

NOTES: This seems to be most prevalent when using H.264 video streams. I think that is the reason for connected to Safari. Other H.264 streams seem to produce similar results when the replaceTrack operation is used.

(In reply to Jean-Yves Avenard [:jya] from comment #2)

I can't reproduce with the steps as listed.

Could you provide additional steps on what to do? Including what to open on Safari, the room to join, which button to click on, then what to do on Firefox.

Thank you

Hello Jean,

Were you able to reproduce this issue per JPorter's listed steps?

Thanks

(In reply to Nils Ohlmeier [:drno] from comment #1)

When I click replaceTrack on Firefox I get asked to share my screen. After that the screen sharing appears in the list of video. But the aspect ratios of all video appear to be fine.

Does one of the video need to be in full screen mode to make this visible?

Hi Nils,

Thanks for testing that part. This issue, as well as this feature, would require two parties join together. So, please try follow JPorter's listed steps above. Note that the issue would not be observed if using Firefox-Firefox or Firefox-Chrome, because they were prefer VP8. However, this cropping issue will appear when the media negotiated in H264. We have other test tool to do H264 call as well. The problem is consistent. Please let me know if you would need more information.

Thanks

(In reply to JPorter from comment #3)

I have reproduced this issue with the following steps:

1. Connect to https://rtcmulticonnection.herokuapp.com/demos/replaceTrack.html from Firefox 65 on Windows 7
   1a. Click "Open Room" and allow camera/microphone access.
   1b. See that local loopback is shown.
   1c. Copy link from the "Hash URL" and send to a Mac OSX with Safari 12.
2. Open the link from Safari 12 on Mac OSX.
   2a. Allow camera/microphone access.
   2b. See that the local and remote video is shown.
3. Go back to the Firefox on Windows.
   3a. See that the local and remote video is shown.
   3b. Note the image of the remote video.
   3c. Click "replaceTrack"
   3d. Select a window to share and allow it.
   3e. Note that the image of the remote video is now cropped to the upper left corner of what it was before.

NOTES: This seems to be most prevalent when using H.264 video streams. I think that is the reason for connected to Safari. Other H.264 streams seem to produce similar results when the replaceTrack operation is used.

Jean-Yves, JPorter added steps, but forgot to NI you.

Can you still reproduce with Firefox Nightly 67?

Fairly sure this is a dup of bug 1525230

Issue resolved in Firefox Nightly 67. Thank you!