Transcoding hevc_amf/h264_amf

[qpirsel]

Hallo zusammen,

 

ich versuche hardware-unterstütztes transcoding auf meinem neuen DMS 3.x zum Laufen zu bekommen. Unter dem RS 1.3 mit QSV ging das ziemlich schnell einzurichten, aber auf meiner neuen Kiste bekomm ich es einfach nicht hin. Als Containerformat plane ich TS zu nutzen und die Tests mach ich mit dem DVBViewer Controller auf meinem Android Smartphone.

 

Anfangs dachte ich es könnte was mit der mitgelieferten ffmpeg Version zu tun haben, weshalb ich mir eine aktuelleres Build besorgt habe. Aber das Verhalten und das Ergebnis bleiben identisch.

 

Prinzipiell funktioniert das HW-unterstützte transcoding mit ffmpeg prima. x256, sowie hevc, wenn ich direkt auf der Kommandozeile eine TS-Datei transcode (ffmpeg.exe -hwaccel auto -i "D:\public\source.ts" -c:v hevc_amf "D:\public\target.mp4"). Schön ~20% GPU Decode/Encode Auslastung, CPU nicht wahrnehmbar.

 

Also habe ich mich versucht Stück für Stück in der ffmpegprefs.ini mit einem separaten Profil ranzutasten. Dabei hab ich die svcdebug nach der entsprechenden Übergabe der Parameter untersucht und diese dann per Kommandozeile nachgebildet - mit Ausgabe in eine Datei.

 

Nun bin ich an dem Punkt, wo ich per Kommandozeile den Livestream mit hvec_amf in eine Datei transcodieren kann, aber auf dem DVBViewer Controller endet es immer damit, dass VLC sich ins endlose rödelt und auf dem Server auch sichtbar kein Transcoding per GPU stattfindet.

 

Im Anhang hab ich mal den Auszug aus der svcdebug eingefügt, welche kein Ergebnis liefert und darunter dieselben Parameter über ffmpeg direkt, nur eben mit Ausgabe in eine Datei, statt in eine Pipe.

 

Vielleicht fällt ja jemandem was auf. Ich bin momentan ratlos.

 

hevc.txt

[Griga]

Die von dir verwendete ffmpeg.exe 4.4-full_build (von VideoHelp.com) habe ich letztlich probiert und damit einige Probleme gehabt. Sie lieferte in vielen Fällen einfach keine Daten via Named Pipe an den DMS. Erst nach einem weiteren Update auf eine Beta vom Juni (auch von VideoHelp.com) ging es wieder reibungslos.

 

Tipp: Du erhälst den vollständigen FFmpeg Debug-Output im svcdebug.log, wenn du im Webinterface Konfiguration -> UPnP -> UPnP Debug Logging einschaltest. Aber Vorsicht: Der DMS schreibt dann insgesamt wesentlich mehr Debug-Informationen als normal, nicht nur von FFmpeg. Das kann schnell zu einer unübersichtlichen Datenmenge im Log führen. Deshalb die Option nur für den Zeitraum einschalten, in dem sie tatsächlich gebraucht wird. Bei einem Neustart schaltet sie der DMS automatisch aus.

 

[qpirsel]

Hi Griga,

 

danke für die Tipps. Ich werde es mal mit der original und beta/nightly testen und die entsprechenden Logs aktivieren.

Edited June 22, 2021 by qpirsel

[qpirsel]

So, ich denke ich bin weiter.

 

Im Log erscheint folgende Zeile:

22.06.21 08:10:49.214 FFMPEG               [AVHWDeviceContext @ 0000020ed01629c0] Failed to create Direct3D device

 

Also habe ich hwaccel erst mal ganz rausgenommen. Und damit funktioniert zumindest das GPU beschleunigte Encoding über DMS. Daraufhin habe ich noch Mal mit dem hwaccel Parameter getestet und von auto auf dxva2 umgestellt - wieder mit demselben negativen Ergebnis. Blieb also nur noch d3d11va und siehe da, damit funktioniert auch das GPU beschleunigte Decoding. Übrigens auch mit ffmpeg 4.4, wobei ich immer nur so ~1min getestet habe.

 

Wenn ich das bei den Recherchen richtig verstanden habe, liegt das mit dxva2 wohl daran, dass es von einem Service aus initialisiert wird. Zumindest funktioniert es ja auf der Kommandozeile problemlos.

[Griga]

11 minutes ago, qpirsel said:

Wenn ich das bei den Recherchen richtig verstanden habe, liegt das mit dxva2 wohl daran, dass es von einem Service aus initialisiert wird.

 

Ob es damit zusammenhängt?

 

https://www.dvbviewer.tv/forum/topic/60051-unc-pfad-bei-media-sammlungen-wir-nicht-gelesen/?do=findComment&comment=464316

 

Nicht sehr wahrscheinlich, dass für DXVA2 Benutzername und Passwort eines Kontos erforderlich sind, aber du kannst es ja mal probieren...