Webcam MJPG Capture-Streams sind nicht verfügbar unter Windows 10

Question

Unter Windows 10 Build 10.1607.14393.10 (alias Anniversary Edition) kann ich keine MJPG Capture-Streams mehr bekommen. War früher sowohl MJPG als auch YUY2-Auflösungen, jetzt bekomme ich nur YUY2 in DirectShow (Kernel-Streaming) und in Media Foundation MJPG konvertierte Medientypen in NV12, bevor die IBaseFilter-Quelle mit irgendetwas verbunden ist. Auf mehreren Systemen mit verschiedenen Kameras getestet. Irgendwelche Ideen, was könnte falsch sein?

 640x480 @30 YUY2 
    ... 
    640x480 @30 MJPG <- gone 
... 
DirectShow: 
    com_t<IAMStreamConfig> sc; 
    if_failed_return_result(camera_output_pin->QueryInterface(&sc)); 
    int number_of_capabilities = 0; 
    int capability_size = 0; 
    if_failed_return(sc->GetNumberOfCapabilities(&number_of_capabilities, &capability_size), -1); 
    for (int i = 0; i < number_of_capabilities && k < count; i++) { 
     VIDEO_STREAM_CONFIG_CAPS scc; 
     assert(sizeof(scc) == capability_size); 
     AM_MEDIA_TYPE* mt = null; 
     if_failed_return(sc->GetStreamCaps(i, &mt, (BYTE*)&scc), -1); 
... 

In MMF:

640x480 @30 YUY2 
    ... 
    640x480 @30 NV12 // camera reports MJPG 4cc in USBView and KsStudio 

for (int i = 0; k < count; i++) { 
    com_t<IMFMediaType> type; 
    if (d->reader->GetNativeMediaType(VIDEO_STREAM, i, &type) != 0) { 
     break; 
    } 
    GUID guid_major_type = {0}; 
    if_failed_return_result(type->GetMajorType(&guid_major_type)); 
    if (guid_major_type == MFMediaType_Video) { 
     GUID guid_subtype = {0}; 
     if_failed_return_result(type->GetGUID(MF_MT_SUBTYPE, &guid_subtype)); 
     AM_MEDIA_TYPE* amMediaType = null; 
     if_failed_return_result(type->GetRepresentation(FORMAT_MFVideoFormat, (void**)&amMediaType)); 
     assert(amMediaType->cbFormat == sizeof(MFVIDEOFORMAT)); 
     const MFVIDEOFORMAT* mi = (const MFVIDEOFORMAT*)amMediaType->pbFormat; 

Answer 1

Als explained by Mike M from Microsoft,

So yes, MJPEG and H.264 being decoded/filtered out is the result of a set of features we needed to implement, and this behavior was planned, designed, tested, and flighted out to our partners and Windows Insiders around the end of January of this year. We worked with partners to make sure their applications continued to function throughout this change, but we have done a poor job communicating this change out to you guys. We dropped the ball on that front, so I’d like to offer my apologies to you all.

In Windows 10 Anniversary-Update MJPG Video von der Webcam von neuen Helferdienst "Windows Camera Frame Server" erfasst wird, die stellt sich selbst als "Ermöglicht mehreren Clients den Zugriff auf Videorahmen von Kamerageräten." Das gleiche wird von Mike M. erwähnt.

Ich für den einen war nicht in der Lage, mehrere Clients zu sehen, die eine Kamera teilen, da die zweite Instanz von TopoEdit mir einen typischen Fehler gab: Fehler beim Starten der Wiedergabe. Hardware MFT konnte aufgrund fehlender Hardwareressourcen nicht mit dem Streaming beginnen.

MJPG- und H264-Medientypen werden jedoch tatsächlich herausgefiltert, da das Plattformupdate jetzt die Verantwortung übernimmt, Szenarien zu vermeiden, in denen mehrere Clients gleichzeitig auf dieselbe Kamera zugreifen und jede einzelne die Dekodierung durchführt.

One of the main reasons that Windows is decoding MJPEG for your applications is because of performance. With the Anniversary Update to Windows 10, it is now possible for multiple applications to access the camera in ways that weren’t possible before. It was important for us to enable concurrent camera access, so Windows Hello, Microsoft Hololens and other products and features could reliably assume that the camera would be available at any given time, regardless of what other applications may be accessing it. One of the reasons this led to the MJPEG decoding is because we wanted to prevent multiple applications from decoding the same stream at the same time, which would be a duplicated effort and thus an unnecessary performance hit.

Anscheinend überraschte diese "Verbesserung" viele.

UPDATE. Es wurde festgestellt, dass das Verhalten zur Verwendung der neuen Frame Server-Funktion systemweit deaktiviert werden kann, indem ein Registrierungswert wie unten definiert erstellt wird. Sobald die Media Foundation-API diesen Wert erkennt, wählt sie einen ursprünglichen Codepfad aus, um mit "Hardware" (KS-Proxy) direkt unter Umgehung von Frame Server zu kommunizieren.

• Schlüsselname:
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows Media Foundation \ Platform (64-Bit-Anwendungen, 32-Bit-Anwendungen in 32-Bit-OS)
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ Windows Media Foundation \ Platform (32-Bit-Anwendungen in 64-Bit-OS)
• Wertname: "EnableFrameServerMode" REG_DWORD
• Wert: 0
012.351.

Answer 2

Da dies die Antwort ich besteht zunächst, dass mehrere Abhilfen angeben läßt von Hacks zu teuerer Entwicklung bis hin

1. (Hack) nimmt alte mfcore.dll von Original-Windows 10, Delay Verbindung mit ihm und Kraftbelastung Ihre lokale Kopie - das ist Hack, versuchen Sie es nicht zu Hause, versenden Sie es nicht.
2. Verwenden Sie schlecht dokumentierte ksproxy.ax oder es ist ein moderner Ersatz mfkproxy, um Ihre eigene Schicht zu implementieren, um mit den Kameras zu sprechen.
3. Schalter Kameras WinUSB und verwenden libusb/libuvc (Code nicht, dass hohe Leistung und nicht die auf Windows reifen) und Ihre eigene Kamera-Schnittstelle implementieren

nun auf die richtige Gestaltung von „Frame-Server“:

Wir haben auch Frame-Server in unserem zSpace-System-Design, das dekomprimierte Bilder, komprimierte Kameras Feed (vier von ihnen mit fast 1Gpixel pro Sekunde insgesamt), Blob-Erkennung Informationen und 3D-Posen Triangulation Ergebnisse an mehrere Clients (Anwendungen einschließlich Remote) an die selbe Zeit. Ganze Sache mit Shared Memory und/oder Sockets ist nur ein paar hundert Zeilen geraden C-Code. Ich habe es implementiert und es funktioniert auf Windows und Linux.

Der Mangel an der Microsoft "Verbesserung" liegt in Ignoranz auf die Bedürfnisse des Kunden und ich glaube, es ist einfach zu beheben.

Für das Argument nehmen wir Kamera Streams komprimiertes Format (könnte MJPG/H.26x/HEVC/etwas Neues und Besseres).

Lassen Sie sagen es mehrere mögliche Klassen von Kunden sind: (? Wollen wir Umcodierung dort)

1. Client, der die rohen komprimierten Daten an das Netzwerk für Remote-Hosts-Streams.
2. Client, der die unverarbeiteten komprimierten Daten im lokalen oder remoten persistenten Speicher (Festplatte, SSD) speichert. (Wollen wir dort transkodieren?)
3. Client, der rohe komprimierte Datenstromanalyse (von trivial bis komplex) durchführt, aber keine Pixel benötigt?
4. Client, der komprimierte Daten tatsächlich verarbeitet und stromaufwärts weiterleitet - denken Sie daran, dass Sie z. JPEG ohne vollständige Dekompression.
5. Client, der die unkomprimierten Daten im HSI-Format benötigt.
6. Client, der unkomprimierte Daten im RGB-Format benötigt, wobei einige Filter (z. B. Gamma, Farbprofil) während der Dekomprimierung angewendet werden.

Genug? Heute erhalten sie alle NV12 (was tatsächlich einen noch größeren Datenverlust in Bezug auf eine halbe Bandbreite von U (Cb) - und V (Cr) -Proben darstellt).

Nun, da Microsoft Frame Server implementiert, müssen sie die Daten auf die eine oder andere Weise und sogar auf mehrere Arten dekomprimieren. Dazu müssen die unkomprimierten Daten im Speicher landen und können dort (bedingt) aufbewahrt werden, falls ein Client davon profitieren könnte. Das anfängliche Design des Medien-Graphen erlaubt Splittern und jeder, der ein wenig Programmierkenntnisse besitzt, kann einen bedingten Splitter implementieren, der nur Daten an die Pins weiterleitet, an denen Clients (Senken) angeschlossen sind.

Eigentlich sollte die korrekte Implementierung Kundenanforderungen berücksichtigen (und diese Information ist bereits vorhanden und von allen Clients in einer Art von Medientypverhandlungen und Attributen verfügbar, die das Diagrammverhalten steuern). Dann sollte es Dekompressoren und andere Filter nur bei Bedarf anwenden, wobei es genau auf die CPU-Cache-Lokalität achtet und die angeforderten Daten an geeignete Clients von geeignetem Speicher durch geeignete Mechanismen liefert. Es wird alle Arten von Optimierungen in den möglichen Permutationen der Mischung des oben erwähnten Klienten und darüber hinaus erlauben.

Wenn Microsoft Hilfe beim Entwerfen und Implementieren des Frame-Servers benötigt, der diese einfachen (wenn nicht gar trivialen) Anforderungen erfüllt - es muss nur gefragt werden - anstatt die große Klasse von Anwendungen und Diensten zu sprengen.

Ich frage mich, wie Microsoft Netzwerk-Strom Hollolens Eingang plant? Über NV12? Oder über einen weiteren Hack?

"Entwickler, Entwickler, Entwickler ..." :(