[FFmpeg-devel] H.263 packetizing into RTP

[Michael Niedermayer]

On Fri, Apr 03, 2009 at 09:47:14PM +0200, Luca Abeni wrote:
> Hi Martin,
> 
> On Fri, 2009-04-03 at 21:08 +0300, Martin Storsj? wrote:
> [...]
> > > > also i suspect that packets should be split at slices/gobs
> > > 
> > > RFC 2190 states that pictures should be split either at gob level
> > > (mode A), at MB boundaries (mode B) or at MB boundaires of P-frames
> > > with PB-frame mode.
> > 
> > As far as I know (I found the original patch in a mailing list post from 
> > Luca Abeni), this is an implementation of RFC 4629 (and 2429); this is a 
> > different RTP packetization scheme than the one in RFC 2190. As of RFC 
> > 4629, this is the recommended scheme for all variants of H.263.
> 
> Yes, this is my understanding too.
> 
> 
> > In this packetization scheme, the frame can be split into packets 
> > regardless of GOB/MB boundaries or anything else. From RFC 4629, section 
> > 6.2:
> > 
> >    A Follow-on Packet contains a number of bytes of coded H.263+ data
> >    that do not start at a synchronization point.  That is, a Follow-on
> >    Packet does not start with a Picture, GOB, Slice, EOS, or EOSBS
> >    header, and it may or may not start at a macroblock boundary.
> > 
> > Splitting packets according to such boundaries would perhaps give better 
> > handling of dropped packets, but isn't mandated.
> 
> Right. This is why I said that the patch is (IMHO) correct but
> suboptimal.

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.
and IMHO this should be implemented before the code is commited, its not
complex ...

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20090403/d5abe87d/attachment.pgp>