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 EFFDF48523 for ; Wed, 6 Dec 2023 13:20:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AAEA868CF88; Wed, 6 Dec 2023 15:20:50 +0200 (EET) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 55FFE68CF4B for ; Wed, 6 Dec 2023 15:20:44 +0200 (EET) Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6ce3efb78e2so3859892b3a.1 for ; Wed, 06 Dec 2023 05:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701868842; x=1702473642; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vyLCchJgThwrjSKjel0g9PcttE1RZSCwH7d6da9rV2U=; b=f6UViCnGBAolzlePAT5bNNnl10CoN4jVNHhA9tTEfzwXZ+UWWAZ+cBinU70kJVYQWT XhBZg71ojCUCweJQMglGR0LK/ucgbas3cpNsvCuTHGHXoTKUttzYt1/h59JJzaqwo8mJ SEnVTQ2D2yA1ZCVMATH9TUTXmc1QQjMGr/7N0qBdjeBmClwWWgxRWbBlZ9EcaFhHGbTq gpwuqwQofAU4W2SQ23RoC1Nf0vQVRZLydlQ6OuwSUDvgzx181j6FpUmmPeesY7W2bPCx 7fKiJksJQRl2bbY2rU5WAt5vdVzg597nZsYghWpWdxGj7iyLXP9+d1s2NiriOiBmKrMh 71IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701868842; x=1702473642; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vyLCchJgThwrjSKjel0g9PcttE1RZSCwH7d6da9rV2U=; b=TABuDlymNcFBTrqd/CrKW5ORy9aiGFHKzXFT/4yRNbNHP2vU8QkncGHpx4CXSqOBTW 7nrLV23ULBONZ8kbYOfGX69sfvqp2qNomPtLUCv1RQ5I/8cRCSVnwsCOv0Zqy9k/b0fi srBNzpDD7Kl5oIjL4DtScjAF7IYJEfay6c7FUk7FaL6MZD8QP9CTqSvVGavleIUrrOC7 kNRuDaQxxGoNje+hWt1j2LThr33XXct+vGgj5tYQhb3PSffTbrwXQxn/rnymzoW/UwQF T+IllbUOPdKsvLUTEIlPtot1H9TWaXmTOS+bNtGg5sB/l4aT09yhrTpm7l/Zu7tZ80/n W6Dg== X-Gm-Message-State: AOJu0YxtBIX/L6yEreGXDWYqGBJJgdzp28j8buIq7KgJSMRT5joUubMM ISB4GB/BY0cpeVw9qzJBasySkbZ82DA= X-Google-Smtp-Source: AGHT+IG7ecUGXR609JN8A5CcaiZJMoXXmhqoIBpS/zVSVTxRe6KOsXpr+oUVU2aL96HAQhgNPuufGw== X-Received: by 2002:a05:6a00:430f:b0:6ce:7631:8d7f with SMTP id cb15-20020a056a00430f00b006ce76318d7fmr893032pfb.51.1701868841437; Wed, 06 Dec 2023 05:20:41 -0800 (PST) Received: from [192.168.0.16] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id ei43-20020a056a0080eb00b006ce9da2e389sm500887pfb.13.2023.12.06.05.20.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Dec 2023 05:20:40 -0800 (PST) Message-ID: Date: Wed, 6 Dec 2023 10:21:20 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org 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> From: James Almer Autocrypt: addr=jamrial@gmail.com; keydata= xsBNBFjZtqABCADLW+vdEoZaJZDsIO6geYFTOcn1unsEHefj9zn+3oTHlDFFzO47mzHsSfbK 9JE2xpOJEVnC8FAF5Sayi/pVwV+mtQUV3n5dgVeVBYF9GUQwOGFCpK8X54RRqhkgknbunOEE 0CtgAJgmpFmmmHgq02GvEspx1h/rh4apqwQR6QX4Favb+x9+i9ytVpwVcBX94vo2toyP7h/K BWfadQmb8ltgE1kshfg+SQs/H5bTV5Z1DuEASf02ZL/1qYB/sdTgWPLv9XMUHHsRFmMY8TMx wJSkP+Af3AiYQPJYz1B1D4tt98T/NoiVdin10zATakPjV8hXaobuRmxgakkUASXudydDABEB AAHNH0phbWVzIEFsbWVyIDxqYW1yaWFsQGdtYWlsLmNvbT7CwJIEEwEIADwCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAFiEEd1EujP2UoWlX5pp6FGMBrXN2WeAFAmJoLUUCGQEACgkQ FGMBrXN2WeAFVQf9GtGhniRs1PzNUOgJktCnv6j4BbLieaIPYPEFXKDHOgjqQE2zVMYXnoXl Jam928ii902a8OY06r9ywn/R8ApD1/3NY/v64O71CY9scz5XyH2au8wIZ6HwFy3/f7sqjdGD uctY8Qs7rjT7NkoC5lmgMu2v2k03dGtM9AAf5AK5gU+H0EUw7vmKKiXzUqt5kvBuf4CEwXvH AQT1SMJ52rIlDWB7FQFyZeUbOAK2IgY/KNedfK6nsgd/eQVnlofPd2XoddE7kP6iys7jJefw DD3g3rZyDTq7in5dyk5glaNpWZpbHGBs+9SCYLnfQ8XvWqPFOD+gj0plamKANgOvavKTxM7A TQRY2bagAQgA69YtILj8kYxmqPr/M8+MXT7wVoOWVW9lvSmPquCELaDy/NIS7D06VC5EuE/6 JlJXZMTn37NLlyWhzwOgXuXw5w2tyoQQBuvqGiXJijuXwXH7HKdzrc6rpYtAqt5w05hzNrFS KrS0izG64VpWrfproy3BsL+8TBm9brLhhNPynVRqVukbbGzlATTzNQGZ14TTi2/dL6DkMQnM qn4jX9UEe4GdGQBP50bUJSSmeiIkyNLWA+znuN2PZEz930ZwNrF9GtDVw7mzcmpCZ7spldE2 tutbpy9D1bIqxyqBrYDSezyzL2adR1qgHyOTMCHg2AYNkrIQHrSyJxKTpZ1/hqOp8wARAQAB wsBfBBgBAgAJBQJY2bagAhsMAAoJEBRjAa1zdlnghekH/0Yb0iYJ74oID2f/Fj+AJKS2ekQF P2xOr8lpGzgp/+yWUvPtqbX0A33anBJdYwxaAC0NataX3tfZ+oJkzXqfmqhIHMPYHdZesJA2 Bk9hU/33mDl5s5U66/z0uelWzwKVHoQ2O6or4+qF3HJFSJLCe9uvWJ3zXf9F342Ftj73sfx+ 3xkw/IXsN1RqbYqDlzpoEQ99SIEfY/8Jjwnd3sIPfqkuyeaYfe6GJDqKawdCEP1oRRlbXEAp TJgYz8r3nPhGv9cdHNDCk44ISbsqVuxIEnLqi4fTPZaGupiQhT+srl268TTAp2TQW7+6Ce/b NPQorMquzS/LZoyALpmsYi/miMc= In-Reply-To: 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-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 12/6/2023 9:55 AM, Nicolas George wrote: > 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 I honestly can't believe you're arguing this. At this point you're just being defensive of your position without really taking into account what you were challenged with. > to do that, you will need to remember (or learn two things): And being condescending will not help your case. > > 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. How can you argue it's fine when you request bitexact output and do NOT get bitexact output? Go ahead and add that command line as a FATE test. See the runners turn yellow. Will you argue it's fine and not broken? Number of threads should not matter, the output has to be deterministic. Saying "Maybe the user likes what he gets. Varying amount of artifacts here and there or a few frames of shift here and there of difference between runs. It's fine!" is laughable. > > 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. If i request -bitexact, i want bitexact output, regardless of running on a core i3 or a Threadripper. There's nothing more to it. > >> 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. Calling random output that happens to be "acceptable" within the subjective expectations of the user as useful sounds to me like you're trying to find an excuse to keep buggy code with unpredictable results around, just because it's been there for a long time. > >> 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. Your previous efforts mattered, but evidently did not yield completely acceptable results, and this overhaul has exposed it. So, like Anton has asked several times, suggest a way to keep deterministic and bitexact output without exponentially increasing memory consumption due to buffering. _______________________________________________ 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".