[FFmpeg-devel] [PATCH 2/3] Provide local copies of avisynth_c.h, avxsynth_c.h, and avxsynth_c.h's requisite headers in compat/avisynth/. The versions of the headers are the same as those provided with x264 for consistency.

[d s]

> On Sun, Mar 3, 2013 at 4:29 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > However that statement makes me wonder: will there be any protection
> > against a avs script that makes AvxSynth call ffmpeg to open itself via
> > this demuxer and so on, resulting in an endless loop and at some point
> > crash?

> It uses swscale as a backend for the resizing functions, that's all
> that I know of, anyway.  Unless simply using the libraries can cause
> this too.  FFMS2 uses several more of the libraries.

> Would composing such a script to test whether it can cause an endless
> loop simply require tons of resizer use (or if FFMS2 is also at risk
> of it, opening lots of video files in variables - or maybe just one
> video in lots of duplicate variables - and then doing operations on
> them, e.g. splicing)?

AvxSynth does not directly not link to ffmpeg in its core. It loads a
port of ffms2 through the standard AviSynth plugin API and uses it to
implement scaling. This functionality can never result in circular
access to ffmpeg. However, it is true that a user could cause an
infinite loop/crash by attemping to open itself. This is the case
regardless of if it does so through FFmpegSource or directly by the
Import function. This is also the case on Windows, as (rather often)
users have noticed when mistyping their AVISource commands
(AVISource("thefile.avs") instead of AVISource("thefile.avi")).