Compression effects on motion

[milqtostr]

Hi all. I've gotten a lot of good info on here, hope someone can help me with this:
I am looking at a video that plays at 18 fps and a car moves through the scene. if I click through the video one frame at a time, the car moves small increments several frames in a row, and then it will jump a good distance, go back to small increments, and then jump a longer distance, etc
The video was H264 encoded, and from what I understand the I frames are the only "true" representations of moments of time, and motion of the car in P and B frames can be produced by motion vectors. could the appearance of irregular movements between frames be a result of the compression? or is motion accurately represented by encoding and the irregular movement is due to dropped frames or something like that.
the video was recorded by a surveillance system

[manono]

...could the appearance of irregular movements between frames be a result of the compression?

No.

or is motion accurately represented by encoding

Yes.

the irregular movement is due to dropped frames

More likely the encoder didn't know what he was doing and removed unique frames. From a surveillance system, eh? They can be pretty screwed up, but still not all jumpy the way you describe, I don't think.

[johnmeyer]

Dropped frames happen all the time. I've seen them from trying to capture screen video, and the capture software can't keep up. They happen with streaming video all the time. Low end systems, like security cameras, very often can't keep up, especially if you are saving the video in real time to the cloud, and then later play it back. Someone gave me Nest camera to play with, and it came with thirty days of free cloud storage. The video looked fine on my iPad, but when I played back the video that was uploaded to their server, I had lots of drops.

And, as manono said, compression does NOT created dropped frames.

[poisondeathray]

Yes, low bitrates, and poor encoder efficiency can cause irregular movements. It has less to do with "true representation of time", and more to do with I frames are usually allocated more bitrate. P and B frames are predicted, and the difference from the original is stored as the residual. They still attempt to be "true representations of time." If you have not enough bitrate for P, B frames - the picture will not be represented correctly. Frames can appear to "stick" or appear like they are dropped (there might be duplicate place holder frames) . When the higher bitrate I frame comes, the actual regular movement might "pop" back into place. If you have enough bitrate, the P,B frames look great. But if poor compression is the culprit - you should be able to tell - there should be other signs like other compression artifacts. ie. It won't be a high quality recording

[milqtostr]

thanks everyone! ok. with regard to the dropped frames:
the video I am looking at is 18 frames per second. I should assume the video was captured at a higher rate, such as 24 fps, and then the frame rate was lowered and it was compressed to reduce file size and bitrate. In this case, the motion of the car between most frames represents 1/24 of a second of movement, but due to dropped frames, occasionally the car moves 1/12 of a second between frames. on average after 18 frames the car moved the right amount, but at any increment of time within that second there will be some small error in position compared to reality.
If this is true, is there a way to use a tool such as ffmpeg to understand more about the increments of time?

[poisondeathray]

Most surveillance systems will have a timestamp, or running timecode. Usually it's encoded into the image as an overlay, but sometimes it might be in the metadata and you can toggle it on/off

So if the framerate conversion, dropping frames was the cause, you should be able to see that "jump" in the timecode overlay

[manono]

A sample might be helpful, 10 seconds or so.