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 7308045EFC for ; Mon, 17 Apr 2023 17:27:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9CD1968BE67; Mon, 17 Apr 2023 20:27:11 +0300 (EEST) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 99813689E1F for ; Mon, 17 Apr 2023 20:27:04 +0300 (EEST) Received: by mail-oi1-f173.google.com with SMTP id bb20so12305256oib.12 for ; Mon, 17 Apr 2023 10:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681752423; x=1684344423; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=j6rGV83CseVyRfW3xiKXH/mZdfPVUZKpcrEeGc5qL0E=; b=Jq7NIQE07A2AqR0xhC6DxZkA8Ep5o40YBw4td6l57pl9MIlIYBrHYONBBupr1Zli3B RFSUsrMN3xsfjb8kXXWtvWrI0JnzVGr88jOSea2+tTS5Z/G1Zc7IP7QBCgvH8tvHelbQ a3do/lMmkmh5J7h+18ycNwRkCcIDlS5Hl8hGPhFVJAeiBOEi0EVTctlbQD39eW7BOFDS ZPiGtisXK7+sCpIWTs2yjzsCROS8LakxmKMlaBM3A5CQbR5LoIcghvh3fyyOYfLtqU/+ sRDpnOCMTfrQYVHlAutEkzj45yKiZE1ltes45o37lEDbORLmvC98u/6S6VnCApZI/k8t GOlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681752423; x=1684344423; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=j6rGV83CseVyRfW3xiKXH/mZdfPVUZKpcrEeGc5qL0E=; b=jT5StbyfISqaj/DBm3OQNxbWgMUsgv0ND09U1alNrWPo3XW3x3JxAassFRNJD0z8ZJ b7U9Hh3SRiOklB0ur0sU9D+NBd3B1UiK+zAT+sLviLprWIPkeGEOPeprwvbxNB6kfrWG coPBLx9KzHrIXwAaZcEZ3psWFXHHMuev7cx0s2LF09DHINuJRevFtWsCsrrltJ3t6ogM jHbtx1/1rLL0PLBFt3S81rAMqYYDYB31x17IZkCJ41mKIvqxPREID2Br6aYSRyrr4Ind hAxPyw9i43DPOV6cYMrl1Yfj72jsld58OK93vDrF9OYz/xwNtP0Ufvzijc+PG+St96XR ZGBQ== X-Gm-Message-State: AAQBX9dAIRnUZQ0LHVNLjzbdBD9UBR50+F+WxC/U6ArLIzeoj7tYOXPH PszMZ7YL5S1i6fwgC56tcErkrMEIuT0= X-Google-Smtp-Source: AKy350adSZQs2jMG2qbU+taCh49+FVfVPpYPSZ34rzEVzi9fUWI/cTr/DCrCpGyzesahwfpuzs4hgw== X-Received: by 2002:a05:6808:2201:b0:38d:e2b0:d5ea with SMTP id bd1-20020a056808220100b0038de2b0d5eamr4060925oib.44.1681752422809; Mon, 17 Apr 2023 10:27:02 -0700 (PDT) Received: from [192.168.0.15] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id bi9-20020a056808188900b00387160bcd46sm4828705oib.46.2023.04.17.10.27.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Apr 2023 10:27:02 -0700 (PDT) Message-ID: <0ff1089c-a964-21a8-a8f9-0f7c39ba63f9@gmail.com> Date: Mon, 17 Apr 2023 14:27:01 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230417143930.1186-1-jamrial@gmail.com> From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avutil/frame: use bitfields for some boolean and enum fields 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 4/17/2023 2:25 PM, Lynne wrote: > Apr 17, 2023, 17:15 by jamrial@gmail.com: > >> On 4/17/2023 12:00 PM, Lynne wrote: >> >>> Apr 17, 2023, 16:40 by jamrial@gmail.com: >>> >>>> Should reduce the size of AVFrame in the next major bump without changing the API. >>>> >>>> Suggested-by: Anton Khirnov >>>> Signed-off-by: James Almer >>>> --- >>>> This supersedes "avutil/frame: add new interlaced and top_field_first flags" >>>> and "avutil/frame: add a keyframe flag to AVFrame". >>>> >>>> libavutil/frame.h | 56 +++++++++++++++++++++++++++++++++++++++++++++ >>>> libavutil/version.h | 1 + >>>> 2 files changed, 57 insertions(+) >>>> >>>> diff --git a/libavutil/frame.h b/libavutil/frame.h >>>> index f85d630c5c..c26067f383 100644 >>>> --- a/libavutil/frame.h >>>> +++ b/libavutil/frame.h >>>> @@ -416,6 +416,7 @@ typedef struct AVFrame { >>>> */ >>>> int format; >>>> +#if FF_API_BITFIELDS >>>> /** >>>> * 1 -> keyframe, 0-> not >>>> */ >>>> @@ -425,6 +426,57 @@ typedef struct AVFrame { >>>> * Picture type of the frame. >>>> */ >>>> enum AVPictureType pict_type; >>>> +#else >>>> + /** >>>> + * 1 -> keyframe, 0-> not >>>> + */ >>>> + unsigned int key_frame: 1; >>>> + >>>> + /** >>>> + * The content of the picture is interlaced. >>>> + */ >>>> + unsigned int interlaced_frame: 1; >>>> + >>>> + /** >>>> + * If the content is interlaced, is top field displayed first. >>>> + */ >>>> + unsigned int top_field_first: 1; >>>> + >>>> + /** >>>> + * Tell user application that palette has changed from previous frame. >>>> + */ >>>> + unsigned int palette_has_changed: 1; >>>> + >>>> + /** >>>> + * Reserved. Must not be touched. >>>> + */ >>>> + unsigned int reserved_bitfield: (sizeof(unsigned int) * 8) - 9; >>>> + >>>> + /** >>>> + * MPEG vs JPEG YUV range. >>>> + * - encoding: Set by user >>>> + * - decoding: Set by libavcodec >>>> + */ >>>> + enum AVColorRange color_range: 2; >>>> + >>>> + enum AVChromaLocation chroma_location: 3; >>>> >>> >>> Definitely disagree on all non-8bit field limits. >>> The reserved_bitfield is especially ugly. >>> A few wasted bits wouldn't affect much, we don't even support building on 6502s. >>> Use bools, or limit them to 8bits so we can use bools when we bump? >>> The rest can be limited to 8bits. >>> >> >> I added reserved_bitfield to turn what otherwise will be compiler-injected padding into something that can be reused if we were to add new fields here instead of at the end of the struct. I can remove it if you prefer, and make color_range and chroma_location into :8. >> Like i told you on IRC, i want to keep these as enum and not change their type to uint8_t, _Bool, or anything like that. Also, i wouldn't be surprised if using _Bool breaks some old weird compilers. >> >> With this change, I'm replacing 40 bytes worth of fields with 8 bytes worth of fields with no API break. >> > > I'm fine with enums staying as enums, and limiting them to 8 bits. > I'm not fine with limiting flags to 1 bit or 2/3 bits. I'd like for them to > be limited to 8 bits, and changing their type to bool or uint8_t at the > bump. You're still saving at least 21 bytes. But why use 8 bits when we can use 1? _______________________________________________ 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".