[Übersicht] Intel - Haswell Info-Thread

nuts

Enthusiast
Thread Starter
Mitglied seit
24.12.2006
Beiträge
5.565
Hallo zusammen,

heute morgen habe ich überrascht festgestellt, dass die Intel Haswell CPU's schon verfügbar sind.
Ich persönlich verspreche mir davon sehr viel für den HTPC-Sektor und daher schonmal ein paar Infos die ich zusammengegoogelt habe.

Es wird mit GT1, GT2 und GT3 diesmal 3 GPU-Versionen geben.
Innerhalb der jeweiligen Klassen sind noch verschiedene Unterversionen geplant.

GT1 - "HD Graphics"
derzeit nicht verfügbar und habe auch keine Infos darüber.
Update:
Auch für die kleinste GPU Einheit gibt es jetzt verfügbare Prozessoren: http://geizhals.de/?cat=cpu1150&xf=1133_Pentium+G#xf_top
Einschränkung: kein Intel® InTru™ 3D Technology

GT2 - „HD Graphics 4200/4400/4600“
HD4600 wird in den derzeit verfügbaren i5 und i7 verbaut, die HD4400 gibt es ab i3 Prozessoren.
20 EU (Shader-Einheiten) sind verfügbar. Etwas mehr als die 16 im HD4000 (Ivy-Bridge), aber große Sprünge fürs Gaming würde ich da nicht erwarten.
Für den HTPC (bis auf madVR) aber sicherlich ausreichend. Speicherbandbreite für Adaptives-Deinterlacing (1080i) ist auch ausreichend vorhanden.
Update:
Auch für die HD4400 stehen ebenso 20 Shader-Einheiten zur Verfügung, die allerdings etwas langsamer getaktet sind.
Für den HTPC dürfte das kaum relevant sein. Decoding/Processing/Scaling passiert in CO-Prozessoren und für madVR reicht es so oder so nicht.


GT3 - „Iris Pro Graphics 5200“
Laut meinen Recherchen soll es diese Variante nur für Notebooks geben.
Eine Desktop-Variante (i7-4770R), allerdings fest verlötet auf dem Mainboard, scheint geplant zu sein.
Interessant bei den HD5200 Modellen ist, neben der doppelten Shader-Anzahl, der EDRAM.
Das ist ein L4 Cache, der eine deutlich höhere Speicherbandbreite ermöglichen sollte.
Die HTPC-Relevanz ist vermutlich nur für GPU intensive Anwendungen (madVR) gegeben.
Wieso die großen GPU's ausschließlich für den Notebook-Bereich angeboten werden ist mir trotzdem ein Rätzel. :wall:

24p Bug
Der erste Test von Anandtech sieht sehr vielversprechend aus.
Update:
Aussagekräftig Bilder @missingremote: Intel Core i7-4770K (Haswell) / Intel DZ87KLT-75K and Intel DH87RL Motherboard - First Look | Missing Remote
Sieht sehr gut aus! Ich prüfe das selbst noch mal aber der 24p Bug scheint Geschichte zu sein.
Update2:
Auch hier im Forum gibt es positive Berichte: http://www.hardwareluxx.de/community/f89/verstaendnisfrage-24p-bug-erklaerung-797983-29.html


RGB Output-Range (hdmi)
Leider hat Intel immernoch einen Fehler bei der Ausgabe von FullRGB 0-255 über hdmi.
Laut nevcairiel (LAV-Entwickler) funktioniert das bei Intel so: https://german.doom9.org/showthread.php?p=1633314#post1633314
D.h. der Benutzer kann nicht frei wählen ob 16-235 oder 0-255 ausgegeben werden soll.
Auch missingremote hat das in ihrem Test (Link s. 24p Bug) bestätigt.
Das ist aber ein reines Treiberproblem. Ich hoffe mal Intel bessert hier nach ...

Update:
@doom9 habe ich folgenden Hinweis gefunden: http://forum.doom9.org/showthread.php?p=1647801#post1647801
Anyone, who want FullRange RGB HDMI output on Intel Graphic may try this:
1. Find your current Intel Graphic Adapter software registry instance under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\xxxx
(0000 on my PC).
2.Create DWORD value:
EnableRGBFullRange
and set it to 1
3. Reboot.
4. Enjoy.
Mit meinem Ivybridge System funktioniert es. :d
Laut einem User im DVBViewer Forum funktioniert der Tweak auch für Haswell CPU's: http://www.dvbviewer.tv/forum/topic/49974-htpc-auf-ivy-bridge-basis/page-19#entry396635

Deinterlacing (Linux)
Gestern auch schon im OpenELEC-Thread geschrieben. Scheint so, als wenn mit den Haswell Chips auch unter Linux Temporal/Spatial Deinterlacing möglich wird:
One remaining problem was the deinterlacing support, to get low power chipsets like the Celeron 847 into being a multitalent. This point was ruled out lately. Timo Rothenpieler (Btbn) a longterm vaapi enthusiast implemented the first deinterlacer within xbmc for vaapi by using the VPP (Video Postprocessing API). It was possible by the changes introduced into libva and libva-intel-driver by Haihao Xiang. In the future, we will also deliver Temporal / Spatial deinterlacing, that has just been released for Intel Haswell. The Haswell Chip is actually already supported with our new vaapi driver packages, Temporal / Spatial deinterlacing will come later (if we find some hardware to actually test it).

Quelle

3D Wiedergabe (MVC)
Gibt es schon Infos welche GPU MVC-Quellen beschleunigen kann?

HD-Tonformate
Bitstream und PCM Ausgabe sollten für alle Modelle unterstützt werden.
Das war schon beim Vorgänger so, aber der Vollständigkeit halber sei es auch hier nochmal erwähnt.

GPU Leistung (madVR)
Wirklich spielen wird man auch mit der neusten Variante nicht können, aber für einen HTPC sollte das auch eine eher untergeordnete Rollen spielen.
Daher möchte ich hier eigentlich Erfahrungswerte mit madVR zusammenfassen.
Jinc3+AR wäre schon nett, aber ob das realistisch ist?
Eine Aussgae vom LAV-Entwickler habe ich schon gefunden: madVR - high quality video renderer (GPU assisted) - Page 957 - Doom9's Forum
On 720p24, scaling to 1080p:

Luma Jinc3+AR / Chroma Jinc3+AR => too slow
Luma Jinc3+AR and Chroma Bicubic75+AR => works

Adding smooth motion overloads it again.

Erste Ergebnisse von missingremote: missingremote.com HD-4600-madVR Test
Lanczos tab3+ AR ist möglich, aber erwartungsgemäß kein Jinc3+AR mit dem HD-4600!
Vielleicht schaffts es ein GT3 Modell? Das würde die NUC dann sehr interessant machen.

Leider auch kein Jinc3+AR mit HD5000 missingremote Intel NUC Test

Quicksync
Ab Haswell gibt es die Möglichkeit verschiedene Qualitätsstufen für die Encodierung auszuwählen.
Die Qualität spielt eine wesentliche Rolle bei der Geschwindigkeit.
Sehr interessant und es gibt auch erste freie Projekte mit Quicksync:
Handbrake

Einen quicksync basierenden Decoder findet ihr hier:
Intel QuickSync Decoder - HW accelerated FFDShow decoder
Auch der LAV-Filter verwendet diesen Decoder.

Treiber
Version: 15.31.17.3257 / 15.31.17.64.3257
ReleaseNotes
32bit
64bit
Betatreiber (computerbase.de)

Weiterführende Links
Computerbase - Intel „Haswell“-Grafik für Desktop-PCs im Test
AnandTech | Intel's Haswell - An HTPC Perspective: Media Playback, 4K and QuickSync Evaluated
hardwareluxx - Intel Haswell (Sockel 1150) Gerüchte + FAQ + Infos
Anandtech Haswell GPU Performance

Solltest ihr interessante Infos über "Intel Haswell" haben übernehme ich die gerne.
Mit den ersten Systemen hier im Forum wird man sich auch etwas genauere Infos zu den einzelnen Punkten aufnehmen können.

Gruß nuts
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es gibt doch schon nen Sammler hier im Luxx??

Aber verstehe natürlich, dass der HTPC Fokus ein anderer ist.
 
Zuletzt bearbeitet:
Im HTPC-Bereich?

edit\ Habe den Sammelthread hier im Forum im Startpost verlinkt.
Wie die Unterpunkte zeigen soll hier der Schwerpunkt auf den HTPC-Eigenschaften liegen.
Ein eigener Thread dafür scheint mir durchaus gerechtfertigt. ;)
 
Zuletzt bearbeitet:
Der Vollständigkeit halber:

Auch der freie MediaCoder unterstützt Quicksync.
Aha, neue Qualitätsstufen für Quicksync. Sehr interessant.
Unterstützt dass dann auch endlich 2 pass?
Im Vergleich zu 2 pass x.264 Encoding, ist Quicksync mit fester Bitrate nämliche eine ganze Ecke schlechter.
Intel ist ja der Meinung dass man bei Quicksync kein 2 pass brauchen würde und dass Ergebnis mit Quicksync und fester Bitrate genauso gut wäre. Dass ist nach meinen Tests und Beobachtungen Marketing-Blödsinn.


Gibt es schon Infos welche GPU MVC-Quellen beschleunigen kann?

Mich würde da eher interessieren welche akuelle Intel CPU dass nicht kann.
Es gibt da ja jemanden der glaubt, dass selbst ein Core i 3 dazu in der Lage wäre.
Ich bin da eher skeptisch. Siehe nuc-Thread...


24p Bug:

Sollte dieser wirklich bei den Haswell CPUs nicht mehr vorhanden sein, was zu diesem Zeitpunkt reine Spekulation ist, hätte Intel ja nur geschlagene vier CPU-Generationen gebraucht um diesen Bug endlich zu beseitigen.
Man möge mir nach sehen, dass sich meine Begeisterung deshalb eher in Grenzen hält. Eine große Leistung wäre dass jedenfalls nicht, ganz im Gegenteil, es ist schon seit drei CPU-Generationen überfällig!

Gruß
hd
 
Zuletzt bearbeitet:
Hast du einen Link zum "Mediacoder"?

Genaue Infos wie Quicksync beim encodieren vorgeht habe ich nicht.
Denke auch nicht das es eine low-level API geben wird, sondern nur grobe Steuerungsmöglichkeiten.
Aber immerhin! Fürs Streaming auf mobile Geräte ist das ziemlich interessant.

@3D
MVC über CPU wird mit einem ausreichend starken Prozessor immer funktionieren.
Mir gehts es hauptsächlich um die GPU-Unterstützung.
 
Hallo nuts!

Hier ein Link zum MediaCoder: MediaCoder - more than a universal audio/video transcoder - MediaCoder official website
Ist soweit ich das verstanden habe ein freies Projekt. Es gibt davon eine freie Version (diese benutze ich) und wohl auch eine kostenpflichtige.
Auch die freie Version unterstützt Quicksync.

Genaue Infos wie Quicksync beim encodieren vorgeht habe ich nicht.

In einem Intel Forum hatte ich dazu einen Thread gelesen, in dem sich ein Benutzer beschwert hatte, dass Quicksync kein 2pass Encoding unbterstützt.
Ein Intel Mitarbeiter antwortete darauf, mit irgendwelchen mir nichts sagenden Technokratie-Geblubber, weshalb Quicksync kein 2 pass brauchen würde und das Ergebnis trotzdem genauso gut wäre, als wenn man etwas mit z.b mit 2 pass enkodieren würde.
Der fragende Benutzer wollte dies nicht so recht glauben, da er andere Erfahrungen hatte und auch mir ging es ähnlich, weshalb ich das Gegenprüft hatte und ebenfalls zu anderen Ergebnissen gekommen bin.


Gruß
hd
 
Zuletzt bearbeitet:
Mal meine persönliche Meinung zum Thema "encoding":

Die Haltung der x264 Entwickler gegeüber den GPU-gestützten Methoden kann ich ehrlich gesagt wenig nachvollziehen.
Das man den "state of art" Encoder in einen dedizierten Chip gießt ist wohl kaum möglich.
Trotzdem bietet z.B. Intel mit Quicksync eine Möglichkeit ein ganz gutes Ergebnis mit geringem Aufwand zu bekommen.
Quicksync ist schnell und ist dabei sehr effizient!
Für Live-Quellen oder Anwendungen bei denen es nicht auf das letzte bisschen Qualität ankommt ist das sehr wohl sinnvoll einsetzbar.
 
Sicherlich mögen die Haswell schon erhältlich sein, aber nur Core i5 und i7, die ja für einen reinen HTPC aber eher
uninteressant sind, da überdimensioniert. Und nach den ersten Tests bei CB kann ich keinen wirklichen Vorteil für
den HTPC-Bereich im Vergleich zu Ivy Bridge erkennen. Ich denk mal, erst wenn die Core i3 Haswell da sind,
wird man sehen, ob es was für den HTPC bringt. Für mich ist aber immer noch der 24p-Bug der Knackpunkt.
 
aber nur Core i5 und i7, die ja für einen reinen HTPC aber eher uninteressant sind, da überdimensioniert.
Überdimensioniert schon, aber preislich ist der Core i5 4570T mit 170 Euro sicherlich nicht die schlechteste Wahl gegenüber einem i3 mit zu erwartenden 110-120 Euro. 50-60 Euro kann man vielleicht schon investieren. Vor allem, da der i5 laut ark.intel.com alle Intel Sonderlocken (Wireless Display, Natives AES Encoding, VT-d, etc.) frei geschaltet hat.

Ich habe einen i5 3470T (Ivy) und die Investition hat sich in Kombination mit dem DQ77KB Board allemal gelohnt. Schade, das es noch nicht so ein Board für Haswell gibt. Hoffentlich kommt da noch was.
 
Zuletzt bearbeitet:
Wofür braucht es 2-pass bei average Bitrate encoding oder CQP/CFR? Das wäre nur für konstantes Encoding nutzvoll, würde allerdings wiederum die Geschwindigkeit deutlich senken. Ich wüsste jetzt nicht wozu constant noch nützlich wäre. Average encoding sieht mit Quicksync deutlich besser aus und läuft genauso schnell.
 
Wofür braucht es 2-pass bei average Bitrate encoding

Überhaupt nicht. Scheinbar kam das missverständlich rüber. Quicksync unterstützt nämlich überhaupt keine variable sondern nur eine average bitrate!
Genau dass ist ja das Problem und somit kann Quicksync auch kein 2 pass. Dass sollte aber mittlerweile bekannt sein.

Average encoding sieht mit Quicksync deutlich besser aus und läuft genauso schnell.

Das ist nach meinen Tests und Beobachtungen falsch! Es ist eben eine ganze Ecke schlechter, als wenn ich das gleiche Material mit variabler Bitrate und 2 pass enkodiere.
Im Grunde ist Quicksync nur eins, nämlich schnell, dass war es dann aber auch schon.
Ich gehe in soweit konform, dass es wohl Szenarien gibt, wo es nicht auf das letzte bisschen Qualität ankommt und in diesen kann Quicksync seinen Geschwindigkeitsvorteil ausspielen.
Wenn es aber auf Qualität ankommt, führt immer noch kein Weg an 2pass mit variabler Bitrate vorbei.

Gruß
hd
 
Überhaupt nicht. Scheinbar kam das missverständlich rüber. Quicksync unterstützt nämlich überhaupt keine variable sondern nur eine average bitrate!
Genau dass ist ja das Problem und somit kann Quicksync auch kein 2 pass. Dass sollte aber mittlerweile bekannt sein.


Das ist falsch. Quicksync unterstützt eine variable Bitrate. Unterstützt wird folgendes:

MFX_RATECONTROL_CBR Use the constant bitrate control algorithm
MFX_RATECONTROL_VBR Use the variable bitrate control algorithm
MFX_RATECONTROL_CQP Use the constant quantization parameter algorithm
MFX_RATECONTROL_AVBR Use the average variable bitrate control algorithm


Das ist nach meinen Tests und Beobachtungen falsch! Es ist eben eine ganze Ecke schlechter, als wenn ich das gleiche Material mit variabler Bitrate und 2 pass enkodiere.
Im Grunde ist Quicksync nur eins, nämlich schnell, dass war es dann aber auch schon.
Ich gehe in soweit konform, dass es wohl Szenarien gibt, wo es nicht auf das letzte bisschen Qualität ankommt und in diesen kann Quicksync seinen Geschwindigkeitsvorteil ausspielen.
Wenn es aber auf Qualität ankommt, führt immer noch kein Weg an 2pass mit variabler Bitrate vorbei.

Gruß
hd


Ich habe zig Tests angestellt und kann dir versichern, CBR kann qualitativ gegen VBR nicht anstinken, was keine sonderlich große Überraschung darstellt. 2pass ist völlig sinnlos für Quicksync. Deine Einschätzung zu Quicksync ist mit Haswell überholt. Die Qualität ist nach meinen ersten Tests beachtlich gestiegen. Die Qualität kann je nach Video fast bis medium x264 Qualität erreichen oder sogar besser. Ich habe gerade ein Video am Wickel was mit Quicksync Balanced besser aussieht als x264 Medium. Dazu dir enorm schnellere Encoding Geschwindigkeit und der niedrigere Verbrauch.
 
Das ist falsch. Quicksync unterstützt eine variable Bitrate. Unterstützt wird folgendes:

Nö, soweit ich das noch in Erinnerung habe, hat variable Bitrate hat mit qs noch nie funktioniert und ich glaube auch gelesen zu haben, dass Intel dass auch sagt.
Du kannst es gerne mal mit MediaCoder ausprobieren. Wenn sich das natürlich zwischenzeitlich geändert haben sollte, ist es etwas anderes.

Ich habe zig Tests angestellt und kann dir versichern, CBR kann qualitativ gegen VBR nicht anstinken,

Dieser Meinung bin ich doch auch...


2pass ist völlig sinnlos für Quicksync.

Weiss ich nicht. Was ich aber weiss ist, dass q.s kein 2pass unterstützt...

ch habe gerade ein Video am Wickel was mit Quicksync Balanced besser aussieht als x264 Medium

Jedoch nicht besser als mit x.264 2pass in Medium. Ich habe es wie gesagt getestet. Da Enkoding für mich wichtig ist, war die CPU-Emtscheidung für meine Workstation auch kein Zufall...

Dazu dir enorm schnellere Encoding Geschwindigkeit

Das habe ich qs bereits zugestanden. Ein etwas höher Verbrauch mit x.264 2pass als mit qs, ist mir die bessere Qualität durchaus Wert. Ansonsten spare ich schon Energie ohne ende, da ich mit der Workstation noch nicht einmal zocke...

Gruß
hd
 
Nö, soweit ich das noch in Erinnerung habe, hat variable Bitrate hat mit qs noch nie funktioniert und ich glaube auch gelesen zu haben, dass Intel dass auch sagt.
Du kannst es gerne mal mit MediaCoder ausprobieren. Wenn sich das natürlich zwischenzeitlich geändert haben sollte, ist es etwas anderes.


VBR wird schon seit einiger Zeit unterstützt. Natürlich funktioniert das. Wer sich ein bisschen damit beschäftigt, sollte das wissen. Probiere es mit Handbrake oder QSTranscode aus. Es kommen immer wieder neue Sachen ins SDK. Logisch das manche Sachen anfangs noch nicht drin waren.

Jedoch nicht besser als mit x.264 2pass in Medium. Ich habe es wie gesagt getestet. Da Enkoding für mich wichtig ist, war die CPU-Emtscheidung für meine Workstation auch kein Zufall...


Ich halte 2-pass mit VBR/CFR/CBR für unnütz. Benutze ich nie für x264.


habt ihr überhaupt mal die handbrake beta cs getestet?
#56 http://www.hardwareluxx.de/communit...oder-intel-cineformstudio-gopro-960326-3.html

die quali hat da massiv zugelegt,selbst mit sandy!


Für Ivy Bridge schon. Mit Haswell gibt es derzeit noch ein paar Probleme. Referenz ist QSTranscode für Haswell, allerdings ist das Programm nicht sehr komfortabel zu nutzen. Qualität mit Haswell hat schön zugelegt in meinen ersten Tests. Handbrake wird das noch in den Griff bekommen.
 
Zuletzt bearbeitet:
ist ja alles noch jungfräulich mit haswell.bei sandy/ivy hätten sie es aber schon früher bringen müssen.das rad ist ja nicht komplett neu erfunden worden dabei.naja,watt solls...
 
VBR wird schon seit einiger Zeit unterstützt.

Scheint so, habe es mir nochmal im MediaCoder angeschaut. Dabei habe ich auch gleich wieder den Grund gesehen weshalb ich es nicht verwenden kann!:
Man kann die Endgröße des Ergebnisses nicht mehr angeben sondern nur einen Prozentwert für die "Video Quality". Ich habe keine Ahnung wie stark der Einfluss dieses Parameters Einfluss auf die Zielgröße hat
So kann ich nicht arbeiten, da ich gewohnt bin, eine feste Zielgröße einzugeben und da ich diese Methode Klasse und Ergebnisorientiert finde, denke ich auch gar nicht daran, mich auf irgend etwas anderes umzustellen!

Ich halte 2-pass mit VBR/CFR/CBR für unnütz.

Da kann man wohl geteilter Meinung sein. Ich sehe es nicht so.


Gruß
hd
 
Zuletzt bearbeitet:
MediaCoder hat mich nicht überzeugt. Recht langsam im Vergleich zu den richtig guten. Das Decoding läuft nicht über Quicksync, ich denke dort verschenkt MediaCoder einiges. Qualität auch eher so mittelmäßig. Ich muss mal testen, wie das mit Haswell jetzt aussieht. /immer noch lahm und hohe CPU Last wegen fehlendem hardware decoding, SDK lange nicht aktualisiert. Mit VBR gibt es eine Fehlermeldung....für die Tonne.
 
Zuletzt bearbeitet:
Recht langsam im Vergleich zu den richtig guten. Das Decoding läuft nicht über Quicksync, ich denke dort verschenkt MediaCoder einiges

Ähm, No Sir! Auch wenn ich da vielleicht etwas verwechsle, aber natürlich läuft das Decoding sowie auch auch das Encoding über Quicksync. Das funktioniert aber nur mit average Bitrate. Also genau dass was ich sage...
Ich sehe den Geschwindigkeitsunterschied doch deutlich! Material dass mit 2pass vbr x/h.264 zwei Stunden braucht, ist mit Quicksync in ca 30 Minuten durch.
Das da Abstriche bei der Qualität zu machen sind, ist fast schon logisch. Noch kommt eben nichts an 2pass vbr ran.

Qualität auch eher so mittelmäßig

Nachdem ich mich da etwas eingelesen hatte, komme ich damit eigentlich gut klar.

Jetzt noch mal zu den "richtig guten"!: Die kosten meines Wissens Geld, was den Mehrwert von Quicksync wieder sehr schmälert, wenn man, um es zu benutzen extra noch Geld für die richtig guten ausgeben muss!

Gruß
hd
 
bei handbrake hatte ich 600-700 fps u. brauchte für nen 1h 47min film 3,5min bei quali auf 2pass eigenprofil niveau.das hätte ich niemals erwartet.wenn man die größe der soundquelle kennt zb. mit mediainfo kann man sehr wohl die endgröße hinterher selber bestimmen mit nen calculator.ich allerdings habs bei 1200 bit gelassen,weil da die quali bei x264 u. auch qs in handbrake durchweg sehr gut war.drunter wars mal so,mal so.

1200 u. cf 20 waren auf selben niveau quali,meistens gleich groß bzw. für mich die passende balance zwischen quali/größe.

für handbrake muss man nix zahlen...
 
Zuletzt bearbeitet:
bei handbrake hatte ich 600-700 fps u. brauchte für nen 1h 47min film 3,5min bei quali auf 2pass eigenprofil niveau.
Vielleicht kommen wir mal zurück zum Thema und ihr macht einen eigenen Thread auf?
 
Wieso? Das Thema ist doch sehr interessant. Eventuell sollte man es aber in einen extra Thread auslagern.

Bis jetzt gab es keine Ausfälle und es wurde sachlich Diskutiert.

Ich finde es nur schade das Handbrake aktuell nur qs bei der Win Version anbietet, mein VDR wandelt nämlich alle Aufnahmen automatisch mit Handbrake nur ist das ein Linux Rechner.
 
Zuletzt bearbeitet:
@madaal

wenn man die größe der soundquelle kennt zb. mit mediainfo kann man sehr wohl die endgröße hinterher selber bestimmen mit nen calculator.

Genau so etwas möchte ich nicht. Ich möchte die genaue Zielgröße vorher eingeben können, alles andere ist mir nicht exakt genug und enduserfreundlich ist es auch nicht. Ich hantiere nicht mit einem bitrate-rechner und spekuliere anhand der Soundquelle wie groß das Endergebnis vielleicht werden könnte.

für handbrake muss man nix zahlen...

Dass weiss ich. Handbrake ist das zweite kostenlose Programm nach MediaCoder das QuickSync unterstützt, dann wird die Luft auch schon dünn!
Ich habe über Handbrake gelesen, dass es sehr umständlich zu bedienen sein soll, weshalb bis jetzt MediaCoder für mich das Programm der Wahl war.
Hb werde ich mir vielleicht mal näher anschauen.

Gruß
hd
 
Ähm, No Sir! Auch wenn ich da vielleicht etwas verwechsle, aber natürlich läuft das Decoding sowie auch auch das Encoding über Quicksync.


Nein läuft es nicht im MediaCoder. Lies dich doch mal ins Thema ein bevor du planlos irgendwas in die Welt setzt. Es gibt zwar eine Art Trick für den Mediacoder, um das Decoding über Quicksync laufen zu lassen, aber der funktioniert höchstens mittelprächtig.
 
Lies dich doch mal ins Thema ein bevor du planlos irgendwas in die Welt setzt.

Was wäre denn das Thema? Enkoding generell? Da habe ich mich eingelesen, dass ist es aber nicht.
Es geht hier im Grunde doch nur darum, welches kostenloses Programm mit QuickSync funktioniert und da gibt es eben nur zwei die mir bekannt sind.
Weshalb da noch groß einlesen wenn die Fakten zu QuickSync bereits fest stehen?:
So gut wie kein kostenloses Programm unterstützt es und für die "richtig guten" muss man löhnen.
Die Qualität kommt nach meinen Versuchen nicht an 2pass vbr ran.
Viel mehr neue Erkenntnisse gibt es da für mich zu gewinnen und das Rad wegen QuickSync neu erfinden zu wollen, überlasse ich anderen.

Gruß
hd

Nachtrag:
Also ich bin mit MediaCoder eigentlich super zufrieden. Knapp 10 Minuten für das enkodieren eines 90 Minuten Films mit 2pass vbr. Damit kann ich leben!
Man schaue ich mal den Screen an! Bei Outputsize kann man auch schön die Zielgröße eingeben.
Also nix mit einem Bitrate-Calculator hantieren und anhand der Soundquelle die Zielgröße schätzen. Mann kann es so auf das Megabyte genau bestimmen. Genau dass habe ich mit meinen Ausführungen zu diesem Aspekt weiter oben auch gemeint. So ist es auch benutzerfreundlich! Alles andere scheidet für mich schon aus Prinzip aus, da ich sehe, wie einfach es sein kann, die Zielgröße zu bestimmen!
prove.jpg


Gruß
hd
 
Zuletzt bearbeitet:
Ich denke sowohl die CPU alsauch die GPU gestützten Methoden haben beim Encodieren ihre Daseinberechtigung.
Ob man das hier in aller ausführlichkeit diskutieren muss weiss ich nicht, aber wenn schon dann bitte mit Quellen damit man nicht jeden Post nachprüfen muss ...
Mediacoder verwendet imho FFMpeg als Decoder (d.h. per CPU), aber lässt sich auch auf andere Decoder einstellen (z.B. FFDShow mit Quicksync).
Quicksync sehe ich z.B. in kleinen Server, die Mediaquellen in Echtzeit auf mobile Geräte streamen.
Dafür ist die Qualität sicher ausreichend und durch die hohe Effizienz bleibt der Server schön sparsam und kühl.

Ich hab im Starpost mal einen ersten madVR Hinweis eingefügt.
Wenn man bedenkt, dass die großen Iris Pro Graphics 5200 die doppelte Shader-Power und eine höhere Speicherbandbreite haben, wird man damit wahrscheinlich auch richtig aggressive madVR Eintellungen wählen können. Gefällt mir! Ich hoffe Intel besinnt sich und bietet diese Variante auch für den Desktop ...
Zumindest in neuen NUC sollen die ja kommen: http://www.hardwareluxx.de/community/f89/intel-next-unit-computing-nuc-929777-7.html

Anderes Thema: Ich hab mal einen Unterpunkt für die Treiber eingefügt.
Wie funtkioniert das bei Intel mit den Beta-Treibern? Gibt es dafür eine offzielle Bezugsquelle?
 
Zuletzt bearbeitet:
quicksync kann auch gut fürs gaming u. gleichzeitig streamen herhalten.das wird schon viel gemacht!

dude,sicherlich ists besser wenn zielgröße genau im programm eingebaut ist.ich habs aber unter 1200 nicht hinbekommen durchweg gute quali zu erzeugen.
da ich vorzugsweise dts o. ac3 durchschleife in mkv waren die zielgrößen zu 99% bestimmbar.wenn man mit aac arbeitet sollten eigentlich nach nen paar encodes die größen sehr gut abschätzbar sein aus erfahrung.mediainfo hilft da ungemein nen blick für zu bekommen.ich bin aber von mb genaues encoden abgerückt u. für mich war zielgröße 1000-1500mb mit ac3/dts zielgebend.nen 3,5h effektfilm bekommste eh zu 99% nicht in die größe hin.2pass ist sicherlich vorzuziehen bei maximal kleiner größe,weils kalkulierbarer ist als cf.

wenn man nun die entwicklerempfehlung von handbrake von cf 18-20 liest u. das man nicht so auf die größe achten sollte für gute encodes stößt es natürlich erstmal sauer auf.nur ohne grund kommt diese aussage sicherlich nicht,weils auch einfach ne technische limitierung von h264 gibt wieviel größe man bei maximaler quali herrauszaubert.ich bin mir sicher das cracks das sicherlich noch besser hinbekommen wie ich, aber jetzt mal nen beispiel zu handbrake.

mein eigenprofil x264:

2 pass,non turbo,average bitrate 1200 profil=high:level=3.1:ref=5:bframes=4:b-adapt=2: direct=auto:me=umh:subme=9:merange=24:trellis=2

4.1 bei hd

das ist sehr gute quali,der rattert sich aber zb. bei dvdgrößen 1-1,5h bei 90-110 minuten längen ein ab.

mit der qs handbrake version bekomme ich bei max. quali setting 4.1 u. 1200 bit genau das selbe ergebnis o. besser in 3-4 minuten durch.
balzon hatte mich drauf hingwiesen in dem hier geposteten thread.da gabs erst hickhack zwischen uns, war dann aber sehr erstaunt übers ergebnis weil ich ihm das nicht glauben wollte.

bei der handbrake version muss man nur den qualiregler nach rechts schieben,3.1 o. 4.1 u. bitrate angeben fürs video.einfacher gehts nicht.was allerdings noch etwas buggi bei allen aktuellen handbrakeversionen ist,ist das nacheditieren aus der que.manchmal nimmt es die nr raus,manchmal nicht.

wer etwas erfahrung mit encoden hat,sollte aber immer mit handbrake klar kommen.wie balzon sagt soll mediaencoder nicht an die quali von handbrake u. qsencode dran kommen.

encoden ist immer das finden von einen kompromiss.lasst euch mal auf den kompromiss von anderen encodern ein.

da entgeht euch was!

beim freemake encoder zb. ist cuda support mit drin.ich hab mir mal die gpu last vom sli u. takt/temps angeschaut.es läuft bei nen encode intervallmäßig 10-25% gpulast ohne temp u. takt anstieg ab.vermutlich hält cuda da nur fürs decoden her.

ich halte aber generell den momentanen stand von gpuencode für überbewertet.meine meinung dazu ist das decoden generell nicht das meiste an leistung beim encode zieht u. es praktisch egal ist,wer das nun macht o. welcher decoder verwendet wird.

gpuencode gibt es momentan eher nicht.es läuft auf nur decodierarbeit u. pseudoencoden(tatsächlich cpu) hinaus.

vegas zähle ich jetzt mal nicht dazu.

balzon,haste eigentlich 600-700 fps mit dem haswell jetzt hinbekommen?:lol:
 
Zuletzt bearbeitet:
Vielen Dank für Deine Ausführungen zu diesem recht interessanten Thema wie ich finde.

ich habs aber unter 1200 nicht hinbekommen durchweg gute quali zu erzeugen.

Das entspricht weitgehend auch meinen Erfahrungen. Kommt dann halt eben auf den Einsatzzweck an. Bei einer aus dem TV aufgenommen Doku muss nicht das letzte Quäntchen Qualität ausgepresst werden, da reichen auch deutlich kleinere Zielgrößen. Wohl aber Ansichts und wahrscheinlich auch Geschmacksache.

Natürlich kann man sich auf die ein oder andere Weise die Zielgrößen kalkulierbar machen. Nur ist es weder schön noch besonders benutzerfreundlich. Die Zielgröße direkt eingeben und bestimmen zu können und der Codec setzt es dann um, halte ich mittlerweile für state of the art.

encoden ist immer das finden von einen kompromiss.lasst euch mal auf den kompromiss von anderen encodern ein.

da entgeht euch was!

Hast ja recht, im Moment sieht es wohl so aus, als ob ich nicht drum rum kommen würde, mich mal mit Handbrake zu beschäftigen.
Dann mal auf zum Enkoden;)


Gruß
hd
 
auf,auf...:)

mach mal nen paar testsencodes nur um sich die quali anzuschauen.dafür lohnt sich das schon.dann willste auch gar nix anderes mehr haben:xmas:

ja,es gibt sicherlich bereiche wo es nicht so auf quali ankommt.nur meistens dann auch nicht auf die größe.ich mein jetzt temporäres speichern.

ich ging von end-langzeitspeichern aus.da hat natürlich jeder auch eigene ambitionen bzw. vorlieben was für ne quali bei welchen material.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh