4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 47

Beitrag von Lord_Carlos » 24.01.2017 14:54:33

Hatten wir nicht ein Thread wo fuer ueber den Nutzten von 4k Diskutiert haben? Ich kann den gerade nicht finden.

Wollte diesen netten Artikel teilen. Da wird ein wenig beschrieben was man erwarten sollte und wie es sie "anders" anfuehlen kann 4k zu gucken.

__________________

Und nochmal zur Linux Hardware: WeTeK play2, kostet ca. 109 EUR, kann 4k abspielen und geht angeblich out of the box mit OpenElec.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

willy4711

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von willy4711 » 12.09.2018 18:08:04

Hallo erstmal, ich bin der Neue
Info: Die GTX 1060 (Treiber 390.77) kann über cuda jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv problemlos mit 8% CPU - Last (AMD FX-6300)das Video abspielen.

Code: Alles auswählen

mpv --hwdec=cuda  jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
Playing: jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
Using hardware decoding (cuda).
VO: [gpu] 3840x2160 cuda[p010]
V: 00:00:30 / 00:00:30 (99%)
Exiting... (End of file)

Code: Alles auswählen

dpkg -l *cuda* |grep ii
ii  libcuda1:amd64       390.77-1     amd64        NVIDIA CUDA Driver Library
ii  libcuda1:i386        390.77-1     i386         NVIDIA CUDA Driver Library
ii  libcuda1-i386:i386   390.77-1     i386         NVIDIA CUDA 32-bit runtime library

Code: Alles auswählen

Tasks: 232 total,   1 running, 231 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7,0 us,  2,2 sy,  0,0 ni, 90,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  16014,4 total,   7582,6 free,   2352,0 used,   6079,8 buff/cache
MiB Swap:   6000,0 total,   6000,0 free,      0,0 used.  13396,8 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                 
20126 will      20   0   13,6g 363764 214308 S  28,9   2,2   0:04.12 mpv 

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von hikaru » 13.09.2018 15:46:57

willy4711 hat geschrieben: ↑ zum Beitrag ↑
12.09.2018 18:08:04
Hallo erstmal, ich bin der Neue
Willkommen Neuer! ;)
willy4711 hat geschrieben: ↑ zum Beitrag ↑
12.09.2018 18:08:04
[/code]

Code: Alles auswählen

dpkg -l *cuda* |grep ii
ii  libcuda1:amd64       390.77-1     amd64        NVIDIA CUDA Driver Library
ii  libcuda1:i386        390.77-1     i386         NVIDIA CUDA Driver Library
ii  libcuda1-i386:i386   390.77-1     i386         NVIDIA CUDA 32-bit runtime library
Das ist entweder stretch-Backports oder Buster. Ich tippe auf Letzteres.
Weil du das nicht explizit erwähnst würde mich jetzt interessieren, ob du ffmpeg und mpv neu compiliert hast.

willy4711

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von willy4711 » 13.09.2018 17:26:33

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 15:46:57
Das ist entweder stretch-Backports oder Buster. Ich tippe auf Letzteres.
Buster mit deb.multimerdia
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 15:46:57
Weil du das nicht explizit erwähnst würde mich jetzt interessieren, ob du ffmpeg und mpv neu compiliert hast.
Verstehe ich nicht. Hab nur Standard installiert.

Ich hatte mal hier
https://developer.nvidia.com/video-enco ... ort-matrix
und hier
https://developer.nvidia.com/nvidia-video-codec-sdk

und dann das Manual von Debianmpv durchprobiert:
unter:
--hwdec=<api>
steht:
cuda requires --vo=gpu (Any platform CUDA is available)
Mehr steht noch im Reference manual:
cuda should be safe, but it has been reported to corrupt the timestamps causing glitched, flashing frames on some files. It can also sometimes cause massive framedrops for unknown reasons. Caution is advised.
Aber vielleicht sind diese Samples zufällig gerade der richtige Codec.
dann hab ich noch alles was mit Cuda zu tun hat installiert
zusätzlich noch
Debianlibnvidia-fatbinaryloader

Dann hat es funktioniert. Andere Kombinationen lassen alle die CPU rechnen.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von hikaru » 13.09.2018 21:16:59

willy4711 hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 17:26:33
Buster mit deb.multimerdia
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 15:46:57
Weil du das nicht explizit erwähnst würde mich jetzt interessieren, ob du ffmpeg und mpv neu compiliert hast.
Verstehe ich nicht. Hab nur Standard installiert.
dmo schummelt mächtig gewaltig.
ffmpeg steht auch bei dmo in main, aber gebaut wurde das Paket mit --enable-nonfree :

Code: Alles auswählen

$ grep nonfree ffmpeg-dmo-4.0.2/debian/rules 
	--enable-nonfree \
willy4711 hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 17:26:33
Ich hatte mal hier
https://developer.nvidia.com/video-enco ... ort-matrix
Interessant!
Ich sehe da bei den älteren GPUs, dass die GTX 950 HEVC unterstützt, was ich ja aus eigener Erfahrung bestätigen kann. Da steht aber auch, dass sogar die GTX 750 HEVC unterstützt.
Falls das hier ein Besitzer einer GTX 750 liest, würde mich mal interessieren, ob ich damals hätte Geld sparen können.

willy4711

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von willy4711 » 13.09.2018 21:57:56

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 21:16:59
dmo schummelt mächtig gewaltig.
ffmpeg steht auch bei dmo in main, aber gebaut wurde das Paket mit --enable-nonfree :
Ja stimmt- dann hab ich ja alles - ohne es zu wissen - richtig gemacht - ein Grund mehr DMO zu benutzen
Aber was hat das "non-free" nun genau damit zu tun, dass ich nun HEVC main 10 via GPU sehen kann ?
Ist doch gut oder ??

Code: Alles auswählen

~$ apt-cache policy ffmpeg
ffmpeg:
  Installiert:           10:4.0.2-dmo3
  Installationskandidat: 10:4.0.2-dmo3
  Versionstabelle:
 *** 10:4.0.2-dmo3 500
        500 http://www.deb-multimedia.org testing/main amd64 Packages
        100 /var/lib/dpkg/status
     7:4.0.2-1+b1 500
        500 http://ftp.debian.org/debian testing/main amd64 Packages

Code: Alles auswählen

~$ ffmpeg
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8 (Debian 8.2.0-4)
  configuration: --disable-decoder=amrnb --disable-decoder=libopenjpeg --disable-mips32r2 --disable-mips32r6 --disable-mips64r6 
  --disable-mipsdsp --disable-mipsdspr2 --disable-mipsfpu --disable-msa --disable-libopencv --disable-podpages --disable-sndio
   --disable-stripping --enable-libaom --enable-avfilter --enable-avresample --enable-gcrypt --enable-gnutls --enable-gpl 
   --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 
   --enable-libfdk-aac --enable-libfontconfig 
   --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc --enable-libkvazaar --enable-libmp3lame 
   --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt 
   --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex 
   --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx 
   --enable-libx265 --enable-libxvid --enable-libzvbi --enable-nonfree --enable-opencl --enable-opengl --enable-postproc
    --enable-pthreads  --enable-shared --enable-version3 --enable-libwebp --incdir=/usr/include/x86_64-linux-gnu
     --libdir=/usr/lib/x86_64-linux-gnu 
   --prefix=/usr --toolchain=hardened --enable-frei0r --enable-chromaprint --enable-libx264 --enable-libiec61883 --enable-libdc1394 
   --enable-vaapi --enable-libmfx --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
  libavutil      56. 14.100 / 56. 14.100
  libavcodec     58. 18.100 / 58. 18.100
  libavformat    58. 12.100 / 58. 12.100
  libavdevice    58.  3.100 / 58.  3.100
  libavfilter     7. 16.100 /  7. 16.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  1.100 /  5.  1.100
  libswresample   3.  1.100 /  3.  1.100
  libpostproc    55.  1.100 / 55.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von hikaru » 13.09.2018 23:39:03

willy4711 hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 21:57:56
Aber was hat das "non-free" nun genau damit zu tun, dass ich nun HEVC main 10 via GPU sehen kann ?
Das weiß ich ehrlich gesagt nicht genau - zumindest der technische Aspekt ist mir nicht klar.
Unter Jessie und Stretch brauchte man zusätzlich noch die beiden Schalter --enable-cuvid und --enable-cuda, um HEVC auf Nvidia-Karten abspielen zu können. So wie ich es verstanden hatte, war Ersterer dafür zuständig, den eigentlichen Decodierungsquellcode einzubinden, während Letzterer Cuda einband, was gewissermaßen das "Backend" für Cuvid darstellt (ähnlich Shared Libraries hinter Programmpaketen).
Warum es diese Schalter in dem ffmpeg-dmo-Paket nicht (mehr) gibt und die HEVC-Decodierung trotzdem funktioniert weiß ich nicht. Vielleicht war das in 3.x etwas Experimentelles das man nicht standardmäßig drin haben wollte, und mit 4.x wurde es regulär aufgenommen, so dass man bei ffmpeg keinen Bedarf mehr dafür sieht, die Funktionalität rauszuziehen.

ffmpeg ist Freie Software, genauer, es steht unter der LGPL. Die LGPL verhält sich in diesem Kontext wie die GPL. Der ffmpeg-Code für Cuda und/oder Cuvid linkt gegen Schnittstellen des Nvidia-Treibers, die nicht GPL-konform sind. Das entstehende Binary ist damit nicht mehr Frei im Sinne der GPL. [1]
Um zu verhindern, dass man aus Versehen so ein unfreies ffmpeg compiliert, werden nicht GPL-konforme Schalter in ffmpeg nur wirksam, wenn man explizit auch den Schalter --enable-nonfree legt. Das ist gewissermaßen eine Sicherheitsabfrage, mit der man bestätigt: "Ja, ich habe verstanden, dass das entstehende Binary nicht GPL-konform ist."
Bei dmo scheint man sich nun um diese Lizenzfrage nicht zu scheren. Ich glaube das ist auch einer der Reibungspunkte zwischen Debian und dmo.
willy4711 hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 21:57:56
Ist doch gut oder ??
Technisch ja, im Sinne des Debian Social Contract ist es nicht.

Jetzt wäre mal interessant zu prüfen, ob es in Debians ffmpeg ab Buster noch die beiden Schalter --enable-cuvid und --enable-cuda gibt oder ob auch hier ein einfaches Compilieren mit --enable-nonfree ausreicht um ffmpeg mit HEVC zu kriegen.
Wenn ich dazu Gelegenheit habe, werde ich das in den nächsten Wochen mal testen.


[1] https://www.gnu.org/licenses/gpl-faq.en ... WithNFLibs

willy4711

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von willy4711 » 14.09.2018 23:36:11

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 23:39:03
Unter Jessie und Stretch brauchte man zusätzlich noch die beiden Schalter --enable-cuvid und --enable-cuda, um HEVC auf Nvidia-Karten abspielen zu können.
Habe das gerade mal in Buster in einer Vm nachgesehen:
Beide Schalter und natürlich auch non-free sind nicht vorhanden.
Das macht aus meiner Sicht aber wenig Sinn.
Auf der einen Seite bietet man via non-free Repos unfreie Treiber und Software an.
Anderseits "kastriert" man die Möglichkeiten der unfreien Treiber durch das entscheidende Codec-Paket ohne auch nur darauf hinzuweisen.
Fairer Weise sollte man doch dann auf deb.multimedia hinweisen. Sonst würde es höchstwahrscheinlich Probleme geben.
Bis auf Debianlibc6 und Debianlibsdl2-2.0-0 stammen alle anderen Abhängigkeiten aus deb.multimedia

Code: Alles auswählen

 apt-cache depends ffmpeg
ffmpeg
  Hängt ab von: libavcodec58
  Hängt ab von: libavdevice58
  Hängt ab von: libavfilter7
  Hängt ab von: libavformat58
  Hängt ab von: libavresample4
  Hängt ab von: libavutil56
  Hängt ab von: libc6
  Hängt ab von: libpostproc55
  Hängt ab von: libsdl2-2.0-0
  Hängt ab von: libswresample3
  Hängt ab von: libswscale5
  Kollidiert mit: <ffprobe>
  Schlägt vor: <nvidia-libvdpau1>
  Ersetzt: libav-tools
  Ersetzt: <libavcodec52>

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: 4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

Beitrag von hikaru » 17.09.2018 13:22:53

willy4711 hat geschrieben: ↑ zum Beitrag ↑
14.09.2018 23:36:11
hikaru hat geschrieben: ↑ zum Beitrag ↑
13.09.2018 23:39:03
Unter Jessie und Stretch brauchte man zusätzlich noch die beiden Schalter --enable-cuvid und --enable-cuda, um HEVC auf Nvidia-Karten abspielen zu können.
Habe das gerade mal in Buster in einer Vm nachgesehen:
Beide Schalter und natürlich auch non-free sind nicht vorhanden.
Nur zur Klarstellung: Das ist Debian, nicht dmo. In dmo liegt --enable-nonfree.
willy4711 hat geschrieben: ↑ zum Beitrag ↑
14.09.2018 23:36:11
Das macht aus meiner Sicht aber wenig Sinn.
Auf der einen Seite bietet man via non-free Repos unfreie Treiber und Software an.
Anderseits "kastriert" man die Möglichkeiten der unfreien Treiber durch das entscheidende Codec-Paket ohne auch nur darauf hinzuweisen.
Das ist Ansichtssache. Ein mit --enable-nonfree gebautes ffmpeg müsste gemäß DFSG nach non-free. Mir fehlt gerade der Überblick, aber ich würde vermuten, dass rund die Hälfte der multimediarelevanten Pakete in Debian direkt oder indirekt von ffmpeg abhängen. Die müssten dann alle mit nach non-free oder zumindest contrib.
Das wäre philosophisch ein ziemlicher Einschnitt für das Debian-Projekt, denn Debian versteht sich ja als dem DSC (und damit den DFSG) verbunden. Nach offizieller Ansicht gehören contrib und non-free gar nicht wirklich zum Debian-Projekt, sondern sie werden nur "den Usern zuliebe" von den selben Maintainern auf der selben Infrastruktur gewartet.
Das "offizielle Debian" würde mit einer Verschiebung von ffmpeg nach non-free einen Großteil seiner Multimediafähigkeit einbüßen, und das auch noch, obwohl die wohl meisten Nutzer gar nicht die nonfree-Option in ffmpeg brauchen.

Natürlich könnte man nun aus einer dmo-Perspektive einwenden, dass genau für diesen Fall doch dmo da wäre. Das Problem ist eben, dass dmo philosophisch nicht zu Debian passt, deshalb gibt es ja dieses Nebenprojekt überhaupt nur (weil es unter dem offiziellen Debian-Dach keinen Platz hat). Deshalb empfiehlt es Debian nicht. Deshalb möchte Debian ffmpeg auch in main behalten und deshalb ist ffmpeg in Debian ohne --enable-nonfree gebaut.
Die konkrete Frage die ich mir stelle, als jemand der eher aus der Debian-Perspektive schaut als aus der von dmo, ist: Warum liegt ffmpeg in dmo nicht in non-free?

PS: Jetzt wo ich näher darüber nachdenke, könnte ich mir vielleicht eine duale Lösung wie z.B. für Debianunrar vorstellen, wo dann ein Debianffmpeg-free in main und ein Debianffmpeg-nonfree in non-free läge und beide stellen Debianffmpeg bereit. Je nachdem, welches man dann installiert, kann man eben HEVC auf Nvidia decodieren oder nicht.
Das Hauptproblem sehe ich hier allerdings in dem "Rattenschwanz" den ffmpeg nach sich zieht. unrar ist ein "Leaf-Paket", also ein Paket am Ende des Zweiges von dem nichts (oder wenig) abhängt. ffmpeg ist aber kein Leaf-Paket. Es wird eine ganze Menge Software auf Basis von ffmpeg gebaut und je nachdem was ffmepg bereitstellt, ändert sich das Verhalten der darauf compilierten Programme. Man müsste also auch den ganzen Rattenschwanz doppelt pflegen. Ich vermute, genau das will man bei Debian nicht. Ich zumindest würde es nicht wollen.


Um dem Beitrag noch etwas technische Relevanz zu geben:
Ich habe am Wochenende unter Buster (ohne dmo) ffmpeg einmal nur mit zusätzlichem --enable-nonfree und einmal mit --enable-nonfree --enable-cuda --enable-cuvid --enable-nvenc gebaut und auf dieser Basis dann jeweils einmal mpv. Dabei musste ich den unter [1] erwähnten Hinweis zu ffnvcodec.pc beachten, auf den ich über [2] aufmerksam wurde. Der Paketbau verlief danach problemlos. Ich hoffe, die Pakete am nächsten Wochenende auf der GTX 950 testen zu können.


[1] https://trac.ffmpeg.org/wiki/HWAccelIntro
[2] https://superuser.com/questions/1299064 ... -ffnvcodec

Antworten