Haha, that's completely true!. The clock component it's incredible hard to use up to the point that I'm not able to simply set the timestamp of the capture in the jpeg metadata, it's muich easier if you simply call to gettimeofday() and set the metadata labels manually.
Clock timestamps are NOT the time of day - it's a signed 64bit value representing the time in us and is controlled by the client. It's used for timestamping frames within a video clip (whether on encode or for scheduling on decode), and is normally set to 0 at the start of encoding. The JPEG encoder doesn't even look at it when forming the EXIF data.
I also recommend to not use the port 73. The h264 encoder works well without it.
That's where I would disagree if using IL rather than MMAL to do video encode.
The clock component should allow for accurate A/V sync if both audio and video sides hook into it (normally audio as master and video slaved to it - it compensates for clock drift too). You can also have the clock running at other than realtime to record slow-mo or fast-mo without any external processing of timestamps (one of our old tests was doing synchronised A/V slow-mo all totally with IL with no client intervention once the pipes were configured). Lots of flexibility, but also a right pain in the proverbial to get right.
The cheat that MMAL pulls with camera is to use the custom parameter OMX_IndexParamCommonUseStcTimestamps
to allow timestamping buffers in the absence of a clock component, but it's not as flexible (no way to do things like pausing the recording to resume again without a change in timestamp, add offsets, scaled time, or a raft of other things).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.