[M4IF Technotes] A different question about vop_time_increment: stuffing?

[Christoph Lampert]

Hi,
since I thought about vop_time_increment for a while I have a question to
the experts, too. I found the part 7.13.1 about bit stuffing to avoid 
generating accidential vop-start-codes 
# 7.13.1 Start codes and bit stuffing A start code is a two-byte code of
# the form  0000 0000 00xx xxxx . Several such codes are inserted into the
# bitstream for synchronisation purposes. To prevent any wrongful
# synchronisation, such codes shall not be emulated by the data. This is
# guaranteed by the insertion of a stuffing bit  1  after each
# byte-aligned sequence of eight 0 s. The decoder shall skip these
# stuffing bits when parsing the bit stream. 
Now when I think about timecodes, this happens all the time: 
Take an ordinary vop_time_increment_resolution 60000 (like for 59.94 Hz
NTSC). Then first vop_time_increment==0 would have to be a encoded as 16
zero bits. So there will surely be a sequence of 8 zero bits at a byte
aligned address. 
Would a compliant bitstream have to set a 1 bit at the correct position
_within_ the numerical value, thus saving e.g.
000|00000000|100000 instead of 000|00000000|00000   
where | indicates the byte boundary? 
If yes, the decoder has to detect if this 1 is a _real_ 1 or just an
"extra 1" and decide whether to skip it by counting zero bits since the
last byte boundary... I don't remember seing this in MoMuSys reference
software.
Christoph Lampert
-- 
Christoph H. Lampert chl   math,uni-bonn,de | Diese Signature wurde maschi-     
Beringstr. 6, Zi. 14, 53115 Bonn, Germany | nell erstellt und bedarf
Tel. (0228) 73-2948  Fax. +49 228 73-7916 | keiner Unterschrift. AZ 27B-6