[FFmpeg-devel] avfilter: Enable in MP4 container both AMR-NB and AMR-WB

Submitted by Bob Kirnum on May 17, 2017, 11:04 a.m.

Details

Message ID CABhwSuJShZSo9RJuKwmckJ3LPUAPi8hu0yUxNHhB+=RSMNqAJg@mail.gmail.com
State New
Headers show

Commit Message

Bob Kirnum May 17, 2017, 11:04 a.m.
---
 libavformat/isom.c   | 2 ++
 libavformat/movenc.c | 2 ++
 2 files changed, 4 insertions(+)

MKTAG('s','a','m','r');
+    else if (track->par->codec_id == AV_CODEC_ID_AMR_WB)    tag =
MKTAG('s','a','w','b');
     else if (track->par->codec_type == AVMEDIA_TYPE_VIDEO)  tag =
MKTAG('m','p','4','v');
     else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO)  tag =
MKTAG('m','p','4','a');
     else if (track->par->codec_id == AV_CODEC_ID_DVD_SUBTITLE)  tag =
MKTAG('m','p','4','s');

Comments

Moritz Barsnick May 17, 2017, 11:21 a.m.
On Wed, May 17, 2017 at 07:04:07 -0400, Bob Kirnum wrote:

> Subject: [FFmpeg-devel] [PATCH] avfilter: Enable in MP4 container both AMR-NB and AMR-WB

This is not avfilter.

>      { AV_CODEC_ID_MPEG4SYSTEMS, 0x02 },
> +    { AV_CODEC_ID_AMR_NB      , MKTAG('s', 'a', 'm', 'r') }, /* AMR-NB 3gp
> */
> +    { AV_CODEC_ID_AMR_WB      , MKTAG('s', 'a', 'w', 'b') }, /* AMR-WB 3gp
> */
>      { AV_CODEC_ID_NONE        ,    0 },
>  };
[...]

Your patch is not usable due to line breaks inserted by your mailer.
Please attach the "git format-patch" patch as a file, or, better, use
"git send-email".

Moritz
Bob Kirnum May 17, 2017, 11:47 a.m.
Apologies.

On Wed, May 17, 2017 at 7:21 AM, Moritz Barsnick <barsnick@gmx.net> wrote:

> On Wed, May 17, 2017 at 07:04:07 -0400, Bob Kirnum wrote:
>
> > Subject: [FFmpeg-devel] [PATCH] avfilter: Enable in MP4 container both
> AMR-NB and AMR-WB
>
> This is not avfilter.
>
> >      { AV_CODEC_ID_MPEG4SYSTEMS, 0x02 },
> > +    { AV_CODEC_ID_AMR_NB      , MKTAG('s', 'a', 'm', 'r') }, /* AMR-NB
> 3gp
> > */
> > +    { AV_CODEC_ID_AMR_WB      , MKTAG('s', 'a', 'w', 'b') }, /* AMR-WB
> 3gp
> > */
> >      { AV_CODEC_ID_NONE        ,    0 },
> >  };
> [...]
>
> Your patch is not usable due to line breaks inserted by your mailer.
> Please attach the "git format-patch" patch as a file, or, better, use
> "git send-email".
>
> Moritz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos May 17, 2017, 11:52 a.m.
2017-05-17 13:04 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> ---
>  libavformat/isom.c   | 2 ++
>  libavformat/movenc.c | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 5522115..49ba735 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -69,6 +69,8 @@ const AVCodecTag ff_mp4_obj_type[] = {
>      { AV_CODEC_ID_QCELP       , 0xE1 },
>      { AV_CODEC_ID_MPEG4SYSTEMS, 0x01 },
>      { AV_CODEC_ID_MPEG4SYSTEMS, 0x02 },
> +    { AV_CODEC_ID_AMR_NB      , MKTAG('s', 'a', 'm', 'r') }, /* AMR-NB 3gp
> */
> +    { AV_CODEC_ID_AMR_WB      , MKTAG('s', 'a', 'w', 'b') }, /* AMR-WB 3gp
> */

Can you provide short samples (not produced with FFmpeg)?

> +    else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)    tag =
> MKTAG('s','a','m','r');
> +    else if (track->par->codec_id == AV_CODEC_ID_AMR_WB)    tag =
> MKTAG('s','a','w','b');

How did you test these?

Carl Eugen
Bob Kirnum May 17, 2017, 12:05 p.m.
Backwards compatibility tested running complete FATE testing.

Our media server can record to and play from MP4 containing H.264 and / or
AMR-NB / WB.  The codecs are proprietary implementations.  We use
libavformat for MP4 containers.  The recorded containers can be played back
using third party tools (open source implementations).

On Wed, May 17, 2017 at 7:52 AM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
wrote:

> 2017-05-17 13:04 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> > ---
> >  libavformat/isom.c   | 2 ++
> >  libavformat/movenc.c | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/libavformat/isom.c b/libavformat/isom.c
> > index 5522115..49ba735 100644
> > --- a/libavformat/isom.c
> > +++ b/libavformat/isom.c
> > @@ -69,6 +69,8 @@ const AVCodecTag ff_mp4_obj_type[] = {
> >      { AV_CODEC_ID_QCELP       , 0xE1 },
> >      { AV_CODEC_ID_MPEG4SYSTEMS, 0x01 },
> >      { AV_CODEC_ID_MPEG4SYSTEMS, 0x02 },
> > +    { AV_CODEC_ID_AMR_NB      , MKTAG('s', 'a', 'm', 'r') }, /* AMR-NB
> 3gp
> > */
> > +    { AV_CODEC_ID_AMR_WB      , MKTAG('s', 'a', 'w', 'b') }, /* AMR-WB
> 3gp
> > */
>
> Can you provide short samples (not produced with FFmpeg)?
>
> > +    else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)    tag =
> > MKTAG('s','a','m','r');
> > +    else if (track->par->codec_id == AV_CODEC_ID_AMR_WB)    tag =
> > MKTAG('s','a','w','b');
>
> How did you test these?
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos May 17, 2017, 12:11 p.m.
2017-05-17 14:05 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> Backwards compatibility tested running complete FATE testing.

What I meant was:
Do you have samples that were not created with FFmpeg, and
cannot be decoded with FFmpeg without your patch, but can
with the patch?

> Our media server can record to and play from MP4 containing
> H.264 and / or AMR-NB / WB.  The codecs are proprietary
> implementations.  We use libavformat for MP4 containers.
> The recorded containers can be played back
> using third party tools (open source implementations).

I would have expected tests with either vanilla WMP or QT.

Carl Eugen
Bob Kirnum May 17, 2017, 12:24 p.m.
Hey Carl.

I will provide samples on this thread.

Do WMP or QT support decoding AMR-NB / WB?

Bob

On Wed, May 17, 2017 at 8:11 AM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
wrote:

> 2017-05-17 14:05 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> > Backwards compatibility tested running complete FATE testing.
>
> What I meant was:
> Do you have samples that were not created with FFmpeg, and
> cannot be decoded with FFmpeg without your patch, but can
> with the patch?
>
> > Our media server can record to and play from MP4 containing
> > H.264 and / or AMR-NB / WB.  The codecs are proprietary
> > implementations.  We use libavformat for MP4 containers.
> > The recorded containers can be played back
> > using third party tools (open source implementations).
>
> I would have expected tests with either vanilla WMP or QT.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Hendrik Leppkes May 17, 2017, 12:27 p.m.
On Wed, May 17, 2017 at 2:05 PM, Bob Kirnum <bkirnum@gmail.com> wrote:
> Backwards compatibility tested running complete FATE testing.
>
> Our media server can record to and play from MP4 containing H.264 and / or
> AMR-NB / WB.  The codecs are proprietary implementations.  We use
> libavformat for MP4 containers.  The recorded containers can be played back
> using third party tools (open source implementations).
>

So are you saying that there is no official specification for AMR in
MP4, and these files are only compatible with your proprietary
software?
We generally require a proper specification to ensure we mux files that work.

- Hendrik
Bob Kirnum May 17, 2017, 12:34 p.m.
Sorry, I am just coming up to speed with this.  I am not the originator of
this implementation, I cleaned it up and now handling this submission
process.

I am told we tested with VLC and QT.  However, QT only supports AMR-NB.
WMP does not support AMR at all.

On Wed, May 17, 2017 at 8:27 AM, Hendrik Leppkes <h.leppkes@gmail.com>
wrote:

> On Wed, May 17, 2017 at 2:05 PM, Bob Kirnum <bkirnum@gmail.com> wrote:
> > Backwards compatibility tested running complete FATE testing.
> >
> > Our media server can record to and play from MP4 containing H.264 and /
> or
> > AMR-NB / WB.  The codecs are proprietary implementations.  We use
> > libavformat for MP4 containers.  The recorded containers can be played
> back
> > using third party tools (open source implementations).
> >
>
> So are you saying that there is no official specification for AMR in
> MP4, and these files are only compatible with your proprietary
> software?
> We generally require a proper specification to ensure we mux files that
> work.
>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos May 17, 2017, 1:23 p.m.
2017-05-17 14:27 GMT+02:00 Hendrik Leppkes <h.leppkes@gmail.com>:
> On Wed, May 17, 2017 at 2:05 PM, Bob Kirnum <bkirnum@gmail.com> wrote:
>> Backwards compatibility tested running complete FATE testing.
>>
>> Our media server can record to and play from MP4 containing H.264 and / or
>> AMR-NB / WB.  The codecs are proprietary implementations.  We use
>> libavformat for MP4 containers.  The recorded containers can be played back
>> using third party tools (open source implementations).
>>
>
> So are you saying that there is no official specification for AMR in
> MP4, and these files are only compatible with your proprietary
> software?

It says here (afaict) that such a specification exists:
http://www.mp4ra.org/codecs.html

I thought that demuxing should already be supported and
that muxing may need specific atoms.

Carl Eugen
Bob Kirnum May 17, 2017, 9:26 p.m.
Did not realize the files I shared were too large.  I copied them to a
shared Google Drive here . . .

https://drive.google.com/drive/folders/0B-TtYdUjPHBmM29uWkU4aHdReE0?usp=sharing

On Wed, May 17, 2017 at 3:30 PM, Bob Kirnum <bkirnum@gmail.com> wrote:

> Sorry for the delay.  Attached are two examples.  Both files play on
> Windows 10 using the 'Movies & TV' app, only the AMR-NB file has audio.
> Both play fine using VLC with audio.
>
> Thanks,
> Bob
>
> On Wed, May 17, 2017 at 9:23 AM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>
>> 2017-05-17 14:27 GMT+02:00 Hendrik Leppkes <h.leppkes@gmail.com>:
>> > On Wed, May 17, 2017 at 2:05 PM, Bob Kirnum <bkirnum@gmail.com> wrote:
>> >> Backwards compatibility tested running complete FATE testing.
>> >>
>> >> Our media server can record to and play from MP4 containing H.264 and
>> / or
>> >> AMR-NB / WB.  The codecs are proprietary implementations.  We use
>> >> libavformat for MP4 containers.  The recorded containers can be played
>> back
>> >> using third party tools (open source implementations).
>> >>
>> >
>> > So are you saying that there is no official specification for AMR in
>> > MP4, and these files are only compatible with your proprietary
>> > software?
>>
>> It says here (afaict) that such a specification exists:
>> http://www.mp4ra.org/codecs.html
>>
>> I thought that demuxing should already be supported and
>> that muxing may need specific atoms.
>>
>> Carl Eugen
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
Carl Eugen Hoyos May 18, 2017, 12:01 a.m.
2017-05-17 23:26 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> Did not realize the files I shared were too large.  I copied them to a
> shared Google Drive here . . .

The question was if you have files that were not created with FFmpeg.

Anyway: Since both files can be decoded with unpatched FFmpeg, I
assume the demuxing hunk of your patch is unneeded, correct?

Any reason why you cannot use mov for muxing?

Carl Eugen
Bob Kirnum May 18, 2017, 12:34 p.m.
Hey Carl,

I am not aware of non-FFmpeg apps which can record to MP4 containing AMR.
That's not to say one does not exist.

I would agree that we likely need no changes for playing these MP4 files.

The MP4 requirement was from one of our customers.

Thanks,
Bob

On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
wrote:

> 2017-05-17 23:26 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
> > Did not realize the files I shared were too large.  I copied them to a
> > shared Google Drive here . . .
>
> The question was if you have files that were not created with FFmpeg.
>
> Anyway: Since both files can be decoded with unpatched FFmpeg, I
> assume the demuxing hunk of your patch is unneeded, correct?
>
> Any reason why you cannot use mov for muxing?
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Bob Kirnum May 19, 2017, 2:19 p.m.
I tried adding support for MOV to see if I could use unpatched FFmpeg
libraries.  Although both AMR-NB and AMR-WB do appear to record to MOV,
neither result plays properly using QuickTime or Windows 'Movies & TV'
app.  The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video.
Appears that the MOV contains two moov atoms, one for audio one for video.
Similar is true for AMR-WB, however, there is never audio as QuickTime and
Windows app do not support AMR-WB.

I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz).  MP4
rejects the codec, MOV seems to have a similar issue as AMR, only video
plays.

I am using the exact same code as we use for MP4 so I am not sure what we
are doing wrong.  Any suggestions for how to debug this?

The recorded files are here . . .

https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0

big-buck-bunny_trailer.h264_s16le.mov
big-buck-bunny_trailer.h264_amrnb.mov
big-buck-bunny_trailer.h264_amrwb.mov

Thanks,
Bob

On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum <bkirnum@gmail.com> wrote:

> Hey Carl,
>
> I am not aware of non-FFmpeg apps which can record to MP4 containing AMR.
> That's not to say one does not exist.
>
> I would agree that we likely need no changes for playing these MP4 files.
>
> The MP4 requirement was from one of our customers.
>
> Thanks,
> Bob
>
> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>
>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
>> > Did not realize the files I shared were too large.  I copied them to a
>> > shared Google Drive here . . .
>>
>> The question was if you have files that were not created with FFmpeg.
>>
>> Anyway: Since both files can be decoded with unpatched FFmpeg, I
>> assume the demuxing hunk of your patch is unneeded, correct?
>>
>> Any reason why you cannot use mov for muxing?
>>
>> Carl Eugen
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
Bob Kirnum May 22, 2017, 3:41 p.m.
The MOV issue I am working on is likely an issue with our framework.  I
hope to have this resolved soon.

Assuming MOV works, we still would like to use MP4 with AMR NB/WB.  What is
the difficulty with enabling this?  Seems it has been updated to accept
Opus recently.

Bob

On Fri, May 19, 2017 at 10:19 AM, Bob Kirnum <bkirnum@gmail.com> wrote:

> I tried adding support for MOV to see if I could use unpatched FFmpeg
> libraries.  Although both AMR-NB and AMR-WB do appear to record to MOV,
> neither result plays properly using QuickTime or Windows 'Movies & TV'
> app.  The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video.
> Appears that the MOV contains two moov atoms, one for audio one for video.
> Similar is true for AMR-WB, however, there is never audio as QuickTime and
> Windows app do not support AMR-WB.
>
> I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz).  MP4
> rejects the codec, MOV seems to have a similar issue as AMR, only video
> plays.
>
> I am using the exact same code as we use for MP4 so I am not sure what we
> are doing wrong.  Any suggestions for how to debug this?
>
> The recorded files are here . . .
>
> https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0
>
> big-buck-bunny_trailer.h264_s16le.mov
> big-buck-bunny_trailer.h264_amrnb.mov
> big-buck-bunny_trailer.h264_amrwb.mov
>
> Thanks,
> Bob
>
> On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum <bkirnum@gmail.com> wrote:
>
>> Hey Carl,
>>
>> I am not aware of non-FFmpeg apps which can record to MP4 containing
>> AMR.  That's not to say one does not exist.
>>
>> I would agree that we likely need no changes for playing these MP4 files.
>>
>> The MP4 requirement was from one of our customers.
>>
>> Thanks,
>> Bob
>>
>> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> wrote:
>>
>>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
>>> > Did not realize the files I shared were too large.  I copied them to a
>>> > shared Google Drive here . . .
>>>
>>> The question was if you have files that were not created with FFmpeg.
>>>
>>> Anyway: Since both files can be decoded with unpatched FFmpeg, I
>>> assume the demuxing hunk of your patch is unneeded, correct?
>>>
>>> Any reason why you cannot use mov for muxing?
>>>
>>> Carl Eugen
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>>
>
Bob Kirnum May 22, 2017, 6:06 p.m.
I resolved our issue with the MOV changes and now have H.264 / AMR-NB and
H.264 / AMR-WB recording to MOV using non-patched FFmpeg.  The former plays
in both QuickTime and the Windows 10 'Movies & TV' app, video and audio.
The MOV containing AMR-WB plays video only in QuickTime and neither in the
Windows 10 'Movies & TV' app.  This is equivalent to the MP4 files we
record with our proposed patch.

On Mon, May 22, 2017 at 11:41 AM, Bob Kirnum <bkirnum@gmail.com> wrote:

> The MOV issue I am working on is likely an issue with our framework.  I
> hope to have this resolved soon.
>
> Assuming MOV works, we still would like to use MP4 with AMR NB/WB.  What
> is the difficulty with enabling this?  Seems it has been updated to accept
> Opus recently.
>
> Bob
>
> On Fri, May 19, 2017 at 10:19 AM, Bob Kirnum <bkirnum@gmail.com> wrote:
>
>> I tried adding support for MOV to see if I could use unpatched FFmpeg
>> libraries.  Although both AMR-NB and AMR-WB do appear to record to MOV,
>> neither result plays properly using QuickTime or Windows 'Movies & TV'
>> app.  The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video.
>> Appears that the MOV contains two moov atoms, one for audio one for video.
>> Similar is true for AMR-WB, however, there is never audio as QuickTime and
>> Windows app do not support AMR-WB.
>>
>> I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz).  MP4
>> rejects the codec, MOV seems to have a similar issue as AMR, only video
>> plays.
>>
>> I am using the exact same code as we use for MP4 so I am not sure what we
>> are doing wrong.  Any suggestions for how to debug this?
>>
>> The recorded files are here . . .
>>
>> https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0
>>
>> big-buck-bunny_trailer.h264_s16le.mov
>> big-buck-bunny_trailer.h264_amrnb.mov
>> big-buck-bunny_trailer.h264_amrwb.mov
>>
>> Thanks,
>> Bob
>>
>> On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum <bkirnum@gmail.com> wrote:
>>
>>> Hey Carl,
>>>
>>> I am not aware of non-FFmpeg apps which can record to MP4 containing
>>> AMR.  That's not to say one does not exist.
>>>
>>> I would agree that we likely need no changes for playing these MP4 files.
>>>
>>> The MP4 requirement was from one of our customers.
>>>
>>> Thanks,
>>> Bob
>>>
>>> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
>>> wrote:
>>>
>>>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum <bkirnum@gmail.com>:
>>>> > Did not realize the files I shared were too large.  I copied them to a
>>>> > shared Google Drive here . . .
>>>>
>>>> The question was if you have files that were not created with FFmpeg.
>>>>
>>>> Anyway: Since both files can be decoded with unpatched FFmpeg, I
>>>> assume the demuxing hunk of your patch is unneeded, correct?
>>>>
>>>> Any reason why you cannot use mov for muxing?
>>>>
>>>> Carl Eugen
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>
>>>
>>
>

Patch hide | download patch | download mbox

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 5522115..49ba735 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -69,6 +69,8 @@  const AVCodecTag ff_mp4_obj_type[] = {
     { AV_CODEC_ID_QCELP       , 0xE1 },
     { AV_CODEC_ID_MPEG4SYSTEMS, 0x01 },
     { AV_CODEC_ID_MPEG4SYSTEMS, 0x02 },
+    { AV_CODEC_ID_AMR_NB      , MKTAG('s', 'a', 'm', 'r') }, /* AMR-NB 3gp
*/
+    { AV_CODEC_ID_AMR_WB      , MKTAG('s', 'a', 'w', 'b') }, /* AMR-WB 3gp
*/
     { AV_CODEC_ID_NONE        ,    0 },
 };

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d20d272..7f44163 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1241,6 +1241,8 @@  static int mp4_get_codec_tag(AVFormatContext *s,
MOVTrack *track)
     else if (track->par->codec_id == AV_CODEC_ID_VC1)       tag =
MKTAG('v','c','-','1');
     else if (track->par->codec_id == AV_CODEC_ID_FLAC)      tag =
MKTAG('f','L','a','C');
     else if (track->par->codec_id == AV_CODEC_ID_OPUS)      tag =
MKTAG('O','p','u','s');
+    else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)    tag =