Overall low performance: as expected or not? about akvirtualcamera HOT 3 CLOSED

Overall low performance: as expected or not?

For the results you are posting, I would say that is better than expected 😆

FFmpeg reports that it is able to drive 30fps and I see no real delay in the resulting video device's output. Great! But when I try to shuffle frames in a 1080p30 mode with the following command, FFmpeg is only able to achieve just 25 fps on average and after a few seconds (as expected as the input still comes with 30 fps) the FFmpeg "rtbufsize" is full and FFmpeg complains and the virtual camera device's output shows more and more delay

It's normal, the bigger the frame size, the higher the delay you will have.

Do you have any ideas what can cause such a low overall performance?

Yes, all the frames format conversions and scaling is by far the biggest bottleneck.

Do you have any ideas how I speed up the processing?

Yes, all the frame processing could be improved parallelizing the conversion, maybe using OpenMP, maybe using the CPU intrinsic functions, maybe passing the task to the GPU, maybe using OpenCL or CUDA, there are a lot of options.
For now, I am satisfied that it works at least, and will try to improve it much later.

I guess feeding YUY2 is actually not intended, even it looks it partly works?

I'll add support for other input formats later.

from akvirtualcamera.

Ok, I've investigated deeper: it was entirely my fault in using a too problematic setup! As I'm a Unix veteran I was used to write down the test pipelines as the mentioned Unix shell scripts, as even under Windows 10 I'm always working inside its WSL. But: the two involved programs in the pipeline are ffmpeg.exe and AkVCamManager.exe and both are regular Windows executables, while the stdio interconnect is from the Unix shell! As a consequence, the video stream had to travel from the Windows world of ffmpeg.exe to the WSL world (for the stdio pipe) and back again to the Windows world of AkVCamManager.exe. And this doubled transfer between the worlds was what effectively limited the overall throughput! Once I executed the pipleline directly inside a Windows .bat file it achieves 60fps:

ffmpeg.exe -hide_banner -f dshow -rtbufsize 240M -s 1920x1080 -framerate 60 -i "video=BRIO 4K Stre
am Edition" -f rawvideo -map 0:v -pix_fmt rgb24 -s 1920x1080 - | AkVCamManager.exe stream AkVCamVideoDevice0 RGB24 1920 1080

So, sorry, there is neither is performance problem within FFmpeg nor AkVirtualCamera. It was the problematic interconnect!

from akvirtualcamera.

Oh ok, I didn't tested it in WSL, I usually use MSYS as my playground.

from akvirtualcamera.