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 584B848518 for ; Wed, 6 Dec 2023 12:56:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3C4E668CF7D; Wed, 6 Dec 2023 14:56:01 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6C63868CEF5 for ; Wed, 6 Dec 2023 14:55:54 +0200 (EET) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 3B6Ctrgu014238 for ; Wed, 6 Dec 2023 13:55:53 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id 97886EB5BB; Wed, 6 Dec 2023 13:55:53 +0100 (CET) Date: Wed, 6 Dec 2023 13:55:53 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <170144198228.8914.6757885452665407226@lain.khirnov.net> <170144268666.8914.14610541165951753799@lain.khirnov.net> <170146019227.8914.6674790290782283298@lain.khirnov.net> <170170715198.8914.12428862753446922670@lain.khirnov.net> <170170963341.8914.15256032845632094107@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <170170963341.8914.15256032845632094107@lain.khirnov.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Wed, 06 Dec 2023 13:55:53 +0100 (CET) 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: Anton Khirnov (12023-12-04): > Which of these are you saying is correct? I do not know? Do you think I am able to reverse MD5 mentally? I am flattered, but I am sorry to confess I am not. Why do you not look at the resulting videos to judge for yourself? But to do that, you will need to remember (or learn two things): First, most people do not have that many CPU threads available, and if they do they will spend them on encoding more than decoding. Second, and most important: for subtitles, in many many cases, a few frames of shift do not matter because the timing in the source material is not that accurate. So the answer to your question is: probably most of the ones generated with a sane number of threads are correct, in the sense that the result is within the acceptable accuracy of subtitles sync and useful for the user. Of course, if the use case is one where perfect accuracy is necessary, users need to revert to a slower and more bulky procedure (like you suggested: open the file twice, which might require storing it entirely) to get it. So really, what you pretend is not breaking anything is really removing one of the options currently available to users in the compromise between speed, latency and accuracy. So I demand you stop pretending you are not breaking anything, stop pretending it is currently broken, just so you can move forward without bothering to search for a solution: that starts to feels like laziness and it always felt like rudeness because I spend a lot of effort in getting this to work in the cases where it can. > The only bug that's been established to exist so far is in your > heartbeat code, which produces random output as per above. As I explained many times, this is not a bug. > Buffering is by itself not a bug, otherwise you'd have to say the lavf > interleaving queue is a bug. Once again, buffering thousands of frames and crashing because out of memory when the current code succeeds and produces an useful result is a regression and the patch series cannot be applied until that regression is fixed. > So for the last time - either suggest a specific and practical way of > reducing memory consumption or stop interfering with my work. The specific and practical way is to let the current logic in place. There might be a few tweaks to make it more accurate, like looking into this comment: /* subtitles seem to be usually muxed ahead of other streams; if not, subtracting a larger time here is necessary */ pts2 = av_rescale_q(pts, tb, ifp->time_base) - 1; But first, we need you to stop behaving as if my previous efforts did not mater just because it does not overlap with your narrow use cases. -- Nicolas George _______________________________________________ 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".