On Thu, Dec 08, 2016 at 07:48:46PM +0100, wm4 wrote: > On Thu, 8 Dec 2016 19:36:20 +0100 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote: > > > On Thu, 8 Dec 2016 18:37:42 +0100 > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > > > Suggested-by: Andreas Cadhalpun <andreas.cadhal...@googlemail.com> > > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > > > --- > > > > libavformat/options_table.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/libavformat/options_table.h b/libavformat/options_table.h > > > > index d5448e503f..19cb87ae4e 100644 > > > > --- a/libavformat/options_table.h > > > > +++ b/libavformat/options_table.h > > > > @@ -105,7 +105,7 @@ static const AVOption avformat_options[] = { > > > > {"format_whitelist", "List of demuxers that are allowed to be used", > > > > OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL }, > > > > CHAR_MIN, CHAR_MAX, D }, > > > > {"protocol_whitelist", "List of protocols that are allowed to be > > > > used", OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL }, > > > > CHAR_MIN, CHAR_MAX, D }, > > > > {"protocol_blacklist", "List of protocols that are not allowed to be > > > > used", OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL }, > > > > CHAR_MIN, CHAR_MAX, D }, > > > > -{"max_streams", "maximum number of streams", OFFSET(max_streams), > > > > AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D }, > > > > +{"max_streams", "maximum number of streams", OFFSET(max_streams), > > > > AV_OPT_TYPE_INT, { .i64 = 100 }, 0, INT_MAX, D }, > > > > {NULL}, > > > > }; > > > > > > > > > > That seems awfully low. Why limit stream count to 100, > > > > Is this too little for real world streams ? > > what limit would not interfere with a positive user experience ? > > > > > > > while allowing > > > e.g. 2GB large font attachments? > > > > theres no limit on attachments currently except the natural int size > > we may want to have a tighter limit there too > > > > > > This will lead to thousands of options tuning various limits that > 1. nobody wants to use, 2. even if they want, will not find, and 3. are > ugly and intrusive. > > And then there'll probably still be a way to easily OOM ffmpeg, and > using a sandbox will still be superior over setting these options.
Ive implemented the generic solution with one parameter in [FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage which you and others dont like i understand why this isnt liked and i understand why many seperate options arent liked but Either of them is needed or FFmpeg cannot saftely be used via normal lib mechanisms and must be run as a seperate process that the main app has to expect to crash with out of memory. (if the input is untrusted media) This is something the community must decide. A. Is a heap limit for av_*alloc*() acceptable ? B. Are case based limits acceptable ? C. document that libavcodec, libavformat and ffmpeg must be run as a seperate process if the media comes from untrusted sources. one of these options has to be choosen. also even if C is choosen, a small set of limits on the main parameters still is needed to allow efficient fuzzing, all issues reported by oss-fuzz recently are "hangs" due to slow decoding, with the pixel max patch it instead of being slow hits this: Picture size 512x65520 exceeds specified max pixel count 414719 in the case i tried [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel