[gelöst] Stretch: Kein mpv-Paketbau mit CUDA möglich?

[hikaru]

Hallo,

letztes Jahr habe ich nach einem Thread im Nvidia-Entwicklerforum [1] einen Jessie-Backport für ffmpeg und mpv gebaut, mit dem sich h265-main10-Videos in 4k abspielen ließen. [2] Diese Pakete habe ich auch mehrfach erfolgreich aktualisiert, zuletzt mit ffmpeg 3.2.2 und mpv 0.22.
Nun habe ich den betreffenden Rechner auf Stretch aktualisiert, stieß dabei aber auf das Problem, dass mein mpv-Selbstbau kein CUDA mehr unterstützt, ohne das auch die Videos nicht mehr in Hardware decodiert werden können.

Dabei vermute ich, dass der ffmpeg-Selbstbau noch ordnungsgemäß funktioniert (40004: Compiler-Optionen --enable-cuda --enable-cuvid --enable-nonfree; Decoder: DEV.L. hevc). Zum Vergleich, die als funktionierend bekannte Ausgabe unter Jessie 40005, die zwar an relevanter Stelle einen Unterschied aufweist, dessen Bedeutung ich aber nicht interpretieren kann:

Code: Alles auswählen

$ diff -u0 ffmpeg_jessie.log ffmpeg_stretch.log | grep hevc
- DEV.L. hevc                 H.265 / HEVC (High Efficiency Video Coding) (encoders: libx265 nvenc_hevc hevc_nvenc )
+ DEV.L. hevc                 H.265 / HEVC (High Efficiency Video Coding) (decoders: hevc hevc_cuvid ) (encoders: libx265 nvenc_hevc hevc_nvenc hevc_vaapi )

mpv ist allerdings der Meinung, dass kein CUDA zur Compilierung zur Verfügung steht (40006), was unter Jessie noch anders aussah (40007).
Was sofort in's Auge springt:

Code: Alles auswählen

$ diff -u0 mpv_jessie.log mpv_stretch.log | grep CUDA
-Checking for CUDA hwaccel                                            : yes 
+Checking for CUDA hwaccel                                            : no

Außerdem dürfte das interessant sein:

Code: Alles auswählen

$ diff -u0 mpv_jessie.log mpv_stretch.log | grep libav
-Checking for libavutil AV_PIX_FMT_MMAL                               : yes 
-Checking for libavtuil av_version_info()                             : yes 
-Checking for libavutil new pixdesc fields                            : yes 
-Checking for libavcodec 64 bit AVPacket.duration                     : yes 
-Checking for libavcodec AVSubtitleRect AVPicture removal             : yes 
-Checking for libavcodec avcodec_profile_name()                       : yes 
-Checking for libavcodec decode/encode API                            : yes 
-Checking for libavcodec AVCodecParameters API                        : yes 
-Checking for libavutil AVHWFramesContext API                         : yes 
-Checking for libavutil HDR TRCs                                      : yes

Wird da der ganze Check von mpv nicht mehr ausgeführt? Ich vermute es, denn wenn ich unter Stretch mit ffmpeg-Selbstbau den letzten Jessie-mpv-Bau wiederhole, dann bekomme ich die Bestätigung für CUDA-Beschleunigung (40008).

Ich bin beim Debuging des Problems überfordert. Kann mir jemand auf die Sprünge helfen?
Die Build-Umgebung ist eine virtuelle Maschine. Diese hat unter Jessie die funktionierenden Pakete gebaut, zeigt nach einem dist-upgrade aber das hier geschilderte Problem. Den ffmpeg-Selbstbau habe ich natürlich nach dem dist-upgrade gemacht und alle Pakete auch vor dem mpv-Selbstbau installiert. Sonst habe ich keine Änderungen vorgenommen.


[1] https://devtalk.nvidia.com/default/topi ... 2/#4983462
[2] viewtopic.php?f=13&t=161817&start=60#p1114398

[hikaru]

Der Übeltäter scheint eine Änderung im wscript von mpv zu sein. Der Code für den cuda-Check wurde geändert. Der Check funktioniert, wenn ich nicht den Originalcode aus mpv 0.23 (wscript.orig) verwende, sondern den aus 0.22 (wscript) zurückhole:

Code: Alles auswählen

# diff -u0 wscript.orig wscript
--- wscript.orig 2017-10-22 22:32:04.000000000 +0200
+++ wscript      2017-10-22 22:32:04.000000000 +0200
@@ -866,2 +866,3 @@
-        'func': check_cc(fragment=load_fragment('cuda.c'),
-                         use='libav'),
+        'func': compose_checks(
+                    check_cc(lib="cuda"),
+                    check_headers('libavutil/hwcontext_cuda.h',  use='libav')),

Das configure-Script liefert dann CUDA-Unterstützung zurück:

Code: Alles auswählen

Checking for CUDA hwaccel                                            : yes

Später laufe ich allerdings in einen anderen Fehler (40010), weil sich der Code von video/decode/cuda.c zwischen den Versionen geändert hat. In die Details wollte ich mich nicht vertiefen. Tausche ich aber die ganze cuda.c von 0.23 gegen die von 0.22 aus, dann lässt sich mpv 0.23 bauen und die Änderung scheint in den Paketen anzukommen:

Code: Alles auswählen

$ mpv --vd=help | grep cuvid
    h263_cuvid (h263) - Nvidia CUVID H263 decoder
    h264_cuvid (h264) - Nvidia CUVID H264 decoder
    hevc_cuvid (hevc) - Nvidia CUVID HEVC decoder
    mjpeg_cuvid (mjpeg) - Nvidia CUVID MJPEG decoder
    mpeg1_cuvid (mpeg1video) - Nvidia CUVID MPEG1VIDEO decoder
    mpeg2_cuvid (mpeg2video) - Nvidia CUVID MPEG2VIDEO decoder
    mpeg4_cuvid (mpeg4) - Nvidia CUVID MPEG4 decoder
    vc1_cuvid (vc1) - Nvidia CUVID VC1 decoder
    vp8_cuvid (vp8) - Nvidia CUVID VP8 decoder
    vp9_cuvid (vp9) - Nvidia CUVID VP9 decoder

Leider bin ich an dem Rechner mit der Nvidia GTX 950 erst wieder in einem Monat, daher kann ich frühestens dann einen echten Test machen und einen Bugreport absetzen. Aber falls jemand anderer mit einer hevc-fähigen Nvidia-Karte das nachvollziehen möchte, dann würde ich mich über eine Rückmeldung freuen.

[hikaru]

Unter Sid gibt es das Problem nicht. Dort lässt sich mit passendem ffmpeg mpv auch ohne Code-Anpassung mit CUDA-Support bauen.

Es sieht so aus, als sei ffmpeg in Stretch (7:3.2.8) an dieser Stelle einfach einen Tick zu alt für die mpv-Version (0.23). Wenn ich mir für ffmpeg 7:3.3.4 aus Sid einen Stretch-Backport baue, dann kann ich auf dieser Basis auch unter Stretch mpv 0.23 mit CUDA bauen. Selbst ein mpv-0.27-Backport aus Sid geht dann.

Da die ffmpeg-mpv-Kombination in Stretch wohl ansonsten funktioniert und der unfreie CUDA-Support in Debian eh nicht verteilbar wäre, sehe ich auch keinen Grund mehr für einen Bugreport.
Vorbehaltlich des noch ausstehenden Praxistests würde ich das Thema damit erstmal als erledigt sehen.

[hikaru]

Nach über einem Monat Pause ist nun auch der Praxistest mit ffmpeg 7:3.4-3 und mpv 0.27 erfolgreich absolviert und ich betrachte das Thema als gelöst.

Technisch unschöner, aber erkenntnismäßig erhellender Nebeneffekt:
Da Avidemux aus deb-multimedia.org ebenfalls von ffmpeg-Paketen abhängt, und zwar neueren aus dmo, und die mir meinen Selbstbau wieder überschrieben hätten habe ich mich an einen Backport gemacht - möglichst ohne Inhalte aus dmo. Die meisten Abhängigkeiten lassen sich aus Debian erfüllen, wenn man im debian/control von Avidemux ein wenig an den Versionsnummern schraubt. Nur libaften0 gibt es nicht. Ich war nicht konsequent genug, darauf zu verzichten, also habe ich nach wie vor ein Paket aus dmo, das aber seinerseits keine Abhängigkeiten hat die mir später auf die Füße fallen könnten.