[Ffmpeg-devel] I'm giving up

Michael Niedermayer michaelni
Wed Dec 6 16:49:13 CET 2006


On Wed, Dec 06, 2006 at 04:47:46PM +0100, Luca Abeni wrote:
> Hi Nico,
> On Wed, 2006-12-06 at 16:18 +0100, Nico Sabbi wrote:
> [...]
> > >>I'm saying that h264 in nal-form sounds total nonsense to me
> > >>for the reason I wrote (because it's unusable in raw form)
> > >>    
> > >>
> > >
> > >Wait a minute.  You say NAL form is nonsense and raw form is unusable.  What
> > >form would you like it in?  I don't know of any others.
> > >
> > >  
> > >
> > NAL and raw form are the same to me (because SPS and PPS are in the mux 
> > headers),
> > as opposed to bytestream format (where headers are inline)
> I see, your point, but this NAL (or raw) form is required by some
> clients (for example, ISMA wants that PPS and SPS are base64-encoded in
> the SDP, and are not transmitted inline). This can be stupid, or smart,
> I do not know... But it is required by some standards.
> I know that I can ask the codec to encode PPS and SPS inline, and then
> parse the stream to remove them... But why generating some NALs and then
> removing them? I was under the impression that the
> CODEC_FLAG_GLOBAL_HEADER flag was designed to help in this case, no? If
> not, what's its purpose?

CODEC_FLAG_GLOBAL_HEADER should cause the encoder to put the global header(s)
in extradata, of course it should use the same format as is used in the
bytestream if possible, any container specific reformating belongs to some
other layer IMHO

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali

More information about the ffmpeg-devel mailing list