Message ID | 1476298710-74434-1-git-send-email-zhennihuang@google.com |
---|---|
State | New |
Headers | show |
Am 13.10.2016 19:03 schrieb "liangsi" <liangsi07@gmail.com>: > > --- > libavformat/isom.h | 1 + > libavformat/mov.c | 5 ++++- > 2 files changed, 5 insertions(+), 1 deletion(-) > Can you elaborate on the reasons of why someone would want this? Preferably in the commit message for future consideration. - Hendrik
> On Oct 13, 2016, at 1:56 PM, Hendrik Leppkes <h.leppkes@gmail.com> wrote: > > Am 13.10.2016 19:03 schrieb "liangsi" <liangsi07@gmail.com>: >> >> --- >> libavformat/isom.h | 1 + >> libavformat/mov.c | 5 ++++- >> 2 files changed, 5 insertions(+), 1 deletion(-) >> > > Can you elaborate on the reasons of why someone would want this? Preferably > in the commit message for future consideration. Shouldn't using the moov atom that is not detected within a free atom be the default? Can you elaborate on the reasons of why someone wouldn't want this? Dave
On Thu, Oct 13, 2016 at 9:54 PM, Dave Rice <dave@dericed.com> wrote: > > > On Oct 13, 2016, at 1:56 PM, Hendrik Leppkes <h.leppkes@gmail.com> > wrote: > > > > Am 13.10.2016 19:03 schrieb "liangsi" <liangsi07@gmail.com>: > >> > >> --- > >> libavformat/isom.h | 1 + > >> libavformat/mov.c | 5 ++++- > >> 2 files changed, 5 insertions(+), 1 deletion(-) > >> > > > > Can you elaborate on the reasons of why someone would want this? > Preferably > > in the commit message for future consideration. > > Shouldn't using the moov atom that is not detected within a free atom be > the default? Can you elaborate on the reasons of why someone wouldn't want > this? > Dave > > +1
Sorry about the second patch I sent. This option is for flexibility since some apps may not want to use the hidden atoms. On Thu, Oct 13, 2016 at 1:44 PM, Robert Krüger <krueger@lesspain.software> wrote: > On Thu, Oct 13, 2016 at 9:54 PM, Dave Rice <dave@dericed.com> wrote: > > > > > > On Oct 13, 2016, at 1:56 PM, Hendrik Leppkes <h.leppkes@gmail.com> > > wrote: > > > > > > Am 13.10.2016 19:03 schrieb "liangsi" <liangsi07@gmail.com>: > > >> > > >> --- > > >> libavformat/isom.h | 1 + > > >> libavformat/mov.c | 5 ++++- > > >> 2 files changed, 5 insertions(+), 1 deletion(-) > > >> > > > > > > Can you elaborate on the reasons of why someone would want this? > > Preferably > > > in the commit message for future consideration. > > > > Shouldn't using the moov atom that is not detected within a free atom be > > the default? Can you elaborate on the reasons of why someone wouldn't > want > > this? > > Dave > > > > +1 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
diff --git a/libavformat/isom.h b/libavformat/isom.h index 2246fed..6824f7e 100644 --- a/libavformat/isom.h +++ b/libavformat/isom.h @@ -214,6 +214,7 @@ typedef struct MOVContext { int use_absolute_path; int ignore_editlist; int ignore_chapters; + int ignore_moov_atom_in_free; int seek_individually; int64_t next_root_atom; ///< offset of the next root atom int export_all; diff --git a/libavformat/mov.c b/libavformat/mov.c index a15c8d1..1d80c09 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4848,7 +4848,8 @@ static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom) if (atom.size >= 8) { a.size = avio_rb32(pb); a.type = avio_rl32(pb); - if (a.type == MKTAG('f','r','e','e') && + if (!c->ignore_moov_atom_in_free && + a.type == MKTAG('f','r','e','e') && a.size >= 8 && c->moov_retry) { uint8_t buf[8]; @@ -5926,6 +5927,8 @@ static const AVOption mov_options[] = { 0, 1, FLAGS}, {"ignore_chapters", "", OFFSET(ignore_chapters), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS}, + {"ignore_moov_atom_in_free", "", OFFSET(ignore_moov_atom_in_free), AV_OPT_TYPE_BOOL, + {.i64 = 0}, 0, 1, FLAGS}, {"use_mfra_for", "use mfra for fragment timestamps", OFFSET(use_mfra_for), AV_OPT_TYPE_INT, {.i64 = FF_MOV_FLAG_MFRA_AUTO},