2020.05.19. 17:27 keltezéssel, Zhong Li írta:
Tomas Härdin <tjop...@acc.umu.se> 于2020年5月19日周二 下午10:25写道：
fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
Marton Balint <c...@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;...
Why not just run multiple copies of the ffmpeg program? Decoding should
almost always be very minor work compared to encoding.
Not vey minor IMHO. For same resolution, H264 decoding is about 10%
computing cost of encoding.
And if adding the filter computing cost (just as yadif filter listed
above), the redundant computing cost is huge.
I agree. I was several times in similar situations.
bb
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
