[FFmpeg-devel] [RFC]separation of multiple outputs' encoding

[Bodecs Bela]

2020.05.19. 17:27 keltezéssel, Zhong Li írta:
> Tomas Härdin <tjoppen at acc.umu.se> 于2020年5月19日周二 下午10:25写道：
>> fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
>>> 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;...
>> 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 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".