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. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
