Quoting Hendrik Leppkes (2016-04-18 12:03:20) > On Mon, Apr 18, 2016 at 12:00 PM, Luca Barbato <[email protected]> wrote: > > On 18/04/16 10:47, Anton Khirnov wrote: > >> Quoting Luca Barbato (2016-04-14 12:48:25) > >>> On 14/04/16 12:21, wm4 wrote: > >>>> From: Michael Niedermayer <[email protected]> > >>>> > >>>> Signed-off-by: Michael Niedermayer <[email protected]> > >>>> --- > >>>> libavcodec/mmaldec.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c > >>>> index a0685ea..5986658 100644 > >>>> --- a/libavcodec/mmaldec.c > >>>> +++ b/libavcodec/mmaldec.c > >>>> @@ -166,7 +166,7 @@ static void ffmmal_stop_decoder(AVCodecContext > >>>> *avctx) > >>>> } > >>>> ctx->waiting_buffers_tail = NULL; > >>>> > >>>> - assert(avpriv_atomic_get(&ctx->packets_buffered) == 0); > >>>> + av_assert0(avpriv_atomic_get(&ctx->packets_buffered) == 0); > >>>> > >>>> ctx->frames_output = ctx->eos_received = ctx->eos_sent = > >>>> ctx->packets_sent = ctx->extradata_sent = 0; > >>>> } > >>>> > >>> > >>> I'd rather not. > >> > >> Why not? > >> > > > > For the same reason you do not link -lasan in release builds you'd > > distribute. > > > > (and generally you do not crash on purpose when you are touching > > hardware acceleration since that's the recipe for a reboot to cleanup > > the kernel state if module unloading fails, never tried with mmal though) > > > > The point of such an assertion is that when it would ever trigger, any > further execution would be much worse than just bailing out here and > now, because something crazy happened that would break everything > either way. > Controlled exit is better than undefined state and continueing anyway.
+153 -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
