On 2012-08-09 11:36:48 +0300, Martin Storsjö wrote: > On Tue, 24 Jul 2012, Kieran Kunhya wrote: > > > On Mon, Jul 23, 2012 at 6:56 PM, Alex Converse <[email protected]> > > wrote: > >> > >> Don't we use a separate codec id for LATM or is that for decoding only? > > > > I'm not really sure whether that codec id is appropriate to use in > > this instance. > > I'm looking into muxing AAC ELD into mpegts, and I stumbled upon some > issues related to this. ELD can't be muxed into ADTS, so it has to be > wrapped in LATM in mpegts. > > In order to do that, we can either have the mpegts muxer convert it into > LATM ("-aflags +global_header -mpegts_flags latm", globla header so that > the encoder outputs it in a format that the chained latm muxer can handle) > or make the fdk-aac encoder output it in LATM form from the start, with > "-latm 1". > > The former case fails since the LATM muxer currently doesn't support AOTs > above SBR, and for (E)LD, the ASC contains more bits that we'd have to > copy into the LATM stream mux config.
I'll can extend the muxer. > The latter case fails, since if using -latm 1, it still uses the normal > AAC codec id, and the mpegts muxer can't identify it as LATM (ending up > with "AAC bitstream not in ADTS format and extradata missing"). If I make > the fdk-aac wrapper change the codec id to AV_CODEC_ID_AAC_LATM if the > latm flag is set, this seems to work fine. But is it even valid for an > encoder to change the codec id during initialization? I think the addition of AV_CODEC_ID_AAC_LATM wasn't a good idea and we should try to avoid. The proper way to would be to copy the encoder struct and change the codec id to AV_CODEC_ID_AAC_LATM. My prefered solution is to support it in the latm muxer though. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
