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 1AECA48399 for ; Fri, 1 Dec 2023 19:50:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 79C6A68CF75; Fri, 1 Dec 2023 21:50:00 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8B30768CE32 for ; Fri, 1 Dec 2023 21:49:53 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 50F0F2405ED for ; Fri, 1 Dec 2023 20:49:53 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id mzKoRh_vKoES for ; Fri, 1 Dec 2023 20:49:52 +0100 (CET) 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 72CDC24043D for ; Fri, 1 Dec 2023 20:49:52 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 4A9EF1601B9; Fri, 1 Dec 2023 20:49:52 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20231130204812.GQ3543730@pb2> <20231201111621.10989-1-anton@khirnov.net> <170144085892.8914.16673285602438268082@lain.khirnov.net> <170144198228.8914.6757885452665407226@lain.khirnov.net> <170144268666.8914.14610541165951753799@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 01 Dec 2023 20:49:52 +0100 Message-ID: <170146019227.8914.6674790290782283298@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture 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 Nicolas George (2023-12-01 16:25:04) > Anton Khirnov (12023-12-01): > > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316787.html > > So not Wednesday but Tursday three weeks ago. The Wednesday email was the one I linked to two emails ago. Here it is again: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317536.html > I did not agree that the current code was broken. > > > The current code is broken because its output depends on the order in > > which the frames from different inputs arrive at the filtergraph. It > > just so happens that it is deterministically broken currently. After > > this patchset it becomes non-deterministically broken, which forces me > > to do something about it. > > That is not true. The current code works and gives correct result if the > file is properly muxed: it cannot be said to be broken. I can definitely say it is broken and I already told you why. But if you want something more specific: * the output of your example with the current master changes depending on the number of decoder frame threads; my patch fixes that * in fate-filter-overlay-dvdsub-2397 subtitles appear two frames too early; again, my patch fixes that > > Your testcase offsets two streams by 60 seconds. > > Indeed. > > > That implies 60 seconds > > of buffering. You would get this same amount of bufering in the muxer if > > you did the same offsetting with transcoding or remuxing two streams > > from the same source. > > One can also avoid this buffering entirely by simply opening the file > > twice. > > You are wrong. You would be right if the offset had been in the opposite > direction. But in the case I chose, it is the subtitles stream that is > delayed, and 60 seconds of subtitles means a few dozens frames at most, > not many hundreds. > > Your change to the sub2video hearbeat makes it continuous, and turns the > few dozens frames into many hundreds: this is what is breaking. > > So I say it again: this test case is useful and currently works, include > it in your test case so that your patch series keeps the feature > working. > > I can consider sending a patch to add it to FATE, but not before Monday. > > Also, note that in the grand-parent message from the one you quoted > above, I gave you a solution to make it work. You told that it was > already what you did, but obviously it is not, so let us resolve this > misunderstanding. IIUC your suggestion was to send heartbeat packets from demuxer to decoder, then have the decoder forward them to filtergraph. That is EXACTLY what I'm doing in the final patch, see [1]. It also does not address this problem at all, because it is caused by the heartbeat processing code making decisions based on av_buffersrc_get_nb_failed_requests(), which fundamentally depends on what frames previously arrived on the video input. [1] https://git.khirnov.net/libav.git/tree/fftools/ffmpeg_demux.c?h=ffmpeg_threading#n527 https://git.khirnov.net/libav.git/tree/fftools/ffmpeg_dec.c?h=ffmpeg_threading#n406 -- 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".