| Message ID | CAB0OVGrdLjUrzYA3xZpD9wmrsgdVvCqYx1WFBug-t1HFu7EqZw@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi Carl, Thanks for your reply. Setting strict_std_compliance to 2 could help in this case. However, as it is a global flag, it could influence other parts in demuxers. It is preferable if we can have control of whether to use moov in free with one separate flag. Thanks, Zhenni On Mon, Oct 24, 2016 at 2:54 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2016-10-24 23:11 GMT+02:00 Zhenni Huang <zhennihuang-at-google.com@ > ffmpeg.org>: > > [...] > > Does the following inlined patch help you? > > Carl Eugen > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 357d800..ed099fc 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -4884,6 +4884,7 @@ > a.type = avio_rl32(pb); > if (a.type == MKTAG('f','r','e','e') && > a.size >= 8 && > + c->fc->strict_std_compliance < FF_COMPLIANCE_VERY_STRICT > && > c->moov_retry) { > uint8_t buf[8]; > uint32_t *type = (uint32_t *)buf + 1; > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
2016-10-25 1:23 GMT+02:00 Zhenni Huang <zhennihuang-at-google.com@ffmpeg.org>: > Thanks for your reply. Setting strict_std_compliance to 2 could > help in this case. However, as it is a global flag, it could influence > other parts in demuxers. Yes, this is intended: If you don't want to read invalid mov files, it seems logical that you don't want to read other invalid files. Or do you have another use case? > It is preferable if we can have control of whether to use > moov in free with one separate flag. I disagree. Please do not top-post here, Carl Eugen
On Mon, Oct 24, 2016 at 4:48 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2016-10-25 1:23 GMT+02:00 Zhenni Huang <zhennihuang-at-google.com@ffm > peg.org>: > > > Thanks for your reply. Setting strict_std_compliance to 2 could > > help in this case. However, as it is a global flag, it could influence > > other parts in demuxers. > > Yes, this is intended: If you don't want to read invalid mov files, it > seems logical that you don't want to read other invalid files. > > Or do you have another use case? > > > It is preferable if we can have control of whether to use > > moov in free with one separate flag. > > I disagree. > > Please do not top-post here, Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Thanks Carl, I think setting strict_std_compliance is fine. Could please you apply the change? Sorry about the top-post, Zhenni
2016-10-31 21:33 GMT+01:00 Zhenni Huang <zhennihuang-at-google.com@ffmpeg.org>: > Thanks Carl, I think setting strict_std_compliance is fine. Could please > you apply the change? Done. Carl Eugen
On Tue, Nov 1, 2016 at 5:45 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2016-10-31 21:33 GMT+01:00 Zhenni Huang <zhennihuang-at-google.com@ > ffmpeg.org>: > > > Thanks Carl, I think setting strict_std_compliance is fine. Could please > > you apply the change? > > Done. > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Thanks!
diff --git a/libavformat/mov.c b/libavformat/mov.c index 357d800..ed099fc 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4884,6 +4884,7 @@ a.type = avio_rl32(pb); if (a.type == MKTAG('f','r','e','e') && a.size >= 8 && + c->fc->strict_std_compliance < FF_COMPLIANCE_VERY_STRICT && c->moov_retry) { uint8_t buf[8]; uint32_t *type = (uint32_t *)buf + 1;