Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video orientation settings (front & back camera) #72

Closed
Aissa-H opened this issue Oct 24, 2017 · 6 comments
Closed

Video orientation settings (front & back camera) #72

Aissa-H opened this issue Oct 24, 2017 · 6 comments

Comments

@Aissa-H
Copy link

Aissa-H commented Oct 24, 2017

Hello !

Thanks for this great lib, working like a charm!

I'm currently using CameraView in my app for taking several video sequences. At the end of the user flow, I'm merging all these sequences to create one video. For this purpose, we use mp4Parser, another great lib!

The problem I have now is that I have my sequences from the front camera upside down after the merge. I assume that it's an orientation issue:

  • front camera sequence has an orientation of 270
  • back camera sequence has an orientation of 90

The issue is described here

So the merge doesn't take into consideration this difference of orientation and set to the front camera sequences an orientation of 90 instead of 270 that's why they are upside down in the result.

Is it possible to have a mode/methods where we could have access to the metadata of the video created by CameraView or eventually to have access to the mediaRecorder? My idea would be to put the same orientation to both side sequences in order to avoid the upside down result after the merge.

Thank you in advance!

@natario1
Copy link
Owner

Thanks! It could be possible from our side to provide the orientation, yes. But it is also already provided in the mp4 file. We don't apply rotations to the actual video, we just add the orientation tag.

So you should be able to read it from the mp4 file itself

@Guimareshh
Copy link

Hey @natario1 ,

I'm working with @Aissa-H, the point isn't to know the orientation of a video (as you said we can read it from the mp4 itself). The goal is to avoid having videos with different orientation. Do you think it's possible ?

@natario1
Copy link
Owner

Oh, ok. So what could the library do? The device is free to rotate. I don't know about your app but I think you should take each MP4, read the orientation tag from the files, rotate videos to a common orientation (e.g. using ffmpeg or whatever) and then merge them.
This ensures that all your parts are correct.

No?

@Guimareshh
Copy link

Using ffmpeg is fine to avoid orientation issue, but the process time to merge all MP4 together is incredibly slow. That's why we are using mp4Parser, it's very fast. But this library has orientation issue. As @Aissa-H said, there is a known bug for 2years now. So we are trying others way to fix the issue.

And one workaround could be to have the same orientation for both front and back camera, instead of being different. I don't know if this is something possible. To be honest, I don't even know why in the Android Camera API we have a different orientation depending of front/back (is this reallly usefull ?!)

@natario1
Copy link
Owner

No, we can't rotate the video for you because it is time consuming. They have different orientations because sensors are built with orientations chosen by the manufacturer and the user can always tilt their device before recording. Videos are saved in an unspecified orientation.

The only way to have them correct is to read the tag and rotate, like VideoView does before displaying. If you must do file manipulation, then you must rotate the whole file

@Guimareshh
Copy link

Ok I understand now, that's because of manufacturers and not because of the OS. Again, something painful for developers ! Anyway, thanks for your time (and for the lib, very easy to use 👍 ) we will close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants