[FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Gyan Doshi]

On 2023-12-14 04:56 pm, Anton Khirnov wrote:
> Quoting Gyan Doshi (2023-12-14 12:22:51)
>>
>> On 2023-12-14 02:48 pm, Anton Khirnov wrote:
>>>>> On Tue, Dec 12, 2023 at 07:41:18AM +0000, Anton Khirnov wrote:
>>>>>> ffmpeg | branch: master | Anton Khirnov<anton at khirnov.net>  | Tue Jul 18 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | committer: Anton Khirnov
>>>>>>
>>>>>> fftools/ffmpeg: convert to a threaded architecture
>>>>>>
>>>>>> Change the main loop and every component (demuxers, decoders, filters,
>>>>>> encoders, muxers) to use the previously added transcode scheduler. Every
>>>>>> instance of every such component was already running in a separate
>>>>>> thread, but now they can actually run in parallel.
>>>>>>
>>>>>> Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
>>>>>> JEEB to be more correct and deterministic.
>>>>>>
>>>>>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
>>>>>> ---
>>> should be fixed by the patch I just sent
>>>
>> I tested a single input --> output conversion to compare performance and
>> I noticed the final report now displays N/A for time, bitrate and speed i.e.
>>
>> frame= 1500 fps=109 q=-1.0 Lsize=   17363kB time=N/A bitrate=N/A speed=N/A
>>
>> whereas commit 1439784ff0 shows
>>
>> frame= 1500 fps=108 q=-1.0 Lsize=   17363kB time=00:00:59.97
>> bitrate=2371.6kbits/s speed=4.34x
>>
>> Is this expected?
> No, but check whether
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-December/318326.html
> (also depends on the previous patch) fixes it.
>

Yes, it does.

Regards,
Gyan