The current DShowCapture implementation has no support for RGB24 video, which causes compatibility issues when running programs dependent on OpenSeeFace through wine. Wine currently exclusively supports RGB24 video formats through the dshow api, and while this is a known issue, it could be a long time until support for other formats can be properly implemented.
As a workaround to improve compatibility, RGB24 should be added as a supported format, and should be put before XRGB when listing formats to encourage other programs to prefer RGB24 over XRGB
|
formats = {0: "Any", 1: "Unknown", 100: "ARGB", 101: "XRGB", 200: "I420", 201: "NV12", 202: "YV12", 203: "Y800", 300: "YVYU", 301: "YUY2", 302: "UYVY", 303: "HDYC (Unsupported)", 400: "MJPEG", 401: "H264" } |
Both VSeeFace and Warudo are both currently unable to perform their own camera tracking because of this issue. They act as though a camera is connected, but never receive any frames of data. The current common workaround is to run OpenSeeFace natively and point it to the correct port, but forcing OpenSeeFace to be run with --use-dshowcapture 0 via a shim also seems to resolve the problem, as OpenCV correctly selects RGB24 via dshow
The current DShowCapture implementation has no support for RGB24 video, which causes compatibility issues when running programs dependent on OpenSeeFace through wine. Wine currently exclusively supports RGB24 video formats through the dshow api, and while this is a known issue, it could be a long time until support for other formats can be properly implemented.
As a workaround to improve compatibility, RGB24 should be added as a supported format, and should be put before XRGB when listing formats to encourage other programs to prefer RGB24 over XRGB
OpenSeeFace/facetracker.py
Line 96 in 85aa70f
Both VSeeFace and Warudo are both currently unable to perform their own camera tracking because of this issue. They act as though a camera is connected, but never receive any frames of data. The current common workaround is to run OpenSeeFace natively and point it to the correct port, but forcing OpenSeeFace to be run with
--use-dshowcapture 0via a shim also seems to resolve the problem, as OpenCV correctly selects RGB24 via dshow