[FFmpeg-devel] H.263 packetizing into RTP

Michael Niedermayer michaelni
Mon Apr 6 19:24:04 CEST 2009


On Mon, Apr 06, 2009 at 04:17:30PM +0300, Martin Storsj? wrote:
> On Sun, 5 Apr 2009, Michael Niedermayer wrote:
> 
> > On Sun, Apr 05, 2009 at 09:31:19PM +0200, Luca Abeni wrote:
> > > Hi Michael,
> > > 
> > > > yes, also to clarify things as maintainer of the h263 decoder and error
> > > > concealment code.
> > > > the only thing that matters is
> > > > that the code that splits at arbitrary byte boundaries tries to
> > > > split at slice/gob boundaries when possible. That is it could try to put
> > > > as many complete gobs/slices in a packet and only if it cannot put a 
> > > > single complete one in there, put a partial one in there.
> > > 
> > > Ok; thanks for clarifying this (this is one of the aspects I was not
> > > sure about). I'll not commit the patch until someone implements this
> > > kind of frame splitting.
> > > 
> > > If someone can provide pointers and/or hints (I do not know much about
> > > H.263 syntax... For example, can I identify slice/gob boundaries by
> > > searching for 0x000001, or similar? Can ff_find_start_code() be used for
> > > this purpose?) I'll work on this... Otherwise I'll wait for someone else
> > > to do the job.
> > 
> > see
> > h263_encode_gob_header()
> > and
> > ff_h263_resync()
> 
> I probably know even less about H.263 syntax than Luca, but took a look at 
> those functions and read up a bit on it; is it ok to look for two 
> consecutive zero bytes? That requires the startcode to be byte-aligned, 
> though. By setting rtp_payload_size in the AVCodecContext, the encoder 
> outputs suitable GBSCs.
> 
> The first attached patch tries to implement this...
> 

> As a related side note, I noticed that the documentation for the command 
> line parameter -ps (which sets rtp_payload_size) seems to be incorrect. It 
> states that this value is in bits, even though it actually is in bytes. I 
> traced this back to SVN rev 962 where the wording "in bits" was added, 
> even though the rtp_payload_size was used as a number of bytes, even back 
> then. Attached a patch to fix this.

last patch ok

[...]
> +            while (p > buf1) {
> +                if (p[0] == 0 && p[1] == 0) {
> +                    /* Found a byte aligned startcode. */
> +                    len = p - buf1;
> +                    break;
> +                }
> +                p--;
> +            }

this can be done a little faster by steping by 2 and only checking the
surounding bytes when the middle one is 0
basically, using ff_h263_find_resync_marker() should achive that

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090406/8ea51dd4/attachment.pgp>



More information about the ffmpeg-devel mailing list