has_more_rbsp_data is broken / fix trailing bits handling about h264-reader HOT 1 OPEN

Hmm, here's a thought. If all the readers were #![derive(Clone) (the ReadBuf for the NAL, the ReadBuf for the RBSP, and the bitstream_io::BitReader), has_more_rbsp_data would be easy. It just needs to clone and look for two upcoming one bits [edit: minor correction: a one bit that isn't the very next bit]. The NAL and RBSP readers would be easy to make Clone. Making bitstream_io::BitReader Clone would be be a feature request for bitstream_io but I don't think they'd object. iirc just a plain #![derive(Clone)] has an automatic where R: Clone on it so this would be a one-line change to bitstream_io.

finish isn't too hard either as mentioned above.

I still don't see a way I'm in love with of having all the methods be trailing bit-aware. There's the seeking backward I described but that's kind of complicated. We could also have a second RBSP reader that marks the point where we're sure there's another one in the stream and compare their positions, but that's still complicated, and it doubles the RBSP decoding overhead. But maybe it's just not important to have them all be trailing bit-aware.

from h264-reader.