[FFmpeg-devel] [RFC]separation of multiple outputs' encoding
Tao Zhang
nowerzt at gmail.com
Mon May 18 09:00:55 EEST 2020
If no more comments, I will try to code something to create a pseudo
encoder which run the actual encoding in the separate thread. Thanks
Tao Zhang <nowerzt at gmail.com> 于2020年5月15日周五 上午10:14写道:
>
> Marton Balint <cus at passwd.hu> 于2020年5月15日周五 上午2:33写道:
> >
> >
> >
> > On Thu, 14 May 2020, Tao Zhang wrote:
> >
> > > Hi,
> > > FFmpeg supports multiple outputs created out of the same input in the
> > > same process like
> > > ffmpeg -i input -filter_complex '[0:v]yadif,split=3[out1][out2][out3]' \
> > > -map '[out1]' -s 1280x720 -acodec … -vcodec … output1 \
> > > -map '[out2]' -s 640x480 -acodec … -vcodec … output2 \
> > > -map '[out3]' -s 320x240 -acodec … -vcodec … output3
> > > In ffmpeg.c, multiple outputs are processed sequentially like
> > > for (i = 0; i < nb_output_streams; i++)
> > > encoding one frame;
> > >
> > > As below wiki noted, the slowest encoder will slow down the whole
> > > process. Some encoders (like libx264) perform their encoding "threaded
> > > and in the background", but x264_encoder_encode still cost some time.
> > > And it is noticeable when multiple x264_encoder_encodes run in the same thread.
> > > https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
> > >
> > > For API users, they can use separate thread for multiple encoding in
> > > their own code. But is there any way to rescue command line users?
> >
> > I am not sure I understand what you want. Processing will still be limited
> > to the slowest encoder, because input processing will still be driven by
> > the slowest encoder, even if the encoders run in separate threads.
> >
> > Buffering encoder input frames is not an option, because input frames are
> > uncompressed, therefore huge. So if you want the faster x264 encoder to
> > finish faster, you have to drive it from a different input, ultimately you
> > should run 3 separate encode processes and accept that decoding and yadif
> > processing happens in all 3 cases separately causing some overhead.
> Currently FFmpeg works like below:
> main thread:
> encoding frame 1 for output 1; encoding frame 1 for output 2; encoding
> frame 1 for output 3; encoding frame 2 for output 1; encoding frame 2
> for output 2; encoding frame 2 for output 3;...
>
> What I want to do is
> thread 1:
> encoding frame 1 for output 1; encoding frame 2 for output 1;...
> thread 2:
> encoding frame 1 for output 2; encoding frame 2 for output 2;...
> thread 3:
> encoding frame 1 for output 3; encoding frame 2 for output 3;...
>
> As the input frame is ref counted, so the buffering memory is not
> huge? Also we can set the max buffering frame limit.
>
> Forgive me for not using multiple separate processes, because mostly
> inputs are network streaming and bandwidth is expensive, a few inputs
> are capture card working as exclusive device.
> >
> > Regards,
> > Marton
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel
mailing list