On 5/4/16, 9:12 AM, "ffmpeg-devel on behalf of Hendrik Leppkes" <ffmpeg-devel-boun...@ffmpeg.org on behalf of h.lepp...@gmail.com> wrote:
>On Wed, May 4, 2016 at 5:01 PM, Felt, Patrick <patrick.f...@echostar.com> >wrote: >>> >>>[...] >>>> +/* libavfilter documentation says that filter init will be called only >>>> once. ffmpeg calls the init twice to enable it to validate >>>> + * the complex filtering has the right input and output pads. this allows >>>> us to bypass the first call if we've specified a stream >>>> + * specifier string */ >>>> +static int initRun=0; >>>> +static int uninitRun=0; >>> >>>You're not allowed to do this, it belongs in the local context. >> >> I did realize that there will be issues if I tried to load the filter twice. >> It wouldn’t function as expected with the current solution. The problem is >> that ffmpeg calls init twice with two different contexts so any values I set >> in the context are cleared on the second run. Indeed, the uninit() function >> is called after the first round. Named Pipes don’t like being opened and >> closed; the ffmpeg process on the other end terminates because the reader >> left and sent an EOF. I need a reasonable way to prevent opening a pipe >> twice. >> > >Global state is one of the things we will not allow under any >circumstances, however. >Its dangerous and usually a sign of trying to fix something on the >wrong side of a problem. Fair statement that I can fully understand (and get behind). That said, should I look at trying to patch ffmpeg then? I’m not sure the best place to fix this or the best way to even start tackling it. > >- Hendrik >_______________________________________________ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
