Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add ability to determine presentation timestamp #36
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
This is a backwards incompatible change, but given we haven't made a release including the
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
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.
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
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.