When was frame 100 in each recording?
Two recordings of the same paper airplane need not share a moment at the same frame index. Matching files also means preserving time references and the method used to pair them.
Filmed together
Imagine two people recording one paper-airplane throw on their phones. One starts before the throw. The other starts around the moment the airplane leaves the hand.
Later, take frame 100 from each recording and put them side by side. One might show the airplane still being held; the other might show it in flight. Same airplane, same frame number.
The number marks a position within a file. It does not establish that the recordings started together. Different capture rates make matching sequence numbers still less meaningful.
Time is also a central difficulty in Sangmin Yoon’s essay about autonomous-driving data. Sensors can use different clocks and produce data at different rates, so joining their records into one event goes beyond storing the files.
It is reassuring to hear that every file arrived. With these two videos, another question follows.
When were these two images captured?
Which clock does the time belong to?
Would a capture timestamp settle it? Even identical numbers can refer to different origins. Time since the video began and the device’s clock time are different references.
Suppose one recording is trimmed to begin as the airplane leaves the hand. Its first frame changes. Keep only the new file’s start and lose its position in the original, and matching it to the other recording becomes harder.
If I received this hypothetical material, I would want the timestamp reference and the trim position alongside the filename. If someone already aligned the clocks or corrected the times, I would want to know how.
Two displays saying ‘twelve o’clock’ do not prove that the devices’ clocks agreed. If their offset or its change during recording is unknown, that uncertainty belongs in the record too.
The official nuScenes schema keeps a sensor file’s path and timestamp alongside references to calibration and vehicle-pose records. The file stays connected to information needed to interpret it.
A phone-video project does not need to copy that entire structure. But I would hesitate to send the files alone and expect the surrounding explanation to be remembered later.
The person recording might remember a shared ‘one, two, three’ before the throw. Someone receiving only the files cannot know that unless the material preserves it.
Trim the lead-in to save space, and an apparently unimportant preparation scene might turn out to have been the clue linking the recordings.
Keep the matching decision
Suppose we analyze these imagined videos by pairing the closest recorded times. That can be a useful choice. Closest available and captured simultaneously still make different claims.
I would keep the original times with each selected pair, the conversion to a shared reference and the remaining gap. If we cannot determine a value, retain an unknown rather than manufacture one.
The acceptable gap also depends on the task. Checking the airplane’s color and comparing the moment it leaves a hand ask different things of the same material. One arbitrary tolerance cannot serve as the answer for every analysis.
Improve the alignment method later and the same originals might produce different pairs. Reconstructing the earlier result then needs the matching rules and their version as well as the source files.
Both files are in the folder. Both play.
But one airplane is still in a hand and the other is already airborne. I would ask whoever called them the same moment to show the part before the throw again.