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<an...@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 _______________________________________________ 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".