When using setOrientationHint for recording videos, Samsung and Motorola phones simply write this value into the Rotation Metadata.
However, it appears HTC phones do not write this value into the metadata and actually attempt to rotate the video after recording. The phones I have tried on Android 4.0.3 and lower actually rotate it 90 degrees no matter the value and the 4.0.4 phones rotate it as per the value.
Has anyone else noticed this behavior and what is the best way to fix this?
In my experience, there's nothing you can do to unify all devices. Some devices add metadata, some rotate the byte array, and some dismiss it altogether.
Another problem you have with metadata is that just as the recording devices differ, so do the playback devices, in Windows for example you might have noticed that jpeg metadata (EXIF) is ignored and all images are displayed landscape.
I would have hoped by now that the hardware manufacturers would have had certain hoops to jump through with regards to camera hardware but it seems that this is still a problem.
Related
Edit:
Seems the issue is this device needs not multiple of 16 dimensions...but multiple of 32. Thing is, I still have no idea how to determine what quantifies as a problematic device. This does appear to use qcom (which I've seen to be problematic on Android 4.X, but this is Android 5.1.1).
I'm encoding a video in my Android app. I'm using Android MediaCodec to do so, converting RGB of each frame to YUV and passing in the pixels.
The code I use has been in place for a while, and works across any device I've come across.
A user came to me with a bug report that their MP4s were coming out weird. The device is a Samsung T337A (a Galaxy Tab 4).
Here are what MP4 exports look like:
NOTE - For whatever odd reason, it doesn't happen at all resolutions. It's confirmed to happen at 768x432 and 1280x720 but does not happen at 640x352 for example (my app makes sure all resolutions are divisible by 16 by default).
On a Nexus 5X (which uses the same semi-planar YUV format) the output works at all resolutions.
So it's something with this device, and maybe other devices I don't know about?
I've looked at all output, and it looks normal and identical to the Nexus 5X I mentioned above (which works 100% of the time).
MediaCodecInfo being used is OMX.qcom.video.encoder.avc, color format being used is 2135033992 (which is COLOR_FormatYUV420Flexible). So basically, nothing weird.
The code is a bit expansive, I'll post if necessary, but just looking for general ideas of why this happens. I'd understand if it was more common, but the same code works for a vast array of other devices, so something funky is going on...
Make sure that you use the right strides and buffer offsets values
I am observing a strange visual glitch when using a GLSurfaceView to render a camera preview on Android.
The reds and blues appear to be swapped in the Camera preview feed - greens seem ok. See the screen capture below.
I am only seeing this problem on a few devices (all variants of the Samsung Galaxy S4).
The glitch only occurs when using certain resolutions - 720x960 upwards is fine, anything below this exhibits the problem (e.g 640x480).
The problem occurs on both the front and rear camera.
The issue is reproducible in the Grafika Sample application (assuming you have a Samsung Galaxy S4 handy) by changing line 185 of CameraCaptureActivity.java like so:
// openCamera(1280, 720); // change this ...
openCamera(640, 480); // to this
I need to encode H264 at 640x480. I thought I could work around the problem by using a higher resolution (same aspect ratio) but still setting my encoder to run at 640x480 - unfortunately this leads to a horrible blocky video feed, presumably due to re-sampling.
Based on trial & error (and clues found in this answer and here) I was able to figure out that this is caused by turning on the recording hint functionality:
params.setRecordingHint(true); // this causes the problem
I was also having some aspect ratio issues which were solved by turning this off. So it seems that Samsung have messed up the setRecordingHint functionality at a driver or hardware level.
Interestingly, if if set the undocumented "video-size" value then I am able to fix the problem AND keep setRecordingHint turned on.
params.set("video-size", "640x480");
I don't know what this is doing compared to:
params.setPreviewSize(640, 480);
or
params.setPictureSize(640, 480);
but clearly it is having an impact. However since this appears to be undocumented and turning off setRecordingHint doesn't appear to have any affect on performance - I think go with disabling setRecordingHint.
We have a native Android webrtc-based voip app. Only in our Android app (as opposed to other platforms), the local camera stream is rotated after being in a call for a while. Usually it takes about 10 seconds. But sometimes more, even as much as a minute.
The remote will get the stream rotated as well, so it's not a rendering issue.
The stream is always rotated 90 degrees clockwise in portrait orientation, but is correct in one landscape orientation and upside down in the other landscape orientation.
After a while, the stream will be rotated back to the correct orientation again (and back to bugged after a while again).
I've tried several revisions ranging from early 8xxx to the latest (9125), all have the same problem. Apprtc demo has the problem as well. I've tested on several different phones (although only Samsung devices) and the problem exists on all of them.
I was faced with the same issue and I didn't found a right solution, but there is a workaround. I found that the reason of the rotation is cpu overuse detection, it leads to changing quality and it seems there is some bug in this functionality in android implementation. So I just added peerConnectionConstraints.optional.add(new MediaConstraints.KeyValuePair("googCpuOveruseDetection", "false"));
and it prevented this rotation.
I have written a basic custom camera which I recently changed to use the flash (where available) on the device. Once I had made the change the code ran fine as before on my HTC One Mini 2, but no longer worked on my Galaxy S4. After stepping through I found my jpeg callback is never reached on the S4, instead the raw callback is run but with a null byte[] supplied.
I found this similar question:
S4 Flash Problem
Which seems to confirm there is an issue and solution on these devices but the solution has not been documented.
To re-iterate, the code works fine on the S4 so long as I don't turn on the flash with:
Camera.Parameters p = mCamera.getParameters();
p.setFlashMode(Camera.Parameters.FLASH_MODE_AUTO);//Or FLASH_MODE_ON
mCamera.setParameters(p);
Can anybody with experience on these devices provide the solution?
After a lot of trial and error over the last week I have stumbled upon two possible solutions to this problem, the first of which doesn't make any sense to me at all:
Force the zoom to be greater than x1. For some reason if I set the zoom to x1.2 etc. the camera works again as I would expect.
Ensure the aspect ratio of the selected picture size matches the native aspect ratio of the device. The S4 has a resolution of 1920x1080 so any picture size that matches this 16:9 ratio works with the flash on. This makes a bit more sense but why the flash makes the difference and why anything that isn't supported should be returned by getSupportedPictureSizes() I don't know (albeit they do seem to be without the flash.)
Currently I have chosen to use option 2 and am testing on my other devices.
Might also be worth mentioning that my next step on the S4 was to allow the user to turn the flash on/off/auto themselves but this required destroying and recreating the camera each time.
In my AS3 Flex Mobile application for Android, I am using camera and it is being automatically rotated 90 degrees before I even done any video rotation by myself, it seems like it's a known bug in AIR. But I was wondering if anyone found a solution since it's really pretty important feature for mobile application developer.
I've tried to do some rotation manually in my code, but it is only fixes the view on my display, but still sends the wrong video to the receiver.
If any code is required I will add the snippets
Please let me know.
As you mentioned, this is a known bug with AIR. It is not consistent, either. On some devices, it is in the correct orientation but in some (and all iOS devices, I believe, though I haven't fully tested that), it is rotated as you are seeing. For example, it was always oriented correctly on my Nexus 4 and on my Nexus 5, but a friends Moto X is rotated incorrectly.
Unfortunately, I don't believe there is anything you can do short of having the user do a calibration (i.e. overlay a straight line and tell them to place it horizontally and click a button) and rotating the camera display and any images you take with the display.
That being said, if you are using the camera to take photos, I highly recommend using CameraUI instead, which is the native implementation.
I've faced the same issue today but i'm developping in Java, not with AIR so i don't know if it the same, for me the solution was to add this line before starting the recording.
mMediaRecorder.setOrientationHint(90);