microsoft / MixedReality-WebRTC

MixedReality-WebRTC is a collection of components to help mixed reality app developers integrate audio and video real-time communication into their application and improve their collaborative experience
https://microsoft.github.io/MixedReality-WebRTC/
MIT License
907 stars 280 forks source link

"SceneVideoSender" camera with "TargetTexture" assigned flips remote output #356

Open CabbageWarrior opened 4 years ago

CabbageWarrior commented 4 years ago

Describe the bug If you use a RenderTexture as a TargetTexture for the Camera connected to the SceneVideoSender component, the remote client will receive an upside-down output in its RemoteVideoPlayer. My target is to give to the camera a fixed size by using a RenderTexture as a size reference.

To Reproduce Steps to reproduce the behavior:

  1. Open the VideoChatDemo scene.
  2. Assign the RemoteVideoPlayer to the Transceiver 1 (the same as the SceneVideoSource one).
  3. Create a new RenderTexture in Assets folder.
  4. Select the Camera assigned to the SceneVideoSource component in the scene.
  5. Add the RenderTexture to the Camera in the Target Texture field.
  6. Build the solution (UWP or Standalone).
  7. Start the built solution.
  8. In Editor, select the NodeDssSignaler component and switch Local and Remote Peer IDs.
  9. Press Play in Unity Editor.
  10. Create the Offer.
  11. See error.

You can test it at runtime by adding and removing the RenderTexture to the camera in UnityEditor. The output image in the RemoteMediaPlayer will be correct (but with sender's viewport size) if no RenderTexture is assigned to the Camera, and flipped (but with RenderTexture size) otherwise.

Expected behavior I expect the output image to have a correct Y orientation regardless of the assignment of the RenderTexture to the camera.

SDP messages (No new offer is generated when the Camera's TargetTexture changes.)

Environment Tests made with these configs:

Additional context I know I can simply flip the Y scale of my RemoteVideoPlayer for Senders I know that have a RenderTexture assigned to their cameras, but so I can't decide to switch the Local Source or the Remote Receiver in a Transceiver without risk of issues if I want to reuse the same Transceiver and avoid unused duplicates.

I hope I was clear in my explanation, but please feel free to ask if you need more details or clarifications!

Thanks a lot for your time! Riccardo

djee-ms commented 4 years ago

Thanks for the feedback. We added some switch in the shader to be able to swap, and normally we also use the UNITY_UV_STARTS_AT_TOP to let Unity automatically flip vertically when needed, but apparently there's still a bug.

djee-ms commented 4 years ago

Unity shenanigans:

This difference tends not to have any effect on your project, other than when rendering into a Render Texture. When rendering into a Texture on a Direct3D-like platform, Unity internally flips rendering upside down. This makes the conventions match between platforms, with the OpenGL-like platform convention the standard.

CabbageWarrior commented 4 years ago

Perfect 👍 Thanks for your reply. So, I think that what I did at the moment (I flipped the renderers in Video Players too, for players that get that type of input) is the correct temporary workaround.

Now I have video players that can switch the referenced video source, so in case of different input types (webcam source, virtual camera with or without an assigned render texture) I'll have to check how to share a value/parameter about the necessity to flip the receiving player or not, in order to flip my video players dynamically. I think it's possible to share this extra info: I only need to discover how 💪

azixMcAze commented 3 years ago

I am hitting the same issue but I do not want to flip the texture when it is displayed because I a streaming the scene to a web browser.

The rendering can be flipped by the Blit command, by using new scale and offset parameter values:

Vector2 srcScale = new Vector2(1f, -1f);
Vector2 srcOffset = new Vector2(0f, 1f);

The difficulty is now to decide if the texture should be flipped. I am not sur if checking SourceCamera.targetTexture and SystemInfo.graphicsDeviceType is sufficient.

The doc says that it is flipped on D3D-like platforms, but I tried on android and it is also flipped.