[FFmpeg-devel] [PATCH] Only output necessary NAL units in H.264 extradata in SDP
Sun Apr 5 22:05:31 CEST 2009
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel