[Ffmpeg-devel] Raw aac

Erik Slagter erik
Wed Feb 8 16:28:38 CET 2006

On Wed, 2006-02-08 at 15:09 +0000, M?ns Rullg?rd wrote:
> > Okay, so you're basically saying: "raw" encoding works and demuxing
> > doesn't, right? It would be nice to have, but gpac can do it too, it's
> > not that a big deal. The encoding stuff is also very nice to have
> > already.
> The aac data found in mp4 files needs the extradata to be useful.  The aac
> "muxer" I added yesterday ignores the extradata and happily writes the raw
> aac data to the output file.  Making sense of such a file is impossible.

Hmm, but somehow it works for encoding?!

> What exactly is it you want to be able to do?

My goal is to have standard compliant h264-in-mp4 files. With the
functionality you added I can make new files okay (raw h264/aac encoding
by ffmpeg, muxing by gpac). The "mp4" (muxed by ffmpeg itself) I already
had, I can process by having ffmpeg extract the h264 (gpac chokes on
this) and having gpac extract the aac (to adts). Then I can mux both
together and voila, isma mp4.

My ultimate goal is to have (of course) ffmpeg doing this correctly.

What's the devels' opinion on either replacing the mp4 muxer by a
gpac-lib-implementation or adding an alternative muxer based on
gpac-lib? I am not at all sure this will be easy/practical to do, but I
guess it will be a lot simpler than completely develop/test/debug a
native mp4 muxer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2771 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060208/5f5c701a/attachment.bin>

More information about the ffmpeg-devel mailing list