| Message ID | CABhwSuJShZSo9RJuKwmckJ3LPUAPi8hu0yUxNHhB+=RSMNqAJg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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
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 >
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
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 >
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
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 >
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
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 >
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
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 >> > >
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
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 >
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 >> > >
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 >>> >> >> >
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 >>>> >>> >>> >> >
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 =
--- 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');