From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Date: Wed, 6 Dec 2023 14:38:04 +0100
Message-ID: <ZXB5PHrorRILf0zY@phare.normalesup.org> (raw)
In-Reply-To: <c8c51462-afae-417d-9ecc-16574cfcc77d@gmail.com>
James Almer (12023-12-06):
> I honestly can't believe you're arguing this.
Yet I do, so I suggest you think a little harder to understand why I do.
> And being condescending will not help your case.
Can you tell that to Anton too please?
> If i request -bitexact, i want bitexact output, regardless of running on a
> core i3 or a Threadripper. There's nothing more to it.
I had not noticed the -bitexact on the test command line. I will grant
the change is acceptable if bit-exact is requested.
> 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.
Well, you are wrong, and what I explained is the real reason: most
subtitles are not timed that accurately. The subtitles on HBO's Last
Week Tonight, for example, can randomly lag or be early by several
seconds. Even serious subtitles, like the ones for scripted shows on
Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds,
i.e. several frames.
And I have used this code. And I look carefully at subtitles. If the
result was lower quality than the source material, I would have noticed
and I would have endeavored to fix it. There never was need.
Now, can Anton claim similar experience working with subtitles from the
real world? Most of this discussions points to the answer being no.
> So, like Anton has asked several times, suggest a way to keep deterministic
> and bitexact output without exponentially increasing memory consumption due
> to buffering.
I will spend time and effort searching for a solution when we agree to
work together.
“Do this or I will break your code” is an unacceptable behavior, whether
it is directed at me or at Paul or at anybody else, and I do not spend
effort when unacceptable behavior is tolerated.
--
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".
next prev parent reply other threads:[~2023-12-06 13:38 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 19:14 [FFmpeg-devel] [PATCH v2] ffmpeg CLI multithreading Anton Khirnov
2023-11-23 19:14 ` [FFmpeg-devel] [PATCH 01/13] lavfi/buffersink: avoid leaking peeked_frame on uninit Anton Khirnov
2023-11-23 22:16 ` Paul B Mahol
2023-11-27 9:45 ` Nicolas George
2023-11-23 19:14 ` [FFmpeg-devel] [PATCH 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust Anton Khirnov
2023-11-27 9:40 ` Nicolas George
2023-11-27 9:42 ` Nicolas George
2023-11-27 13:02 ` Paul B Mahol
2023-11-27 13:49 ` Nicolas George
2023-11-27 14:08 ` Paul B Mahol
2023-11-29 10:18 ` Anton Khirnov
2023-11-23 19:14 ` [FFmpeg-devel] [PATCH 03/13] fftools/ffmpeg_filter: track input/output index in {Input, Output}FilterPriv Anton Khirnov
2023-11-23 19:14 ` [FFmpeg-devel] [PATCH 04/13] fftools/ffmpeg: make sure FrameData is writable when we modify it Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 05/13] fftools/ffmpeg_filter: move filtering to a separate thread Anton Khirnov
2023-11-24 22:56 ` Michael Niedermayer
2023-11-25 20:18 ` [FFmpeg-devel] [PATCH 05/13 v2] " Anton Khirnov
2023-11-25 20:23 ` [FFmpeg-devel] [PATCH 05/13] " James Almer
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 06/13] fftools/ffmpeg_filter: buffer sub2video heartbeat frames like other frames Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 07/13] fftools/ffmpeg_filter: reindent Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 08/13] fftools/ffmpeg_mux: add muxing thread private data Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 09/13] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 10/13] fftools/ffmpeg_demux: switch from AVThreadMessageQueue to ThreadQueue Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 11/13] fftools/ffmpeg_enc: move encoding to a separate thread Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 12/13] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure Anton Khirnov
2023-11-23 19:15 ` [FFmpeg-devel] [PATCH 13/13] fftools/ffmpeg: convert to a threaded architecture Anton Khirnov
2023-11-24 22:26 ` Michael Niedermayer
2023-11-25 20:32 ` [FFmpeg-devel] [PATCH 13/13 v2] " Anton Khirnov
2023-11-30 13:08 ` Michael Niedermayer
2023-11-30 13:34 ` Anton Khirnov
2023-11-30 20:48 ` Michael Niedermayer
2023-12-01 11:15 ` [FFmpeg-devel] [PATCH 13/13 v3] " Anton Khirnov
2023-12-01 14:24 ` Nicolas George
2023-12-01 14:27 ` Anton Khirnov
2023-12-01 14:42 ` Nicolas George
2023-12-01 14:46 ` Anton Khirnov
2023-12-01 14:50 ` Nicolas George
2023-12-01 14:58 ` Anton Khirnov
2023-12-01 15:25 ` Nicolas George
2023-12-01 19:49 ` Anton Khirnov
2023-12-04 15:25 ` Nicolas George
2023-12-04 16:25 ` Anton Khirnov
2023-12-04 16:37 ` Nicolas George
2023-12-04 17:07 ` Anton Khirnov
2023-12-06 12:55 ` Nicolas George
2023-12-06 13:21 ` James Almer
2023-12-06 13:38 ` Nicolas George [this message]
2023-12-07 17:26 ` Paul B Mahol
2023-12-21 11:53 ` Paul B Mahol
2023-12-22 10:26 ` Anton Khirnov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXB5PHrorRILf0zY@phare.normalesup.org \
--to=george@nsup.org \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git