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 DBE1D49172 for ; Sat, 4 May 2024 20:59:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EFCA268D60E; Sat, 4 May 2024 23:59:05 +0300 (EEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0558668D60D for ; Sat, 4 May 2024 23:58:58 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 05E38E0002 for ; Sat, 4 May 2024 20:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1714856338; 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=wQJCJLEgu0G0oYi6UDbFZnmOgZWw2G6Hci1VXb+MY74=; b=ZQL0tpPrXBJ68LeZlJyZyUtKDYRcaYg1vjeumo8pkRXK8llSX/QtQvj/TkIdrAFi6ZUdvg GOMRKie6OqLLetKM75Cb1IKtWPZi/QOFrCHRaP5XgMdoLT36y3kNeuYA+ZDBAyK8SbyjuB zr9XqQW0pNhDc6NznERaz1+CVWS7pluxNclryHUNDMrSh2eVw34wl56W7LlrQ4TEUVJ2ZM EEM6U+NTiP3c1qOsQCWDsZNex5+de2YspQiTh8xSTErk1eWAaIo+2ui3XXVkvLaFzJ1PY/ LWTtuvz8ca8xknETueFUqUGtxhz8sneMP7H4fk0BuUH2HT3ixCQAFGyA8s1H4w== Date: Sat, 4 May 2024 22:58:57 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240504205857.GW6420@pb2> References: <20240430231926.2506728-1-michael@niedermayer.cc> <8aa7804e-ce52-48ff-8909-dc4ca98763da@gmail.com> <51cfa301-0a67-484b-a68b-0c2d5e5ea9e8@gmail.com> MIME-Version: 1.0 In-Reply-To: <51cfa301-0a67-484b-a68b-0c2d5e5ea9e8@gmail.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH v3] avformat/framecrcenc: compute the checksum 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="===============3340269035184494240==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3340269035184494240== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L6F19Er05sWvQB2i" Content-Disposition: inline --L6F19Er05sWvQB2i Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 04, 2024 at 12:16:00PM -0300, James Almer wrote: > On 5/4/2024 5:34 AM, Marton Balint wrote: > >=20 > >=20 > > On Thu, 2 May 2024, James Almer wrote: > >=20 > > > On 5/2/2024 6:23 PM, Marton Balint wrote: > > > >=20 > > > >=20 > > > > =A0On Wed, 1 May 2024, Michael Niedermayer wrote: > > > >=20 > > > > > =A0This allows detecting issues in side data related code, same a= s what > > > > > =A0framecrc does for before already for packet data itself. > > > > >=20 > > > > > =A0This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e5= 7. > > > >=20 > > > > =A0Can you at least add an option which allows disabling dumping th= e side > > > > =A0data? Changing the format of framecrc output again and again is > > > > not very > > >=20 > > > The framehash/framemd5 muxer is versioned, which is what you should > > > use if you want parseable output. > >=20 > > Okay, but then the question is that why framecrc is using different code > > and options? >=20 > Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The > latter was renamed/aliased to framehash and made to use the AVHash API, > which supports all lavu hashing algorithms, and is versioned. > If anyone cared, framecrc could be also made into an alias of framehash t= hat > defaults to adler32 output, but it would result in a massive change to > reference files, if anything because AVHash initializes adler32 with a 1 > whereas framecrc does it with a 0. normally starting adler32 at 0 is bad as one could prefix by a 0 byte with no checksum change, but given we also show the size that spcific case isnt an issue can we make the initial value for adler32 configureable so as to improve lo= ng term stability of checksums ? (or add a adler32_1 to AVHash) thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. --L6F19Er05sWvQB2i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZjahjQAKCRBhHseHBAsP qy63AJ9lg+hGuJcnB/XjghZwBVfknqKg2wCfX2jKe7lXOWTlOtRvdCjHgdEMCOk= =wi8k -----END PGP SIGNATURE----- --L6F19Er05sWvQB2i-- --===============3340269035184494240== 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". --===============3340269035184494240==--