Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenGeht der 265 überhaupt schon für YT?
Nein.
Aber das Äquivalent dazu (VP9) geht schon. Und das kann FFmpeg und somit auch Shotcut nutzen.
Dauert aber extrem lange. Genauso als würde man mit HVEC (h265) kodieren.
Damit buttert ihr nur unnötig Zeit rein und im Endeffekt sieht das Video nicht besser aus als das H264 Video.
Der Server würde in keine Rechenzentrum stehen
Das war mir schon klar und habe es daher auch berücksichtigt.
3. Auf dem Server in Premiere alles fertig schneiden etc.
4. Auf dem Server das Rendering starten
Diese Möglichkeit hatte ich dir auch genannt.
Problem ist halt das du keine Grafikkarte auf dem Server dann haben wirst, laut deiner Aussage aus dem Startpost.
Heißt: Der Encoder ist dann fertig und wartet womöglich auf die Frames, weil die CPU die Frameneuberechnung (Rendering) nicht schnell genug macht.
Weil wie schon oben geschrieben ist es die GPU die die Neuberechnung schnell macht, damit der Encoder sich nicht langweilen muss.
Fazit: Die GPU beim Rendering hat schon seine Daseinsberechtigung. Weil es halt parallelsierbar ist.
Wenn die CPU das nun macht, dann Staut sich der Kram noch mehr. 
Sprich der Kolben in der Sanduhr wird immer größer. Und die Zeit das der Sand durchläuft auch.
Also: Wenn du schnell Encodieren willst mit so ein Bearbeitungsprogramm, dann ist halt eine GPU für das Rendering schon von Vorteil. Zumal du ja auch Zeit sparen möchtest.
Oder du sagst halt wirklich das alles auf CPU laufen soll. In diesem Falle müsste man dann A) schauen ob Premiere überhaupt only CPU Fähig wäre ohne Grafikeinheit und B) ob sich das Zeittechnisch so negativ auswirkt das du selbst sagst das es dir so nicht rechtens ist.
Kannst halt auch AVISynth dann in diesem Falle verwenden und MeGUI. AVISynth als CPU Renderer und MeGUI mit sein x264 als CPU Encodierer.
Ich denke mal letzteres würde sogar um einiges Effizienter dann laufen, wenn keine GPU auf dem Server ist.
Durch das render und encoden ist meine CPU Last bei 60-70% was bedeutet dass ich keine weiteren Aufnahmen machen kann während mein Premiere das Video rund macht.
Ich will es eigentlich so hinbekommen, dass ich gleichzeitig aufnehmen und mein Video fertig machen kann Da war halt jetzt die 2. Idee mit dem kleinen Server
Ich weiß jetzt nicht wie du den Media Encoder einstellen kannst das dein Zeug in der Warteschlange steht und auf einem anderen Rechner (dein Server) encodiert werden kann.
Aber zu 100% kann ich dir schon mal sagen das der Render Prozess auf deinem PC stattfinden wird und nicht auf dem Server PC. Soviel kann ich dir jetzt schon halt sagen, sofern du weiterhin Premiere verwendest und die Premiere eigenen Sachen.
ABER es gibt für dich eine simple und recht ansprechbare Lösung die A) 100% funktioniert und B) effizient laufen würde.
Als erstes bräuchtest du einen Frameserver der die Daten von A nach B leitet (Am besten machste das mit nem festen stationären LAN-Kabel und zwei Netzwerkkarten die zusammen eine ordenliche Übertragung gewährleisten.)
Frameserver wären z.B. der DebugMode Frameserver oder der Advanced Frameserver
Einer davon geht auf jedenfall mit deinem Adobe.
Und dann brauchst du auf deinem Server ein Encoder System/GUI. z.B. MeGUI oder FFmpeg oder xMediaRecode oder oder oder...
Das Ganze hat ein Nachteil dann auch: Es wäre keine Batchfunktion möglich. Also mehrere Projekte hintereinander würde nicht gehen.
Und natürlich der Nachteil das das Rendering immer noch, wie oben geschrieben schon, auf deinem primär PC ablaufen würde.
Das wäre eine Möglichkeit.
ODER
Du machst dein Rendering + Encoding auf dem Server PC, aber dann musst du auf deinem Server PC die Bearbeitung machen. Sprich du müsstest die Videos zum Server PC übertragen.
Andere Möglichkeiten gibt es dann nicht mehr.
Und ja das sind meine jetzigen Einstellungen, und es läuft erst einmal irgendwie
Hatte ich eben schon erwähnt. Eine Möglichkeit effizient zu Encodieren wäre das Video über einen Frameserver an ein Drittprogramm zu übergeben. Sprich das Rohe Video aus Premiere raus und z.B. in MeGUI encodieren lassen oder in FFmpeg.
Wäre eine Möglichkeit.
Die zweite effiziente Methode wäre die Nutzung von x264vfw
Nach der Installation von dessen kann man diesen Codec als VFW Codec auswählen.
Weitere Infos zur Einstellung und Herangehensweise findest du hier: x264vfw für Videoschnittprogramme
Würde sich deiner Meinung nach der Server mit Dual Xeon lohnen?
Wenn du sowas wie eine Art Auto Encoder machen möchtest, ja.
Aber dann frage ich mich wozu du dann Premiere nutzen willst noch?
Weil für so ein Auto Encoder reicht an sich ein CMD Encoder wie x264, FFmpeg oder dergleichen.
Weil verstehe grad den Grund nicht warum du auf einen Server kommst? Ein Server ist doch ein 2tes Gerät. Ein 2ter separater PC sozusagen wo dann deine Software von wegen Website etc drauf ist.
Verstehe da noch nicht was da dein Premiere noch mittendrin soll
Dann verzichteste doch auf die GPU wieder irgendwo wenn das auf dem Ding alles laufen soll.
Wie gesagt... komm da mit deiner Logik noch nicht ganz mit was du vor hast
Hier einmal meine Einstellungen:
Einstellungen 1
Einstellungen 2
Ohje. WMV9. Bitte sag mir das du ein Joke machst
Sofern du den Standard Mainconcept Encoder von H264 nutzt in Premiere und solange Premiere seine Urgestein rudimentären Einstellungen dir präsentiert, bei denen selbst ein echter Profi verzweifeln würde, würde ich sagen das es ein nicht ganz so effizienter Weg ist.
Kennste das Stau Prinzip?
Stell dir ne Sanduhr vor. Oben ist dein Video (Sand) und der würde ganz schnell nach unten rieseln, wenn da nicht der Trichter wäre. Der Trichter ist der Encoder. Und jetzt versuchst du mit nem Koben nachzuhelfen (das wäre jetzt in diesem Falle die GPU)
Was passiert wohl? Der Kolben würde genauso schnell nach unten zu drücken gehen als wenn du den Sand so durch rieseln lassen wolltest
Mit anderen Worten: Der Renderprozess ist fertig und vor dem Encoder stapeln sich die fertigen Frames die noch encodiert werden müssen.
Weil der Encoder nicht parallelisierbar ist, der Rendervorgang aber schon.
Ich kenne deine Encodereinstellungen nicht, eventuell kann man da einiges optimieren damit das ein wenig oder gar erheblich schneller von Statten geht.
Ok, da ich ich meinen Videos nicht so viele effekte drin habe, wäre der kleine server mit 2 Xeons also besser?
Solange du deine Videos in irgendeine Art von Videobearbeitungssoftware stecken tust. (Sony Vegas, Magix, Premiere, und und und). Solange wird immer eine Neuberechnung der Frames stattfinden.
Das Video wird in einem Schnittprogramm immer erst decodiert und in eine Rohfassung gebracht. In den meisten Fällen wird sogar alles auf den RGB Farbraum geeicht und Audio wird auf PCM Signale geeicht.
Und bevor du Encodierst wird dein Video immer zwangshaft vom Programm neu berechnet. Deswegen steht auch meist immer das Wort "Rendern" da. Was du aber unter Rendern angibst sind die Encodierer.
Weil der Ablauf ist immer gleich:
Video / Audio -> Rendern (Neuberechnung) -> Encodieren -> Neues File
Und bevor du halt Encodieren kannst muss es neu berechnet werden halt. Darum wird Rendern und Encodieren immer auch zusammengeworfen von den Leuten und heißt für die Masse halt fälschlicherweise bzw. zur hälfte falsch, einfach nur "Rendern". Fällt halt alles darunter.
Sind aber 2 separate Prozeduren.
Rendern halt via GPU am besten und Encodieren via CPU. Und dann machste schon mal nix falsch.
AVISynth berechnet z.B. über die CPU die Frames neu, statt der GPU.
Bei Sony Vegas kann man das sogar umstellen, ob CPU oder GPU.
Dann steht da meist was von CUDA Nutzung, wenn man eine NVIDIA hat
Damit hab ich aber noch nicht Encodiert ;D
Den Encoder kann man dann ebenfalls wählen. Die meisten sind dann oft CPU Encoder. Darunter fallen z.B. der x264vfw, x264, XVID, DIVX, MagicYUV, UTVideo, etc. pp
Und dann gibt halt die GPU Encoder wie z.B. NVEnc, Intel QuickSync oder AMD VCE
Musst halt nur Rendern und Encodierung auseinander halten. Die haben an sich nix miteinander zu tun, sondern werden nur oft hintereinander durchlaufen.
Vllt. hilft dir dieses Bild zur groben Veranschaulichung des Ganzen:
H.265 wird da wohl recht schnell kommen ... wenngleich vermutlich in ähnlicher Güte wie deren H.264 - Encoder. Müsste sogar in MAGIX schon enthalten sein, wenn ich mich richtig erinnere.
Ich sag es ja gerne noch mal: Die LPer werden es nicht nutzen.
A) Es dauert erheblich länger mit HVEC zu encodieren als mit x264, einfach weil das Teil stärker auf Kompression ausgelegt ist schon
B) Der H264 Encoder in Magix, Adobe und Co. sind, wenn sie dann x264 enthalten haben, so rudimentär einstellbar, das man glatt denken kann das das Teil erst 1 Woche alt ist. Ich meine wie lange ist x264 schon im Umlauf?
Die bauen jetzt schon HVEC ein und haben dabei nicht mal ihren h264/x264 richtig im Griff von den Einstellungen her.
Das nenne ich eigentlich schon traurig.
Ehrlich? Wenn die ganzen Unternehmen keinen Dunst haben was für Optionen und Angaben richtig sind für die Codecs und da irgendwelche Kuriosen Slider und Textboxen einbringen wo dann total bescheuerte Werte stehen die keinerlei Sinn ergeben, dann sollten die Entwickler es lieber sein lassen und nur eine Parameter Box da hin knallen. Weil ein paar Parameter Angaben zu den Ordentlichen Referencen des Codecs sind meist Optimaler als deren Müll.
Und letztens hatte ich wieder einen im TS gehabt der mir mit seinen Adobe Premiere angegeben hat. Er war da ganz stolz drauf das er x264 nutzen konnte dank x264pro. Da hat er locker 280 € ausgegeben für. Bis ich ihn gesagt habe das er den Kram auch Kostenlos hätte machen können.
Fand ich irgendwie Fail.
Wieviel will den Adobe dann für x265pro ? 540 € ? xD
Da kauf ich mir dann lieber noch nen Rechner oder am besten gleich ne neue Konsole xD Hab ich irgendwie mehr von.
Und ich denke die meisten sind schon mit h264 überfordert. Was wollen die mit HVEC denn anfangen was weitaus langsamer ist?
Ich meine... warum nutzt denn bis jetzt noch keiner VP9? Das geht auf YT hochzuladen. Aber machen tut es irgendwie keiner
Fürs Rendern ist GPU gut.
Fürs Encodieren ist CPU gut.
Encodierer die eine GPU nutzen wären NVIDIA NVEnc, AMD VCE, Intel Quick Sync
Encodierer die eine CPU nutzen wären alle restlichen ;D
Rendern (Video/Audio) = Neuberechnung von Frames und Samples. Halt alles was extrem gut parallelisiert werden kann.
Encodieren (Video/Audio) = Das Komprimieren und Verschlüsseln von Informationen, weshalb man die Dinger dann auch Codecs nennt ;D
Fazit: Ein GPU Encoder wie er bei einigen Programmen wie Sony, Magix, Adobe, etc. zu finden ist, ist schlechter konfiguriert und somit schneller. Ein CPU Encoder genauso Moderat konfiguriert würde schneller sein. Oder umgekehrt genauso, wenn man den GPU Encoder genauso einstellen würde wie ein CPU Encoder wäre der CPU Encoder schneller. Einfach aufgrund dessen das beim Encodieren so gut wie gar nix parallelisiert werden kann.
Nur ist es blöd fürs Marketing wenn man GPU Encoder präsentiert und die schlechter laufen ;D Darum werden die halt ganz raffiniert schlechter konfiguriert um den User zu verarschen und diesem glauben zu machen das die Dinger schneller sind
Bei Aufnahmen kann man aber die CPU entlasten, wenn man mit einem GPU Encoder aufnimmt. Weil die Spiele können parallelisiert, während der GPU Encoder da rum dödelt Da hat dann die CPU sehr viel Freiraum dann.
Bei Bearbeitungsprogrammen wie gesagt bringt einen das relativ gar nix. Da ist die CPU schneller.
Die Bildberechnung wie Effekte und Co. sollte aber in einem Bearbeitungsprogramm am besten von der GPU erledigt werden. Sprich das Rendern.
Ist ja korrekt, aber halt auch ineffizient wenn man den Ablauf mit berücksichtigt was da alles passiert ohne das man davon was mitbekommt.
XD Genial der Guide xD
Jo. mit x264 sollste CRF nehmen und bei NVEnc ist CRF ja blödsinn, da nimmt man dann CQP xD Weil ja x264 ja kein CQP besitzt xD
Köstlich xD
Hör bitte auf, sonst weine ich noch vor Lachen xD
Nutze mal lieber bei NVEnc entweder den Lossless Mode bzw ein CQP Wert von 0 oder verwende halt ein CRF Wert von 18 - 24
Weil ein Unterschied von 15 und 18, den musste mir erst mal zeigen xD
PS: Die schreiben ja auch das man bei QPI, QPP und QPB jeweils 15 - 25 eingeben sollte. xD Aber keiner schreibt das man 3 unterschiedliche Werte dort angeben sollte ;D
Da wird das Endprodukt in MP4 umgewandelt und auf Youtube hochgeladen.
Also noch mal encodiert.
Oder meinst du mit MP4 umwandeln das es nur in MP4 gemuxt wird? Dann wären aber keine großen Bearbeitungen möglich an Frames.
Oder du meinst wirklich neu encodiert. Dann wäre es logischer. Sprich Verlust Aufnahme -> Bearbeitung -> Verlust Encoding -> Hochladen.
Das wäre das wie ich es jetzt von dir verstanden habe.
Also Doppel Verlust + YT Verlust Encoding = 3 fach Verlust.
Genial. Also hat @De-M-oN richtig gelegen
man muss es ja nicht im MP4 umwandeln. Die Elgato lässt einem ja die Wahl. Ist halt das Feature für den Direkt-Upload fürs Internet durch die Software.
Wenn du damit auf das Streaming ansprechen willst, geht man doch ohnehin ganz anders vor. Da braucht es dann keiner lokalen Aufnahme.
Bzw. es muss ja nicht weiter bearbeitet werden. Da stellt man den ersten Encodiermodus so ein das es direkt hochgeladen werden kann ohne große Zeitverluste.
Ja, dann wäre so ein Feature aber während der Aufnahme gut.
Nach einer lokalen Aufnahme gewollt die Aufnahme schlechter machen um sie dann mit Programm xyz weiter zu bearbeiten erscheint mit aber recht ineffektiv.
Und offenbar gibt es einen Unterschied zwischen QP und CQP.
Nein, gibt es keinen. QP ist der Constant Quantizer Parameter Modus. Für absolute DAUs wie User des OBS hat man halt eben dann auch das C noch davor gesetzt, damit wirklich jeder weiß das es sich um den Constant Quantizer Parameter Modus handelt.
Sprich QP = CQP
Da gibt es 0 Unterschied.
Auf dem Guide von OBS steht, man soll einen CQP Wert zwischen 15 und 25 wählen.
Welcher Guide denn bitte? Kannste den mal bitte posten.
Weil das ist totaler Blödsinn irgendwie was du da schreibst. Gerade 15. xD
Nein, ehrlich. Diesen Guide würde ich gern mal sehen bitte.
Für mein Empfinden läuft der OBS, so wie er gerade bei mir läuft, um einiges besser als der MSI mit der schondensten Einstellung für die CPU.
Weil OBS, als auch der MSI AB oder auch Fraps oder DXTory alle voneinander ganz andere Hooking Verfahren nutzen sich in Spiele zu hooken um dort die Direct3D oder OpenGL APIs abzugreifen nach Frames aus dem Backbuffer.
Und da jede Software anderes arbeitet bei Spiel xyz, kannste nicht pauschal jetzt sagen das OBS besser läuft.
Es ist dein Empfinden bei den jetzigen Spielen die du grad hast. Kann sein. Gibt auch Games, da würdeste mit OBS verzweifeln. Da würde dann wieder MSI AB oder DxTory wieder besser funktionieren. Ist einfach so.
nicht ganz richtig; die Codierung ist zwar live, aber der nach der Aufnahme stattfindende MP4-Export aus den Rohdateien dauert ein bisschen.
Meine Erfahrung mit solchen Karten war eigentlich immer das die Aufnahme lokal auf dem Rechner stattfindet (die sogenannte Rohaufnahme) und die dazugehörige Software so blöd ist diese Rohaufnahme noch mal zu codieren.
Macht man aber das Tool vorher zu, kann man irgendwo auf dem Rechner die Rohaufnahme verwenden.
Würde ich auch machen, da die Rohaufnahmen von solchen Capture Karten/Boxen sowieso lossy sind.
Meist nutzen die Hersteller dann ein Transport Stream für die Rohaufnahmen. entweder TS oder M2TS.
Die Software die zur Aufnahme meist mitgeliefert wird will dann oft daraus noch eine MP4 machen. Und da entsteht schon irgendwo meist Verlust.
Also doppelte Lossy Codierung oder wie?
Ganz genau. So funktioniert das bei vielen Herstellern von Capture Karten/Boxen.
Und du siehst ja selbst... einige User wollen schlechte Qualität einfach haben. Weil die interessiert das nicht xD
Ich liste mal alle Modis auf die man bei Encoder so antrifft, damit man weiß wofür sie stehen:
CRF = Constant Rate Factor
CQP = Constant Quantizer Parameter
QP = Quantizer Parameter
RF = Rate Factor
CBR = Constant Bitrate
VBR = Variable Bitrate
ABR = Average bitrate
CVBR = Constrained Variable Bitrate
AVBR = Average Variable Bitrate
LA (VBR) = Look Ahead Variable Bitrate (Ist besser als das Standard VBR)
ICQ = Intelligent Constant Quality (Ist eine bessere Version des CQP Modus)
LA (ICQ) = Look Ahead Intelligent Constant Quality (besser als der übliche ICQ Modus)
VCM = Video Conferencing Mode (zeichnet sich durch schlechte Qualität und Bitrate aus)
Für den CQP oder den QP Modus werden oft weitere Angaben benötigt wie QPI, QPP und QPB
Im Falle von x264 und NVEnc werden diese 3 Werte optimal automatisch durch Angabe eines Wertes bestimmt.
Habe CQP gewählt, einen Wert von 18 (war default), Keyframe 1 und Profile auf high.
Wieso nimmst du so ein Wert für den QP Modus? Für CRF währe er ok, wenn du danach nicht weiter bearbeiten willst. Aber für Aufnahmen schon Lossy? Wieso?
Kann ich leider nicht ganz nachvollziehen grad.
QP=0 für Lossless, weil du encodierst doch dein Video dann eh noch mal bestimmt mit MeGUI, nach dem SSM.
Weil Verlust (Aufnahme) + Verlust (x264 Encoding MeGUI) = Noch mehr Verlust Und YT gibt dem Video den Rest. xD
Also Optimal ist dein Workflow nicht grad.
Aber auf 4:2:2 zu kommen scheint nicht möglich, zumindest ist es das, was ich aus den OBS Foren rauslese.
Keine Ahnung ob das deine Grafikkarte zulässt die der NVEnc unterstützt.
Die erste Generation kann nämlich noch keine höheren Farbräume verstehen als YUV 4:2:0
Erst die zweite, die Maxwell (GM107/GM108) oder halt höhere Generationen von Grafikkarten, können bis YUV 4:4:4 supporten.
Und @De-M-oN würde dir ohnehin bei der Verwendung von NVEnc zu einer Pascal Grafikkarten Generation raten. Alles andere taugt da doch sowieso nix ;D
Unter Erweitert kannste dann ja mal versuchen mit i422 als Farbformat (Farbraum) einzustellen für eine YUV 4:2:2 Aufnahme.
Ich verstehe davon zwar nur die Hälfte, aber bei CPU intensiven Spielen wie Rainbow Six Siege oder BF1 merke ich einen DEUTLICHEN Unterschied zwischen meiner jetzigen OBS Konfiguration und MSI AB mit MagicYUV im Farbraum 4:2:0, leider.
Das macht im Schnitt einen Unterschied von an die 50fps!
Da liegt es doch nahe den NVENC via OBS zu nutzen...
Er wollte damit sagen das OBS den NVEnc nur für das Encoding verwendet, jedoch nicht über die NVIDIA aufnimmt, sondern immer noch auf die DirectX Oberfläche sich hooken muss um die Frames abzugreifen.
Das heißt das dieser Prozess gegenüber dem was Shadowplay tut viel langsamer ist und die FPS runter zieht.
Denn Shadowplay hookt sich nicht in das Spiel ein, sondern vielmehr greift er Hardwaretechnisch auf der Grafikkarte die Frames schon ab via NVFBC.
NVFBC ist nämlich das Aufnehmen des Frontspeichers ohne die OpenGL oder Direct3D APIs in Anspruch zu nehmen.
Daher ist Shadowplay auch so extrem performant.
Was OBS jedoch nur nutzen tut ist NVEnc, sprich den Encoder, den sie dann höstwahrscheinlich über NVIFR laufen lassen. Ist nicht ganz so performant als die NVFBC Variante, wenn das so solo läuft.
Beide zusamm und man habe Shadowplay.
Und wenn Shadowplay einen mehr Optionen geben würde, könnte man damit sogar Lossless aufnehmen und sogar in höheren Farbräumen. Was NVIDIA aber nicht machen wird, da ja die meisten User eh nur schlechte Qualität haben möchten und damit halt voll zufrieden sind. Und sich halt darüber auch noch freuen
Allerdings arbeitet x265 nach wie vor noch sehr langsam und codiert in h265
Ach... ich dachte er macht daraus XVID xD
Und ich glaube kaum das er Salonfähig für Let's Player wird. Denkt doch mal nach. Die Kodierung von HVEC oder auch VP9 dauern gegenüber dem h264 immens.
Und die Geduld für so ein Encoding haben die wenigsten Leute in diesem Forum. Ganz zu schweigen von den unfassbaren Luxus des Supports dieser Codecs bei bekannten Marken wie Sony, Magix oder Adobe.
Weil die hängen ja noch mit x264 hinterher.
Natürlich... auf Wunder kann man immer hoffen xD
Ok. Und als Encodiermodus nimmste was? CQP? QP? CRF? Bitrate?
Und als Farbraum haste was genommen?
Na was haste denn eingestellt? Main? Baseline?
