From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id C6DA64E422 for ; Mon, 9 Jun 2025 20:24:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 8A8C468CEEE; Mon, 9 Jun 2025 23:24:36 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 5232C68C2C3 for ; Mon, 9 Jun 2025 23:24:30 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 794F0431EB for ; Mon, 9 Jun 2025 20:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1749500669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SkAGFPRFlHRKN/9ID+0W0jFWtGflbLDZwnLINd+DCpw=; b=Q092xc50RZgFWYEJPA6MwryJfpFM/z7WYNGcPVulShPGVKj41enk6TOB0gt3LKKsYrKAvF z10rlc2GCuFs8wTGo2um2YIf4lm2x9p7Zbrvk0Fp74gbsyMsTeJSomRt+7UX1wMz2Kccc3 Dx7ntYc9HSOjewwf1vC22EpunHMK6Fi0M+QMjKpTrDAFbGMppwfMFa29A+qZl5Z5vpK9Ew FwuRK2IVtM96CK/iSzcXgV59FyMD6t8+nbNMZneRaXigpowKmdvEswmG5FMd6yMUVc6c+y cS4voSyClbnSv+w2OXxtdRDIfjdCD7l6iDZGvIOo2EgjzpYFqOQb3bF1JBxuEg== Date: Mon, 9 Jun 2025 22:24:28 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250609202428.GS29660@pb2> References: <20250518122639.2958966-1-michael@niedermayer.cc> <20250518212323.GH29660@pb2> <81deebf3-9693-49e5-b14f-7863775b934e@gmail.com> MIME-Version: 1.0 In-Reply-To: <81deebf3-9693-49e5-b14f-7863775b934e@gmail.com> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeljeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeeigeektdejudffjefhteegjedtgeettefggedthfejgfevhfetgeekjedtvdfhveenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] avformat/framecrcenc: List types and checksums for for side data 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: multipart/mixed; boundary="===============0105773953534887821==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0105773953534887821== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FOoMwsxGyyUmiQOw" Content-Disposition: inline --FOoMwsxGyyUmiQOw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 07, 2025 at 11:54:03PM -0300, James Almer wrote: > On 5/18/2025 6:23 PM, Michael Niedermayer wrote: > > On Sun, May 18, 2025 at 11:43:14AM -0300, James Almer wrote: > > > On 5/18/2025 9:25 AM, Michael Niedermayer wrote: > > > > This allows detecting changes and regressions in side data related = code, same as what > > > > framecrc does for before already for packet data itself. > > > >=20 > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavformat/framecrcenc.c | 116 +- > > > > tests/ref/fate/autorotate | 2 +- > > > > tests/ref/fate/cover-art-mp3-id3v2-remux | 2 +- > > > > tests/ref/fate/ffmpeg-bsf-input | 10 +- > > > > tests/ref/fate/ffmpeg-spec-disposition | 2 +- > > > > tests/ref/fate/force_key_frames-source | 784 ++++++------ > > > > tests/ref/fate/force_key_frames-source-drop | 34 +- > > > > tests/ref/fate/force_key_frames-source-dup | 1224 +++++++++----= ------ > > > > tests/ref/fate/gapless-mp3 | 6 +- > > > > tests/ref/fate/h264_redundant_pps-side_data | 2 +- > > > > tests/ref/fate/id3v2-priv-remux | 2 +- > > > > tests/ref/fate/matroska-hdr10-plus-remux | 2 +- > > > > tests/ref/fate/matroska-ogg-opus-remux | 2 +- > > > > tests/ref/fate/matroska-opus-remux | 2 +- > > > > tests/ref/fate/matroska-vp8-alpha-remux | 14 +- > > > > tests/ref/fate/mov-cover-image | 2 +- > > > > tests/ref/fate/segment-mp4-to-ts | 250 ++-- > > > > tests/ref/fate/shortest | 100 +- > > > > tests/ref/fate/webm-hdr10-plus-remux | 2 +- > > > > tests/ref/fate/webm-webvtt-remux | 24 +- > > > > 20 files changed, 1346 insertions(+), 1236 deletions(-) > > > >=20 > > > > diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c > > > > index 2ba20f3aab4..96c2a82eb2a 100644 > > > > --- a/libavformat/framecrcenc.c > > > > +++ b/libavformat/framecrcenc.c > > > > @@ -21,8 +21,11 @@ > > > > #include > > > > +#include "config.h" > > > > #include "libavutil/adler32.h" > > > > #include "libavutil/avstring.h" > > > > +#include "libavutil/intreadwrite.h" > > > > +#include "libavutil/hdr_dynamic_metadata.h" > > > > #include "libavcodec/codec_id.h" > > > > #include "libavcodec/codec_par.h" > > > > @@ -48,6 +51,20 @@ static int framecrc_write_header(struct AVFormat= Context *s) > > > > return ff_framehash_write_header(s); > > > > } > > > > +static av_unused void inline bswap(char *buf, int offset, int size) > > > > +{ > > > > + if (size =3D=3D 8) { > > > > + uint64_t val =3D AV_RN64(buf + offset); > > > > + AV_WN64(buf + offset, av_bswap64(val)); > > > > + } else if (size =3D=3D 4) { > > > > + uint32_t val =3D AV_RN32(buf + offset); > > > > + AV_WN32(buf + offset, av_bswap32(val)); > > > > + } else if (size =3D=3D 2) { > > > > + uint16_t val =3D AV_RN16(buf + offset); > > > > + AV_WN16(buf + offset, av_bswap16(val)); > > > > + } > > > > +} > > > > + > > > > static int framecrc_write_packet(struct AVFormatContext *s, AVPa= cket *pkt) > > > > { > > > > uint32_t crc =3D av_adler32_update(0, pkt->data, pkt->size); > > > > @@ -58,11 +75,104 @@ static int framecrc_write_packet(struct AVForm= atContext *s, AVPacket *pkt) > > > > if (pkt->flags !=3D AV_PKT_FLAG_KEY) > > > > av_strlcatf(buf, sizeof(buf), ", F=3D0x%0X", pkt->flags); > > > > if (pkt->side_data_elems) { > > > > + int i; > > > > av_strlcatf(buf, sizeof(buf), ", S=3D%d", pkt->side_data= _elems); > > > > - for (int i =3D 0; i < pkt->side_data_elems; i++) { > > > > - av_strlcatf(buf, sizeof(buf), ", %8"SIZE_SPECIFIER, > > > > - pkt->side_data[i].size); > > > > + for (i=3D0; iside_data_elems; i++) { > > > > + const AVPacketSideData *const sd =3D &pkt->side_data[i= ]; > > > > + const uint8_t *data =3D sd->data; > > > > + uint32_t side_data_crc =3D 0; > > > > + > > > > + switch (sd->type) { > > >=20 > > > Wont this potentially introduce extra work for when we add new types? > >=20 > > no, it will be less work > >=20 > > because maintaining this in a seperate branch is the identical work > > but in addition its also the extra work due to the seperate branch. > > and it adds complexity if one wants to bisect. > >=20 > > Every hour i have to spend maintaining this or anything > > else in a seperate branch is an hour less i spend on the ffmpeg core > > repository. > You're seeing this the wrong way. I think partly you see my position wrong and partly we disagree a bit > You want this feature, and every day it's > not upstreamed, it's potential extra work in your local repo. That's on y= ou, I do my testing for FFmpeg. Not for me. I can stop all of it and it just me= ans i would have more time. [...] > The way this should be handled is: Does the project need it, or do > developers want it? no, thats close but its not the correct question. I think a better question is: does it improve FFmpeg. Where FFmpegs value is a weighted sum of many things like future features, future bugs, future speed, future #users, future #developers, ... "need" is too narrow, alot of things are good but not strictly needed "want" is emotional and subjective, does anyone want money without working ? Or just think of it that way. You have 2 companies, one that tries to maxim= ize future profits and one that does only what it needs or its members want ? If you had to take a bet with all the money you own, in which of the 2 would you invest ? We are not a company, but the principle is the same. For us its not profits in dollar terms but in user satisfaction maybe. > Because the extra work i talked about earlier is > potentially adding a case to the switch for every new side data type added > from now on, that you're putting on other developers' shoulders. This is true But also the extra tests take work off peoples sholders by recognizing bugs related to sidedata earlier >=20 > That said, I'm not against this in principle, but again, it will mean ext= ra > work when adding future side data types that encapsulate long elaborate > structs. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire --FOoMwsxGyyUmiQOw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaEdC+QAKCRBhHseHBAsP q2mCAKCNFChwjOHsw6DQnWU7XL8pRvsuQQCfcuSLe8PabIl7tB0M9Pc8sgBQa1c= =q/6V -----END PGP SIGNATURE----- --FOoMwsxGyyUmiQOw-- --===============0105773953534887821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============0105773953534887821==--