Re: [libav-devel] [PATCH] libfdk-aacenc: add LATM/LOAS encapsulation support

[Martin Storsjö]

On Tue, 24 Jul 2012, Kieran Kunhya wrote:

On Mon, Jul 23, 2012 at 6:56 PM, Alex Converse <alex.conve...@gmail.com> wrote:
On Mon, Jul 23, 2012 at 9:20 AM, Kieran Kunhya <kier...@ob-encoder.com> 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
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel