From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 370A7481C8 for ; Tue, 12 Dec 2023 18:38:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AA26968D107; Tue, 12 Dec 2023 20:38:09 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6052F68D0B5 for ; Tue, 12 Dec 2023 20:38:03 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id CF176E9A70 for ; Tue, 12 Dec 2023 19:38:02 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqc-dvQV1Qwv for ; Tue, 12 Dec 2023 19:37:58 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 12470E213F for ; Tue, 12 Dec 2023 19:37:58 +0100 (CET) Date: Tue, 12 Dec 2023 19:37:57 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <170238021813.8914.858553900721142755@lain.khirnov.net> Message-ID: <11543aff-ca4-8427-318e-44ea5f41d65e@passwd.hu> References: <20231206082220.5532-1-cus@passwd.hu> <20231206082220.5532-7-cus@passwd.hu> <170196664712.8914.15749136255711961223@lain.khirnov.net> <85f4ba43-ab24-2598-6346-28dfef2ee88e@passwd.hu> <170238021813.8914.858553900721142755@lain.khirnov.net> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 12 Dec 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-12-08 00:11:21) >> Wipe reminds me of the wipe effect. How about 'predecode_clear'? > > Fine with me I guess. > >>> >>>> + */ >>>> +#define AV_CODEC_FLAG_CLEAR (1 << 12) >>>> /** >>>> * Only decode/encode grayscale. >>>> */ >>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c >>>> index 2cfb3fcf97..f9b18a2c35 100644 >>>> --- a/libavcodec/decode.c >>>> +++ b/libavcodec/decode.c >>>> @@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS >>>> >>>> validate_avframe_allocation(avctx, frame); >>>> >>>> + if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type == AVMEDIA_TYPE_VIDEO) { >>>> + uint32_t color[4] = {0}; >>>> + ptrdiff_t linesize[4] = {frame->linesize[0], frame->linesize[1], frame->linesize[2], frame->linesize[3]}; >>>> + av_image_fill_color(frame->data, linesize, frame->format, color, frame->width, frame->height); >>> >>> Should this check for errors? >> >> Lack of error checking is intentional. av_image_fill_color might not >> support all pixel formats, definitely not support hwaccel formats. It >> might make sense to warn the user once, but I don't think propagating the >> error back is needed here. >> >> I primarily thought of this as a QC feature (even thought about making the >> color fill green by default to make it more noticeable (YUV green happens >> to be 0,0,0), but for that I'd need similar checks for colorspaces to >> what I have for fill_black())... > > As Mark said, I expect people to want to use it as a security feature. > So either it should work reliably, or it should be made very clear that > it's for debugging only. > > For non-hwaccel pixel formats, you can fall back on memsetting the > buffer to 0. IMHO for security you don't need to clear every frame, only new ones in the buffer pool. Considering that it only affects the first few frames, we might want to do that unconditionally, and not based on a flag. And it is better to do this on the buffer level (because you might not overwrite some bytes because of alignment with a color fill). So for this flag, I'd rather make it clear it is not security-related, and also that it has performance impact. Regards, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".