On Tue, Jul 24, 2012 at 4:16 PM, Martin Storsjö <[email protected]> wrote: > On Tue, 24 Jul 2012, Kieran Kunhya wrote: > >> On Mon, Jul 23, 2012 at 6:56 PM, Alex Converse <[email protected]> >> wrote: >>> >>> On Mon, Jul 23, 2012 at 9:20 AM, Kieran Kunhya <[email protected]> >>> wrote: >>>> >>>> >>>> --- >>>> libavcodec/libfdk-aacenc.c | 15 ++++++++++++++- >>>> 1 file changed, 14 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c >>>> index f2c3fbd..4d7aa7b 100644 >>>> --- a/libavcodec/libfdk-aacenc.c >>>> +++ b/libavcodec/libfdk-aacenc.c >>>> @@ -33,6 +33,8 @@ typedef struct AACContext { >>>> int afterburner; >>>> int eld_sbr; >>>> int signaling; >>>> + int latm; >>>> + int header_period; >>>> >>>> AudioFrameQueue afq; >>>> } AACContext; >>>> @@ -45,6 +47,8 @@ static const AVOption aac_enc_options[] = { >>>> { "implicit", "Implicit backwards compatible signaling", 0, >>>> AV_OPT_TYPE_CONST, { 0 }, 0, 0, AV_OPT_FLAG_AUDIO_PARAM | >>>> AV_OPT_FLAG_ENCODING_PARAM, "signaling" }, >>>> { "explicit_sbr", "Explicit SBR, implicit PS signaling", 0, >>>> AV_OPT_TYPE_CONST, { 1 }, 0, 0, AV_OPT_FLAG_AUDIO_PARAM | >>>> AV_OPT_FLAG_ENCODING_PARAM, "signaling" }, >>>> { "explicit_hierarchical", "Explicit hierarchical signaling", 0, >>>> AV_OPT_TYPE_CONST, { 2 }, 0, 0, AV_OPT_FLAG_AUDIO_PARAM | >>>> AV_OPT_FLAG_ENCODING_PARAM, "signaling" }, >>>> + { "latm", "Output LATM/LOAS encapsulated data", >>>> offsetof(AACContext, >>>> latm), AV_OPT_TYPE_INT, { 0 }, 0, 1, AV_OPT_FLAG_AUDIO_PARAM | >>>> AV_OPT_FLAG_ENCODING_PARAM }, >>>> + { "header_period", "StreamMuxConfig and PCE repetition period (in >>>> frames)", offsetof(AACContext, header_period), AV_OPT_TYPE_INT, { 0 }, >>>> 0, >>>> 0xffff, AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM }, >>>> { NULL } >>>> }; >>>> >>> >>> 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. > > > What advantages does this have over the latm muxer (either using it directly > or via the mpegts muxer)? > > I'm ok with adding this at least - it might not be structurally ideal but > doesn't add too much kludge either. > > // Martin >
Their's writes the bit reservoir field properly (though that's not important for dvb). Their's also sticks multiple aac frames into a LATM frame which I haven't seen in the wild myself but I would assume is legitimate. I haven't looked at whether there's anything the API doesn't provide that we would need to mux ADTS or LATM. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
