Strange MP4 video twitching (jitter) after copy mode

[Vide]

I used some different versions of AVIDemux for Windows, including current version 2.7.0, and noticed following unpleasant thing:

I take an MP4 video file made with built-in Samsung Galaxy SII camera app. In the video all the motions are smooth.
Then I load it into AVIDemux, choose copy mode for video and audio, choose MP4 Muxer, save video to other file and then watch the result.

The resulting video disappoints me, because it makes an impression of jittering / twitching / jerking in time, I don't know what is the right word to describe this. I suppose that adjacent two frames are swapped in time, so that the motion seems to be constantly uneven as if some small moments are being constantly skipped. I do not know whether my supposition is right.

If I watch the resulting video in AVIDemux frame-by-frame, all motions are in a proper sequence.
If I watch the resulting video in MPC HC frame-by-frame, all motions are in a proper sequence too.

I am watching videos in MPC HC (Media player classic, Home cinema) x64.

Please help me to identify the problem to look for solution.

[mean]

An sample from you S would help, not the one processed , the original

[Vide]

An sample from you S would help, not the one processed , the original

How do I provide a sample if it's size is 20MB and here are allowed attachments up to 192kb? Any attempt to modify video spoils it. The defect is noticeable only in motion.

I could write a tool to compare binary files with offset, but I need some time for that.

The first look thrown at binaries showed that the original file contains strings: "ftypisom" and "isom3gp4" and the processed one contains "ftypisom" and "isomiso2avc1mp41". The processed file is 5524 bytes longer than the original one.

I did a simple binary search of two randomly chosen unique binary strings found in original file and found that first string is found in original file with an offset 4348, in processed file with offset 4E0. Difference is 3E68 (15976 dec). Second string is found in original file with an offset 16BED7, in processed file with offset 16BC65. Difference is 626 hex (272 dec). So, I could not say that data volumes were simply copied assigning them different headers only. Definitely large blocks were moved so that an offset between them isn't constant.

My end task is only to concatenate 4 video files with a lowest possible change of data streams.

[Jan Gruuthuse]

Err, perhaps you could Upload Hochladen Télécharger Subir: the video file <= click