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 D15FD435AB for ; Fri, 17 Jun 2022 10:46:30 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 86A6668B8B1; Fri, 17 Jun 2022 13:46:27 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3D65C689B6B for ; Fri, 17 Jun 2022 13:46:20 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 6144E240175 for ; Fri, 17 Jun 2022 12:46:19 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RP6WI1TOyqGb for ; Fri, 17 Jun 2022 12:46:18 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 3514F2400F5 for ; Fri, 17 Jun 2022 12:46:18 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 552561601B2; Fri, 17 Jun 2022 12:46:18 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDB6PR0101MB2214DA9E20F3E164B930D87B8FAC9=40DB6PR01?= =?utf-8?q?01MB2214=2Eeurprd01=2Eprod=2Eexchangelabs=2Ecom=3E?= References: <20220616195534.5278-1-anton@khirnov.net> <20220616195534.5278-24-anton@khirnov.net> =?utf-8?q?=3CDB6PR0101MB2214DA9E?= =?utf-8?q?20F3E164B930D87B8FAC9=40DB6PR0101MB2214=2Eeurprd01=2Eprod=2Eexcha?= =?utf-8?q?ngelabs=2Ecom=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 17 Jun 2022 12:46:18 +0200 Message-ID: <165546277831.13099.11304958668330237723@lain> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 24/35] fftools/ffmpeg: use the sync queues to handle -frames 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: Quoting Andreas Rheinhardt (2022-06-16 22:33:46) > Anton Khirnov: > > Same issues apply to it as to -shortest. > > > > Changes the results of the following tests: > > - matroska-flac-extradata-update > > The test reencodes two input FLAC streams into three output FLAC > > streams. The last output stream is limited to 8 frames. The current > > code results in the first two output streams having 12 frames, after > > this commit all three streams have 8 frames and are the same length. > > This new result is better, since it is predictable. > > The point of the test was that only one stream is limited so that one > can see the extradata update directly in the test result: The unlimited > streams have a different extradata than the limited stream (because said > extradata contains an md5 of the decoded data). So it is expected that > the extradata hashes of the first two streams coincide and differ from > the hash of the last stream. Right, but my point is that the amount of data that ends up in those unlimited streams is largely an accident of how the code happens to work currently and is not guaranteed by anything. Are you suggesting any specific changes to the test or the patch? E.g. the atrim filter could be used to replicate previous behaviour if you'd like to keep it. > (The current test results btw show an imperfection: The extradata of the > last stream is not updated, as the encoder is not flushed (or the flush > packet does not arrive at the muxer). Fixing this (as seems to be the > case) is good.) Correct - frame-limiting is now done before sending frames to the encoder, so all packets, including the one from flushing the encoder, get to the muxer. -- Anton Khirnov _______________________________________________ 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".