Reader singleton startframe

[nimski]

The current protobuf readers for cam and imu allow you to specify a startframe parameter. However this actually refers to the starting protobuf message. For example, with a visual-inertial dataset, in order to start on the 100th image, you might have to specify [startframe=23000] to skip all the relevant IMU messages.

What's more, the startframe parameter gets overwritten with every new driver that uses the reader singleton. So for example -cam proto:[startframe=2000]://blahblah -imu proto:[startframe=200] would set the starting protobuf message to 200.

Finally, because the reader has to skip a ridiculous number of messages, the seek operation can be really slow.

We should solve this by either including an index header in the log file allowing you to instantly skip to a particular offset, or by having a separate index that we build using logtool. Or some other sorcery.

[chachi]

👍 Definitely a PIA

[gsibley]

We discussed having the index constructed post-hoc via logtool. We also
discussed having it appended to the protobuf file. This way, all .log
files can be indexed added, and are readable with and without indexes.

On Mon, Aug 11, 2014 at 1:06 PM, Jack Morrison notifications@github.com
wrote:

[image: 👍] Definitely a PIA [image: ]

Reply to this email directly or view it on GitHub
#20 (comment).

Gabe Sibley, PhD

Assistant Professor
Department of Computer Science

University of Colorado, Boulder

[jfalquez]

I think the biggest issue is the way the singleton starts queuing messages. If a camera from log is initialized, the queuing thread immediately starts capturing only camera messages and discarding everything else. If later in the code an IMU is initialized, then the singleton will start queuing up IMU messages as well. This means that some data was lost, and also, the head of the queue might be in a "bizarre" state where a bunch of camera messages are queued without IMU messages in between.

This is something we need to discuss carefully and sit down like we did with Hack-a-thon 1.0 since it is a major code revamp.