TMElyralab / MuseTalk

MuseTalk: Real-Time High Quality Lip Synchorization with Latent Space Inpainting
Other
2.51k stars 308 forks source link

为什么realtime脚本生成用时,比日志显示的fps实际要慢很多? #49

Closed jercas closed 4 months ago

jercas commented 5 months ago
itechmusic commented 5 months ago

Hello,延时有很大部分是存储png所致的。目前的代码逻辑是,batch=4推理UNet与VAE,同时会有单独线程进行图片拼接与存储png。进度条播放完其实已经生成完了,后续是拼接与存png的时间

你这边看起来没有开单独线程进行存储?

jercas commented 5 months ago

@itechmusic 感谢回复! 我这边是按照realtime_inference的pipline启动跑的,并没有看到单独启线程进行图片处理的部分,这边看到图片的存储实在realtime_inference.procees_frames() func里,紧接着image_blending之后处理的。

请问这拆分存储、拼接对的部分代码在哪个模块,或者是否有参照的脚本呢?

itechmusic commented 5 months ago

hello,不好意思,目前发现这个脚本有些bug,速度不太正常。我们正在修复

kingsaction commented 5 months ago

png能否不落地,常驻内存,后面在落到磁盘

itechmusic commented 5 months ago

目前代码已经修复,加入了float16使推理速度达到30fps+。速度会受I/O影响,可以使用python -m scripts.realtime_inference --inference_config configs/inference/realtime.yaml --skip_save_images命令跳过保存png,单纯体验推理速度。

jercas commented 5 months ago

hi,经过测试后,skip_save_images看起来并没有减少I/O的损失,测试的日志如下:

itechmusic commented 5 months ago

hi,经过测试后,skip_save_images看起来并没有减少I/O的损失,测试的日志如下:

  • 硬件:V100 * 1;
  • 样例:测试case中的sun视频+音频。
  • 存图片
image
  • 不存图片
image

hello,第一次运行时可能会有模型warm up导致的耗时。这是我们在V100上用batch_size=8的结果 image

jercas commented 5 months ago

感谢~ 依照测试,warmup的问题确实会一定程度上影响Infer速率,我依照你的测试配置,跑了几版测试,但fps还是远低于图例,请问其中差距 问题大概在哪呢?

image
itechmusic commented 5 months ago

感谢~ 依照测试,warmup的问题确实会一定程度上影响Infer速率,我依照你的测试配置,跑了几版测试,但fps还是远低于图例,请问其中差距 问题大概在哪呢?

  • 测试视频 sun.mp4,测试音频[yongen.wav, sun.wav, yongen.wav, sun.wav],已提前进行avater抽取
  • 硬件v100-SXM2-32GB * 1, bs=8
image

有点不知道原因。。。请问有试过换一张卡测试吗?