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

[Anton Khirnov]

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.

-- 
Anton Khirnov