gplracerx wrote:VideoReDo says the clips are MPEG4 Part 2, which it doesn't support. That's the old divX/Xvid standard, according to ffmpeg.org, that was replaced by H.264. I'm betting that's the problem with that video anyway. Somehow the GoPro H.264 video was converted to the old standard. The fact that it won't load into GoPro Studio means it isn't the original format from the camera.
You must have a flag set or are missing some libraries somewhere in ffmpeg that's causing the conversion to MPEG4 part 2. Both the HQ and the lower bit rate videos are MPEG4 Part 2. I have very little experience with ffmpeg so I can't help with finding the problem.
Pretty sure I stated directly in the post you downloaded the video from (quoted below) that it was rerun through ffmpeg with -vcodec mpeg4 -qscale:v 3 so...not sure what your point is. Earlier I ran it directly with the source video from the gopro and the results were the same as well. This is pretty clearly an encoding issue, just comes down to what causes it - whether it's a combination of android os / encoding package, or something else.
petik0 wrote:I took the same video but generated regular mpeg4 with qscale set to 3 (higher quality) and reran overlay for one lap. This time I'm also including the session datalog from Harry's in case you (Harry) can try to actually run the overlay on your device. You may be able to confirm if the original recording is the culprit or the encoder that is being used on these particular devices if yours happen to overlay cleanly.
I'm going to have to take these videos down from google in a few days since I've a size limit there and some are quite large.
My point is that the mpeg codec you used was not H.264, it was Xvid. The problem is that very likely neither the original GoPro video nor your re-encoded video are compatible with the Android codecs. Likely the resolution and bit rate of the original video was too high. When you re-encoded it with the rather unspecific codec mpeg4, you got Xvid instead of H264. I believe the correct video codec is x264.
More searching revealed that it looks like you have to enable libx264 when you install ffmpeg. I suggest trying Handbrake and use the Android option to convert your GoPro videos.
Last edited by gplracerx on Wed Nov 19, 2014 9:52 pm, edited 1 time in total.
The video library in LapTimer has H.264 disabled as it would require me to put LapTimer into the public domain. This is the reason mpeg4/2 is used. It has several disadvantages (size / quality) but should be supported by most players.
gplracerx wrote:My point is that the mpeg codec you used was not H.264, it was Xvid. The problem is that very likely neither the original GoPro video nor your re-encoded video are compatible with the Android codecs. Likely the resolution and bit rate of the original video was too high. When you re-encoded it with the rather unspecific codec mpeg4, you got Xvid instead of H264. I believe the correct video codec is x264.
Harry already stated he's not using H264 for re-encoding, he's currently using straight up MPEG4. Also the shaky phone source was H264 and still had these issues. Just for the fun of it i'll rerun ffmpeg with codec set to x264 but I have a hundred bucks on it making absolutely no difference.
Also, I don't know how videoredo determines it's codecs but mpeg4 part 2 and xvid are not the same. xvid did implement mpeg4 part 2 but they're not actually interchangeable terms. Also, I dropped that video onto a fresh tablet with nothing on it but the stock player and it handles it just fine.
Wait, then why did you send a link to a PLAYER for your reference of a claim that stock android can't handle xvid?
If it can play it, it can decode it. Encoding is handled within Harry's. You can actually throw a huge variety of videos into Harry's and it will encode them. Just haven't found one yet that doesn't get choppy.
I found an editor that would work, MPEG Streamclip v1.2. It probably works because it's old. The latest copyright date is 2008. So I cut out a lap from the HQ video and saved it without changing format, used iBrowse to put it in the documents folder on a new (yes, you can actually win things on those string cutting games in the mall) iPad Air (iOS 7.1.2 HLT 18.3.6) and imported the .hlptrlz file. The time stamp was ~14 to ~16 minutes, so I guessed it was lap #8 and linked and overlaid. No pixelation artifacts and smooth frame rate. The video was as shaky as the original, but looked good. So the problem does seem to be Android related, or at least your Android device.
The problem is clearly related to the video library used (or the way LapTimer uses the video library). ffmpeg is a respectable and very universal library, but it is hard to use and misses good hardware integration. It is a "better than nothing" mechanism if one wants to do video processing on an Android device. Without, it is not even possible up to Android 4.3. I do not want to get any religious discussion or statements, but in this area iOS is dimensions better than Android. I needed to invest a complete month of work just to create something from Android / ffmpeg that has been available in iOS out of the box... Just another background story.
Mid-term I plan to use video processing support available since Android 4.3. It will be a "version 1" implementation (and comes with nearly no documentation), but I hope to find a better integrated solution here. But till then, ffmpeg needs to work... I will re-check the current implementation based on the input submitted (thanks for this) - it definitively is possible - even with mpeg4/2.
