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

[Shailendra Singh]

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> 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] *On Behalf Of *Shailendra Singh
> *Sent:* Friday, April 25, 2024 8:19 AM
> *To:* 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/543ea22f/attachment.html