Using Jetson-utils for our project, everything working really well, just a few minor bits left to figure out. One of them is figuring out how to extract the timestamp of a frame output to the H264 encoder within an MP4 container. I can see that videoSource has a method to get the last timestamp, but nothing similar for videoOutput.
Essentially I’m after the timestamp in the final MP4 file. I’m trying to find the best way to sync the timestamps in another file with the timestamps in the MP4 file.
This is the version information, hope it’s enough:
The other way around essentially. My processing chain is the following:
CSI Camera → Frame → Overlay data on top → H264 encoding → output to MP4 file.
The data being overlaid is also saved in a log file. The difficulty comes from determining what line in the log file (CSV) corresponds to which frame of the resulting MP4 file. I have a few ideas in mind, but unsure which is feasible:
After rendering the encoded frame, extract the timestamp of said frame in the MP4 file. That would allow me to add that information to the log file.
Somehow force the output to have a constant framerate. Didn’t find any clear solution for this unfortunately.
Post-process the video file afterwards. Since I know that each frame corresponds to an entry in the log file, I just need a way to extract the timestamp of each frame in the video.
Hope it makes sense, but happy to bring further clarifications if required.
Hi,
The timestamp is stored in dts in GstBuffer. You can add the code to nvarguscamerasrc or nvv4l2h264enc plugins to get the information. Source code of the plugins is in
Thank you. I was able to get a good solution by getting the timestamp from the videoSource frame. Correct me if I’m wrong please, but that timestamp is also used in the MP4 file, correct?
So if I capture frame A with timestamp 48.950s and that frame is rendered to the output video file, it will be found at that timestamp. Is that correct? That’s what my experiments suggest.
Hi,
Yes, the timestamps will be identical from source to sink. One possible deviation can be in start offset. The source may have some start offset due to system time, and the mp4 file starts from zero.