I think you are asking about the /velodyne_points output from velodyne_pointcloud, is that right?
Those data are published as a PCL point cloud, which is required to be 16-byte aligned. The driver defines a custom PointXYZIR point type in order to add an extra field containing the ring number. The layout is defined in velodyne_pointcloud/point_types.h, with a four-byte float for each of the three coordinates and the intensity, followed by two bytes for the ring number. Unfortunately, the remaining 14 bytes in each entry are just padding, required by PCL to ensure alignment consistent with the use of vector floating point instructions.
The ring sequence is defined in velodyne_driver/ring_sequence.h. It is a way of representing which laser produced each point in the cloud. Since the actual device laser numbers are somewhat scrambled, the driver re-orders them into a range from zero to N-1, where N is the number of physical lasers. Ring zero is the lower-most laser, ring one is next. Ring N-1 is the upper-most.
While the PointCloud2 representation is convenient to work with in PCL, it is not at all byte-efficient. For later playback and analysis, I recommend saving the raw /velodyne_packets topic, then using velodyne_pointcloud, on the saved messages.
If you don't care about the ring number, you can convert the custom PointXYZIR to a standard PCL PointXYZI, which fits neatly into 16 bytes.
Hope that helps. Let me know if I answered the wrong question...
Not an answer, but would it perhaps be an idea to run the bag file through a quick conversion session with
velodyne_pointclouddoing the conversion for you, storing the pointclouds in a new bag and reading that in matlab?