0

I'm trying to test this sample in my galaxy S3 and everything seems to work well but when i try to play the recorded file, no player can play the file. I send the video to my computer and tried with VLC, gom player, etc and always get an error like " entry format no recognized" The file has the right size. What is happening?

Edit: I tested the same sample in a moto G and works ok. Can be a galaxy S3 related issue?

Thanks

borja
  • 125
  • 9
  • The output is a .mp4 encoded with AVC, so it should work with anything, though you will occasionally see complaints about VFR. Are you able to play the file using the video playback activities in Grafika? – fadden Feb 22 '15 at 16:56
  • Continuous sample is working but videos recorded with cameraCaptureActivity are not playable. I tried with play video activities and get a force close. – borja Feb 22 '15 at 20:42
  • My guess would be that the MediaMuxer is failing near the end, and as a result the file header isn't being written to the .mp4. Watch the logcat output when recording with CameraCaptureActivity and see if you can spot a failure in the log file. – fadden Feb 22 '15 at 22:14
  • just before the log message "setupVideoEncoder succeded" i get this message about 6 o 7 times: W/ACodec﹕ do not know color format 0x7f000001 = 2130706433. – borja Feb 22 '15 at 22:54
  • I had not get this error in a moto G. Instead, i get this: E/ACodec﹕ [OMX.qcom.video.encoder.avc] storeMetaDataInBuffers (output) failed w/ err -2147483648. But everything is working fine i guess. Video is playable with no color issues. – borja Feb 22 '15 at 23:10
  • The color format complaint should be harmless (see e.g. http://stackoverflow.com/questions/28497410/). The failure would appear near the end; look for some MediaMuxer babble. (Or look for it in a successful run, and then see if you see the same sorts of messages at the end of an unsuccessful run.) – fadden Feb 23 '15 at 05:41
  • I activated verbose on VideoEncoderCore and at stop i get this in a infinite loop: D/Encoder_Core﹕ no output available, spinning to await EOS – borja Feb 23 '15 at 11:03
  • That fits with the symptoms -- if it's not seeing the end-of-stream indication, it won't tell MediaMuxer to close the file, and the .mp4 file header won't get written. So the next thing to figure out is why it's spinning. Is `TextureMovieEncoder.handleStopRecording()` not being called? (NOTE: you need to tell it to stop recording in the "user interface"... if you just back out of the activity it will leave the recording open.) – fadden Feb 23 '15 at 17:05
  • Yes, i can see the call in the log: D/Encoder﹕ handleStopRecording After that: 1. drainEncoder(true) 2. sending EOS to encoder 3.sent 537 bytes to muxer and 4. enter the loop:no output available, spinning to await EOS. Thank you – borja Feb 23 '15 at 18:41
  • Sounds like the `BUFFER_FLAG_END_OF_STREAM` isn't getting through the codec. Was there a "reached end of stream unexpectedly" earlier in the log file? Maybe EOS got sent early, and now the code is stuck waiting for an EOS event that already happened. – fadden Feb 23 '15 at 20:59
  • i can't see something like that in the log. – borja Feb 23 '15 at 22:00
  • Unfortunately I'm about out of guesses, and I don't have a GS3 to try myself. If it's only failing on the GS3 that suggests a GS3 bug, but I wouldn't want to declare that as fact without proof. – fadden Feb 24 '15 at 04:06
  • I understand. Yes, it seems like a GS3 bug. Is there another way to send EOS manually from other thread?I don't know what is EOS so maybe is a stupid question but is like it did encoding well, just need to close. Thank you anyway :) – borja Feb 24 '15 at 09:37
  • "EOS" just means End of Stream. – fadden Feb 24 '15 at 16:38

1 Answers1

0

I'm sure that this is not the best way to overcome this. But anyway, anything is better than a infinite loop and a corrupted file so... i put a counter for EOS waiting iterations with a limit, if it is reached breaks the loop. File is playable now. No secondary problems for now. Thanks

borja
  • 125
  • 9