Difference between Piclock and Pi Camera Clock?

Question

I have been recording uncompressed videos using Picamera. I am using custom output to capture Presentation timestamps (pts) and Pi-internal clocks time for each frame. Code Below.

import io
import picamera
import time

class PtsOutput(object):
    def __init__(self, camera, video_filename, pts_filename, pi_time_filename):
        self.camera = camera
        self.video_output = io.open(video_filename, 'wb')
        self.pts_output = io.open(pts_filename, 'w')
        self.pi_time_output = io.open(pi_time_filename, 'w')
        self.start_time = None

    def write(self, buf):
        self.video_output.write(buf)
        if self.camera.frame.complete and self.camera.frame.timestamp:
            if self.start_time is None:
                self.start_time = self.camera.frame.timestamp
            self.pts_output.write('# timecode format v2\n')
            self.pts_output.write('%f\n' % ((self.camera.frame.timestamp - self.start_time) / 1000.0))
            self.pi_time_output.write('# frame write time: %s\n' %time.time())

    def flush(self):    
        self.video_output.flush()
        self.pts_output.flush()
        self.pi_time_output.flush()

    def close(self):
        self.video_output.close()
        self.pts_output.close() 
        self.pi_time_output.close() 

with picamera.PiCamera() as camera:
    camera.resolution = (320,240)
    camera.framerate = 30
    camera.start_recording(PtsOutput(camera, 'test_30fps.yuv','pts.txt','pi_clock_time.txt'), format='yuv')
    camera.start_preview()
    camera.wait_recording(60)
    camera.stop_recording()

I have multiple questions:

1. Can I compare the frame capture times according to two clocks ( pi clock & picamera clock). What is the relationship between the two clocks?

2. What is exact definition of Presentation time frame. Is it time camera takes the image or is it the time it decides to take? or something else?
   

3. Which time is more reliable ? time given by picamera or piclock ? I see that inter-frame duration(difference of timestamps of any two consecutive frames) of picamera clock don't differ at all. which seems to good to be true.

Answer 1

This is definitely outside my realm of knowledge and would probably be better asked on the Raspberry Pi camera forum where the firmware devs might pick it up. Still, I'll try and answer as best I can given what I've read in the past:

1. There is no relationship between the Pi's clock and the camera's clock; they are entirely separate. The Pi's clock runs all the time (when the Pi is operational), while the camera's clock only runs when the camera is operational.

2. I'm unaware of the exact definition of the presentation timestamp. I'd assume it's the exposure time of the frame (or more precisely the first or perhaps the last line of the frame given we're dealing with a rolling shutter) according to the camera's clock. It is definitely sourced from the camera's clock but I don't know for certain when it's read.

3. The frame timestamp will definitely be more accurate, and I'm not at all surprised it's near perfectly accurate. Consider what's happening in each case:

   • When you query the Pi's clock you're asking a relatively slow interpreted language to ask the CPU to query the system clock while a non-realtime operating system carries on various tasks in the background (via context switching). There'll be a huge amount of "wobble" as a result.

   • By contrast, when the camera is activated it's simply sitting there capturing frames, tagging each with its timestamp according to its own clock, uninterrupted by anything else. When you read a frame's timestamp you're not interrupting things and asking it for the camera's clock now - you're reading a timestamp that's already been set from the frame meta-data. And it's not surprising that the frame capture cycle is extremely well regulated; it's a rolling shutter so the frame is being read line-by-line. If the line timing wasn't near perfect I imagine there'd be all sorts of artefacts.

Edit

From further discussion with the firmware devs in the forum, it appears the frame timestamp is from the start of the capture.