[Mp4-tech] [Video][H.263] Non byte-aligned start codes

[Gary Sullivan]

Shailendra,
Note that RFC 2190 has been deprecated (it now has only "historic" status in the IETF).
FYI: http://www.ietf.org/iesg/1rfc_index.txt .
Best Regards,
Gary Sullivan
________________________________
From: Shailendra Singh [mailto:ssingh179 gmail.com]
Sent: Monday, April 28, 2024 2:44 AM
To: Gary Sullivan
Cc: mp4-tech lists.mpegif.org
Subject: Re: [Mp4-tech] [Video][H.263] Non byte-aligned start codes
Hi Gary,
Thanks for the reply.
I do understand your explanantion, but I believe that there are situations where the non byte aligned start codes pose a problem - for instance, a RTP (RFC 2190) packetizer for H.263 bitstreams.
Incidentally, I found it interesting to compare RFCs 2190 and 3984 - a RFC 2190 packetizer seems to require a much deeper knowledge of the bitstream being packetized than RFC 3984, with the added complication of search for non byte aligned Group of Block start codes.
Regards,
Shailendra
On Sat, Apr 26, 2024 at 5:34 AM, Gary Sullivan <garysull windows.microsoft.com<mailto:garysull windows.microsoft.com>> wrote:
Shailendra,
I suppose the only reason not to byte align some start codes is to save bits.  Byte alignment is not as useful in some system environments (e.g. H.320) as it is in others, and good decoders would want to search for non-byte-aligned start code patterns anyway as part of their checking of the validity of the bitstream data.
As for why the design is different for GOB start codes versus slice start codes, that is because GOB start codes were in the original version of the standard, while slice start codes were something that was added several years later as an optional mode of operation.  We basically regretted that we had not required byte alignement of GOB start codes in the first place, but it was too late to do anything about that historical fact.  So we designed the new mode of operation to act differently in that regard.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces lists.mpegif.org<mailto:mp4-tech-bounces lists.mpegif.org> [mailto:mp4-tech-bounces lists.mpegif.org<mailto:mp4-tech-bounces lists.mpegif.org>] On Behalf Of Shailendra Singh
Sent: Friday, April 25, 2024 8:19 AM
To: mp4-tech lists.mpegif.org<mailto:mp4-tech lists.mpegif.org>
Subject: [Mp4-tech] [Video][H.263] Non byte-aligned start codes
Hi All,
The H.263 Recommendation states : "All picture, slice, and EOSBS (End Of Sub-Bitstream code) start codes *shall* be byte aligned, and GOB (Group Of Blocks) and EOS (End Of Sequence) start codes *may* be byte aligned."
My question is:
What is the possible reason that the GOB and EOS start codes are allowed to be non-byte aligned, given the fact that it is so much easier to search for a byte aligned start code in a bitstream?
With a non-byte aligned start code, use of stuffing bits is unnecessary, which would result in some savings in the overall bitcount, but to me the loss of ease of search for a byte aligned start code seems too big a price to pay for this saving.
I am particularly perplexed about the GOB start code, given the fact that a Slice Start Code (SSC) *has* to be byte aligned, and the GOB start code and the SSC serve a similar purpose (and both are words of 17 bits, with the same value - 0000 0000 0000 0000 1).
Thanks,
Shailendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080428/77943b3f/attachment.html