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 8F2D742872 for ; Tue, 5 Apr 2022 10:59:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 92D1168B137; Tue, 5 Apr 2022 13:59:39 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C5B9168A59A for ; Tue, 5 Apr 2022 13:59:33 +0300 (EEST) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 010EF49AAF for ; Tue, 5 Apr 2022 12:59:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1649156373; bh=ZfI8JMGsA7jGqbZC9RZ/hIUR++BLFuQWEKCoOzcDxkM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=sAT+dRrHNPUeXNb2IxL53+4kzMZ7zKzVPhL9zXKYLH4leOvyQzmGXokoyJKe19KBQ bgvqOLYyrScVgpxjSYOom1v5wEIopAjk1gkFX8GL9W76VdN/4wPaH/w8obiG+CpYrx pqZWJJx10MjSsrnLzJoB59BagyXHsZc4zfQS66Rk= Date: Tue, 5 Apr 2022 12:59:32 +0200 Message-ID: <20220405125932.GB55885@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: References: <20220328152612.95684-1-ffmpeg@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [PATCH v7 1/2] avcodec/pngenc: support writing iCCP chunks 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, 01 Apr 2022 15:31:16 +0200 Andreas Rheinhardt wrote: > Passing the PNGEncContext would be more natural. Changed. > Since db57a5370bd37105d389a45b04bf4970802407ec the callers' > max_packet_size are not size_t any more, but always 64bit (so that > there's no truncation in case size_t is 32bit). Changed. > ULONG_MAX is the maximum of unsigned long, yet deflateBound uses uLong. > The latter is a currently typedef for unsigned long, but do we want to > rely on that? The ordinary way to check for whethe a value can be > represented in a type is by "if (sd->size != (uLong)sd->size)" Changed. I didn't know about this trick, thanks. > AV_LOG_WARNING makes no sense given that you error out afterwards. > (And anyway: Is a log-message really needed for something that will > never happen in reality?) I think you're right. For JPEG it makes sense to keep around an error printout, because the JPEG profile limit is quite small in comparison (16 MB - the largest ICC profiles I have encountered in the wild are on the order of megabytes as well). But PNG supports up to 4 GB ICC profiles, which strains all conceivable credibility. Somebody would have to be deliberately trying to hit this limitation. Removed both error printouts (including the one about zlib misbehaving, equally unlikely). _______________________________________________ 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".