[FFmpeg-devel] [PATCH] Only output necessary NAL units in H.264 extradata in SDP

[Michael Niedermayer]

On Sun, Apr 05, 2009 at 09:53:12PM +0200, Luca Abeni wrote:
> Hi Loren,
> 
> On Sat, 2009-04-04 at 05:56 +0000, Loren Merritt wrote:
> [...]
> > >    sprop-parameter-sets:
> > >        This parameter MAY be used to convey
> > >        any sequence and picture parameter set NAL
> > >        units (herein referred to as the initial
> > >        parameter set NAL units) that MUST precede any
> > >        other NAL units in decoding order.  The
> > >        parameter MUST NOT be used to indicate codec
> > >        capability in any capability exchange
> > >        procedure.
> > >
> > > The way I interpret this, only SPS and PPS are allowed. Am I getting this
> > > right?
> > 
> > If I interpret it literally, then not even SPS/PPS are allowed.
> 
> So, now I am confused... Which NALs should go in "sprop-parameter-sets"?
> (I am asking because I intended to commit the patch, but after reading
> your comment I want to be sure).
> 
> When I originally read the RFC, I somehow got the impression that all
> the NALs contained in the extradata are allowed to be in
> sprop-parameter-sets. Now, re-reading the RFC I see that it mentions
> "sequence and picture parameter set NAL units", which I assume to be SPS
> and PPS... Is this wrong?

the RFC is poorly worded, the MUST NOT requirement pretty much says you
cant put SPS&PPS in there.

With texts like this one has no choice but to violate it, because SPS&PPS
obviously have to be in there.
I wonder when someone will get up their ass and write a generic RT*P
replacement instead of all that contradictionary and dulplicated junk


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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20090405/383fadba/attachment.pgp>