[FFmpeg-devel] H.263 packetizing into RTP
Sun Apr 5 21:45:49 CEST 2009
On Sun, Apr 05, 2009 at 09:31:19PM +0200, Luca Abeni wrote:
> Hi Michael,
> On Fri, 2009-04-03 at 23:15 +0200, Michael Niedermayer wrote:
> > > > 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.
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel