DiAVC - bisher schnellster AVC-Decoder - taugt der was ?

Nun, im englischen doom9-Forum wird er ausgiebig getestet. Mit Ausnahme eines einzigen Gegners ist er bei allen anderen Testern der schnellste Software-Decoder (verglichen u.a. mit CoreAVC, DivX H.264 und ffmpeg-mt). Ich hab ihn mir auch registriert, weil ich noch eine ältere Nvidia-Karte (6800) habe, die noch nicht CUDA-fähig ist, und bin recht zufrieden. Im AviSynth-Plugin DGAVCDecDI wird der DiAVC-Decoder auch verwendet (als Ersatz für den nicht immer frame-exakten libavcodec-Decoder damaliger DGAVCDec-Versionen). Das einzige, was DiAVC wohl bisher noch nicht beherrscht, dürfte Lossless-AVC sein. Und man sollte möglichst eine SSE2- oder gar SSE3-fähige CPU haben (auch wenn Kompatibilität bis herunter zu MMX gesichert werden soll).

Schnell soll der DiAVC schon sein, aber selbst bei Tests auf der Anbieterseite von DiAVC sieht man: Welten liegen nicht dazwischen:
http://www.di-avc.com/compare/compare.html

Sehr gern hätte mich auch mal der Unterschied zu ffdshow interessiert.

Gruß

akapuma

ffdshow ist vertreten durch "ffmpeg-mt". Schon seit einiger Zeit bietet der Filter diesen Multithreading-Decoder an.

Ich hatte vor kurzem selbst ein paar Tests auf meinem Q6600 System gemacht:
http://forum.doom9.org/showpost.php?p=1442024&postcount=1100

Leider muss ich sagen, dass DiAVC zwar wirklich performant, aber noch nicht ganz "stabil" ist.
In DVBViewer ist die Ausgabe mit DiAVC fehlerhaft, während die anderen (CoreAVC mit/ohne CUDA, ffdshow mit/ohne MT, DivX H.264 Decoder) problemlos funktionieren.
Und in MPC-HC hatte ich das Problem, dass die GUI unter Verwendung von DiAVC nur stark verzögert reagiert...

Hi,

Unterstützt denn dieser DiAVC, CUDA oder andere Hardwarebeschleunigung ?

bye Haka

Zitat von Haka

Hi,

Unterstützt denn dieser DiAVC, CUDA oder andere Hardwarebeschleunigung ?

bye Haka

Nein. Und es macht ja auch keinen Sinn, den schnellsten H.264 Software-Decoder zu entwickeln und dann den Hardware-Decoder die ganze Arbeit machen zu lassen

(Dazu muss man wissen, dass die heute verfügbaren "CUDA beschleunigten" Decoder nicht etwa die einen GPU-basierten Decoder per CUDA implementieren, sondern lediglich über die CUVID-Schnittstelle den in der Grafikkarte integrierten Hardware-Decoder ansprechen. Das bedeutet auch, dass sich sämtliche "CUDA Decoder" in puncto Performance oder Level/Profile Unterstützung oder Decoder-Bugs nicht im Geringsten unterscheiden, da die ganze Arbeit so oder so von der identischen Hardware übernommen wird und der "Software" Teil lediglich die Daten weiterreicht)

Zitat von Haka

Hi,

Unterstützt denn dieser DiAVC, CUDA oder andere Hardwarebeschleunigung ?

bye Haka

DiAVC ist ein reiner Software-Decoder ohne jegliche GPU-Unterstützung bei der Decodierung. Meines Wissens plant "schweinsz" auch nichts dergleichen für DiAVC.

Was er plant ist aber angeblich ein eigener Videorenderer, der per NVIDIAs CUDA oder ATIs STREAM die GPU für's Resizing, Schärfen, Entrauschen usw. nutzen kann. Siehe hier:

Zitat von schweinsz

No, I have no plan to use CUDA or ati's STREAM for offloading the cpu decoding, but I have a big plan to use the CUDA or ati's STREAM to post-process the frames, including super-resolution, sharpen, denoise, etc. I plan to code a video renderer to do this. I am learning the cuda.

Die GPU (und nicht den integrierten Hardware-Decoder) per CUDA/STREAM zum Post-Processing einzusetzen ist natürlich etwas anderes. Und es könnte durchaus Sinn machen.

Aber bis jetzt ist davon noch nix zu sehen. Also mal abwarten, ob der Ankündigung auch Taten folgen

Zitat von LoRd_MuldeR

Dazu muss man wissen, dass die heute verfügbaren "CUDA beschleunigten" Decoder nicht etwa die einen GPU-basierten Decoder per CUDA implementieren, sondern lediglich über die CUVID-Schnittstelle den in der Grafikkarte integrierten Hardware-Decoder ansprechen.

Moment... Moment... verstehe ich das richtig: über CUDA kommt (bei den gängigen Decoder-Lösungen) der selbe in der GPU integrierte Hardware-Videodecoder zum Einsatz, der prinzipiell auch bei DXVA zum Einsatz kommt !?

Zitat von Tom Keller

Moment... Moment... verstehe ich das richtig: über CUDA kommt (bei den gängigen Decoder-Lösungen) der selbe in der GPU integrierte Hardware-Videodecoder zum Einsatz, der prinzipiell auch bei DXVA zum Einsatz kommt !?

Exakt

Wieso sollte sich jemand die Mühe machen einen H.264 Decoder über CUDA oder Stream als "echten" GPU Kernel zu implementieren (und zu testen!), wenn bei praktisch jeder halbwegs aktuellen Grafikkarte ein fix und fertiger H.264 Decoder bereits als "fest verdrahtete" Hardware (bei Nvidia "VPx" genannt) an Bord ist? Der einzige Unterschied ist, dass sich der Hardware Decoder über die CUDA Video API (CUVID) möglicherweise flexibler ansprechend lässt als über DXVA. Ich würde auch mal vermuten, eine "dedifizierter" Hardware Decoder arbeitet Energie-effizienter als eine GPU.

(Auch unterscheidet sich die Leistung der GPU zwischen den "Top" und den "Low-Budget" Modellen enorm, wohingegen der Hardware Decoder bei allen Modellen einer Generation der selbe ist)

Ist das dann auch bei DGIndexNV so? Falls "ja" verstehe ich nämlich nicht, warum darüber mit meiner 9600GT (neben H.264- auch) VC-1- und MPEG2-Decodierung möglich ist, wenn das doch der in der GPU integrierte Videodecoder gar nicht beherrscht :hm: ...

Zitat von Tom Keller

Ist das dann auch bei DGIndexNV so? Falls "ja" verstehe ich nämlich nicht, warum darüber mit meiner 9600GT (neben H.264- auch) VC-1- und MPEG2-Decodierung möglich ist, wenn das doch der in der GPU integrierte Videodecoder gar nicht beherrscht :hm: ...

Ja, definitiv!

Du kannst auch mit GPU-Z nachprüfen, dass beim Decodieren mit DGDecNV der "Video Engine Load" hoch geht, nicht aber der "GPU Load".

Eine GeForce 9600GT verfügt laut Liste (übrigens auf der DGDecNV Web-Seite verlinkt) über einen "VP2" Decoder Chip:
http://en.wikipedia.org/wiki/PureVideo…o_.28HD.29_GPUs

Und weiter:

Zitat

"PureVideo HD der zweiten Generation kann Videos in den Formaten MPEG-2, H.264 und WMV3/VC-1 verarbeiten und damit den Hauptprozessor beim Abspielen dieser Videoformate entlasten."
- http://de.wikipedia.org/wiki/Nvidia_Pu…eite_Generation

Außerdem steht ja auch auf der DGDecNV Seite:

Zitat

That means the card must have a VP2 or greater engine. VP1 is not supported!

Das ist der Punkt, den ich nicht nachvollziehen kann. Die 9600GT bietet doch meines Wissens über den VP2 keine VC-1- und MPEG2-Full-Bitstream-Decodierung, sondern für beides(?) "nur" iDCT und Motion Compensation. Heißt das jetzt, dass bei DGIndexNV das Bitstream Processing grundsätzlich von der CPU erledigt wird (egal ob man es mit H.264, VC-1 oder MPEG2 füttert)... oder wird bei H.264 (da es der VP2 ja kann) das Bitstream Processing auch gleich vom VP2 übernommen? Wobei letzteres ja irgendwie unlogisch wäre, da Donald Graft DGIndexNV dann sozusagen für alle Eventualitäten ausgerüstet haben müsste - also: erste Decoderstufe für VP3+ über CUDA & darunter per CPU - was ja den Entwicklungsaufwand deutlich erhöhen würde...

Zitat von Tom Keller

Das ist der Punkt, den ich nicht nachvollziehen kann. Die 9600GT bietet doch meines Wissens über den VP2 keine VC-1- und MPEG2-Full-Bitstream-Decodierung, sondern für beides(?) "nur" iDCT und Motion Compensation. Heißt das jetzt, dass bei DGIndexNV das Bitstream Processing grundsätzlich von der CPU erledigt wird (egal ob man es mit H.264, VC-1 oder MPEG2 füttert)... oder wird bei H.264 (da es der VP2 ja kann) das Bitstream Processing auch gleich vom VP2 übernommen? Wobei letzteres ja irgendwie unlogisch wäre, da Donald Graft DGIndexNV dann sozusagen für alle Eventualitäten ausgerüstet haben müsste - also: erste Decoderstufe für VP3+ über CUDA & darunter per CPU - was ja den Entwicklungsaufwand deutlich erhöhen würde...

Nur weil beim VP2 Chip das "Bitstream Processing" für die Formate MPEG-2 und VC-1 weiterhin "in Software" abläuft, heißt das ja nicht, dass dieser Teil des Decodierungs-Prozesses zwangsläufig in der Anwendung selbst implementiert werden muss. Ich kenn mich jetzt mit der CUVID-Schnittstelle nicht im Detail aus, würde aber mal stark vermuten, dass solche "Details" entweder im Nvidia-Treiber oder in der CUVID Bibliothek weg abstrahiert werden. Was nicht "in Hardware" unterstützt wird, muss eben Software-seitig emuliert werden - aber das kann für die jeweilige Anwendung transparent geschehen. Wirklich Aufwendung ist das "Bitstream Processing" ohnehin vor allem bei H.264 (Stichwort: CABAC) und dass beherrscht VP2 bekanntlich in Hardware.

Das mit der softwareseitigen Umsetzung war mir schon klar. Ich konnte mir halt nur nicht vorstellen, dass DG sowas extra für DGIndexNV entwickelt hätte, um allen NVIDIA-CUDA-Usern die selben Funktionen zur Verfügung zu stellen. Das schien mir einfach zu abwegig - und deswegen konnte ich mir die VC-1/MPEG2-Unterstützung von DGIndexNV nicht wirklich erklären (auch wenn ich sehr froh über deren Existenz bin). Aber das mit der Abstrahierung im Treiber bzw. in den CUVID Libraries klingt tatsächlich am logischsten - auf die Idee bin ich gar nicht gekommen.
:ichdoof:
Danke für den (offensichtlich nötigen) Denkanstoß!

Zurück zu Lück:

Zitat von Haka

Unterstützt denn dieser DiAVC, CUDA oder andere Hardwarebeschleunigung ?

Nicht die Beschleunigung der Grafikkarte.

Aber ganz massiv Beschleunigungen des Prozessors basierend auf "Streaming SIMD Extensions": SSE2 und SSE3 werden - wo verfügbar - optimal genutzt, hier hat schweinsz anscheinend erhebliches Hintergrundwissen.

Und davon abgesehen (@ Didée) wäre er wohl nicht der erste Decoder, der mit DVBViewer Problemchen hat. Der ist ja schon als Kompatibilitäts-Benchmark verschrien wie damals der MS FlightSim 1 für "IBM-kompatible PCs". ;D

Zitat von LigH

Und davon abgesehen (@ Didée) wäre er wohl nicht der erste Decoder, ...

Hast Du Lord-M gemeint? Ich hab' doch gar nichts gesagt ...

Zitat von schweinsz

I have a big plan to use the CUDA or ati's STREAM to post-process the frames, including super-resolution, sharpen, denoise, etc.

Hehe, da freu' ich mich schon drauf. Wenn eine Quelle "normal" gesample'd ist, dann ist Super-Resolution technisch nicht möglich. Egal ob CUDA oder STREAM.