New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to determine presentation timestamp #36

waveform80 opened this Issue Dec 24, 2013 · 4 comments


None yet
2 participants

waveform80 commented Dec 24, 2013

As mentioned in the comments for #34, it should be easy to query the pts (presentation timestamp) and dts (decoder timestamp) properties from the buffer headers. At the moment, I'm not convinced we need dts (the comments in the buffer header indicate that this only deviates from pts when B-frames are involved, but as far as I know the H.264 encoder never outputs B-frames). However, pts should be easy to extract and make accessible to end users.

This brings up the question of design. I'm not convinced I named the frame property very well. Without looking at the docs it's no obvious whether it's referring to the frame image, an object representing the frame, a frame number, or something else. I could rename it frame_number but now that pts is getting added another possibility presents itself:

Change the frame property from returning a simple frame number to being something that returns a namedtuple which represents various properties about the current frame (number, pts, and maybe a keyframe property?).

This is a backwards incompatible change, but given we haven't made a release including the frame property yet I don't think that's a huge deal. And the only change for any users using it at the moment is from frame to, say, frame.index

@ghost ghost assigned waveform80 Dec 24, 2013


This comment has been minimized.

martinohanlon commented Dec 24, 2013

I was thinking something similar and grouping encoder_data together. I was actually thinking a static class with properties but a tuple would be a simpler implementation. I share your thoughts though that frame should probably be renamed.


This comment has been minimized.


waveform80 commented Dec 25, 2013

FYI, a namedtuple (derived from tuple) basically is a static class with properties (its implementation in the collections module is a bit of a hack that involves eval() but to be honest I couldn't come up with a better way of designing it :). Still, that sounds like the way to go - and makes future expansion of the facility easy as I can just extend the namedtuple with more fields.

What source of encoder data were you hoping to combine with this? If they're equally easy to grab I'm more than happy to extend the ticket to include them.


This comment has been minimized.

martinohanlon commented Dec 26, 2013

I see, namedtuple does sound like the way to go. Other data that springs to mind, although it might not be easily accessible:

  • size, total size of the video
  • length
  • dropped frames

This comment has been minimized.


waveform80 commented Jan 1, 2014

Size is certainly possible - I'll add properties for the size of the current frame and the total size of the video recorded so far (bytes). It should also be possible to add a property for the size of video since the last call to split_recording().

Isn't length (which I'm assuming is the duration of the video recorded so far) equivalent to PTS? I'll have to experiment with this a bit and see if the reading from the pts field in the buffer header starts to vary from the wall-clock.

Not sure about dropped frames - picamera itself has no facility for dropping frames in the case of over-run - it rather dumbly assumes that whatever stream the user gives it is capable of handling the throughput. As far as I'm aware there's no facility for asking MMAL if the encoder's dropped any frames either - but if you know of one I'm happy to look into it.

@waveform80 waveform80 closed this in 670500c Jan 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment