> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Thursday, April 14, 2022 12:02 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architec
om: ffmpeg-devel On Behalf Of
> > Paul
> > > > B Mahol
> > > > Sent: Monday, April 11, 2022 10:52 PM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, April 13, 2022 11:43 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> arch
Soft Works (12022-04-12):
> I have always asked you kindly
You have been repeatedly rude towards the people who know libavfilter
well.
On top of that, you have shown that you do not understand how
libavfilter currently works.
On top of that, you have refused to learn how libavfilter currently
wo
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Tuesday, April 12, 2022 11:29 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architec
g-devel On Behalf Of
> > > > Anton Khirnov
> > > > Sent: Monday, April 11, 2022 10:29 AM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Monday, April 11, 2022 10:52 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architec
g>
> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > architecture
> >
> > Quoting Soft Works (2022-04-08 17:27:10)
> > > > Furthermore, remember that this is just the first step. There will
> > be
> > > > further patchset
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, April 11, 2022 10:29 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architecture
Quoting Soft Works (2022-04-08 17:27:10)
> > Furthermore, remember that this is just the first step. There will be
> > further patchsets converting the other components. I intend to
> > upstream
> > them gradually one after the other. Your suggestion would require me
> > to
> > instead write the wh
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Thursday, April 7, 2022 10:33 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> archit
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > architecture
> >
> > Quoting Soft Works (2022-04-05 23:05:57)
> > > do I understand it right that there won't be a single-thread
> > > operation mode that replicates/corresponds
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya
> Sent: Wednesday, April 6, 2022 7:57 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architect
>
> Not gonna happen, not gonna block progress because of whim of single random
> contributor.
>
Agreed, this patch series is as important as buffer referencing. We can't
let holdouts block progress.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
g>
> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > architecture
> >
> > Quoting Soft Works (2022-04-05 23:05:57)
> > > do I understand it right that there won't be a single-thread
> > > operation mode that replicates/correspond
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Wednesday, April 6, 2022 10:42 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> archit
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Wednesday, April 6, 2022 1:17 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> archite
eg-devel On Behalf Of
> > > > Anton Khirnov
> > > > Sent: Tuesday, April 5, 2022 9:46 PM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a thr
To clarify futher, the [RFC] tag applies mainly to patches 34-49/49,
which will certainly require some changes, possibly substatial ones.
Previous patches should IMO be acceptable for master as they are. I
would appreciate reviews for those, so I can push them sooner rather
than later and thus red
Quoting Soft Works (2022-04-05 23:05:57)
> do I understand it right that there won't be a single-thread
> operation mode that replicates/corresponds the current behavior?
Correct, maintaining a single-threaded mode would require massive
amounts of extra effort for questionable gain.
>
> Not that
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Tuesday, April 5, 2022 11:19 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architecture
g>
> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > architecture
> >
> > Quoting Michael Niedermayer (2022-04-05 21:15:42)
> > > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote:
> > > > Hi,
> > > > this
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Tuesday, April 5, 2022 9:46 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architect
Quoting Michael Niedermayer (2022-04-05 21:15:42)
> On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote:
> > Hi,
> > this WIP patchset is the first major part of my ongoing work to change
> > ffmpeg.c architecture such that every
> > - demuxer
> > - decoder
> > - filtergraph
> > - encoder
On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote:
> Hi,
> this WIP patchset is the first major part of my ongoing work to change
> ffmpeg.c architecture such that every
> - demuxer
> - decoder
> - filtergraph
> - encoder
> - muxer
> lives in its own thread. The advantages of doing this
The code can also be obtained from branch ffmpeg_mt/mux in my tree
git://git.khirnov.net/libav
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
Hi,
this WIP patchset is the first major part of my ongoing work to change
ffmpeg.c architecture such that every
- demuxer
- decoder
- filtergraph
- encoder
- muxer
lives in its own thread. The advantages of doing this, beyond increased
throughput, would be enforced separation between these compone
27 matches
Mail list logo
