Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
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: Mon, 04 Dec 2023 18:07:13 +0100
Message-ID: <170170963341.8914.15256032845632094107@lain.khirnov.net> (raw)
In-Reply-To: <ZW4AQwuMjxd8MQ2z@phare.normalesup.org>

Quoting Nicolas George (2023-12-04 17:37:23)
> Anton Khirnov (12023-12-04):
> > broken. If that extra buffering is an actual problem for someone, it can
> > be easily avoided by opening the file twice.
> 
> Not a solution if the file is streamed or generated.
> 
> > As I said before, your command does NOT work. Its output changes
> > unpredictably depending on unrelated parameters.
> 
> It still produces correct output in most of the cases, which is what
> matters to users.

$ for i in $(seq 1 4 64); do
.   echo -ne "$i\t";
.   ./ffmpeg -v fatal -threads $i -i sub.mkv -preset ultrafast \
.     -lavfi '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' \
.     -bitexact -y -f matroska md5:
. done
1       287e929cba6c67c6ce8e35954548048d
5       7e234d83cca90d4b0ee4d563e21a8bd8
9       abfd093a36b1661db022616d97c45fad
13      f6be9d63a7dce69cd16581895923b196
17      2c7144c01f6294e65e305f602b58a718
21      99564d81199a1f453ccff24ac2db7eac
25      02ec0aadb03a0205ccacb4c873ee9ad9
29      76643205916887fd444525ea8bb610fb
33      6267a2baeb1554bc5f219890ac8b37aa
37      f955daadf62c91ddce5705561e32804f
41      523c61ebad03b6ba297812cb7939b679
45      96c48966f459442707f29f854aa59c3b
49      ad92b3f79c7bb31fdc272b2a81985334
53      362a7d6c0a681a049adf4802e0dc8771
57      1529ffd4f487ea13b9a37f4f1b9879eb
61      53db192ac534d348b3ed63fdcbac945a

Which of these are you saying is correct?

> > I maintain that your demand to "fix" your testcase (i.e. reduce its
> > memory consumption) is highly unreasonable –
> 
> My demand is not that you REDUCE the memory consumption, my demand is
> that you DO NOT INCREASE IT HUNDREDFOLD.
> 
> That is a perfectly reasonable demand.
> 
> >						unless you specify how
> > exactly that is supposed to be accomplished while preserving
> > determinism.
> 
> Fixing the bugs introduced by threading

The only bug that's been established to exist so far is in your
heartbeat code, which produces random output as per above.

Buffering is by itself not a bug, otherwise you'd have to say the lavf
interleaving queue is a bug.

So for the last time - either suggest a specific and practical way of
reducing memory consumption or stop interfering with my work.

-- 
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".

  reply	other threads:[~2023-12-04 17:07 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 [this message]
2023-12-06 12:55                                       ` Nicolas George
2023-12-06 13:21                                         ` James Almer
2023-12-06 13:38                                           ` Nicolas George
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=170170963341.8914.15256032845632094107@lain.khirnov.net \
    --to=anton@khirnov.net \
    --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