Wrong transcoding video's orientation and switching between microphone devices from setting is not working
Hi Ziggeo Team,
In our project, we are currently using react-ziggeo (version 4.4.3) for our react application. There are two issues that we cannot find any workaround.
The first one is with video orientation. When recording on Safari iOS, the recorded video will be transcoded to landscape orientation. I already checked it on the Ziggeo dashboard and found that the original stream is still normal but the transcoding one is in the landscape orientation and it seems this transcoding one is used to display the video.
We also try to upgrade the ziggeo-client-sdk inside react-ziggeo from the stable version (2.36.12) to the latest version (2.39.2). The issue with the video's orientation is fixed but there are some other issues like no video preview when uploading, verifying, processing if we skip picking a snapshot.
Another issue is about switching the microphone devices. We are able to switch between devices but it seems the recorder always uses the default one as the recorded video only has the sound from the default microphone.
The image below is how we implement react-ziggeo in our application.
Thank you.
-
Hi Hoang,
I believe that one part of this post relates to this one: https://support.ziggeo.com/hc/en-us/community/posts/4404690396307-Recorder-on-Safari-is-transcoding-video-to-landscape-The-thubmnail-of-playbacks-is-stretched-out-and-playbacks-are-rotated-to-landscape
I am happy to hear that it is no longer happening for you with r39.
there are some other issues like no video preview when uploading, verifying, processing if we skip picking a snapshot.
Preview is actually running when available. What that means is that we will not be able to show the preview every time, when it is, we will.
In r39 we have added a check for the preview to make sure the upload does not stop where in some cases in earlier revisions the uploading could stop if preview was not available.
It is possible that for some reason it affects the preview from being shown in some cases. Will check and let you know.
Another issue is about switching the microphone devices. We are able to switch between devices but it seems the recorder always uses the default one as the recorded video only has the sound from the default microphone.
Are you trying to switch the recorder before recording starts or during recording? If pre-recording, that should work however it depends, in some browsers such as Firefox there are issues when switching the mic / camera and it has to be done in a specific manner. This is why we do not currently have the support for outside controls.
PS: flashincognitosupport is no longer needed since Adobe dropped support for Flash and we have as well in our never revisions. You can see more about it here: https://ziggeo.com/blog/no-flash-should-you-worry/
0 -
Hi Bane,
Thank you for your reply.
Although the orientation was fixed in r39, we don't want to use that solution because we will lose the ability to always keep the package up-to-date as we have to upgrade react-ziggeo package manually. Besides, not only about the video preview but we also experience new issues with r39. For example, if verifying is failed (due to no internet connection), it will not automatically retry (r36 does) or show the user an option to retry. Please help me to check it too.
About switching the microphone, we do it before recording. We already did some tests with Chrome (the latest version), but it is not working at all. We can confirm that this issue exists because we even test the recorder at ziggeo.com on several machines and still the same result. We even try to do it with native javascript as we changing the srcObject of the video tag inside ziggeo recorder with the stream combined from microphone and camera but no luck. The normal video tag works just fine but the video tag inside ziggeo recorder won't work anyway. The only way we can make the second microphone device work is to disable the first one in Windows sound setting.
Please let me know if you need more insight. We hope to solve these issues soon.0 -
Hi Hoang,
Sorry for the wait.
In regards to the verified event, I have just reported it to my colleagues working on this to check out and see what might be happening.
Now since there are 2 different things that could happen, I do wish to get more details from you.
We have the upload protection where if you are uploading the video and the connection breaks, it will continue to upload it. On the other hand when verifying video fails we show the error and allow the end user to click on the error to try to re-upload it.
Can you please let me know more precisely when the issue with uploading not going through happens?
In regards to not using r39, that makes sense. With that said, I do have to say that we rarely back-port some feature. In most cases it would involve a lot of work to do this since it would require some other things from the updates as well.
We do this only for security reasons. We would at that time either back-port some security update or if that is not possible, we would increase our stable revision to some other.
As such it might be a while before the updates in r39 become available through normal "stable" revision.
In terms of switching the controls. This is actually a bit more complex. This is also the reason why we do not yet have support for own controls to be used for selecting the microphone and camera.
* Something we are working on to provide.
Until this is made possible, it would only be possible to do it in some sort of "hacky" way which might not always work as you expect.
What you could try is to use something like so:
recorder.set(“audioinput”, selectedMicrophoneId);
recorder.activate();* The above code (including the .activate()) is aimed after the recorder was already shown and activated. If removed, it would likely not work fine. This is not to say that might work as is, just saying that this is something that could work.
Hope that this helps.
0 -
Hi Bane,
The uploading process is working just fine and the end-user can retry if it is failed, we have no problem with it. What I'm trying to say is, in the latest version, if the internet connection is lost after being uploaded successfully, the verifying process will be failed but it does not show verifying failed message, it keeps stuck at verifying, no option to retry or automatically retry (I have checked and after the verifying request failed, no request is followed).
With regard to the switching microphone issue, I just want to clarify that we are using the built-in microphone switching of Ziggeo recorder (the image below) and it does work at all as it always uses the default microphone. As I understand, you are saying the microphone switching might not work with outside control, so what about this built-in control?
Please help me to confirm if this built-in switching is functional or not.
Besides, we will try to do what you suggest to see if it can be a workaround.
Thank you.
0 -
Hi Hoang,
The built in controls should work just fine. We will do some tests to see if we can recreate this behavior. I see that most of the items you have are tagged with bluetooth. Is it switching to non bluetooth ones?
While for us it should not make any difference, I personally have USB based cameras and mics and regardless if it is one or more it always worked fine and want to see if that might be the possible path to explore.
In terms of verified event and re-uploading our colleagues looked into it and found 2 different cases when it could fail. Both are internal and are being worked on to prevent the same in future.
0 -
Hi Hoang,
My colleagues have been looking into this and it seems that for a very long time Chrome had an issue with Bluetooth devices. If you check the following few reports you can see it is for several years and still marked as "Wontfix".
https://bugs.chromium.org/p/webrtc/issues/detail?id=739
https://appuals.com/chrome-bluetooth-audio-issues/
It is also good to mention that the Web API for bluetooth is still not fully available: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API#browser_compatibility so it is not as easy to utilize the Bluetooth API directly. That said, I would personally not expect it to talk with the camera in the same way as we can through browser, however as that API is updated so will the browser's built in integration with Bluetooth.
In our tests we could not recreate the same for non bluetooth devices which seemed to work just fine. Is there a chance you can test with non-bluetooth cameras and mics?
0 -
Hi Bane,
I have discussed this with my team and we have several questions.- First of all, our main concern is how we can fix the wrong video orientation on safari iOS without additional issues (the latest version is still buggy). Could you please help us to find a solution (maybe a hotfix version) that will fix the orientation problem and does not introduce any new issue? If the only solution is to wait for the next stable version, then when can we expect it to be released? We're kind of hurry now.
- About the issue with Bluetooth devices, we can see that the Bluetooth devices still work on Google Meet and even an example about WebRTC here. Could you please let us know why it works in those sites but not working with the Ziggeo recorder?
- The last thing is we've experienced on some old devices (eg. iPhone 6) the below error when trying to open the recorder. Could you please let us know why it happens and is there any way we can detect the issue so that we can customize the UI to meet our use case? Please note that we do use SSL for our website.
0 -
Hi Hoang,
First, let me apologize for the delay in reply. I know you have wrote to us in the support tickets since your post here, however I still want to make sure we provide you with some details here as well just in case anything was missed.
The cause of delay is that unfortunately the content passed without being approved. This is a type of oversight that I am not very proud of and definitely something that will be improved going forward.
What happened: We are using Zendesk Community system and we can either allow everything (including spam) or block everything and with blocking, we relayed on single email notification that can easily get and was missed.
We have just made some changes to how the notifications will be handled internally so that entire support team going forward gets an email about this, so we can moderate and reply much faster.
With that said, thank you for your understanding and I will try to answer your questions to the best I can.
1. Safari and wrong orientation
In the latest revision of r39 we have sorted out the change made by Safari team, and your recording should now be working properly (after upgrade to r39).
2. Bluetooth and recording with Ziggeo
I apologize if I made it seem as if Bluetooth will always fail. It will not. There are however many cases where it was reported that various browsers had issues with Bluetooth connections.
In our own internal tests, everything seems to be working fine, however we recognize that any of the mentioned and non mentioned Bluetooth issues between browser and Bluetooth device would impact our system.
What we can suggest is checking with different devices to see if you can see any difference. From our point of view, we are asking browser to provide us with the data and we are not concerned nor looking what technology the device is using.
Once Bluetooth API in browsers is better, we will likely have detection and then connect to the Bluetooth devices through it instead. This of course remains to be seen, depending if that would provide us with better UX.
Why it would work on some other systems is something I would not really know. The other codes on the page could in some way impact it (for example page that has a lot of small calls happening entire time vs page that has no changes). That too of course would completely depend on the browser.
3. Older device support
Older devices unfortunately do not have technology available that the new ones have. Because of this, they can not get the same type of support and instead would report back the error.
iPhone 6 and iPhone 7 should work the same, as long as the iOS version installed supports any of the WebRTC versions (talking about Safari support for it).
The same error should no longer be shown as we have removed the support for Flash in newer releases.
You can however use any of our error events to know that error has occurred:
https://ziggeo.com/docs/sdks/javascript/browser-interaction/events
Hope this helps and thank you again for your understanding.
0
Please sign in to leave a comment.
Comments
8 comments