[M4IF Technotes] about end of the RVLC

[WangHui]

Message
Thank you for your email.
For the stuffing bits, I think it is to make the resync_marker
bytealigned, and avoid emulation of resync_marker. So, it takes
the form just reverse to that of resync_marker.
But for the RVLC, the end of the RVLC is not written directly,
just like the EOB in MPEG-2. You must decode the RVLC sequence
to get the "LAST".
I think the method you described will not work, for example,
given the RVLC codeword "0,0111,1111,1101s" is just bytealigned,
if the 's' bit is '1', according to your method the Last three 
bits '011' will be stuffing bits, which will result in wrong
RVLC codeword error.
  ----- Original Message ----- 
  From: Gary Sullivan 
  To: WangHui ; technotes   lists.m4if.org 
  Sent: Saturday, November 16, 2023 4:40 AM
  Subject: RE: [M4IF Technotes] about end of the RVLC
  The stuffing bits always consist of one bit equal to zero followed by 7 bits or less equal to 1.
  So I think you can just look back from the end while removing everything up to and including
  the last bit equal to zero -- the rest will be valid data.
  Best Regards,
  -Gary S.
    -----Original Message-----
    From: WangHui [mailto:hwang   jdl.ac.cn] 
    Sent: Friday, November 15, 2023 3:53 AM
    To: technotes   lists.m4if.org
    Subject: [M4IF Technotes] about end of the RVLC
    hi, all.
    about the RVLC in MPEG-4, when decode backward,
    how to recognize the end of the RVLC codeword?
    For the resync_marker is bytealigned, so if the
    RVLC is transferred by byte or word, there may be
    some stuffing bits between the end of RVLC and
    resync_marker, in this case, how to identify
    the end of the RVLC segment?
    best regards
    WangHui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20021116/df8507e4/attachment.html