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 3465C4B09D for ; Mon, 27 May 2024 19:32:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9670568D4BE; Mon, 27 May 2024 22:32:55 +0300 (EEST) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3E57968AC15 for ; Mon, 27 May 2024 22:32:49 +0300 (EEST) Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6f8e859eb20so53654b3a.0 for ; Mon, 27 May 2024 12:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716838367; x=1717443167; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=u1wZS3pDrtWqyaL/N9P0iMVEB2kJ9f4TEcaVuzx4u5I=; b=PghXSHVysWis6mzWjJWs7E1z0XbU4XImnfqLojzFHjK4iV5eG2991wN0NBv0dMXTpY j6XsFVzD//9tFNpNK++Ge5iPSVr/JMQmPehTzHvB4W4jwQNEPE9uZLqj7S3GI+6C2fTP E3hwt4e6kDouao9L+kr1fleUv548GsLArbr2IPjJN3hVVswm6FhZRNK9MWYn+Wj9VpW1 IHZyXXrCEbgbHweQsuhyylWWj/hRay+HWgXs+HwDPoY8C/TEsKJT7NuBX276mcALCWae V208m045Uboe5nlozCETBFFwsBH7RQXgdfJ++ckmKojSCiM0c0cah/c2eJDLIe8C2wzU Lp6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716838367; x=1717443167; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u1wZS3pDrtWqyaL/N9P0iMVEB2kJ9f4TEcaVuzx4u5I=; b=T87eBtBKSjD6qZb5zhhU2ioMFojdShbJsh7N9M4Y844qJ37Iyd2B0Gwn3A1sUPkgcN KuPL4KLCx2M7e0+/GD/3K5s5fX7kKOFocRymfGBFZUzun78SQT7Yb73L6AggNWTwXkg2 fDjq3EJFvu5N4mg3rgVlu5Od7vyJPknt8YMJ9dD1zzRBmyE0/gTidvORQAhwYV4Uzso4 vVcZuFK4MV+wGavdlw7VxaeZUlvWiu8FYDyM1MMS/qxFgYe9T6Xas/0JUvnp7A+poyiK dOtP4aUpkx7yDuDkBHz9/oL/N9tDG5WDpuyp4ZfBRTf/t9ljhyENJkQeFh6tgjbs8GEb 7Z9Q== X-Gm-Message-State: AOJu0Yye5SFFN/diT2tI9BoqC8CzTmoDofmi5uVkKm2C2DK3xurFq1Fg z3kQm6ksntWrOjumUrSZjQo524jMGAvB/zi0XzRDOBphOP49NIsnkwHzpg== X-Google-Smtp-Source: AGHT+IE1Nvkx3x3/5UkJpLwqhnDCjxZm19YdgGB2OuZYEfeSo38nOgRuD1cJuCoSci6QbVjL5GUOmA== X-Received: by 2002:a05:6a20:2d26:b0:1af:bd03:3222 with SMTP id adf61e73a8af0-1b212f34294mr13256320637.45.1716838367020; Mon, 27 May 2024 12:32:47 -0700 (PDT) Received: from [192.168.0.10] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-68221892b75sm6329492a12.21.2024.05.27.12.32.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 May 2024 12:32:46 -0700 (PDT) Message-ID: Date: Mon, 27 May 2024 16:32:43 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240427003623.118199-1-michael@niedermayer.cc> <171679774316.28895.4366606367617414113@lain.khirnov.net> <20240527181105.GN2821752@pb2> <703eafba-1d9a-458b-a4ee-f2092a73bd83@gmail.com> <20240527192055.GO2821752@pb2> Content-Language: en-US From: James Almer In-Reply-To: <20240527192055.GO2821752@pb2> Subject: Re: [FFmpeg-devel] [PATCH] 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-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 5/27/2024 4:20 PM, Michael Niedermayer wrote: > On Mon, May 27, 2024 at 03:17:15PM -0300, James Almer wrote: >> On 5/27/2024 3:11 PM, Michael Niedermayer wrote: >>> On Mon, May 27, 2024 at 10:15:43AM +0200, Anton Khirnov wrote: >>>> Quoting Michael Niedermayer (2024-04-27 02:36:23) >>>>> This allows detecting issues in side data related code, same as what >>>>> framecrc does for before already for packet data itself. >>>>> >>>>> Signed-off-by: Michael Niedermayer >>>>> --- >>>> >>>> I am against this patch. Checksumming side data is a fundamentally wrong >>>> thing to do. >>> >>> It, or something equivalent is neccessary for regression testing. >>> (and it was you who asked also for the tests i run to be part of >>> fate. But here you object to it) >>> >>> You know, not checking side data is not checking it so differences would then not be >>> detected allowing for unintended changes to be introduced (aka bugs) >> >> You have seen how much code is needed to get hashing to work for all targets >> with some types, > > framecrcenc.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 73 insertions(+), 3 deletions(-) > > 70 more lines of code, in my patch > > If we need another 70 to handle some corner cases, no idea if we do, thats > still negligible IAMF and video_enc_params. And potential future types. It's not negligible. > > >> so it does feel like it's not the right thing to do. > > I dont think i can follow that logic Extra custom code to take into account specific side data types in order to output a common hash value. Do we really need to add that when we already have side data type specific parsing code to in ffprobe? > > >> ffprobe (and f_sidedata) are what should be used for actual integrity >> checks. > > ffprobe cannot test ffmpeg, ffmpeg is a seperate excutable I didn't say ffprobe should be used to test ffmpeg, i said ffprobe should be used to test side data integrity. > > If you suggest that side data should not be tested in FFmpeg while packet.data > should be tested. That position seems inconsistant to me > > If you suggest that neither side data nor packet.data should be tested in FFmpeg > iam confident that there would be a majority disagreeing. > > f_sidedata is not at the output of ffmpeg so even if it could test it, it > does not test the ffmpeg output. I meant {a,f}_showinfo, sorry. And it does not apply to packet side data, obviously. > We also dont replace running md5sum and framecrc on ffmpeg output by a bitstream > filter. > > Again, there is need to test what comes out of FFmpeg, thats at the muxer level > thats what framecrcenc does. Packet side data does not come out of ffmpeg, it comes out of libavformat (or libavcodec/libavfilter in the case of frame side data). A user of lavf can look at side data instead of needing a lavf muxer to print a hash that needs ad hoc code for it to match across targets. > > thx > > [...] > > > _______________________________________________ > 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". _______________________________________________ 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".