From: "Ronald S. Bultje" <rsbultje@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] How to use threads inside custom encoder Date: Fri, 24 Feb 2023 08:47:00 -0500 Message-ID: <CAEEMt2mDKCWzojdX1y5mUa=20Ebggn=B00BKpY_CEV0feKGqrA@mail.gmail.com> (raw) In-Reply-To: <1677176098.0668886000.bos3u4y6@frv55.fwdcdn.com> Hi, On Thu, Feb 23, 2023 at 1:28 PM Alex <3.14pi@ukr.net> wrote: > Hi! > I write custom encoder codec and want to use threads to speed up encoding > process. I know what ffmpeg have frame level threads and slices threads, > but in my case best option is to use frame level threads > with FF_CODEC_ENCODE_CB() function. > But I have couple of questions: > > 1) Then I add AV_CODEC_CAP_FRAME_THREADS flag to capabilities of my > encoder then ffmpeg call init function of my encoder for each spawned > threads (for example 9 times because I have 8 core cpu ). How to prevent > this and call init function only once? (I need to reuse encoder context.) > In frame threading, each "frame instance" has its own context. They can be synchronized and use dependent data. See how other codecs do this, e.g. h264 decoder (the concept is identical between encoder & decoder). You can, for example, use avcodec->internal->is_copy for this. See update_thread_context() for synchronization between threads. If this design doesn't work for you, you don't have to use the frame-level API. Just mark them as slice threads and everything can be managed inside your codec without the frame-threading API "overhead". 2) Is it possible to request more decoded frames inside encode callback > function? > Encoders can simply buffer frames and output only when ready (this is why send/receive are separate API), see AV_CODEC_CAP_DELAY. Ronald _______________________________________________ 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-02-24 13:47 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-23 18:28 Alex 2023-02-24 13:47 ` Ronald S. Bultje [this message] 2023-03-13 4:46 ` Andreas Rheinhardt
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='CAEEMt2mDKCWzojdX1y5mUa=20Ebggn=B00BKpY_CEV0feKGqrA@mail.gmail.com' \ --to=rsbultje@gmail.com \ --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