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

[Shailendra Singh]

Hi Gary,
I am aware of the current statuses of RFCs 2190, 2429 and 4629 - however, at
least some of current implementations support (only) RFC 2190, and to inter
operate with these systems, one has no choice but to support RFC 2190 (even
though RFC 4629 is available).
Regards,
Shailendra
On Mon, Apr 28, 2024 at 5:09 PM, Gary Sullivan <
garysull windows.microsoft.com> wrote:
>  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> 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/80b29cec/attachment.html