PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Mit der GPU Videos komprimieren


Seiten : 1 2 [3] 4

deekey777
2009-12-05, 21:51:25
Es ist aber auch vollstellbar, dass das Encoding weiterhin auf der CPU läuft, das Decoding dagegen auf der GPU.

Intel hat mit Ct ein eigenes Süppchen.

deekey777
2011-08-21, 16:33:27
H.264 encoding - CPU vs GPU: Nvidia CUDA, AMD Stream, Intel MediaSDK and x264 (http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html)
Videoumwandlung auf einer Radeon weiterhin unbrauchbar.
Videoumwandlung über Cuda kaum brauchbar.
Videoumwandlung mit x264&GUI: einzig und allein brauchbar.

Zur Ehrenrettung von Cyberlink MSE: Es kann auch Main oder High, wenn man das PS3-Profil nimmt (aber nicht auf einer Radeon).

LovesuckZ
2011-08-21, 16:35:32
Wenn man Zeit hat, ist Nicht-CPU-Umwandlung sowieso keine Frage.

Ansonsten hängt das ganze doch vom Ausgangsmaterial, dem eigenen Anspruch und der investierten Zeit ab.

ENKORE
2011-08-21, 18:15:26
Wie man sieht reichts ja bereits für n billiges iphone/ipod etc. aus... auf den glare screens sieht man ja eh fast nix

deekey777
2011-08-21, 18:37:44
Wie man sieht reichts ja bereits für n billiges iphone/ipod etc. aus... auf den glare screens sieht man ja eh fast nix
Wie bitte was?

Deinorius
2011-08-21, 20:51:17
Videoumwandlung auf einer Radeon weiterhin unbrauchbar.


Es ist an sich interessant, dass die Qualität mit AMD sogar höher liegt, als bei nvidia. Zugegeben, die Bitrate liegt bei AMD höher, dafür war es aber durchgehend mit Baseline statt Main kodiert.

Nichts desto trotz ändert das nix am Zustand der GPU Encoder allgemein. Im derzeitigen Zustand gibts nicht mal für die ohne Zeit keine Begründung das zu nutzen.

Wie man sieht reichts ja bereits für n billiges iphone/ipod etc. aus... auf den glare screens sieht man ja eh fast nix


Öhm... um es mal diplomatisch auszudrücken; selbst für diese Nutzergruppe ist StaxRip die bessere Wahl. Die Qualität ist höher und man kann die Geschwindigkeit erhöhen und würde dennoch nicht unter die Qualität der GPU Encoder kommen.
Die Usability von StaxRip ist auch gut genug. Solche Programme sollte man so oder so nur nutzen, solange man kein kompletter... ähm... kein DAU ist.

Und um es nicht diplomatisch auszudrücken: *zensiert* :P

aufkrawall
2011-08-22, 09:53:47
Und was ist besser bei StaxRip als bei Handbrake?
Kann mit den aktuellen Nightlies sogar DTS-HD Passthru (wenn mans braucht ;) ).
Sowohl DVD- als auch BD-Rips waren hier damit absolut gelungen und die Bedienung ist kinderleicht.

Hab mit den ganzen GPU gestützten Programmen auch nur schlechte Erfahrungen gemacht. Quali mist, Ton nicht synchron zum Bild, geringe Ton-Quali und Abstürze...

deekey777
2011-08-22, 10:04:37
Und was ist besser bei StaxRip als bei Handbrake?
....
Nichts.
Darum steht ja "solche Programme". :)
Ich selbst habe lange Zeit RipBot benutzt, um Filme für mein iPhone umzuwandeln, aber irgendwie will es nicht mehr, also bin ich auf Handbrake umgestiegen.
Es ist an sich interessant, dass die Qualität mit AMD sogar höher liegt, als bei nvidia. Zugegeben, die Bitrate liegt bei AMD höher, dafür war es aber durchgehend mit Baseline statt Main kodiert.

Nichts desto trotz ändert das nix am Zustand der GPU Encoder allgemein. Im derzeitigen Zustand gibts nicht mal für die ohne Zeit keine Begründung das zu nutzen.


...:P
Also was mit AMC&Cuda los ist, weiß ich nicht, MSE ist da deutlich besser.
Egal: MSE beherrscht die Möglichkeit, dass die Grafikkarte die Decodierung übernimmt, was die Rechenzeit reduziert. Leider ist das Programm an sich so geschrieben, dass ja niemand seine Blu-rays fürs iPhone umwandelt. Hinzu kommt, dass das Programm an sich sehr eingeschränkt ist.
Daher ist aktuell die beste Möglichkeit, Dekodierung auf die GPU bzw. deren Videoprozessor auszulagern und mit x264 zu kodieren. Cuda-Paket hat ja die entsprechende Dokumentation, wird auch genutzt. AMD bietet entsprechendes seit einigen APP-Versionen an, ob das schon jemand nutzt, weiß ich nicht.

Deinorius
2011-08-22, 11:02:08
Solche kommerziellen Programme kann man als ernsthafter Videofreak doch nie in Betracht ziehen. ;)
Das teilweise stark beeinträchtige Featureset ist dabei noch das schlimmste von allen, obwohl das Missachten der besten Encoder an sich noch schlimmer sein müsste.

Daher ist aktuell die beste Möglichkeit, Dekodierung auf die GPU bzw. deren Videoprozessor auszulagern und mit x264 zu kodieren. Cuda-Paket hat ja die entsprechende Dokumentation, wird auch genutzt. AMD bietet entsprechendes seit einigen APP-Versionen an, ob das schon jemand nutzt, weiß ich nicht.


So ist es. Schade aber, dass nur die GT 520 die derzeit beste VP5 bereit hält. Dass jedoch AMD mit der Dokumentation nachholt, ist aber ein freudige Botschaft, wird jedoch von DG NV nicht verwendet. Falls die Dokumentation gut genug dafür ist.

deekey777
2012-03-22, 23:54:08
So, beide Hersteller bieten jetzt Hardware-Encoder an, Nvidia hat sogar geschafft, Vorabversion von Media Esspresso bereitzustellen, während AMDs VCE noch brach liegt (können die Besitzer neuer Radeons den OpenCL 1.2 Betatreiber vom 15.03.2012 anschauen?).
Hier die Balken:
http://www.computerbase.de/artikel/grafikkarten/2012/test-nvidia-geforce-gtx-680/21/#abschnitt_nvenc_mit_mediaespresso_im_einsatz
http://www.guru3d.com/article/geforce-gtx-680-review/6

Aber wie immer gilt: Schneller ist definitiv nicht besser und die kommerzielle Software ist Schrott.

AnarchX
2012-03-22, 23:59:14
Hier gibt es eine SSIM Analyse:

http://www.pcinlife.com/article_photo/gtx_680/results/encoder.png

http://pc.pcinlife.com/Graphics/20120322/GeForce-GTX-680.html#NVENC_%E7%94%BB%E9%9D%A2%E5%93%81%E8%B4%A8%E9%87%8F%E5%8C%96%E6%B5%8B%E 8%AF%95%E7%BB%93%E6%9E%9C

Was das Whitepaper zum NVENC sagt:
NVENC
All Kepler GPUs also incorporate a new hardware-based H.264 video encoder, NVENC.
Prior to the introduction of Kepler, video encoding on previous GeForce products was handled by encode software running on the GPU’s array of CUDA Cores. While the CUDA Cores were able to deliver tremendous performance speedups compared to CPU-based encoding, one downside of using these high-speed processor cores to process video encoding was increased power consumption.
By using specialized circuitry for H.264 encoding, the NVENC hardware encoder in Kepler is almost four times faster than our previous CUDA-based encoder while consuming much less power.
27
It is important to note that an application can choose to encode using both NVENC hardware and NVIDIA’s legacy CUDA encoder in parallel, without negatively affecting each other. However, some video pre-processing algorithms may require CUDA, and this will result in reduced performance from the CUDA encoder since the available CUDA Cores will be shared by the encoder and pre-processor.
NVENC provides the following:
 Can encode full HD resolution (1080p) videos up to 8x faster than real-time. For example, in high performance mode, encoding of a 16 minute long 1080p, 30 fps video will take approximately 2 minutes.
 Support for H.264 Base, Main, and High Profile Level 4.1 (same as Blu-ray standard)
 Supports MVC (Multiview Video Coding) for stereoscopic video—an extension of H.264 which is used for Blu-ray 3D.
 Up to 4096x4096 encode
We currently expose NVENC through proprietary APIs, and provide an SDK for development using NVENC. Later this year, CUDA developers will also be able to use the high performance NVENC video encoder. For example, you could use the compute engines for video pre-processing and then do the actual H.264 encoding in NVENC. Alternatively, you can choose to improve overall video encoding performance by running simultaneous parallel encoders in CUDA and NVENC, without affecting each other’s performance.
NVENC enables a wide range of new use cases for consumers:
 HD videoconferencing on mainstream notebooks
 Sending the contents of the desktop to the big screen TV (gaming, video) through a wireless connection
 Authoring high quality Blu-ray discs from your HD camcorder
A beta version of Cyberlink MediaEspresso with NVENC support is now available on the GeForce GTX 680 press FTP. Support will be coming soon for Cyberlink PowerDirector and Arcsoft MediaConverter.

http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf

robbitop
2012-03-23, 08:44:18
Die Frage ist ja definitiv zu stellen, wie gut die Qualität ist. Bei Intel war sie brauchbar - aber nur für die schnelle Convertierung für das Smartphone. Vergleichbar gute Qualität wie mit der CPU gab es nicht. Interessant wäre es zu wissen, ob das nun deutlich besser geht.

Deinorius
2012-03-23, 08:49:47
Die SSIM-Werte sind wahrlich nicht berauschend. Schade, dass die nicht gegen x264 getestet haben.

Mich würde viel mehr interessieren, ob man diese Hardware-Einheit irgendwie für x264 nutzen könnte (CPU- und NVENC-Nutzung gleichzeitig). Weiß da jemand von einer Diskussion dazu? Bei Intels Hardware-Einheit gab es ja eine Diskussion, die dem Ganzen nicht abgeneigt war.

robbitop
2012-03-23, 09:03:18
SSIM? Kann mir jemand kurz erklären, was das ist?

Deinorius
2012-03-23, 09:13:35
Eine Methode Bildqualität in Zahlen auszudrücken. Während PSNR schlecht nutzbar ist, berücksichtigt SSIM psychovisuelle Begebenheiten. Heißt, es wird eher darauf geachtet, ob das Bild für das Auge gut aussieht, als dass es für eine Maschine (PSNR) gut aussieht.

Ich hoffe, ich habe es vernünftig genug ausgedrückt. :)

robbitop
2012-03-23, 10:38:28
Und SSIM von 1 ist zu erreichen? Was schafft denn ein gut eingestelltes x264 bei ähnlichen Bitraten?

deekey777
2012-03-23, 14:53:25
SSIM? Kann mir jemand kurz erklären, was das ist?
http://www.behardware.com/articles/828-5/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html
...
Mich würde viel mehr interessieren, ob man diese Hardware-Einheit irgendwie für x264 nutzen könnte (CPU- und NVENC-Nutzung gleichzeitig). Weiß da jemand von einer Diskussion dazu? Bei Intels Hardware-Einheit gab es ja eine Diskussion, die dem Ganzen nicht abgeneigt war.
Ich hab mir (wieder) den Riesenthread im Doom9-Forum angetan. Niemand hielt Intel davon ab, libx264 in Quickdings zu integrieren. Niemand wird abgehalten, x264 auf Quicksync zu portieren. Nur kann das nur dann passieren, wenn Intel den Lowlevel-Acces ermöglicht.
DS scheint letztes Jahr den Zugang zum Lowlevel bekommen zu haben:

Arguably, because you haven't submitted a patch yet: there's nothing stopping anyone from adding Sandy Bridge hardware support to libx264. I haven't blocked any attempts at this, and I don't plan to. I don't plan to write Sandy Bridge hardware support for x264, but I'm not the only developer, and it's an open source project.
Since the original Intel failure, I have learned quite a bit more about the lower-level details, and I'd quite love to explain more, but unfortunately I am now deep into NDA territory. If this means people are going to blame x264 for QuickSync's failings, well, unfortunately there's not much I can legally do about it anymore.
does that mean you are now technically able to allow some parts of x264 encoding to be done by quicksync? If so is this support going to be added?
Maybe yes, probably not. There are some pretty devastating technical limitations.

Weder Nvidia noch AMD werden abgehalten, x264 in ihre Hardware-Encoder zu integrieren (so weit es geht). Tun sie das nicht, wäre das durch Dritte nur dann möglich, wenn man Lowlevel-Access auf diese Encoder bekommt.

Deinorius
2012-03-23, 21:32:57
Und SSIM von 1 ist zu erreichen? Was schafft denn ein gut eingestelltes x264 bei ähnlichen Bitraten?


Du weißt, was der Wirkungsgrad ist? Soviel zu 1.
Die Werte sehen vielleicht auf den ersten Blick nicht unbedingt schlimm aus, aber vergleichen wir es mal mit den SSIM-Werten von BeHardware z.B. von Inception oder K-On (http://www.behardware.com/articles/828-21/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html).

In der Grafik für NVENC haben wir knapp 0.98 bei 4 Mbps, bei Inception mit x264 ist es ziemlich ähnlich bei ungefähr gleicher Bitrate und bei K-On (als Anime nicht so schwer für H.264) sieht es für x264 besser aus. Ultrafast sollte man natürlich nicht miteinbeziehen. Es spricht sogar viel für x264, dass man nur diese Voreinstellung außer Acht lassen muss.
Und der große Unterschied, der x264 den Sieg bringt ist die Auflösung! 720x480 bei NVENC gegen 720p bei x264. Runtergerechnet müsste man die NVENC-Werte bei 1.5 Mbps nehmen, da sind es rund 0.956. x264 ist da (mit Ausnahme von ultrafast) durchgehend höher.
Ich glaub, mehr muss man nicht sagen.

Ich hab mir (wieder) den Riesenthread im Doom9-Forum angetan. [...]


Danke für deine Mühe. Im Großen und Ganzen hab ich es mir so ähnlich schon gedacht. Für AMD hab ich wenig Hoffnung, also setz ich da schon eher auf nvidia. Wenn, dann kommt wohl für Intel zuerst etwas, aber mal sehen. Hoffentlich macht BeHardware dann einen Vergleichtest mit dem neuen NVENC.

robbitop
2012-03-26, 08:59:34
@Deinorius

Danke für die Erklärung und den Link! Bei Videokomprimierung bin ich, ehrlich gesagt, ziemlich blank. :D



1/2* OT:
Der Bildvergleich von Behardware ist ja der Wahnsinn! :up:
Ich hätte nicht gedacht, dass trotz CABAC 2-Pass noch deutliche Vorteile bringt. Man achte auf die Augenbrauen.

Wenn man sich mal die SSIM Werte dazu anschaut, kann ich nur sagen: das kann absolut nur ein ganz grober Richtwert sein. Alle Verfahren bei Behardware von 1-P Ultrafast bis 2-P Superslow unterscheiden sich nur in der 2. - 3. Nachkommastelle. Da würde ich, ohne Blick auf den Bildvergleich, frei nach Pareto 1-P Ultrafast nehmen.

Nach dem sich aber beim Bildvergleich IMO massive Unterschiede zeigen (Haut um das Auge und die Augenbraue), ist das ganze doch etwas zu ungenau (SSIM).

Als grober Richtwert aber wohl zu gebrauchen oder?

Wann ist eigentlich mit h265 zu rechnen?

Deinorius
2012-03-26, 10:40:47
Wieso sollte CABAC einen großen Unterschied zu Gunsten von 1Pass machen? 2Pass ist immer im Vorteil (solange die Einstellungsunterschiede nicht zu groß sind). Vergleiche mal die SSIM-Werte. Selbst veryfast 2Pass sieht besser aus als veryslow 1Pass.
Und ja, SSIM ist nur ein Richtwert. Nichts kann Vergleichsbilder ersetzen.

Bei h.265 finde ich viel interessanter, wann die Unterstützung kommen soll. Der Standard kann noch so gut sein, h.264 ist einfach überall gegenwärtig. Das kann noch dauern, bis sich da etwas tut.

robbitop
2012-03-26, 12:17:54
Wieso sollte CABAC einen großen Unterschied zu Gunsten von 1Pass machen?
Ich hatte es so verstanden, dass CABAC dafür sorgt, dass das Video fortwährend genau die Bitrate bekommt, die sie benötigt. Für weniger komplexe Bilder mehr, für weniger komplexe weniger.

pest
2012-03-26, 13:24:33
CABAC = Context Adaptive Arithmetic Coding

Hat nix mit Bitratenverteilung zu tun, sondern ist ein Modellierungs und Kodierungsverfahren was besser als VLC (Variable Length Coding) ist.

robbitop
2012-03-26, 14:17:39
Was für Ergebnisse sind von h265 eigentlich in etwa zu erwarten? Ist ein ähnlicher Sprung wie vom Vorgänger zu erwarten?

aufkrawall
2012-03-26, 14:29:52
Was für Ergebnisse sind von h265 eigentlich in etwa zu erwarten? Ist ein ähnlicher Sprung wie vom Vorgänger zu erwarten?
Im Vergleich zu x264 ist wohl ein Sprung zu erwarten, aber erstmal rückwärts. :D

robbitop
2012-03-26, 14:57:57
Das wäre dann ein :facepalm: :D
Ich hoffe, dass es nicht so kommt.

aufkrawall
2012-03-26, 15:06:48
Laut den Einschätzungen auf doom9 wird es wohl einige Zeit lang dauern, bis es H.265 Enkoder gibt, die mit x264 mithalten können.
Von der Flexibilität und dem Featureset mal ganz abgesehen.

Deinorius
2012-03-26, 16:28:55
Von deren breitflächigen Unterstützung durch Hardware-Hersteller (und freie Coder für alles im Internet erst recht :D) und Nutzung für Inhalte erst recht.

Bis zum Ende des Jahrzehnts erwarte ich mir sowieso rein gar nix.

Im Vergleich zu x264 ist wohl ein Sprung zu erwarten, aber erstmal rückwärts. :D


Das hast du aber schön gesagt. :ulol:

deekey777
2012-04-02, 14:29:51
Es sieht so aus, dass Power Director 10 build 1424c die erste Software ist, die Nvidias Hardware-Encoder unterstützt.
http://www.cyberlink.com/downloads/support/powerdirector/patches_en_US.html

Ronny145
2012-04-06, 18:03:11
Es sieht so aus, dass Power Director 10 build 1424c die erste Software ist, die Nvidias Hardware-Encoder unterstützt.
http://www.cyberlink.com/downloads/support/powerdirector/patches_en_US.html


Hier ein Benchmark: http://techreport.com/articles.x/22735/4

san.salvador
2012-04-06, 18:24:40
Es sieht so aus, dass Power Director 10 build 1424c die erste Software ist, die Nvidias Hardware-Encoder unterstützt.
http://www.cyberlink.com/downloads/support/powerdirector/patches_en_US.html
Was macht der anders als Loiloscope oder Tmpgenc?

AnarchX
2012-04-06, 23:04:50
Theoretisch sollte der NVENC 1080p mit 240 FPS encoden können.

Deinorius
2012-04-06, 23:09:06
Theoretisch? Unter welchen Bedingungen?

GTX999
2012-04-21, 09:55:51
spätestens wenn die neuen konsolen am markt sind purzeln die preise für cpus. (ein 6 core i7 sollte dann ein absolutes minimum darstellen).

wenn ein tegra am tablet in absehbarer zeit schneller enc/decodieren kann als ein i5 2500k kommt man sich doch ein wenig verarscht vor. ;D

AnarchX
2012-04-21, 10:06:25
Theoretisch? Unter welchen Bedingungen?
Laut Whitepaper.

Momentan bietet die Software wohl nur diese Möglichkeit:
MediaEspresso is restricted to Baseline@4.0, 25fps, and CBR
http://forum.doom9.org/showthread.php?p=1568826#post1568826


.. spätestens wenn die neuen konsolen am markt sind purzeln die preise für cpus.
intel sollte schon so 12-20 core i5/i7 cpus am markt haben ... diese oldie quad verarsche stinkt schön langsam.

Mit Server-CPUs sind diese Optionen verfügbar. Im Mainstream-Desktop sind wohl Quad-Cores, deren einzelne Kerne eine hohe Single-Thread-Leistung bieten, noch sinnvoller bzw. bezahlbar.

Wirklich interessant sind die dedizierten Encoding-Prozessoren im Bezug auf Energieverbrauch und der Möglichkeit sie auch zu nutzen, während die CPU andere rechenintensive Aufgaben übernehmen muss.
Zumal auch die kleinen Kepler GPUs NVENC enthalten, da könnte man einen PC mit entsprechenden Dual-Karten mit 8 oder mehr Encodern ausstatten.

AnarchX
2012-04-23, 19:16:46
QuickSync 2.0 vs NVENC: http://www.anandtech.com/show/5771/the-intel-ivy-bridge-core-i7-3770k-review/21

deekey777
2012-05-16, 10:42:41
What We've Been Waiting For: Testing OpenCL Accelerated Handbrake with AMD's Trinity (http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu)
While video transcoding is significantly slower on Trinity compared to Intel's Sandy Bridge on the traditional x86 path, the OpenCL version of Handbrake narrows the gap considerably. A quad-core Sandy Bridge goes from being 73% faster down to 7% faster than Trinity. Ivy Bridge on the other hand goes from being 2.15x the speed of Trinity to a smaller but still pronounced 29.6% lead. Image quality appeared to be comparable between all OpenCL outputs, although we did get higher bitrate files from the x86 transcode path. The bottom line is that AMD goes from a position of not really competitive, to easily holding its own against similarly priced Intel parts

Interessant ist das allemal, auch wenn die Software aktuell für sinnvolles Transcoding nicht nutzbar ist.

AnarchX
2012-05-16, 10:48:16
Unter SiSoftware Sandras Transcoding Benchmark behauptet sich Trinity auch sehr deutlich:

http://www.4gamer.net/games/133/G013372/20120514010/TN/036.gif
http://www.4gamer.net/games/133/G013372/20120514010/


Erklärung:
Neuer Benchmark: Formatkonvertierung
Misst die Transkodierungsbandbreite beim Umwandeln einer Mediendatei von einem Format in ein anderes.

Warum? Viele Geräte können zum Beispiel von Videokameras aufgezeichnete Formate nicht direkt wiedergeben. Vor dem Überspielen auf ein Wiedergabegerät müssen solche Formate deshalb häufig erst umgewandelt werden, damit sie korrekt abgespielt werden können. Da dieses Material mehr und mehr in HD vorliegt, kann dieser Vorgang einige Zeit in Anspruch nehmen und deshalb jeder Leistungsvorteil eine Menge an Zeitersparnis bedeuten.

Mittels der neuen Media Foundation aus Windows 7, wird die Umwandlung von WMV (z.B. Movie Maker) nach MP4/H264, nach MP4/H264 (z.B. Wiedergabe auf mobilen Endgeräten)und nach MP4/H264 unter Verwendung verschiedener Profile (HD TV 720p, SD TV 480p, Tablet-PC, Telefon, usw.) gemessen.

Mit dem Benchmark lassen sich die Leistung von hardwarebeschleunigten Umwandlungskomonenten (z.B. GPU´s) mit Multithreading unterstützenden Softwarekonvertern (CPU) vergleichen.
http://www.sisoftware.co.uk/?d=news&f=2011_release

aufkrawall
2012-05-16, 11:02:00
Unter SiSoftware Sandras Transcoding Benchmark behauptet sich Trinity auch sehr deutlich:
Darf ich fragen wieso "auch"?
Beim Link von deekey777 sehe ich das eher als Niederlage für AMD. Nicht nur, weil Intel trotz OpenCL immer noch schneller ist. Aber eigentlich sollte die Trinity-GPU doch wesentlich mehr Leistung bieten als die von IVB, oder nicht?
Deshalb würd ich es eher als Fiasko sehen, dass Intel auch da vorne liegt.

Und das QS von IVB ist ja auch ein Killer, wie man deinem vorigen Link entnimmt.
Der Dekoder kann 4k 60fps Video flüssig darstellen, btw.
Und das bei einem Energieverbrauch, von dem AMD und Nvidia nur träumen können.
Bei AMD geht nicht mal 4k mit 24fps in Hardware...
Edit: Auch nicht bei GCN mit UVD 4, mal wieder ein Treiber-Bug.

mironicus
2012-05-16, 11:11:29
Solange die Open-CL Enkodierung mit x264 auch die gleiche Qualität ergibt wie mit der reinen CPU, wäre das genial. Aber das muss man erst mal genauer untersuchen.

Die bisherigen Hardwareenkoder-Lösungen (Intel, AMD, NVidia) waren von der Qualität bisher unbrauchbar (allenfalls für schnelle Konvertierungen wo Qualität nicht so wichtig ist).

robbitop
2012-05-16, 11:12:47
QS kann man aber von der Qualität ggü. x86 vergessen. Ergo kein Vergleich.

aufkrawall
2012-05-16, 11:39:25
QS kann man aber von der Qualität ggü. x86 vergessen. Ergo kein Vergleich.
Klar, aber die Konkurrenz hat bei viel weniger fps noch eine deutlich schlechtere BQ.

deekey777
2012-05-16, 11:43:43
Klar, aber die Konkurrenz hat bei viel weniger fps noch eine deutlich schlechtere BQ.
Woher die Weisheit?

robbitop
2012-05-16, 11:45:22
Bis dato weiß man noch nicht, wie die Qualität der OpenCL Lösung ist. Aber er bezieht sich vermutlich auf den sehr schnellen x86 Pfad von Intel.

aufkrawall
2012-05-16, 11:58:59
Woher die Weisheit?
Bis dato weiß man noch nicht, wie die Qualität der OpenCL Lösung ist. Aber er bezieht sich vermutlich auf den sehr schnellen x86 Pfad von Intel.
QS ist schneller und hat eine bessere BQ als Nvidias NVENC, braucht dabei auch noch weniger Strom.
AMDs VCE steht immer noch in den Sternen.
OpenCL kann IVB auch und ist dabei sogar schneller als Trinity.
Bei x86 rennt Intel AMD auch davon.

Eventuell geht mit GCN aber bei x264 OpenCL tierisch die Post ab, das könnte interessant sein.

mironicus
2012-05-16, 12:00:38
Bei Planet3Dnow steht im Forum-Thread zum Newsbeitrag, das AMD selbst an dem Code arbeitet und den natürlich noch nicht zur Verfügung stellt.

aufkrawall
2012-05-16, 12:06:14
Bei Planet3Dnow steht im Forum-Thread zum Newsbeitrag, das AMD selbst an dem Code arbeitet und den natürlich noch nicht zur Verfügung stellt.
Die Hauptsache ist doch, dass es Open Source und Dank OpenCL auch hardwareübergreifend ist. Immerhin ist es auch x264 und nicht irgendein selbstgebauter Schrottenkoder wie etwa der von Nvidia CUDA.

Das wird Nvidia nicht freuen. ;)

deekey777
2012-05-16, 12:44:15
QS ist schneller und hat eine bessere BQ als Nvidias NVENC, braucht dabei auch noch weniger Strom.
AMDs VCE steht immer noch in den Sternen.
OpenCL kann IVB auch und ist dabei sogar schneller als Trinity.
Bei x86 rennt Intel AMD auch davon.

Eventuell geht mit GCN aber bei x264 OpenCL tierisch die Post ab, das könnte interessant sein.
QS interessiert keine Sau. Warum? Weil's dicht ist, man hat null Einfluß darauf. Intel gibt keine Informationen heraus.
Nvidias HW-Encoder ist noch eine große Unbekannte: Gibt es vernünftige Tests? Hat man darauf Zugriff?
Auch über AMDs VCE weiß man nichts und weniger.
In Handbrake ist die Performance des A10-4600 überragend. Man darf nicht vergessen, dass es sich um Videoencoding, etwas was gerade GPUs nicht schmeckt, womit nur ein Teil darauf ausgelagert werden kann. Hinzu kommt, dass die CPU-Kerne die meiste Arbeit erledigt haben und erfahrungsgemäß die GPU mit UVD-Takt lief (die Grafikeinheit übernimmt auch das Decoding). Auch sind die CPU-Kerne niedriger getaktet als die des i7-3720.

Und sehr wichtig:
Du vergisst paar Kleinigkeiten: den Preis und den Preis des Endgerätes.

aufkrawall
2012-05-16, 12:56:30
QS interessiert keine Sau. Warum? Weil's dicht ist, man hat null Einfluß darauf. Intel gibt keine Informationen heraus.

Ist das bei irgendeinem nicht OS-Enkoder anders?
Außerdem funktioniert QS-Dekoding bereits in der Praxis verdammt gut.


Nvidias HW-Encoder ist noch eine große Unbekannte: Gibt es vernünftige Tests? Hat man darauf Zugriff?

Siehe #535 (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9265796&postcount=535).
Mehr weiß ich auch nicht, aber dort killt QS es mit links.


Auch über AMDs VCE weiß man nichts und weniger.

Weil es im Gegensatz zu QS und NVENC bisher eben nur auf dem Papier existiert.


In Handbrake ist die Performance des A10-4600 überragend. Man darf nicht vergessen, dass es sich um Videoencoding, etwas was gerade GPUs nicht schmeckt, womit nur ein Teil darauf ausgelagert werden kann.

Mit Badaboom (ich weiß, dass es Müll ist ;) ) krieg ich meine GTX 570 zu über 90% ausgelastet.


Hinzu kommt, dass die CPU-Kerne die meiste Arbeit erledigt haben und erfahrungsgemäß die GPU mit UVD-Takt lief (die Grafikeinheit übernimmt auch das Decoding).

Wus?
"Die Grafikeinheit" übernimmt eben nicht das Dekoding, sondern der UVD Videoprozessor.
Und die GPU läuft garantiert bei OpenCL-Nutzung mit vollem Takt.
Und dass die CPU der limitierende Faktor sein soll, musst du auch erstmal belegen.
Womöglich wird die mit OpenCL so gut wie gar nicht genutzt, eben weil es auf der GPU läuft.


Und sehr wichtig:
Du vergisst paar Kleinigkeiten: den Preis und den Preis des Endgerätes.
Ist der so wichtig? ;)

robbitop
2012-05-16, 21:54:38
QS ist aber keine Alternative da qualitativ zwar nicht grottenschlecht aber immernoch genausoschlecht wie 1 pass performance setting im x86 Pfad. Darüber braucht man sich IMO gar nicht unterhalten.

aufkrawall
2012-05-16, 22:44:57
QS ist aber keine Alternative da qualitativ zwar nicht grottenschlecht aber immernoch genausoschlecht wie 1 pass performance setting im x86 Pfad. Darüber braucht man sich IMO gar nicht unterhalten.
Ich sag doch auch nirgends etwas anderes. :)
Ich seh nur nicht, wo irgendwer anders besser wäre.

Ronny145
2012-05-16, 22:58:07
QS ist aber keine Alternative da qualitativ zwar nicht grottenschlecht aber immernoch genausoschlecht wie 1 pass performance setting im x86 Pfad. Darüber braucht man sich IMO gar nicht unterhalten.


Gibt es hier Vergleiche zwischen Quicksync 2.0 Quality und 1 Pass Performance?

robbitop
2012-05-17, 14:28:55
Irgendwer hatte mal einen sehr guten Test mit gezoomten Bildern geschickt. Da sprang es mir direkt in's Auge. QS ist höchstens (im Vergleich zu x86 High Quality 2 pass) für einen quick and dirty Rip auf's Smartphone zu gebrauchen.

Ich bin gespannt auf die Qualität von OCL Handbrake mit x264. Der "geringe" Geschwindigkeitszuwachs spricht erstmal für ein positives Zeichen.

Ronny145
2012-05-17, 17:26:20
Irgendwer hatte mal einen sehr guten Test mit gezoomten Bildern geschickt.


Von wann stammt der Test? Vermutlich ist der älter, kann sich also nur um Quicksync 1.0 handeln. Mich interessiert QS 2.0 Quality im Vergleich zu x264 Performance.

AnarchX
2012-05-17, 18:17:16
War wohl der Test von Hardware.fr/BeHardware: http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html

Hoffentlich gibt es da bald ein 2012er Update mit QS2.0, NVENC und AMDs VCE.

aufkrawall
2012-05-17, 18:41:29
Hoffentlich gibt es da bald ein 2012er Update mit QS2.0, NVENC und AMDs VCE.
Unterstützt der Catalyst denn mittlerweile VCE?
Sonst kann man natürlich lange drauf warten, dass es jemand testet. :D

danger!
2012-05-17, 21:32:38
Darf ich Euch kurz eine leichte OT-Frage stellen? Nach dem, was ich hier die letzten Seiten gelesen - ok, überflogen;) - habe, kennt ihr Euch ja anscheinend wirklich aus auf dem Gebiet Video-Encoding...

Wenn ich alle heiligen drei Zeiten mal ne DVD rippen will habe ich bisher einfach Handbrake genommen und das Teil vor sich hinlaufen lassen - einfach Standardeinstellungen, bei Standard-Qualität....

Ohne sich nun 4 Wochen einlesen zu müssen - gibt´s da momentan ne aktuell DEUTLICH bessere Alternative oder ne suuuper tolle Einstellung in HB (die einer von Euch kennt;)), die die "beste" Qualität bei nicht gigantisch größerem Output-File bringt???

Nicht sooo wichtig bei den 5 DVD´s, die ich im Jahr rippe - aber da hier anscheinend die geballte Kompetenz anwesend ist, frag ich einfach mal ganz verschämt...:rolleyes::D

MfG
& schon mal vielen Dank...
danger!


@AnarchX: Sollte das hier zu OT sein, einfach kicken - sooo wichtig ist das nicht, hätte mich nur grade interessiert... :)

ameisenbaer
2012-05-17, 21:52:13
ne suuuper tolle Einstellung in HB (die einer von Euch kennt;)), die die "beste" Qualität bei nicht gigantisch größerem Output-File bringt???


Ich kodiere bei PAL mit einer average bitrate von 3000 (2 pass),
allerdings mit ziemlich rechenintensiven Einstellungen
(10 R-Frames, 10 B-Frames, QPRD in all frames)

aufkrawall
2012-05-17, 22:04:55
Ohne sich nun 4 Wochen einlesen zu müssen - gibt´s da momentan ne aktuell DEUTLICH bessere Alternative oder ne suuuper tolle Einstellung in HB (die einer von Euch kennt;)), die die "beste" Qualität bei nicht gigantisch größerem Output-File bringt???

Nö, und ich nehme an, du nutzt wahrscheinlich schon das High Profile von Handbrake?

AnarchX
2012-05-17, 22:26:35
Unterstützt der Catalyst denn mittlerweile VCE?
Sonst kann man natürlich lange drauf warten, dass es jemand testet. :D


Mit Trinity wohl schon:
http://techreport.com/r.x/trinity-mobile/mediaespresso.png

Both VCE and QuickSync appear to halve transcoding times... except the latter looks to be considerably faster. We didn't see much of a difference in output image quality between the two, but the output files had drastically different sizes. QuickSync spat out a 69MB video, while VCE got the trailer down to 38MB. (Our source file was 189MB.)
http://techreport.com/articles.x/22932/8

:freak:

Ronny145
2012-05-17, 22:36:22
Die konvertierten Trailer inklusive dem Original müsste man runterladen können um das richtig zu beurteilen. Bezüglich der Qualität hat das kaum eine Aussagekraft.

aufkrawall
2012-05-17, 22:44:44
Mit Trinity wohl schon:

http://techreport.com/articles.x/22932/8

:freak:
Ah, muss wohl so sein. :D :redface:
Dass die Intel in Software trotzdem schneller sind, ist aber ein schlechtes Zeichen.
Da müsste die Quali von VCE schon so gut sein wie x264 x86, damit es irgendeinen Sinn hätte.

aufkrawall
2012-05-18, 00:32:31
Gibt nun ein fertig kompiliertes x264 OpenCL Build zum Download:
http://forum.doom9.org/showpost.php?p=1574959&postcount=21

CPU ist bei 100%, GPU geht nur alle paar Sekunden mal auf höchstens 20% hoch.
Ist mit meiner GTX 570 anscheinend nicht schneller als pures Softwareenkoding, aber vielleicht siehts mit AMD anders aus?

danger!
2012-05-18, 09:20:40
Nö, und ich nehme an, du nutzt wahrscheinlich schon das High Profile von Handbrake?


Hallo aufkrawall,

jawohl, das nutze ich auch. Ok, dann bleib ich dabei, hat mir bisher gut ausgereicht... Wollte nur fragen, ob´s jetzt ein neueres "Super-Tool" gibt, das Handbrake grandios schlägt...

Vieln Dank!

MfG
danger!

aufkrawall
2012-05-18, 11:09:52
Wollte nur fragen, ob´s jetzt ein neueres "Super-Tool" gibt, das Handbrake grandios schlägt...

Handbrake nutzt ja x264, welches der beste Enkoder ist.
Und da es sonst bei DVDs afaik alles unterstützt, wird es wohl noch lange Zeit das ideale Tool für DVD-Rips bleiben. :)

Deinorius
2012-05-18, 17:17:56
@danger!
Da du sicher nicht zuviel Zeit aufwenden willst, gibt es nicht viel, was du tun könntest. Da gäbe es höchstens ein paar Tipps:

Da du nicht so oft enkodierst, kannst du ja ohne weiteres langsame, aber besser komprimierende Einstellung bei x264 verwenden. Du hast dort eh ausreichend Optionen. Wichtig ist nur, dass die Kompatibilität zu deinen ganzen Abspielgeräten bestehen bleibt.
Bei den Avisynth-Filtern gibt es sehr viel Potential, dafür müsstest aber sehr viel Zeit aufwenden. Nichtsdestotrotz bieten die AllinOne-Tools ja schon diverse an, probiere einfach a bisserl aus.
Noch eine praktische und besonders zeitsparende Methode, ist die Verwendung von crf (Constant Quality). Solange du keine genaue Dateigröße brauchst, kommst du damit sicher gut zurecht. Je niedriger der Wert ist, umso besser ist die Qualität. Ich würde nur Werte zwischen 22-18 nehmen. Unter 18 bringt nix, 20 ist die goldene Mitte und 22 nur, solange die Qualität noch passt. Darüber hinaus gibt es x264-Einstellungen, welche die Dateigröße zu sehr ansteigen lassen, ohne die Qualität merklich zu verbessern, mir fällt da jetzt spontan nur trellis=1 ein.

Tools wie Handbrake alleine bringen keine großartigen Verbesserungen mit sich, sie dienen nur zum Komfort, um die Arbeit deutlich zu erleichtern. Handbrake ist gut, meine eigene Wahl ist jedoch StaxRip. Das soll jetzt keine Werbung sein. Wenn du mit Handbrake zufrieden bist, passts.

deekey777
2012-07-07, 14:06:06
http://blogs.amd.com/play/2012/06/28/the-new-catalyst/
New AMD Catalyst™ 12.7 Beta feature: Video Codec Engine

When we introduced the AMD Radeon™ HD 7000 Series in December, we also began discussing a feature of Graphics Core Next we call the Video Codec Engine, or VCE. VCE is a hardware mechanism that allows supporting AMD Radeon™ products to dramatically accelerate video encoding in a VCE-enabled application. Starting with AMD Catalyst™ 12.7, owners of AMD Radeon™ HD 7900/HD 7800/HD 7700 Series products are now ready take advantage of this feature in compatible applications like vReveal and ArcSoft MediaConverter.
Hat jemand den Mist ausprobiert?

Googlehopf
2012-10-09, 14:01:49
Auf der AMD Fusion Developer Summit 2012 gab es auch einen Vortrag betreffend OpenCL Beschleunigung von x264:

hier (http://www.youtube.com/watch?v=uOOOTqqI18A&feature=relmfu)

Vortragende waren Jason Garret-Glaser, x264 und Steven Borho, Multicore Inc.

AnarchX
2012-10-09, 16:56:04
Viele SSIM Messungen: http://www.inpai.com.cn/doc/hard/183013.htm

Deinorius
2012-10-09, 17:23:46
Interessant. Wenn ich das richtig deute, hat gerade QuickSync ziemlich aufgeholt. Habe ich die Geschwindigkeiten übersehen?

Ronny145
2012-12-15, 21:03:48
Ein kleiner Test von mir mit MediaEspresso 6.7 CPU/Quicksync (High Profil) und Handbrake anhand dieses (http://betav2.gamersyde.com/leech_29212_1_en.html) knapp 5 Minuten langen Videos. Jeweils 13 Mbit im H264 Format, was pro Video ~470 MB ergibt.

MediaEspresso 6.7
Original (http://s7.directupload.net/images/121215/elcd9ohb.png)
HD4000 Quicksync Fast= 1:22, Bild (http://s7.directupload.net/images/121215/5rqoezdi.png)
HD4000 Quicksync Quality= 1:22, Bild (http://s14.directupload.net/images/121215/79tmwkpd.png)
3570K CPU Quality= 5:29, Bild (http://s1.directupload.net/images/121215/k63t2jzg.png)

Handbrake 0.9.8
Normal Profil H264= 4:03, Bild (http://s7.directupload.net/images/121215/pw6ct7oe.png)
High Profil H264= 12:56, Bild (http://s1.directupload.net/images/121215/dkd2fepj.png)

Warum das High Profil in Handbrake so unscharf aussieht kann ich mir nicht erklären. QS Fast keinen Deut schneller und sieht schlechter aus. QS Quality bietet ein für mich überraschend sehr gutes Verhältnis aus Schnelligkeit und Bildqualität. Ich bin mal gespannt was die angekündigten Qualitätsverbesserungen in Haswell bringen.

Deinorius
2012-12-15, 21:44:00
Handbrake komprimiert doch eigentlich nur mit x264. Kannst du mal nachsehen (wenn möglich), welche Kommandozeilenbefehle zwischen MainProfile und HighProfile unterscheiden? Eigentlich ist zwischen Main und High alleine kein allzu großer Leistungsunterschied.
Allein schon wegen der Unschärfe will ich das wissen.

aufkrawall
2012-12-15, 21:45:58
Das Handbrake High Profile hat nicht viel mit dem H.264 High Profile zu tun.
Das ist eine Festlegung diverser Einstellungen von x264 der Handbrake-Entwickler, basierend darauf was sie für richtig halten.

Ronny145
2012-12-15, 21:56:30
MediaInfo meldet High@L4.1, dagegen für das Handbrake Normal Video nur Main@L4.1.

@Deinorius

Ich bin kein Handbrake Spezialist. Das sind einfach die Standardprofile, geändert wurde nur fps auf 30 und Avg Bitrate 13500. Bei Advanced sehen Normal und High jedenfalls ziemlich unterschiedlich aus.

Deinorius
2012-12-15, 23:13:06
Aber man wird doch wohl die jeweiligen Einstellungen für x264 einsehen können.

aufkrawall
2012-12-15, 23:19:50
Handbrake sein lassen und x264 direkt/per Avisynth nehmen.

Deinorius
2012-12-15, 23:21:04
Sag das Ronny145! :ugly: Ich empfehle z.B. StaxRip.

Ronny145
2012-12-15, 23:21:20
Normal:

http://www.abload.de/thumb/normal76cva.png (http://www.abload.de/image.php?img=normal76cva.png)

High:

http://www.abload.de/thumb/highdvfes.png (http://www.abload.de/image.php?img=highdvfes.png)


Oder meintest du was anderes?

Deinorius
2012-12-15, 23:37:52
Nein, genau das meinte ich...

Oida, was geht mit denen? Reference Frames auf 1? Und subme auf 2????? :facepalm: (OK, nur meine Meinung, aber dennoch...)

Da ist nichts ersichtlich, wieso das Video unscharf wird. Was zeigt dir der Reiter Video Filter an?

Ronny145
2012-12-15, 23:59:18
Decomb Default beim High Profil, alles andere steht auf Off.

Deinorius
2012-12-16, 00:10:47
Decomb wirst du für ein PC-Spielvideo nicht brauchen.

Ist das beim normalen Profil dasselbe?

Ronny145
2012-12-16, 00:14:55
Ne beim normalen deaktiviert. /daran liegt es nicht

Nightspider
2012-12-16, 01:05:27
Kann man schon Videos in H.265 encodieren oder muss man da erst teure decoder kaufen?

aufkrawall
2012-12-16, 01:09:07
Gibts noch nix.

Deinorius
2012-12-16, 01:15:11
Ne beim normalen deaktiviert. /daran liegt es nicht


Mach trotzdem mal einen Encode bei deaktiviertem Decomb.

Kann man schon Videos in H.265 encodieren oder muss man da erst teure decoder kaufen?


Mit Decodern wirst du wohl kaum etwas encodieren können. :tongue:

H.265 ist laut Zeitplan im Januar bereit, ratifiziert zu werden. Also noch Geduld.

Ronny145
2012-12-16, 12:15:11
Mach trotzdem mal einen Encode bei deaktiviertem Decomb.



Hatte ich bereits. Die unschärfere Darstellung bleibt bestehen: http://s7.directupload.net/images/121216/zxbmk3dr.png

Die Enkodierzeit ist auf 10:25 gesunken. Man könnte auf trial and error Prinzip die advanced Einstellungen durchtesten, wäre dann nur recht zeitaufwändig. Wenn das bei anderen Videos auch für Unschärfe sorgt, ist das high preset total verkorkst. In MediaEspresso 6.7 muss übrigens für das high Profil m2ts Output ausgewählt werden. Im Mp4 Output enkodiert das nur im main oder baseline Profil, was ein schlechteres Ergebnis für CPU und QS zur Folge hat.

Ronny145
2013-01-15, 01:29:48
Intel's Quick Sync: Coming Soon to Your Favorite Open Source Transcoding Applications (http://www.anandtech.com/show/6665/intels-quick-sync-coming-soon-to-your-favorite-open-source-transcoding-applications-)

-/\-CruNcher-/\-
2013-01-15, 16:03:55
Mach trotzdem mal einen Encode bei deaktiviertem Decomb.




Mit Decodern wirst du wohl kaum etwas encodieren können. :tongue:

H.265 ist laut Zeitplan im Januar bereit, ratifiziert zu werden. Also noch Geduld.


Es wird wahrscheinlich aber noch einige Jahre dauern bis es H.264 vollständig ersetzt ist, wobei es wird interessant zu sehen ob der Anpassungs Zyklus schneller geworden ist sieht man die angebliche Wichtigkeit von H.265 und die Vorerfahrung mit der H.264 Einführung sollte es vieleicht bei H.265 sogar viel schneller ablaufen diesmal, man sieht ja auch überall schon die Solutions von den DSP Entwicklern selbst im Mobile bereich das war bei H.264 so früh nicht der Fall.
Und um das Internet zu dominieren muss das ja auch alles Fix ablaufen das die anderen quasi keine Chance haben (Google, Open Source).
Vorher war das Internet nicht so im Fokus wie diesmal damals ging es Hauptsächlich um die Blu-Ray (Hollywood) Etablierung ausgehend hier stark von Sony als MPAA und MPG LA beteiligter, Apple als MPAA MPG LA benifiteur hatte schon mehr interesse am Internet mit ihrer Itunes Ökosystem Erweiterung.
Apple werden auch höchstwahrscheinlich die ersten wieder sein die den H.265 Ökosystem wechsel inhouse vorantreiben werden in der nächsten Zeit.

Es ist allerdings sehr chaotisch momentan da haben sich viele Platformen an H.264 gewöhnt (Lizensen akzeptiert) und die HTML5 integration ist ja auch im Gange und die Solutions laufen langsam durchweg Rund die ganze Chain funktioniert zwischen verschiedenen Geräten und sind sehr erschwinglich geworden wie sie sollen (Platformen, Hardware, Mobile, Software, Broadcast) und es wird wieder alles über den haufen geschmissen und Quasi von 0 angefangen allerdings mit etwas mehr Erfahrung als vorher in allen Integrationsbereichen ;)

Und als Grund dafür hört man immer die H.265 premisse "wir die mächtigsten Konzerne der Welt müssen den Internet Traffic reduzieren" ;)

Knuddelbearli
2013-01-15, 16:12:03
gibt es schon Hardware Unterstützung für h.265?
Desktop GPUs unterstützen das ja glaube ich noch nicht

-/\-CruNcher-/\-
2013-01-15, 16:43:16
Wie gesagt Desktop hat mehr luft diesmal, die ersten die man momentan sieht mit Decoding Solutions das ist Hauptsächlich der Mobile bereich.

Ronny145
2013-01-15, 17:33:30
Gibt es eigentlich mittlerweile ein Programm, welches NVENC zum Encodieren benutzt? Die Testversion von MediaEspresso war nie öffentlich zugänglich.

PrefoX
2013-01-15, 20:00:14
Handbrake nutzt ja x264, welches der beste Enkoder ist.
Und da es sonst bei DVDs afaik alles unterstützt, wird es wohl noch lange Zeit das ideale Tool für DVD-Rips bleiben. :)
megui erzeugt trotzdem bessere ergebnisse, obwohl ich bei beiden das gleiche build habe.

HarryHirsch
2013-01-17, 21:16:22
Gibt es eigentlich mittlerweile ein Programm, welches NVENC zum Encodieren benutzt? Die Testversion von MediaEspresso war nie öffentlich zugänglich.

tmpgenc nutzt das zeug für die filter (cropping, denoising etc).
die qualität ist allerdings mies gegenüber der cpu.

Ronny145
2013-03-28, 14:02:20
Handbrake demnächst mit Quicksync Support.

HandBreak*, one of the most popular open source video transcoders, is being accelerated using Intel® Quick Sync Video – dedicated hardware built into the latest Intel Core processors. Intel and the HandBreak team are showcasing the new HandBreak optimized for Intel Quick Sync Video at GDC.
http://newsroom.intel.com/community/intel_newsroom/blog/2013/03/27/intel-delivers-new-range-of-developer-tools-for-gaming-media

Grestorn
2013-03-28, 14:04:03
Schön. Wenn Handbrake jetzt noch CUDA oder OpenCL einbauen würde... :)

Ronny145
2013-03-28, 14:05:45
Es gibt bereits Test Builds mit OpenCL Support, soll aber nicht so pralle funktionieren den Kommentaren zu urteilen.

robbitop
2013-03-28, 14:13:09
Quicksync wäre mir qualitativ noch nicht gut genug. Aber Intel will das ja immer weiter entwickeln.

Ronny145
2013-03-28, 14:15:23
Quicksync wäre mir qualitativ noch nicht gut genug. Aber Intel will das ja immer weiter entwickeln.


Du hast es noch nie getestet nehme ich an.

robbitop
2013-03-28, 14:18:38
Anand und andere Seiten haben es im Detail getestet und vergrößerte Screenshots hochgeladen mit Mouseover. Wozu sollte ich also das gleiche wiederholen? :rolleyes:

Ronny145
2013-03-28, 14:30:55
Anand und andere Seiten haben es im Detail getestet und vergrößerte Screenshots hochgeladen mit Mouseover. Wozu sollte ich also das gleiche wiederholen? :rolleyes:


Nützt dir gar nichts. Getestet wird doch meist mit Arcsoft und MediaEspresso @mp4. Arcsoft Mediakonverter hat eine grottige Qualität im Vergleich zu manch anderen QS Encodern und im Mediaespresso ist der Unterschied zwischen dem normal und high Profil riesig. Das high profil gibt es ohne ini Änderung allerdings eben nur mit m2ts Videos. Mediaespresso mit m2ts hat die beste Qualität aller QS Encoder und schneller war in meinen Tests nur Arcsoft und Badaboom (eingestellt). Von daher ist die Pauschalisierung anhand der oberflächlichen und veralteten Tests immer so eine Sache ohne sich selber damit befasst zu haben. Sehr schön wäre wenn Handbrake auf das Niveau von Mediaespresso kommt und mehr Einstellungsfreiraum bei der Bitrate und dem Profil zulässt.

Deinorius
2013-03-28, 15:32:47
Wenn ihr schnelle Komprimierungen wollt, dann nehmt halt die schnellen Presets von x264. Der einzige wirkliche Vorteil von Quicksync ist wohl eher der niedrige Stromverbrauch und wäre somit beim Atom sinnvoller platziert.

Ronny145
2013-03-28, 15:41:06
Wenn ihr schnelle Komprimierungen wollt, dann nehmt halt die schnellen Presets von x264. Der einzige wirkliche Vorteil von Quicksync ist wohl eher der niedrige Stromverbrauch und wäre somit beim Atom sinnvoller platziert.


Das ist viel langsamer als QS und von der Qualität kaum besser zu vernünftigen QS Encodern.

Deinorius
2013-03-28, 17:08:58
Nicht nach den Tests, die ich kenne. Oder hat sich in der letzten Zeit bei QS so viel getan? Hier wurde ja schon mal ein umfangreicher Test verlinkt, der eindeutig für x264 spricht.

Wie gesagt, QS bringt da schon eher was bei schwächeren CPUs.

Ronny145
2013-03-29, 00:18:17
Das schnellste x264 Preset in Handbrake ist deutlich langsamer als MediaEspresso mit meinem i5-3570k. Um genau zu sein Faktor 1,7 in meinem Testvideo. Nächstes Problem die Qualität. Das Ultrafast Preset sieht deutlich schlechter aus weil es starke Artefaktbildung gibt und somit kein gleichwertiger Ersatz darstellt.

MediaEspresso QS Quality m2ts: http://s14.directupload.net/images/130328/3c48bq6u.png
Ultrafast Handbrake: http://s7.directupload.net/images/130328/6jsac9yf.png

Das nächstschnellere preset wäre super fast. Ziemlich genau Faktor 2 zwischen QS. Keine großartig auffallende Artefaktbildung und ingesamt von der Qualität noch am vergleichbarsten: http://s1.directupload.net/images/130328/4h9s9ch8.png

Very fast als nächstes mit Faktor 2,8 Abstand: http://s7.directupload.net/images/130328/gk3yegtu.png

Wie gesagt, Mediaespresso m2ts Leistungs/Qualität ratio wäre super wenn das Handbrake so hinbekommt. Mit dem Einstellungsfreiraum von Handbrake wäre das dann für Quicksync die klare Nummer 1. Bin gespannt auf Haswell. Die Qualität soll bei gleicher Bitrate gestiegen sein.

Deinorius
2013-03-29, 00:24:08
MediaEspresso QS Quality m2ts: http://s14.directupload.net/images/130328/3c48bq6u.png
Ultrafast Handbrake: http://s7.directupload.net/images/130328/6jsac9yf.png


Ähm... interessant. Also plattwalzen ist die bessere Qualität, während x264 sich bemüht, mehr Details zu belassen (was teilweise durchaus etwas nach hinten gehen kann), ist hingegen qualitativ schlechter. Ernsthaft? :|

Ronny145
2013-03-29, 00:37:07
Ähm... interessant. Also plattwalzen ist die bessere Qualität, während x264 sich bemüht, mehr Details zu belassen (was teilweise durchaus etwas nach hinten gehen kann), ist hingegen qualitativ schlechter. Ernsthaft? :|


Ja ist es. Schau dir doch mal die Artefakte an. Nach der Logik hätten die nächstbesseren presets eine schlechtere Qualität, weil die laut dir dann auch plattwalzen würden. Sogar das Original sieht plattgewalzter aus als ultrafast. Mit einer Nachschärfung würde man die qualitativ besseren Modi und QS da auch hinbekommen bei weniger Artefaktbildung. Ultrafast entfernt sich definitiv am weitesten vom Original.

Deinorius
2013-03-29, 00:40:46
Jetzt habe ich irgendwie die beiden letzteren Links übersehen. Ja ok, hast bei Spiele-Videos recht. Ein Vergleich mit Filmen würde mich aber mehr interessieren.

Konami
2013-03-29, 00:44:01
Das schnellste x264 Preset in Handbrake ist deutlich langsamer als MediaEspresso mit meinem i5-3570k. Um genau zu sein Faktor 1,7 in meinem Testvideo. Nächstes Problem die Qualität. Das Ultrafast Preset sieht deutlich schlechter aus weil es starke Artefaktbildung gibt und somit kein gleichwertiger Ersatz darstellt.

MediaEspresso QS Quality m2ts: http://s14.directupload.net/images/130328/3c48bq6u.png
Ultrafast Handbrake: http://s7.directupload.net/images/130328/6jsac9yf.png

Das nächstschnellere preset wäre super fast. Ziemlich genau Faktor 2 zwischen QS. Keine großartig auffallende Artefaktbildung und ingesamt von der Qualität noch am vergleichbarsten: http://s1.directupload.net/images/130328/4h9s9ch8.png

Very fast als nächstes mit Faktor 2,8 Abstand: http://s7.directupload.net/images/130328/gk3yegtu.png

Wie gesagt, Mediaespresso m2ts Leistungs/Qualität ratio wäre super wenn das Handbrake so hinbekommt. Mit dem Einstellungsfreiraum von Handbrake wäre das dann für Quicksync die klare Nummer 1. Bin gespannt auf Haswell. Die Qualität soll bei gleicher Bitrate gestiegen sein.
Danke für den Vergleich. :up:
Ja, MediaEspresso sieht deutlich besser aus als die Ultrafast-Einstellung in Handbrake. Aber leider immer noch nicht wirklich... toll. Hätte gehofft, dass QS schon weiter wäre.

Ronny145
2013-03-29, 00:49:18
Jetzt habe ich irgendwie die beiden letzteren Links übersehen. Ja ok, hast bei Spiele-Videos recht. Ein Vergleich mit Filmen würde mich aber mehr interessieren.


Wenn du ein hochqualitatives und möglichst kurzes Video Sample hast, kann ich mir das beim nächsten mal gerne ansehen.

Deinorius
2013-03-29, 01:30:48
Darauf komme ich gerne zurück. ;)

Eigentlich dürfte ein Zeichentrickfilm in SD sogar noch fordernder sein, da man die Artefakte leichter sieht. :ugly:

klutob
2013-03-29, 01:34:57
Wie sehen denn, im Vergleich, die Dateigrößen zwischen QS und x264 aus?

Ronny145
2013-03-29, 01:42:45
Bei dem Test? So gut wie identisch. Jeweils bei um die 470 MB.

Deinorius
2013-03-29, 10:42:41
Komprimierst du mit 2pass oder crf? Haben QS Encoder überhaupt crf?

aufkrawall
2013-03-29, 11:51:20
QS hat weder crf noch multipass. So lange bleibts imho nutzlos.

Ronny145
2013-03-29, 12:15:57
CRF wird unterstützt von QS. Damit lässt sich die Qualität deutlich steigern, Problem ist nur die größer werdende Datei irgendwann. Der 2-pass ist nutzlos im Vergleich. Hier 2-pass ultrafast: http://s14.directupload.net/images/130329/mewqpmxs.png

Sehr grottiges Performance/Qualitäts ratio. Langsamer als very fast oder super fast und schlechter aussehend.

Deinorius
2013-03-30, 00:07:23
Hab dir jetzt per PN einen Link zu zwei Proben geschickt. Bin gespannt, was dabei rauskommt. :)

Ronny145
2013-03-30, 01:04:58
Ich habe erst Sonntag richtig dafür Zeit. Ein Schnelltest mit 13Mbps und der hdprobe hat aber gezeigt, dass der Content viel einfacher für Videos ist als Far Cry 3. Ich würde daher mit niedriger Bitrate testen wollen, damit man besser Unterschiede erkennen kann. Wie wäre es mit 6 oder 8 Mbps?

Deinorius
2013-03-30, 18:00:55
1080p sollte mit x264 bei den besseren Presets schon bei 8 MBit/s sehr gut aussehen. Ich habe selber mit diesem Material bei unter 7 sehr gute Ergebnisse erzielt.

Also max. 6.

Ronny145
2013-03-31, 20:18:27
Also hier mit 6Mbps. Die Videos werden von 192MB (26.1 Mbps) auf ~45MB eingeschrumpft. Das Video ist nur 1 Minute lang und dementsprechend kurz sind die Umwandlungszeiten. Arcsoft hat das Video nicht öffnen können, habe mich für Quicksync auf Mediaespresso und Badaboom beschränkt. Die Handbrake Videos sind im High Profil L4.1 gemacht.

Original (http://s1.directupload.net/images/130331/bf897jaq.png)

Badaboom QS Low= 6 Sekunden (http://s7.directupload.net/images/130331/9yxqnc6m.png)
Badaboom QS Mittel= 9 Sekunden (http://s1.directupload.net/images/130331/3i78svfb.png)
Badaboom QS Hoch= 9 Sekunden (http://s7.directupload.net/images/130331/shjbtmz9.png)

MediaEspresso QS schneller= 10 Sekunden (http://s7.directupload.net/images/130331/t9s3jxt2.png)
MediaEspresso QS langsamer= 12 Sekunden (http://s14.directupload.net/images/130331/7dk6xkme.png)

Handbrake

Ultrafast= 13 Sekunden (http://s7.directupload.net/images/130331/9vvq2jfq.png)
Super fast= 19 Sekunden (http://s14.directupload.net/images/130331/47sumqz6.png)
Very Fast= 27 Sekunden (http://s1.directupload.net/images/130331/au4r74pg.png)
Faster= 39 Sekunden (http://s14.directupload.net/images/130331/2c8y6em5.png)
Fast= 55 Sekunden (http://s14.directupload.net/images/130331/m68jsczq.png)
Medium= 69 Sekunden (http://s1.directupload.net/images/130331/46ju6xr2.png)


Ultrafast und Super Fast über die CPU konvertiert unsauberer als QS, gut erkennbar an der braunen Tasche. Besonders Ultrafast sticht negativ hervor wie sich schon am Far Cry 3 Beispiel gezeigt hat.

Deinorius
2013-03-31, 21:01:25
OK, habe mir jetzt mal die Screenshots einigermaßen angesehen, wenn auch nicht alle. Vorzugsweise habe ich bei der Tasche und bei dem Baumstamm rechts oben verglichen. Badaboom schafft es, eine höhere Qualität zu erreichen als Mediaespresso. (Hätte ich das Video besser als .m2ts schicken sollen? Kann man aber auch nach muxen.)
Ultrafast ist wirklich nicht besonders, das stimmt auch. Aber ich teile nicht deine Meinung zu Super fast. Beim Vergleich von Badaboom Hoch mit Super fast sieht man kaum Unterschiede bei der Tasche, bzw. könnte man darüber streiten, was besser aussieht. Der Baumstamm hingegen sieht bei Super fast eindeutig besser aus. Von mir aus liegt der Effizienzvorteil damit bei Badaboom bei rund 2:1 mit Qualitätsvorteil bei x264 super fast.

Könntest du vielleicht auch den Stromverbrauch von Badaboom Hoch mit x264 super fast ausmessen? Dann könnte man den gesamten Verbrauch und somit zumindest die absolute Effizienz berechnen.
Hast du die CPU übertaktet? Du hast insgesamt ein effizientes System.

Ich muss aber auch allgemein sagen, dass man die Unterschiede selbst bei Ultra fast beim Schauen des Filmes selber wohl kaum sehen würde. Disney Animation Blu-Rays sind da nunmal Referenz. Auch so ist die Geschwindigkeit auch bei der CPU sehr beeindruckend, wenn man bedenkt, dass das hier 1080p ist.
Machst du noch einen Vergleich mit dem SD Video?

Ronny145
2013-04-01, 15:13:47
Hier der Stromverbrauch mit default System.

Badaboom= 59W-65W (die schnelleren QS Modi ziehen etwas mehr)
Handbrake Super Fast= 88W


Badaboom hat neben dem Arcsoft Mediaconverter die höchste GPU Auslastung und gleichzeitig niedrigste CPU Belastung aller mir bekannten QS Enkoder. Die beiden benutzen die GPU für encoding+decoding während einige andere QS Enkoder das Decoding nicht auf der GPU ausführen. Das sorgt für größere CPU Belastung. Zu dem anderen schreibe ich vielleicht später noch was.

Deinorius
2013-04-01, 16:42:08
Meinst du mit GPU jetzt eh die Encode-Einheit auf dem Intel Core i5 3570K? Die nvidia GPU sollte mit QS ja eigentlich nicht belastet werden.

Auf jeden Fall läuft das Ganze ja wirklich schön effizient. Genug, dass ich meine grundlegende Meinung zumindest zu QS ändern kann. Die Varianten von AMD und nvidia dürften hingegen nicht wirklich besser geworden sein.
Gerade für Online-Videos dürfte QS eine gute und schnelle Alternative sein, die mit entsprechender Unterstützung noch bessere Ergebnisse liefern sollte. Hoffentlich bekommt x264 einen QS-Modus, wo die vielen Vorteile von x264 mit einfließen, nämlich vorwiegend Trellis, Adaptive Quantization, (mbtree) und ganz besonders Psy optimizations! Stelle ich mir ganz praktisch vor, wenn man z.B. auf seinem Ultrabook recht hochwertige Videos in einer sehr schnellen Zeit erstellen kann. ;)

Untestützt QS eigentlich CABAC? Würde mich wundern, wenn ja.

Ronny145
2013-04-01, 18:29:06
Meinst du mit GPU jetzt eh die Encode-Einheit auf dem Intel Core i5 3570K? Die nvidia GPU sollte mit QS ja eigentlich nicht belastet werden.


Die 660 Ti war ausgebaut, ich meine schon die HD4000.


Untestützt QS eigentlich CABAC? Würde mich wundern, wenn ja.


Lässt sich einstellen. Ich gehe davon aus.

Deinorius
2013-04-02, 00:13:22
Lässt sich einstellen. Ich gehe davon aus.


Ich sollte dann wohl zwischen Encode-Einheit und Encode mittels GPU-Shader unterscheiden. Denn die Unterstützung von CABAC über GPU soll laut Dark Shikari durch die schlechte Parallelisierbarkeit kaum möglich sein.

Aber der wichtigste Vergleich muss ja erst noch in SD erfolgen.

Ronny145
2013-04-03, 02:59:12
Deswegen die Hardwareunterstützung in der MFX Engine.


Das ist relevant hier.

Support for features like Intel® Quick Sync Video and OpenCL* in systems with discrete graphics on Windows 8
o Now, one can use both Intel Quick Sync Video and OpenCL even when Intel® HD Graphics is not the primary
display adapter
o This requires Intel Graphics driver to be installed and will work only on Windows 8 platforms.

http://downloadmirror.intel.com/22652/eng/ReleaseNotes_Gfx_3071.pdf


Ich bleibe bei Windows 7, von daher betrifft mich das nicht.

Deinorius
2013-04-03, 22:34:54
Finde ich an sich blöd, dass das auf Win8 begrenzt ist. Andererseits finde ich QS vorwiegend für mobile Geräte mit möglichst wenig Wärmeentwicklung am interessantesten, welche auch nicht immer eine diskrete Graka haben.

Ronny145
2013-04-09, 00:28:20
MediaEspresso QS Quality m2ts: http://s14.directupload.net/images/130328/3c48bq6u.png
Ultrafast Handbrake: http://s7.directupload.net/images/130328/6jsac9yf.png

Das nächstschnellere preset wäre super fast. Ziemlich genau Faktor 2 zwischen QS. Keine großartig auffallende Artefaktbildung und ingesamt von der Qualität noch am vergleichbarsten: http://s1.directupload.net/images/130328/4h9s9ch8.png

Very fast als nächstes mit Faktor 2,8 Abstand: http://s7.directupload.net/images/130328/gk3yegtu.png


QSTranscode 1.0.0.2 (http://babgvant.com/blogs/andyvt/archive/2013/04/06/qstranscode-1-0-0-2.aspx) Balance= http://s7.directupload.net/images/130408/cdsg37zv.png


In nur 52 Sekunden im High Profil, das ist die Wucht für die sehr gute QS Qualität. CPU Auslastung unter 10%. MediaEspresso braucht 85 Sekunden oder so.

PrefoX
2013-04-09, 10:31:28
QSTranscode 1.0.0.2 (http://babgvant.com/blogs/andyvt/archive/2013/04/06/qstranscode-1-0-0-2.aspx) Balance= http://s7.directupload.net/images/130408/cdsg37zv.png


In nur 52 Sekunden im High Profil, das ist die Wucht für die sehr gute QS Qualität. CPU Auslastung unter 10%. MediaEspresso braucht 85 Sekunden oder so.
wie funzt das prog? bei mir schließt sich das fenster immer sofort oO

Ronny145
2013-04-09, 13:11:19
Über cmd.exe starten mit cd Befehl. Eine GUI soll später kommen. Für das Far Cry Video sieht das bspw. so aus:

qstranscode.exe -i c:\Far.mp4 -o c:\Faroutput.mp4 -h264 -w 1920 -h 1080 -b 13500 -aac -ab 128 -f 30 -u 1

boxleitnerb
2013-04-09, 14:10:39
Welche Quellcontainerformate und Codecs kann das Ding verarbeiten? Mit einer .mkv Quelldatei stürzt es hier ab.

Edit:
Mit .mp4 auch.

Ronny145
2013-04-09, 14:24:41
Meine mkv und mp4 samples funktionieren. Mehr habe ich nicht probiert. Hast du ein Link zu einem Video?

boxleitnerb
2013-04-09, 14:27:52
Müsste erst hochladen, kann etwas dauern.
Hab auch grad mal ein Video mit Fraps gemacht, das konnte er ebenfalls nicht umwandeln und ist abgestürzt.

mkv:
http://www.file-upload.net/download-7446629/test.mkv.html

avi von Fraps:
http://www.file-upload.net/download-7446662/trine2.avi.html

Ronny145
2013-04-09, 14:57:29
Welchen Treiber hast du installiert? Ich muss erstmal meine 660 Ti wieder ausbauen.

boxleitnerb
2013-04-09, 15:05:54
314.22 WHQL. Win7 x64.

Ronny145
2013-04-09, 15:17:20
Ich meine den Intel Treiber. Der Nvidia Treiber hat doch für Quicksync nichts zu melden. Version 1003 hat ein Bug, damit stürzen meine samples jetzt auch ab. Musst auf eine neue Version warten oder 1002 nehmen. Ich versuche mich nachher an deinen samples.

boxleitnerb
2013-04-09, 15:24:50
Achso das ist Quicksync? Dachte es geht hier um dGPUs. Na dann kann das nichts werden, hier ist ein 3930K verbaut.

Deinorius
2013-04-09, 19:15:52
Was für Input akzeptiert QSTranscode? Geht auch Avisynth?

Ronny145
2013-04-09, 23:56:33
So viel habe ich noch nicht getestet. Das Programm selber ist ja noch im frühen Entwicklungsstadium. Generell auf Quicksync bezogen wird nur MPEG2/VC1/AVC unterstützt. Kennt jemand Seiten mit brauchbaren HD samples? Wer eine GCN Karte besitzt könnte das hier mit VCE Support testen: http://bluesky23.yu-nagi.com/en/AsVideoConv.html

Läuft bei mir leider instabil.

Ronny145
2013-05-20, 22:34:32
Nightly Build von Handbrake mit QS ist seit kurzem verfügbar.


HandBrake with Intel's Quick Sync Video (Beta)

Up next is a beta build of HandBrake that makes use of Intel's recently released open-source SDK for QuickSync Video. It's still early days but the folks at Intel have done an awesome job on this patch and have been extremely helpful so kudos to them!

Please note, it is highly recommended that you are running Intels iGFX driver 15.31.3071 or later.
https://trac.handbrake.fr/milestone/QuickSync%20Beta

AnarchX
2013-05-23, 15:51:33
ShadowPlay: A Revolution In Game Capture, Coming Soon To GeForce Experience

Capturing footage from your favorite games can reduce frame rates quite considerably at native resolutions, in addition to reducing level and texture load speeds if capturing to the hard drive holding the game. Furthermore, some apps record using uncompressed formats, filling your drive with gigabytes of data.

If you own a GeForce GTX 600 or 700 Series GPU, you’ll soon have a new option for creating high-quality captures, courtesy of an upcoming GeForce Experience module we’re calling ShadowPlay. Completely free to use, ShadowPlay leverages the H.264 encoder built into Kepler graphics cards to record max quality, native resolution gameplay footage that is compressed and encoded on the fly, before being automatically saved as a YouTube-friendly .mp4. [...]

http://www.geforce.com/whats-new/articles/introducing-the-geforce-gtx-780

Gipsel
2013-05-23, 17:10:16
Mal sehen, wann das dann bei AMD folgt. :rolleyes:

Hugo78
2013-05-23, 19:54:23
Na in dem Fall werd ich mir GeForce Experience auch mal anschauen. :D

Ronny145
2013-06-14, 17:10:01
Intel Quick Sync Video on the 4th Generation Intel Core Processor includes these new H.264 encoding features:
1. Per-MB bit rate control
2. Trellis quantization
3. Multi-level hierarchical motion estimation
4. Multi-reference
5. Multi-predictor
6. B-pyramid
7. Lookahead
http://newsroom.intel.com/servlet/JiveServlet/previewBody/3880-102-1-6896/WP-HD-Graphics-4200.pdf
http://intelnewsroom.hosted.jivesoftware.com/servlet/JiveServlet/downloadBody/3910-102-1-6927/Intel%20Xeon%20E3-1200v3%20Launch%20Deck.pdf


Braucht es für Lookahead Encoder Updates oder ist das automatisch aktiv mit Haswell?

Deinorius
2013-06-14, 17:29:55
Mal eine Frage, weil ich es einfach nicht weiß: Unterstützt Quicksync auch CABAC?

Gebrechlichkeit
2013-06-14, 17:43:27
Mal eine Frage, weil ich es einfach nicht weiß: Unterstützt Quicksync auch CABAC?

In dieser .pdf steht was von Cabac, ich tippe mal auf ja.
http://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.19.8-Video/HC23.19.820-QuickSync-Jiang-Intel_08012011b.pdf

-Entropy coding is a high performance serial compute
-30Mbps CABAC alone may require ~GOPS

Deinorius
2013-06-14, 18:25:59
Ah sehr gut. Damit dürfte QS z.B. auf einem Ultrabook wirklich sehr interessant sein.
Ein aktueller Vergleich wäre wieder gut. :)

Ronny145
2013-06-15, 02:35:42
CABAC ist automatisch aktiv seit Ewigkeiten. Wegen dem Lookahead steht das im whitepaper:


Lookahead is an advanced feature available at the SDK level that can provide further quality improvements, especially when the contents have many scene changes.


Brauch es wohl App Support. Ein Media SDK Update soll bald kommen. Das gleiche für die 7 target usages. Wenn man Glück hat gibt es 3 zur Auswahl in heutigen Encodern. Die meisten kommerziellen wie MediaEspresso oder MediaConverter bieten gar nur 2 oder gar keine Auswahlmöglichkeiten an.



Prior generations of Intel Quick Sync Video focused on three pre-defined configurations or usages, but now application developers have more options. Intel Quick Sync Video now defines seven distinct target usages (TUs), each with a particular balance of quality and performance. Many software vendors only use two or three of the defined target usages in their application, saving development time.

Ronny145
2013-06-21, 23:58:35
http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance

Quicksync Evaluation vom QSTranscode Author. Das ganze ist allerdings nur vorläufig. Die neuen Haswell Features werden erst im kommenden SDK unterstützt. Im speziellen lookahead verspricht deutliche Qualitätssteigerungen. SDK und passender Treiber sollen bald kommen. Erst dann können Devs ihre Apps anpassen.

dargo
2013-07-01, 20:42:39
Wie ist eigentlich der aktuelle Stand bei GCN was Videoencoding angeht?

Ronny145
2013-07-01, 20:54:55
Der einzig mir bekannte VCE Encoder: http://bluesky23.yu-nagi.com/en/AsVideoConv.html

Ob das was taugt, keine Ahnung.

Ronny145
2013-07-01, 21:48:00
Ach ja lookahead wird jetzt unterstützt vom neuen SDK.


Intel® Media SDK 2013 R2 introduces API version 1.7. This version is backwards compatible with API version 1.6. API version 1.7 introduces the look ahead bitrate control algorithm and the new extended buffers to enable the advanced control over H.264 encoder for the video conferencing use case.

Enumeration MFX_RATECONTROL_LA and a respective mfxExtCodingOption2:: LookAheadDepth field were added to enable the new look ahead bitrate control algorithm and configure its depth parameter. The algorithm is supported only by the hardware implementation of Intel® Media SDK dynamic library for the 4th Generation Intel® Core™ Processors with Intel® Iris™ Pro Graphics, Intel® Iris™ Graphics or Intel® HD Graphics 4200+ Series.
http://registrationcenter-download.intel.com/akdlm/irc_nas/3264/IntelMediaSDK2013R2.zip

Ronny145
2013-07-12, 23:11:53
Erster Test mit Lookahead an einem bislang worst case Video für Quicksync. QSTranscode 1011, Balanced Preset, Video Bitrate und Größe bei allen gleich (5500 Kbit/317MB).


CBR: http://img856.imageshack.us/img856/604/iu6.png
VBR: http://img43.imageshack.us/img43/7281/okyx.png
AVBR: http://img33.imageshack.us/img33/5505/xdq2.png
CQP: http://img11.imageshack.us/img11/7277/bvbw.png
LA_Depth 60: http://img11.imageshack.us/img11/5739/mzry.png


Lookahead sticht die anderen klar aus. Wenn Handbrake eine neue Version mit LA Support veröffentlicht schaue ich mir das genauer an.

dargo
2013-07-13, 13:06:25
Erster Test mit Lookahead an einem bislang worst case Video für Quicksync. QSTranscode 1011, Balanced Preset, Video Bitrate und Größe bei allen gleich (5500 Kbit/317MB).


CBR: http://img856.imageshack.us/img856/604/iu6.png
VBR: http://img43.imageshack.us/img43/7281/okyx.png
AVBR: http://img33.imageshack.us/img33/5505/xdq2.png
CQP: http://img11.imageshack.us/img11/7277/bvbw.png
LA_Depth 60: http://img11.imageshack.us/img11/5739/mzry.png


Lookahead sticht die anderen klar aus. Wenn Handbrake eine neue Version mit LA Support veröffentlicht schaue ich mir das genauer an.
Interessant... LA_Depth 60 sieht für nur ~5,5Mbit und Full-HD wirklich sehr gut aus. CQP ist zwar auch noch recht brauchbar, kommt aber an LA nicht ran. Die anderen sind schon beinah eine Katastrophe. :freak:

PS: hast du das selbst getestet? Wie sind die einzelnen Zeiten beim Encoding?

Ronny145
2013-07-15, 17:12:56
Ja das habe ich selbst getestet. CBR, VBR, AVBR sieht dort so besonders schlecht aus, weil das ein Szene Wechsel im Video gewesen ist, ist mir erst im Nachhinein aufgefallen. Ein Frame weiter und es sieht fast vergleichbar mit CQP aus. Bei ruhenden Szenen ist VBR fast immer klar im Vorteil gegen CQP (zumindest bei so hohen CQP Faktoren). CQP ist robuster bei Szenewechseln. LA ist noch besser. Bei Szenewechseln und vermutlich das gleiche bei schnellen Videosequenzen ist der Unterschied zu den anderen Bitrate Modi am größten. Bei dem Video 50% längere Encodierzeit verglichen zu VBR und 63W Systemverbrauch statt 48W. Speicher und GPU Verbrauch steigt an. Die GPU läuft fast immer auf 100% Anschlag. Iris Pro wird mit Lookahead wohl klar vor einer GT2 liegen. Davon abgesehen gibt es noch keinen offiziellen Treiber mit Lookahead Support und ein paar neue Haswell Features wie Trellis Quantization unterstützt selbst QSTranscode noch nicht.

Deinorius
2013-07-16, 12:50:40
Kannst du mal einen x264 Vergleich bei ungefähr gleicher Enkodierzeit machen? Sieht schon sehr interessant aus.

dargo
2013-07-16, 13:19:26
Kannst du mal einen x264 Vergleich bei ungefähr gleicher Enkodierzeit machen? Sieht schon sehr interessant aus.
So ein Vergleich würde mich auch interessieren.

Es ist zwar toll wenn die BQ deutlich besser ist, wenn man dafür aber 50% länger warten muss sieht das wieder ganz anders aus.

Ronny145
2013-07-16, 15:58:50
Vergleichbar wäre Ultrafast preset mit x264 und meinem i5.

Handbrake x264 Ultrafast 1:37 min: http://img843.imageshack.us/img843/1237/ggr3.png
QSTranscode 1.0.1.1 LA_Depth 60 TU4 1:27 min: http://img11.imageshack.us/img11/5739/mzry.png

Jeweils 5471 Kbit im High h264 Profil (decomb off für ultrafast).

Wie gesagt lohnt ein richtiger Vergleich derzeit nicht. Wäre verschwendete Zeit wenn nächsten Monat die Ergebnisse nicht mehr aktuell sind.

Deinorius
2013-07-16, 17:31:45
Der Vergleich ist so schön interessant genug. Zumindest bei diesem Video hat x264 mit ungefähr der gleichen Encodierzeit keine Chance. Das ist faszinierend. x264 ist zwar immer noch besser für hohe Qualität, was aber deutlich länger dauert.
Liege ich richtig in der Annahme, dass das Video etwas unter 8 min lang ist? Außerdem steht die Entwicklung weder bei x264 noch bei CS still, also wieso auf einen Vergleich verzichten?
Hast du auch den Stromverbrauch zwischen x264 und LA_Depth 60 beobachtet?

robbitop
2013-07-16, 23:49:52
Ich habe dazu eine Frage: die x264 presets (ultrafast, fast etc) verringern ja die BQ. Wenn man aber gleichzeitig einen festen CRF Wert einstellt, müsste die BQ nicht immer gleich sein und nur die Kompressionsrate mit der Geschwindigkeit skalieren?

Deinorius
2013-07-17, 17:25:45
Meinst du vielmehr crf?

robbitop
2013-07-17, 19:44:45
Ja genau - typo.

Deinorius
2013-07-17, 20:27:10
Zu 100% verstehe ich den Text nicht direkt, also sage ich es mal so.

Bei gleicher Bitrate entscheiden die Presets die BQ. Je schneller umso schlechter die BQ. Bei gleichem CRF bleibt die BQ aber an sich gleich, an sich bzw. rein theoretisch!

robbitop
2013-07-17, 20:57:03
Zu 100% verstehe ich den Text nicht direkt, also sage ich es mal so.

Bei gleicher Bitrate entscheiden die Presets die BQ. Je schneller umso schlechter die BQ. Bei gleichem CRF bleibt die BQ aber an sich gleich, an sich bzw. rein theoretisch!
Also verliere ich bei gleichem CRF nur Kompressionsgrad, wenn ich ein schnelleres Preset wähle?

Deinorius
2013-07-17, 21:06:33
Richtig. Bei aktiviertem CABAC könnte die Kodiergeschwindigkeit je nach Preset sogar sinken.

robbitop
2013-07-17, 21:23:45
Warum das?

Deinorius
2013-07-17, 21:51:44
CABAC führt dazu, dass höhere Bitraten höhere Encode- und Decode-Anforderungen benötigen. Habe ich selber schon oft genug gesehen. Ich habe vor langer Zeit eine bessere Erklärung gelesen, sagen wir einfach: Is holt so. :D
Der Effekt ist jetzt nicht riesig, aber (deutlich) vorhanden. Du kannst ja schauen, wie hoch der Decode-Aufwand bei einer Blu-Ray (ohne AACS natürlich) gegenüber dem selben Video mit 6 MBit/s liegt. ;)

Ronny145
2013-07-17, 22:34:09
http://forums.adobe.com/thread/1243687?tstart=0

Hat jemand das Nvenc Plugin für Adobe ausprobiert? Bei mir enkodiert das zwar problemlos, zu erkennen an der hohen Video Engine Auslastung, abspielen kann ich die nvenc enkodierten Videos aber nicht.

Timbaloo
2013-07-22, 22:44:45
Hätte mal eine kurze Frage (hab jetzt nicht den ganzen Thread durchsucht und auf die schnelle hat die SuFu auch nichts ausgespuckt):

Wenn ich mittels Quicksync transcodiere (also de+encoding) wird steigt meine CPU-Temperatur (3570K) nicht wirklich an. Vielleicht 3-5K. Die Performance ist wie man wohl erwarten sollte (~250fps @ 1080p -> 1080p, bzw. ~500fps @ 1080p -> 480p). Ist das "normal"? :eek:

AnarchX
2013-07-23, 09:42:09
Ja, QuickSync realisiert einen großen Teil des Encodings über dedizierte Schaltkreise, sodass die CPU-Kerne kaum Arbeit haben.
Wobei die extrem schnellen Encoding-Presets natürlich bei der Qualität entsprechend sparen.

robbitop
2013-07-23, 10:09:47
Das müsste sich mit entsprechender Bitrate doch wieder ausgleichen lassen oder? Spätestens mit einem angegebenen CRF sollte die BQ doch so sein, wie man es haben möchte - halt auf Kosten der Größe. Oder liege ich mit meiner Annahme falsch?

Timbaloo
2013-07-23, 10:23:50
Dass es zum größten Teil nicht auf der CPU läuft war mir klar, dass es aber so krass ist finde ich echt erstaunlich. Jetzt muss ich noch Lucid MVP aufsetzten :)

aufkrawall
2013-07-23, 11:38:26
Quicksync-Deinterlacing geht allerdings auch recht stark auf die CPU.

Würde dir btw. nicht zum Virtu-Schrott raten. Mit Windows 8 soll man ab IVB Dank neuer APIs QS auch so mit dGPU nutzen können.

Deinorius
2013-07-23, 12:06:01
Das müsste sich mit entsprechender Bitrate doch wieder ausgleichen lassen oder? Spätestens mit einem angegebenen CRF sollte die BQ doch so sein, wie man es haben möchte - halt auf Kosten der Größe. Oder liege ich mit meiner Annahme falsch?


Das stimmt so. Ich würde jedoch nicht ausschließen, dass es geringfügige Unterschiede geben könnte. Ich rede hier jedoch vorwiegend aus Erfahrung mit Animes in SD.

Gibt es bei Quicksync überhaupt CRF?

Ronny145
2013-07-23, 12:26:39
Das Gegenstück ist CQP. Damit ist es konstant, nur wenn es konstant schlechter ist, kann das nicht gleich sein. Bei niedriger Bitrate fand ich CRF/CQP schlechter als VBR. Da müsste man wohl auf viel niedrigere Faktoren gehen und größere Dateien in Kauf nehmen.

Das Nvenc Plugin für Adobe habe ich ans laufen bekommen. Qualität ist richtig gut eigentlich. CPU Last recht hoch, liegt wohl an Adobe.

Deinorius
2013-07-23, 12:32:18
Bei niedriger Bitrate fand ich CRF/CQP schlechter als VBR. Da müsste man wohl auf viel niedrigere Faktoren gehen und größere Dateien in Kauf nehmen.


Diese Aussage kann ich zu einem guten Teil bestätigen. Generell ist aber der niedrigste real sinnvolle CRF der Wert 20. Geht man mit dem Wert weiter runter, wird die Datei größer, aber gerade bei HD bezweifle ich sehr, dass die Qualität wirklich sichtbar besser wird. Möchte man jedoch auf Nummer sicher gehen, sollte der Wert nicht unter 18 gehen. Das ist dann wirklich grober Unfug. Einzig CRF 0 als Lossless Mode macht für Zwischenschritte Sinn.

Nutzt CQP die selben Werte?

Ronny145
2013-07-23, 12:35:30
Ja um die 20 kann das Sinn machen von der Qualität wenn man die Dateigrößen akzeptiert. Bei niedrigen Full HD Bitraten von 5-6 Mbps müsste ich meistens auf 25-30 gehen und das sieht dann schlechter als VBR aus.

Timbaloo
2013-07-23, 12:49:41
Würde dir btw. nicht zum Virtu-Schrott raten. Mit Windows 8 soll man ab IVB Dank neuer APIs QS auch so mit dGPU nutzen können.
Ist nicht, dass ich scharf auf das Lucid Zeugs bin. Aber deswegen extra Win8 kaufen? Wenn dann warte ich auf 8.1. Aber danke für die Info! Mit etwas Glück geht es auch irgendwann unter Win7 :)

Deinorius
2013-07-23, 13:18:08
Ja um die 20 kann das Sinn machen von der Qualität wenn man die Dateigrößen akzeptiert. Bei niedrigen Full HD Bitraten von 5-6 Mbps müsste ich meistens auf 25-30 gehen und das sieht dann schlechter als VBR aus.


Also ich habe bei den letzten Videos mit crf20 in 720p (meistens 1280x544) Bitraten von 1763 bis 2934 kbit/s erreicht. Ich wundere mich daher etwas, dass du sogar auf 25-30 runtergehen müsstest. Um was für Videos geht es dabei?

Ronny145
2013-07-23, 13:19:28
Alles Full HD.

Deinorius
2013-07-23, 13:20:14
Ich meinte eigentlich den Inhalt. Voller Action, ruhige Szenen mit wackeliger oder stiller Kamera?

Ronny145
2013-07-23, 19:47:09
Die Bitrate hängt stark an der Auflösung. Mit 25-30 meinte ich CQP. RF Werte können niedriger sein.

Deinorius
2013-07-23, 21:38:39
Ich habe das mit CQP und 25-30 schon richtig verstanden. Ich würde aber dennoch gerne wissen, ob die Videos alle bunt durchgemischt sind, oder ob es sich um bestimmte Genres handelt.

Ronny145
2013-07-27, 23:03:41
Durcheinander gemischt würde ich sagen. Neue Handbrake Beta für Quicksync mit Lookahead Support ist draußen. Wegen einem Bug geht LA Depth nur bis maximal 45. 60 würde ich bevorzugen aber 45 ist auch ok fürs erste.

Ronny145
2013-08-01, 23:04:14
Quicksync-Deinterlacing geht allerdings auch recht stark auf die CPU.

Würde dir btw. nicht zum Virtu-Schrott raten. Mit Windows 8 soll man ab IVB Dank neuer APIs QS auch so mit dGPU nutzen können.


Bislang habe ich im Bios auf iGPU umgestellt, DVI auf iGPU gewechselt und Neustart. Zeitanspruch 1 Minute. (Treiber alles schon installiert wenn man das einmal macht) Für Nvidia User habe ich noch eine bessere Möglichkeit gefunden.

http://s1.directupload.net/images/130801/jyvad6y2.png


Von Disable auf Enable umstellen. Handbrake benutzt dann ohne zu meckern die iGPU trotz aktiver 660 Ti und Windows 7. Sehr nützlich.

Timbaloo
2013-08-02, 00:55:28
Das werde ich morgen gleich mal probieren :)

aufkrawall
2013-08-02, 01:07:58
Von Disable auf Enable umstellen. Handbrake benutzt dann ohne zu meckern die iGPU trotz aktiver 660 Ti und Windows 7. Sehr nützlich.
Interessante Entdeckung.
Sollte bei den Handbrake Nightlies dann einfach QS als Enkoder-Option verfügbar sein? Ist es bei mir mit Sandy Bridge und Build 5675 leider nicht.

Ronny145
2013-08-02, 01:38:17
Unter Video Codec H.264 Intel QSV. Du brauchst die QS Beta.

http://sourceforge.net/projects/handbrake/files/Betas/QSV/

Im activity log müsste sich QS zu erkennen geben nachdem ein Video geladen wurde. Entscheidend ist hierbei die Hardware Version. Die muss vorhanden sein. Wenn ich im Inspector auf disable stelle fehlt die Version.

[01:21:19] Intel Quick Sync Video support: yes
[01:21:19] - 4th gen. Intel Core processor
[01:21:19] - hardware name: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
[01:21:19] - hardware version: 1.7 (minimum: 1.3)
[01:21:19] - software version: 1.7 (minimum: 1.3)


SB unterstützt glaube nur API 1.3 oder 1.4 mit den 15.28er Treibern. Im Bios habe ich iGPU auf enabled. Außerdem muss ein Intel Treiber installiert sein. Noch als Tipp, Handbrake nutzt custom gop Werte, die ich für nicht optimal halte. Besser sind meistens Intels eigene SDK Werte. Genauso das TU2 in der default Einstellung, macht kein Sinn auf Haswell. TU4 ist der bessere Kompromiss. Das advanced query Feld müsste mit default gop dann so aussehen:


lookahead=0:gop-ref-dist=0:gop-pic-size=0:target-usage=4


(auf Haswell kann man das lookahead natürlich auf 1 stellen wer zugunsten von Qualität auf Geschwindigkeit verzichten will)

Timbaloo
2013-08-02, 08:27:05
Hmmm, scheint bei mir auf die schnelle nicht zu funktionieren.

Ausgabe:
- intel quick sync video support: yes
- hardware version: 1.6 (minimum: 1.4)

Soweit gut, aber sobald ich einen Job starte kackt der Decoder ab:
Error code -3, ff_qsv_dec_init 106
[08:22:25] decavcodecvInit: avcodec_open failed
ERROR: Failure to initialise thread 'Video decoder (libavcodec)'

Muss ich heute abend in Ruhe nochmal anschauen.

aufkrawall
2013-08-02, 11:34:12
Bei mir erkennt er keinen QS-Support, geht also wohl nicht mit SNB.
Mein Bruder hat sich nen 4770k bestellt, kann damit bald testen.

Ronny145
2013-08-02, 11:55:03
Hmmm, scheint bei mir auf die schnelle nicht zu funktionieren.

Ausgabe:
- intel quick sync video support: yes
- hardware version: 1.6 (minimum: 1.4)

Soweit gut, aber sobald ich einen Job starte kackt der Decoder ab:
Error code -3, ff_qsv_dec_init 106
[08:22:25] decavcodecvInit: avcodec_open failed
ERROR: Failure to initialise thread 'Video decoder (libavcodec)'

Muss ich heute abend in Ruhe nochmal anschauen.


Welcher Treiber ist installiert?


Bei mir erkennt er keinen QS-Support, geht also wohl nicht mit SNB.
Mein Bruder hat sich nen 4770k bestellt, kann damit bald testen.


Wird in der Systemsteuerung die HDxxx angezeigt? Es kann sein das manche Biose bei dGPU Benutzung automatisch die iGPU deaktivieren. Mein Bios hat eine Funktion im Bios.

aufkrawall
2013-08-02, 12:04:10
Wird in der Systemsteuerung die HDxxx angezeigt? Es kann sein das manche Biose bei dGPU Benutzung automatisch die iGPU deaktivieren. Mein Bios hat eine Funktion im Bios.
Ist aktiv. Mit dem Multimonitorhack geht es auch, es scheint also wirklich erst ab IVB mit diesem Shim-Trick zu gehen.

Ronny145
2013-08-02, 13:43:52
Ich glaube das liegt am Intel Grafiktreiber. Die headless QS/OpenCL Funktion gibt es erst ab der 15.31 Treiberserie (für Windows 8). Für die Shim Funktion braucht es vermutlich 15.31 oder neuer, die von SB nicht mehr unterstützt werden.

Timbaloo
2013-08-02, 13:53:27
Welcher Treiber ist installiert?
Den habe ich vor 2 Wochen bei intel gezogen. Genaue Version gibt's später.

aufkrawall
2013-08-02, 14:09:01
Ronny, kannst du mal testen, ob bei LAV Video Dekoder auch QS damit geht (muss während des Abspielens "Active" anzeigen)?

Ronny145
2013-08-02, 14:20:01
Den habe ich vor 2 Wochen bei intel gezogen. Genaue Version gibt's später.


Müsste Build 3165 sein. Damit geht es bei mir. Erkannt wird QS ja scheinbar, sonst würde keine Hardware Version angezeigt werden. Du kannst ja mal QSTranscode oder MediaEspresso austesten, nicht dass das irgendein Handbrake Bug in Verbindung mit Ivy Bridge ist.


Ronny, kannst du mal testen, ob bei LAV Video Dekoder auch QS damit geht (muss während des Abspielens "Active" anzeigen)?


Wenn du mir sagt wie ich das austesten kann.

aufkrawall
2013-08-02, 14:26:41
Wenn du mir sagt wie ich das austesten kann.
LAV installieren:
http://code.google.com/p/lavfilters/downloads/list

In MPC HC in den Optionen -> Interne Filter -> Rechtsklick in den Listen und alle deaktivieren.
Dann bei externe Filter LAV aus der Liste hinzufügen und immer "Bevorzugen" wählen:
http://abload.de/thumb/lavw1y3o.jpg (http://abload.de/image.php?img=lavw1y3o.jpg)

Wenn du jetzt ein Video abspielst, sollte bei Wiedergabe -> Filter dort LAV stehen. Kannst du gleich auswählen, um in die Option vom Videodekoder zu kommen. Dort kannst du dann rechts QS auswählen. Wenn das klappt, steht dort während des Abspielens bei QS "Active". Wenn da dann nur "Available" steht, ist es nicht aktiv.

klutob
2013-08-02, 14:27:02
^^Läuft hier mit IVB und Win8, müßte dann mit Haswell erst recht funktionieren.

Ronny145
2013-08-02, 17:26:15
LAV installieren:
http://code.google.com/p/lavfilters/downloads/list

In MPC HC in den Optionen -> Interne Filter -> Rechtsklick in den Listen und alle deaktivieren.
Dann bei externe Filter LAV aus der Liste hinzufügen und immer "Bevorzugen" wählen:
http://abload.de/thumb/lavw1y3o.jpg (http://abload.de/image.php?img=lavw1y3o.jpg)

Wenn du jetzt ein Video abspielst, sollte bei Wiedergabe -> Filter dort LAV stehen. Kannst du gleich auswählen, um in die Option vom Videodekoder zu kommen. Dort kannst du dann rechts QS auswählen. Wenn das klappt, steht dort während des Abspielens bei QS "Active". Wenn da dann nur "Available" steht, ist es nicht aktiv.


Hmm mit dem MPC und Windows Media player bekomme ich nur ein schwarzes Bild beim Abspielen von Videos bei aktiver Shim Option. Der VLC Player hat dagegen keine Probleme. Da macht ein Test kein Sinn.


^^Läuft hier mit IVB und Win8, müßte dann mit Haswell erst recht funktionieren.


Sollte das nicht nativ funktionieren mit 15.31 Treibern auf Windows 8?

Timbaloo
2013-08-02, 18:57:21
Müsste Build 3165 sein. Damit geht es bei mir. Erkannt wird QS ja scheinbar, sonst würde keine Hardware Version angezeigt werden.
Ja, ist 3165. Was ich nun gemacht habe ist den aktuellen Beta-Build (svn5671_x86_64) installiert, dort erkennt er den QS support schon gar nicht mehr :(

Und da ich ein unglaublich schlauer Fuchs bin, habe ich den alten Build (wo er QS noch erkannt hat) bereits gelöscht... :facepalm:

Du kannst ja mal QSTranscode oder MediaEspresso austesten, nicht dass das irgendein Handbrake Bug in Verbindung mit Ivy Bridge ist.
Werde ich mal tun.

Nachtrag: nvidia Treiber aktualisiert: Läuft nun :)

Dank dir Ronny :)

Ronny145
2013-08-02, 20:32:40
Dann ist das wohl eine recht neue Funktion im Nvidia Treiber.

Timbaloo
2013-08-02, 20:45:41
Hast du eigentlich mal das 4k-Video aus dem neueren x264-Benchmark (Schlammsau) durchgeprügelt? Wenn ich bei 4k als Ziel bleibe, dann bekomme ich mit QS gerade mal 3-4fps. Wenn ich allerdings auf 1920 (also der entsprechenden 1080p Auflösung) setze, dann komme ich auf ~160fps. Skaliert dann wohl nicht ideal mit der Auflösung :freak:

Wäre interessant ob dein Haswell da ähnlich reagiert wie mein Ivy.

QS-Einstellungen habe ich auf default gelassen.

Ronny145
2013-08-02, 21:34:43
Ne bir mir nicht. 50-70 fps je nach setting. Konvertiert der das bei dir fertig? Handbrake hängt bei 99,97%. QSTranscode kein Problem.

Timbaloo
2013-08-02, 21:49:28
Hängt bei mir auch am Ende. Manchmal crasht handbrake auch einfach.

Da scheint der Haswell das 4k-Gütesiegel zu bekommen :D

Muss mal schauen ob das bei einer gewissen Auflösung einfach sprungartig abkackt, oder ob es halt einfach schlecht skaliert.

Ronny145
2013-08-02, 21:55:59
4K sollte auf Ivy Bridge eigentlich funktionieren. Teste mal das 4k Video hier: ftp://download.intel.com/newsroom/kits/restricted/ha$well!/4K_Release_h264_100mbps.zip

Timbaloo
2013-08-03, 00:00:27
Gleiches Verhalten. Was auffällt ist, dass die CPU ordentlich belastet wird (im Mittel um die 90%).

O.K. bei dem intel-Video bekomme ich bis 1920x1080 tolle fps (~150) und keine CPU-Last, aber sobald ich die Grenze überschreite (z.B. 2048x1152 geht die CPU-Last in die Höhe und die fps fallen auf unterirdische Werte (<10fps). Auszug aus dem Log (Fall 2048x1152):

[00:09:27] Intel Quick Sync Video support: yes
[00:09:27] - 3rd gen. Intel Core processor
[00:09:27] - hardware name: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
[00:09:27] - hardware version: 1.6 (minimum: 1.3)
[00:09:27] hb_init: starting libhb thread
HandBrake svn5671 (2013072701) - MinGW x86_64 - http://handbrake.fr
4 CPUs detected

...

[00:09:30] qsv: Intel QSV/MediaSDK uses hardware implementation
[00:09:30] qsv: RateControlMethod:MFX_RATECONTROL_CQP(I:20/P:22/B:22)
[00:09:30] qsv: TargetUsage:2 AsyncDepth:4
[00:09:30] qsv: GopRefDist:4 GopPicSize:32 NumRefFrame:0

Hmmmm, macht mich jetzt nicht schlauer...

Gut, alles größer Full-HD juckt mich nicht die Bohne, aber interessant ist das schon irgendwie.

Ronny145
2013-08-03, 00:46:59
Klares Zeichen, dass das encoding nicht von Quicksync übernommen wird. Oder unterstützt IVB nur decoding von 4k? Nach langer Suche nicht viel gefunden, aber das hier klingt danach: http://software.intel.com/en-us/forums/topic/346250

Nach Hardware encoding sieht es ja auch nicht aus.



[00:09:30] qsv: GopRefDist:4 GopPicSize:32 NumRefFrame:0



Auf Ivy Bridge verwendet Handbrake immer noch eine GOpPicSize von 32? :freak: Das ist der reinste Müll, die Qualität ist damit einfach viel schlechter. Nimm besser die SDK Default Werte:


gop-ref-dist=0:gop-pic-size=0

Timbaloo
2013-08-03, 00:56:56
Interessant.

Was die Einstellungen betrifft, hey, lass mir Zeit, das Ding rennt erst seit heute hier :D

dildo4u
2013-09-10, 16:29:05
Divx 10 hat jetzt HEVC(h.265) intrigiert.

Natürlich noch keine GPU Beschleunigung beim 4K Video hab ich 60% CPU Auslastung mit einem AMDX6 3.2Ghz.Um das Video zu sehen muss man DivX 10 plus HEVC Plugin installieren und dann den Browser neu starten.

http://www.divx.com/en/hevc-demo

Laut Heise nutzt das 4K Video nur 3.5Mbit/sec.

http://www.heise.de/newsticker/meldung/DivX-10-spielt-und-kodiert-Videos-in-HEVC-1949942.html

Deinorius
2013-09-10, 18:18:05
3,5 MBit/s für 4K? Da müsste ich wohl die einzelnen Bilder im Zoom betrachten, wenn ich die Qualität davon beurteilen wollen würde. :ugly:

AnarchX
2013-09-11, 08:44:44
Twitch mit QuickSync Support: http://newsroom.intel.com/community/intel_newsroom/blog/2013/09/10/chip-shot-twitch-implements-intel-quick-sync-video-technology-for-streaming

Ronny145
2013-09-13, 00:15:23
Ein Schwung voller Quicksync Slides von der IDF.

http://s14.directupload.net/images/130913/lyy8dtky.png

http://s14.directupload.net/images/130913/t9lllppr.png

http://s1.directupload.net/images/130913/8t6vumh5.png

http://s14.directupload.net/images/130913/9wgm3np4.png

http://s1.directupload.net/images/130913/2fek63gf.png

http://s1.directupload.net/images/130913/ht7x5czw.png

http://s1.directupload.net/images/130913/br3zlanp.png

http://s1.directupload.net/images/130913/mta79xoe.png

http://s1.directupload.net/images/130913/9bdif32x.png

http://s14.directupload.net/images/130913/fkatu458.png

http://s14.directupload.net/images/130913/zausdtah.png

HisN
2013-09-13, 17:45:21
Kennt von euch jemand das Programm Action! ?
Das nehme ich um kleine Videos aufzunehmen.
Der GPU-Kodierer ist jedenfalls nicht zu gebrauchen, praktisch keine Einstell-Möglichkeiten und produziert Farb-Artefakte :-(
(Und ganz nebenbei ... auch hier wird die 2. GPU nicht genutzt^^).


https://www.youtube.com/watch?v=2qjge-YAT8c

Ronny145
2013-09-13, 22:42:41
Welche GPU nutzt das Programm?

HisN
2013-09-14, 13:06:58
Eine Nvidia-GPU. Hier: Titan.

AnarchX
2013-09-14, 13:15:35
Wohl nur eine simple CUDA-Lösung: http://mirillis.com/en/products/splashexport_ultimate_performance.html

Da kann man nur hoffen, dass ShadowPlay von NV bald fertiggestellt wird.

AnarchX
2013-09-26, 18:21:17
VLC hat nun auch QuickSync-Support: http://www.heise.de/newsticker/meldung/VLC-media-player-mit-wertvollen-Verbesserungen-1967952.html?wt_mc=rss.ho.beitrag.rdf

Deinorius
2013-09-26, 20:22:10
Hab mich verlesen. -.-

Ronny145
2013-09-26, 20:41:50
Mithilfe von Intel QuickSyncVideo kann man unter Windows zudem Hardware-beschleunigt Videos kodieren.


Bedeutet einfach nur das Quicksync mit anderen Betriebssystemen nicht kompatibel ist. Wie kann ich mit dem VLC konvertieren? Gibt es eine FAQ?

cpushreder
2013-10-03, 21:11:03
ich nutze mit meiner 650ti mediacode. hat ne schöne implementation von cuda und quick sync.
wenn ich meinen 2500k auf 5 ghz takte kann ich sogar meine graka voll auslasten.

ich habe dabei bemerkt das hier dann mein prozessor dennoch das nadelöhr ist, da er das videomaterial decodieren muss. bei ca 21 facher codiergeschwindigkeit kommt er dann doch nicht mehr hinterher. gibt es hier die möglichkeit mit quicksync das video ecodieren zu lassen um evtl noch etwas fixer fertig zu werden, oder nicht so hoch takten zu müssen?

aufkrawall
2013-10-03, 21:16:12
Wenn das Programm DirectShow-Codecs zum Dekodieren verwendet, kannst du LAV Filters installieren, dort Quicksync/Cuda/DXVA2 CB auswählen und musst LAV eventuell noch mit Win7DSFilterTweaker zum Standard für H.264 machen.
Das sollte dann gehen.

Ronny145
2013-10-03, 21:21:46
MediaCoder? Der ist crap für Quicksync (nicht nur wegen dem fehlenden Hardware Decoding).

aufkrawall
2013-10-03, 21:23:04
(nicht nur wegen dem fehlenden Hardware Decoding).
Kann man mit Avisynth füttern, dann geht das natürlich.
Aber schon klar, der Encode wird nicht besser.

cpushreder
2013-10-03, 21:38:54
MediaCoder? Der ist crap für Quicksync (nicht nur wegen dem fehlenden Hardware Decoding).

beim encoding mit quick sync habe ich ca faktor 7 erreicht, warum sollte dann nicht auch decoding damit funktionieren?

Edith:
http://forum.mediacoderhq.com/viewtopic.php?p=36495#p36495

Ronny145
2013-10-03, 22:35:54
beim encoding mit quick sync habe ich ca faktor 7 erreicht, warum sollte dann nicht auch decoding damit funktionieren?


Der Faktor sagt ohne die Encoder Parameter so gut wie nichts aus. Warum das decoding nicht auf der iGPU läuft? Da musst du dem Entwickler fragen.



Edith:
http://forum.mediacoderhq.com/viewtopic.php?p=36495#p36495


Das habe ich probiert. Es senkt die CPU Last ein wenig, von zufriedenstellend weit entfernt. Für Quicksync ist die Handbrake Nightly eine bessere Wahl.

Ronny145
2013-10-05, 18:19:22
http://www.bandicam.com/support/tips/intel-quick-sync/

So lässt sich Quicksync mit dedizierter Karte nutzen. Es funktioniert wie beschrieben auf meinem Windows 7 System mit Handbrake. (die "by adding the display device" Lösung meine ich)

cpushreder
2013-10-05, 19:53:59
klappt bei mir nicht.
ich kann schon beim auswählen der iGPU für den anderen display output aufhören

Ronny145
2013-10-05, 20:35:51
Mit klappt nicht kann ich nichts anfangen. Warum du aufhören kannst weiß auch keiner.

cpushreder
2013-10-06, 01:48:06
ich kann zwar ein weiteres display einrichten, aber ich kann nur meine gtx auswählen.

Ronny145
2013-10-06, 02:02:18
Simpelste Ursache wäre das die iGPU einfach nicht aktiviert ist.

aufkrawall
2013-10-06, 11:40:14
http://www.bandicam.com/support/tips/intel-quick-sync/

So lässt sich Quicksync mit dedizierter Karte nutzen. Es funktioniert wie beschrieben auf meinem Windows 7 System mit Handbrake. (die "by adding the display device" Lösung meine ich)
Ja, nur wie ist die Performance?

Ronny145
2013-10-06, 16:29:06
Gleich oder etwas besser. Alle sonstigen GPU Aktivitäten übernimmt die dedizierte. Beim Encoding Vorgang bekommt man deswegen nichts mit, alles bleibt voll bedienbar.


Den zweiten Monitor sollte man in eine Ecke schieben:

http://s1.directupload.net/images/131005/djnalvg7.png


Die Maus verschwindet sonst ein bisschen wenn man an den Rand gelangt.

aufkrawall
2013-10-06, 17:16:58
Als dauerhafte Lösung taugt das imho nicht. Irgendwann muss man immer den Cursor wieder aus dem Nichts ziehen und das nervt dann schon.
Mal eben für ein Spiele-Capture wahrscheinlich gar nicht so schlecht. Muss es auch mal ausprobieren...

Ronny145
2013-10-06, 17:28:18
Irgendwann? Wie oft kommt die Maus genau in die eine Ecke?

aufkrawall
2013-10-06, 17:34:09
Bei mir häufig, etwa weil ich oben links ein nicht ganz unwichtiges Symbol hab.
Oder sei es, dass man aus Faulheit erstmal den Cursor grob in die Ecke knallt, um schnell oben links in der Menüleiste was zu wählen.

-/\-CruNcher-/\-
2013-10-06, 18:11:24
Man sollte sich die liste anschauen wer quicksync zu erst implementiert hat Bandicam könnt ihr in die tonne tretten ;)

wie viele andere auch ;)

Wer kostenloses alternative sucht is mit Unwinders Quicksync implementation bestens beraten ;)

Und wer drüber nachdenkt H.265 für Live Game Recording mit der CPU zu nutzen der hat sie nicht mehr alle beisamen weder mit Rovis(DivX) Encoder noch mit irgend einem anderen ;)

Mit Haswell wird Intel es anscheinend wirklich schaffen X264 zu killen nun steht praktisch nur noch Jasons Psy optimierung gegen Intel :)

Was intel da in der Zeit seit Sandy Bridge eingeholt hat ist irre Nvidia und AMD sollten echt Angst haben :)

Schon bemerkenswert was Intel in kurzer zeit aus dem Boden stampft

Zudem darf man nicht vergessen haben sie immernoch die NGV IP in der Schublade ;)

aufkrawall
2013-10-06, 18:36:58
Auf der Grafikkarte mit gesondertem Chip enkodieren, dürfte aber immer weniger Leistung kosten als QS. Da müssen die unkomprimierten Bilder über den Bus und etwas CPU-Leistung kostet es ansich auch.

-/\-CruNcher-/\-
2013-10-06, 18:43:23
Ich hab schon sehr extreme Quicksync Realtime workflows gefahren und das auf Sandy Bridge unterschätz Intel nicht, vor allem hatten sie als erstes nen Hardware Adaptive Lanczos4 Scaler (made in israel) ;)
Und ihr Motion Adaptive Deinterlacing ist auch nicht ohne, sie sind Nvidia und AMD in vielem weit voraus gewesen damals :)
Und mit ihren SDKs haben sie auch extreme aufgeholt :)

Einzige was man Intel übel nehmen kann das sie die Offset Engine damals gekilled haben in ihrem Larabee wahn und vieleicht die ein oder andere Wetbewerbsverzerrung in den Kaufhäusern gegen AMD ;)

Ronny145
2013-10-06, 20:54:00
Bei mir häufig, etwa weil ich oben links ein nicht ganz unwichtiges Symbol hab.
Oder sei es, dass man aus Faulheit erstmal den Cursor grob in die Ecke knallt, um schnell oben links in der Menüleiste was zu wählen.


Dann schieb es doch in eine andere Ecke.


Man sollte sich die liste anschauen wer quicksync zu erst implementiert hat Bandicam könnt ihr in die tonne tretten ;)

wie viele andere auch ;)

Wer kostenloses alternative sucht is mit Unwinders Quicksync implementation bestens beraten ;)



Warum kann man Bandicam in die Tonne treten? Ich sollte Afterburner, Bandicam, Mirillis Action und Movavi Screen Capture 4 auf Performance testen und danach die Qualität vergleichen. Crysis 3 sollte sich gut anbieten.

aufkrawall
2013-10-06, 20:56:50
Dann schieb es doch in eine andere Ecke.

Ungern. So ganz neu ist dieser Trick ja nicht und mein Eindruck von doom9 war, dass die meisten Leute diesen unpraktisch finden.
Wenn man nicht so oft konvertiert, kann man aber mit dem on demand einrichten wohl ganz gut leben und wer häufig QS nutzt, hat eh immer noch Win 8 als Option.

Ronny145
2013-10-06, 21:14:24
Warum ungerne? Beide Begründungen sind keine. Mit Windows 8 geht das nicht automatisch, die App muss QS im dx11 Modus laufen lassen.

aufkrawall
2013-10-06, 21:19:51
Warum ungerne? Beide Begründungen sind keine.

So oder so ist es ein Komfortverzicht. Akzeptier einfach, dass manche Leute das so sehen. Ich persönlich konvertiere auch so gut wie nie ein Video, schon deshalb ist es mir wayne.


Mit Windows 8 geht das nicht automatisch, die App muss QS im dx11 Modus laufen lassen.
Ok, ist ein Argument, das mir neu war.
Das sollte aber mittelfristig doch nicht das große Problem sein, beim MediaCoder Enkoder kann man die API wählen.

Ronny145
2013-10-07, 00:27:05
So oder so ist es ein Komfortverzicht. Akzeptier einfach, dass manche Leute das so sehen. Ich persönlich konvertiere auch so gut wie nie ein Video, schon deshalb ist es mir wayne.



Ich akzeptiere es natürlich. Mich interessiert der Grund. Wenn oben links ein Symbol sitzt muss man den zweiten Monitor nicht oben links in die gleiche Ecke setzen. Ungerne ist keine Begründung. Der Verweis auf doom9 ist ebenso keine Begründung. Ich kann bei mir keinen Komfortverlust festellen. In die 1 Pixel große Ecke komme ich nur wenn ich es drauf anlege.

Ich habe mir die Performance näher angesehen. Movavi Game Capture 4 war ein Reinfall. Erstens wird QS nur über Software unterstützt und zweitens gibt es keinen Aufnahme Hotkey, den man im Spiel betätigen könnte. Afterburner der nächste Reinfall. Deutlich langsamer als Mirillis Action und Bandicam. Afterburner ist nicht empfehlenswert in dem Zustand. Bleiben nur noch Mirillis Action und Bandicam. Beide ähnlich schnell +- 1 fps.


Das sollte aber mittelfristig doch nicht das große Problem sein, beim MediaCoder Enkoder kann man die API wählen.


D3d11 funktioniert im Mediacoder nicht. Außer es funktioniert nur unter Windows 8, was ich nicht testen kann.


Ja in der Tat ab Windows 8 nutzbar.


Direct3D11 acceleration - uses Direct3D11.1 accelerated encoding. This mode is only available under Windows 8 and newer OS. This mode doesn't require any monitor detection tricks so it is strongly recommended to use it if it is available (i.e. if you're under Windows 8).


Macht ja auch Sinn wenn das headless nativ erst ab Windows 8 unterstützt wird vom Betriebssystem. Afterburner würde das unterstützen, macht wegen der schwachen Performance nur kein Sinn. Vielleicht bessert sich das zukünftig noch.

-/\-CruNcher-/\-
2013-10-07, 19:13:06
Wow das hätte ich nicht von Unwinder erwartet, das er gegen Mirillis verliert (allerdings sind sie spezialisiert auf Video und kennen die OS bottlenecks in und Auswendig), sicher das du den test ordentlich durchgeführt hast vieliecht ein Bug schon geprüft wo die Performance hängt beim D3D Capturen oder beim Encoden selbst ? ;)

Macht mich neugierig jemanden wie Unwinder verlieren zu sehen müsste doch seinen Russischen stolz ankratzen gegen die Polen nicht mithalten zu können ;)

Bandicam scheint ja eine menge wett gemacht zu haben waren doch asiaten dahinter oder irre ich mich (waren es nicht chinesen) am Anfang war die Software doch grotenschlecht ?

Und naja die russen von Movavi waren immer schon mit vorne dabei aber ihre Software hat nie wirklich das gekonnt was sie überall versprochen haben (viel ffmpeg drin) auch mit dem Ganzen Intel partner marketing drum rum hallte nix von der Firma dahinter.

Interessant würde es werden wenn Cyberlink (taiwaner) sagen würde hey das machen wir jetzt auch so ne Gamer Recording Software mit GPU blimblim <- würde mich echt nicht wundern, könnte auch gut konkurenz für Mirillis Action werden, allerdings haben sie das NT6 WDM und D3D hooking knowledge nicht so ist ja nicht ihr gebiet denke aber mal das könnten sie schnell aufholen mit ihrem wissen ;)

Das der Dxtory macher (chinese) sich nicht sagt "hey was die alle können kann ich schon lange" wundert mich auch etwas immerhin hatt er da eine solide Hooking und Capture basis um Quicksync oben drauf zu setzen und würd ihn ja auch nix kosten ausser ein wenig zeit mit dem Media SDK :)

Stan (chinese) mit MediaCoder und seinem Mega ffmpeg und co workflow nee glaube nicht das er effizient WDM und D3D hooken könnte, aber er könnte ja was dazu kaufen ;)

Aber "Unwinder" das verwundert echt der hat extreme viel NT low level knowledge

Das selbe wie bei Dxtory gilt übrigens genauso für Fraps versteh ich nicht kostet sie nix aber interessiert sie anscheinend auch nicht, noch nicht Haswell abwarten ;)

test von mir damals auf Sandy Bridge ;) https://mega.co.nz/#!dlkkVbxb!THR2_Riobj0zKMlI12zWkiFnvjtdjP_TWT1cTqNkTVg

alles die Intel HD 2000 war schon beindruckend, ich meine seien wir mal ehrlich ausser abstürzende Games und schrott treiber kannte man von Intel bis dato nichts anderes und dann sowas :)

und dann schlägt ihr Flexibler Video Hardware Decoder auch noch so ziemlich jeden anderen und sie setzen einen Encoder oben drauf der nicht mal schlecht war für die Zeit zwar noch weit entfernt von X264 aber immerhin besser als AMDs und Nvidias resultate :D

Ronny145
2013-10-07, 19:36:35
Ich habe alles mögliche ausprobiert. Beim Afterburner lassen sich immerhin die Target presets einstellen, geht bei den anderen nicht. Aber das ist so viel langsamer in Crysis 3 und Project CARS, es bringt nichts. Keine Ahnung woran es liegt, vielleicht macht er bei der QS Implementierung was falsch. Bei den Konvertier Tools gibt es ja auch größere Unterschiede. In Handbrake und QSTranscode ist die CPU Last viel geringer als in anderen Tools. Als reines screenshot/capture Tools ist Afterburner übrigens eine Katastrophe, von der Aufmachung sind mir Bandicam und Action weitaus angenehmer zu bedienen.

Bei Bandicam ist der Sound nicht optimal. MPEG-1 zieht stärker an der CPU und drückt die fps, ich empfehle PCM mit Bandicam. AAC oder AC3 wäre sinnvoller statt MPEG-1. Mirillis Action scheint bei der Aufnahme noch einen tick flotter als Bandicam mit PCM zu laufen. Bandicam ist flexibler bei der Bitrate Auswahl, allerdings nur mit dem CBR Bitrate Modus. VBR mit freier Auswahl wäre sinnvoller. In Mirillis steht nur low, normal, high zur Auswahl. Für Playclaw 5 ist Quicksync Support geplant, sobald verfügbar probiere ich das aus.

klutob
2013-10-07, 19:58:27
^^Was meinst du mit langsamer beim Afterburner, Framerateeinbruch beim Recording? Habe mal kurz die Beta getestet (Win8) und war überrascht wie gut es funktionierte, Action erzeugt bei mir im Ggs. immer wieder Ruckler im Video.
Laut Afterburnerbenchmark reicht mein Ivy für ~70FPS@1080p.

Ronny145
2013-10-07, 20:08:25
Afterburner hat die fps viel stärker nach unten gedrückt während der Aufnahme.

-/\-CruNcher-/\-
2013-10-07, 20:33:37
Action ist technisch schon so das ziemlich beste es ist halt für Daus konzipiert deshalb wenig optionen ;)

Afterburner würde ich keinem neuling für sowas empfehlen es ist halt noch gute alte Rivatuner Base (System Analyse Sensor und GPU Management) MSI hat die ganzen Gamer zusätze (Capture, Recording haste nicht gesehen) von Unwinder abgefordert glaube nicht das er selbst die Richtung gehen wollte :)
Am ende hatte es den faktischen tot von Rivatuner zur folge :(

klutob interessantes differenz resultat zu ronnys :)

sehr wichtig bei der ganzen sache der Intel treiber und dessen media sdk komponenten natürlich ist Win8 und Win7 auch interessant im Vergleich bei sowas, sprich wirkt sich WDDM 1.2 im Vergleich zu WDDM 1.1 hier positiv aus für Win8 vor allem beim memcpy :)

Ronny145
2013-10-07, 21:28:02
Was soll sich da genau wie auswirken? Wenn es Performance Vorteile geben würde, wüsste ich das.

In Trine 2 ist Afterburner so schnell wie Bandicam, was zeigt das Afterburner die CPU stärker auslastet. In Trine 2 werden nur 1-2 Kerne ausgelastet, in Crysis 3 und pCARS ein Quadcore ziemlich stark auf 4 Kernen. Klutob hat vermutlich ein Spiel getestet, wo das aufgrund geringerer CPU Auslastung nicht ins Gewicht fällt.


In Trine 2 ist mir ein anderes Problem vom Afterburner aufgefallen. Afterburner erlaubt nur mkv als Format mit Quicksync. Das Format ist beschränkt auf 25 Mbps (der Slider geht auf 30 Mbps). Bandicam mit Qualität 100 kommt auf 93 Mbps. (Die Bitrate scheint von Spiel zu Spiel zu variieren mit Qualität x)


Bei ~70FPS@1080p ist nur die Software Implementierung aktiv, die läuft noch schlechter. Dann ist es fraglich, ob in Action Quicksync aktiv ist.

Gebrechlichkeit
2013-10-08, 13:55:33
Mal ganz off topic gefragt, welche Software (video edit) benutzt (ihr) Du fuer Bandicam, Ronny145?

Das Problem mit Bandicam ist der inkompatible Treiber, habe es mit ver. Trial Software ausprobiert, keines kann so richtig mit den Files umgehen (preview, cut etc..).
(moechte ungern ein Thread extra dafuer erstellen, evtl. wurde die Frage hier bereits gestellt...)

Thx

Ronny145
2013-10-08, 17:57:25
Keyframe Interval auf 1 stellen. VirtualDub kommt damit klar.

Und FourCC Code auf x264 stellen.

http://www.bandicam.com/support/tips/h264-fourcc/

aufkrawall
2013-10-11, 21:32:25
Selbst mit meiner SNB-IGP funktioniert auf Win 8(.1) ohne den Multimonitor-Trick QS-Dekoden via LAV und Enkoden via MediaCoder/Afterburner (DX11).
Gibt allerdings einen Bug im Intel-Treiber, 50p-Deinterlacing ist nur 25p. Auf Haswell geht das aber.

Ich hoffe, Handbrake zieht zeitnah nach mit dem DX11-Support.