Choppy overlay video Android V18.1

[petik0]

I did just try QT Pro and selected H.264 instead of MPEG-4 (still using an mp4 container) and the video did get processed by laptimer - unfortunately it's still just as choppy on PC and shows artifacts on the tablet. So weird.

[Harry]

In case you have ffmpeg installed, try "ffmpeg -i myvideofile"

[petik0]

Just got back from a track weekend and was able to confirm this issue is present on 3 different devices with video recorded directly on the device and not on the gopro. The devices are:
Samsung Galaxy Tab S 8.1
Sony Xperia Z1 compact
Sony Xperia Z3 compact

I posted the source and the overlaid videos from the Z3 here:
https://drive.google.com/file/d/0BxWx9e ... sp=sharing
https://drive.google.com/file/d/0BxWx9e ... sp=sharing

You'll see that the source is shaky - that has to do with my crappy mount. However you can clearly see the overlaid video is super choppy.

[Harry]

Looking into the recording, I believe the problem here is not on timestamps not being calculated correctly (which is what I thought first), but an issue that from video encoding. The video library uses MPEG3 to encode video. It is less efficient than H.264 which is used for the original video. In addition, compression strongly depends on the content of individual frames. This means a shaky video will always require more bandwidth or create more quality issues compared to a more steady video. So while H.264 could cope with this situation, MPEG3 couldn't... That's a theory, but it makes sense from my point of view.

Future workarounds are either getting a more stable mount and original video, or the replacement of the video library in LapTimer (which is planned for Spring next year).

- Harry

[bulls23]

Looked at both videos and to me it looks as if the overlayed one simply has a lower frame rate rather than showing problems with compression since picture quality looks fine (meaning as shaky and blurred as the original). Or is this the way HLT is suposed to work in such cases -> reducing frame rate below 30fps or 25fps?

btw: is there really video MPEG3? I thought that was made part of HD MPEG2. I guess you meant MPEG4...just curious

[Harry]

Yes, MPEG4. To check the update rate (which is *not* changed by LapTimer), the original videos are required.

- Harry

[bulls23]

I downloaded both videos from Youtube to check and they are both 29,97fps. I guess there is still the possibility of the original overlayed video having a lower frame rate and Youtube changing it after upload. Additional question: will HLT on Android drop frames (or kind of repeating them) while keeping the original frame rate? That would also lead to that kind of choppy video.

[Harry]

LapTimer writes back exactly the same number of frames as it had in the original video. So same # of frames and same update rate. The scope is certainly cut to the lap overlay range and frame timestamps are normalized to start at 0. Due to decoding / encoding and different encoders, all the frame types (B/I frames etc.) are changed too. But that is already something going on in the encoder, not on application level.

- Harry

[petik0]

bulls23, if you really want to look at what's happening, ignore youtube processing as it skews the visuals. also, it will vary significantly what video player you use. for example VLC will show the issue as though it's running a lower framerate (or dropping frames) whereas wmp or many players directly on your device will show this as artifacts.

Harry, I don't see any difference between the artifacts/choppiness on the latest video i uploaded and the original i uploaded back at the start of this thread from the gopro which was mounted much better and didn't shake. I'd love to see where switching to the H264 library gets this as the app really isn't usable for video overlay - I don't understand how everyone else running the android app isn't having these issues.

[bulls23]

bulls23, if you really want to look at what's happening, ignore youtube processing as it skews the visuals. also, it will vary significantly what video player you use. for example VLC will show the issue as though it's running a lower framerate (or dropping frames) whereas wmp or many players directly on your device will show this as artifacts.

I'm not fully understanding...but for me the choppy overlaid Youtube video the "low frame rate" choppyness is the same for Quicktime, VLC and Windows Media Player all running on Win7. I played around with Handbrake to see if using MPEG4 instead of x264 leads to that kind of choppy video. I used the non choppy Youtube video with no overlay. Using different quality settings in the standard Android profile I either got same quality as x264 but with larger file sizes or lower quality all the way down to blocky video but never that kind of low frame rate look. Of course I'm aware ffmpeg in handbrake can't simulate the implementation in Android but I've never experienced "low frame rate look" due to low quality encoding or high compression...basically I'm disagreeing with Harry and the theory of the shaky video leading to that choppyness...but then again I'm just an annoying smart ass