Skip to main content

Wrong transcoding video's orientation and switching between microphone devices from setting is not working



  • Bane

    Hi Hoang,

    I believe that one part of this post relates to this one:

    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:


  • Hoang Vo

    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 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.

  • Bane

    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);

    * 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.

  • Hoang Vo

    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.

  • Bane

    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.

  • Bane

    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".

    It is also good to mention that the Web API for bluetooth is still not fully available: 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?


Please sign in to leave a comment.