Infoseite // mp4 Bitraten Problem gelöst!

Frage von klusterdegenerierung:


Habe doch hier schon öfter die Problematik in Resolve wegen der frei eingestellten Bitrate angesprochen und immer wieder kamen so Kommentare wie nutze doch Handbrake, oder dein Video hat nicht mehr Info, oder oder!!

Nun hab ich mich auf die Suche im Resolve Forum gemacht und dort hatte jemand genau das gleiche Problem und ihm wehte witzigerweise genau der gleiche ahnungslose Wind entgegen! ;-)
Ich bin auch schon öfter über den sehr missverständlichen Punkt ""Key Frames" im Render Menü gestolpert, der standartmässig auf auto oder 12 steht.

Folgt man dieser netten Aufklärung des Foristen, bekommt man genau wie in Premiere die Bitrate die man auch eingestellt hat!
Persönlich finde ich das extremst hilfreich und macht handbrake für mich an der Stelle überflüssig.

So you like the quality of a certain encoder because it has all-I frames, but don't want the bit rate so high.

Take the Quicktime or MP4 formats, visit the Key Frames parameter and change it from Automatic to Every "1" Frames. I don't like the term "Key Frames" here because it is confusing with the same term in another contexts. So now you have a codec in all-I, now take the Quality setting and change it from Automatic to Restrict to #### kb/s.

Do all that and let's see if you can have your cake and eat it too.



Antwort von cantsin:

Das bringt Dir doch gar nichts - nur aufgeblasene Dateien ohne Bildqualitätsgewinn... Und Du wirfst die Vorteile des h264-Encodings zum Fenster raus.

All-I ist IMHO nur sinnvoll als kamerainterner Codec, wenn man den NLE entlasten will.



Antwort von klusterdegenerierung:

Ne ist klar,
ich nehme in Cam files mit 100Mbit auf, schneide die alle zusammen und am Ende kommt eine "9Mbit" Datei dabei raus und das soll dann state of the art sein und jedem Anspruch genügen?
Ne is klar!! Dann können wir ja wieder 8GB SD Karten einführen, denn mit 7Mbit ist man doch ganz weit vorne!



Antwort von klusterdegenerierung:

Witzig auch das seit jahrzehnten in Premiere nix anderes passiert und solche Dateien mit bis 80Mbit ausgegeben werden statt mit 9, aber das ist ja auch lange nicht so professionell wie Resolve welches sich mit sowas ja viel besser auskennt und Jahrelang haben wir umsonst die Batraten so hoch gesetzt.

Ich stellen meine Cam von 100Mbit auf 19Mbit, ist doch viel besser und genau das gleiche, 100 ist ja zu 80% nur Luft.



Antwort von dosaris:

...nur aufgeblasene Dateien ohne Bildqualitätsgewinn... Und Du wirfst die Vorteile des h264-Encodings zum Fenster raus.

All-I ist IMHO nur sinnvoll als kamerainterner Codec, wenn man den NLE entlasten will. that's it!

wieder mal 'n terminologisches Problem:

der Rat zu Handbrake bezieht sich implizit auf den dort enthaltenen X.264-Encoder für h.264.
Der ist weitgehend anerkannt der beste encoder f h.264.
Deswegen könnte man genau so gut AviDemux nehmen, weil das denselben x.264-Encoder beinhaltet.

All-I war eigentlich eine Krücke, um in zu schwachen CPUs die Bilddifferenz-Auswertung
der interframe-encodings zu vermeiden.
Aus performance-gründen, nicht wegen der Qualität.
Diese Aera ist aber vorüber.
Aus der Zeit stammt auch noch der heiße Tipp, dass höhere Bitrate zu besserer Bildqualität führt.
Stimmt auch irgendwie, ein bischen. Nämlich dann, wenn der encoder ineffizient programmiert ist.
Ein billiger/schlechter Encoder benötigt dann in der Tat eine höhere Bitrate als ein guter (zB x.264),
um etwa gleiche brauchbare Bildqualität zu generieren. Oder bei einem vorgegebenen encoder,
um max Qualität aufzunehmen. Aber auch da gibt's iA einen break-even-point,
wo die Ausgabe nur noch größer, aber nicht mehr besser wird.



Antwort von klusterdegenerierung:

Warum nehmen wir dann in einer Lumix mit 250Mbit oder Sony 100Mbit auf wenn das alles Blödsinn ist?
Muß ich unbedingt mal Arri verklickern, das die das auch mit 15Mbit genauso hinbekommen.



Antwort von Jörg:

die Differenzierung zwischen internem Aufnahmecodec und Deliverycodec ist ganz schön
schwierig zu verstehen...



Antwort von klusterdegenerierung:

Genauso wie der zwischen mäßiger delivery Quali und hoher.
Ihr gebt bei Euren Kunden, sofern sie auch gerne mp4s haben möchten, Bitraten von 9Mbit ab?

Sehr professionell!



Antwort von rdcl:

ich habe deine anderen Threads dazu nicht mitbekommen. Was genau ist dein Problem mit dem h264 Export aus Resolve?






Antwort von dosaris:

Jörg hat geschrieben:
die Differenzierung zwischen internem Aufnahmecodec und Deliverycodec ist ganz schön
schwierig zu verstehen... gerade dieser Aspekt wird auch kaum kommuniziert.

Per saldo ist es aber plausibel:

der Aufnahmecodec MUSS fertig sein mit dem encoding bevor das nächste Bild rein kommt.
Bei 60fps also in weniger als 16 msec (er muss ja noch wegspeichern). Deswegen schaffen etliche
cams höhere fps-Raten nicht mehr bei voller Auflösung.
Wenn dann die Hardware im sensor-Prozessor zu schwach ist wird die Kompression reduziert
und stattdessen die Bitrate erhöht. Das bringt etwa wieder gleiche Bildqualität.

Beim Deliverycodec gibt's diese realtime-Forderung iA nicht. Da ist es egal, ob der Rechner zum
Rendern u encoding 2 od 3 Std braucht. Man sitzt eh nicht davor und wartet.
Da kann man für's encoding den Suchraum (wo ist das jeweilige Bildelement nach einem pan geblieben?)
schon mal vergrößern und auch mal einige CPU-Zyklen mehr investieren.



Antwort von Jörg:

Ihr gebt bei Euren Kunden, sofern sie auch gerne mp4s haben möchten, Bitraten von 9Mbit ab?

Sehr professionell! keine Ahnung, warum du auf den 9 Mb/s rumreitest.

Alle Leute, die von mir mit Filmchen beglückt werden wollen, bekommen aus Resolve solche bitrates serviert...
Wo ist das Problem?
Resolve_bitrate_mp4.JPG



Antwort von klusterdegenerierung:

Jörg hat geschrieben:
Ihr gebt bei Euren Kunden, sofern sie auch gerne mp4s haben möchten, Bitraten von 9Mbit ab?

Sehr professionell! keine Ahnung, warum du auf den 9 Mb/s rumreitest.

Alle Leute, die von mir mit Filmchen beglückt werden wollen, bekommen aus Resolve solche bitrates serviert...
Wo ist das Problem?

Hallo Jörg,
weil egal was ich in restricted eintippe am Ende immer mit 9Mbit rauskommt.
Wähle ich stattdessen high, bekomme ich 8Mbit.

Bei Best bekomme ich 26Mbit, aber bei restricted bekomme ich selbst bei 1000000kbs nur 9Mbit.
Am Ende des Tages verstehe ich hier nicht, warum man hier immer Wünsche kritisiert und unmodeln möchte.

Ist doch nix dabei wenn ICH 50Mbit ahben möchte, geht in jedem NLE.



Antwort von rdcl:

Seltsam. Ich habe gerade ein Grading exportiert, und das hat bei dem "Best" Settings zwischen 50 und 80 Mbit/s. Sowohl als h264 mov, als auch als mp4.



Antwort von srone:

klusterdegenerierung hat geschrieben:
Ist doch nix dabei wenn ICH 50Mbit ahben möchte, geht in jedem NLE. wozu, dass du eine dicke datei hast, die keinen deut mehr qualität beinhaltet, wie die kleine?

was macht das für einen sinn?

lg

srone



Antwort von Jörg:

weil egal was ich in restricted eintippe am Ende immer mit 9Mbit rauskommt. vermutlich weißt nur du, warum du restricted wählst, wenn du hohe bitraten willst...



Antwort von blueplanet:

...ich mische mich mit meinen Erfahrungen kurz ein, da ich mich ebenfalls gerade für die Ausgabe eines Projekts mit der Problematik "herumschlage". Aus Premiere heraus...aber das ist jetzt ersteinmal zweitrangig.

Fest steht, wie hier bereits angemerkt, der Codec x.264 u.a. aus "handbrake" oder dem plugin für Premiere "voucoder R3" liefert die besseren (saubereren) Ergebnisse als alles was Premiere implementiert hat. Und das ziemlich unabhängig von der Bit-Rate.
Insofern stimmt das, was @Jörg sagt. Die Bit-Rate ist nur das Zünglein an der Waage.

Ob ich aus "modernem" Material mit 50, 30 oder mit 20MBit/s herausrechne ist (fast) zu vernachlässigen. Alles darunter ist dann schon wieder generell vom Material abhängig (z.B. viel Bewegung im Bild). Gut zu beurteilen auch an Schwarzblenden die dann gern zum Überblendenbandig neigen (aber anderes Thema).

Ich denke viel entscheidender ist, in welcher Geschwindigkeit der Encoder arbeitet. Das ist sowohl bei Premiere wie auch Resolve (?) nicht einstellbar, sondern der Gesamtperformance zugeordnet. Nicht so bei "handbrake" & Co. Hier lässt sich das nach den eigenen Anforderungen konfigurieren: fast, slow, veryslow, placebo. Und das ist immens wichtig für ein sauberes encoden, jedenfalls mehr als die hohe Bit-Rate (meine Erfahrung).

Kombiniert man das "vernünftig", kommt dann wirklich Freude auf, schafft ein x.264 augenscheinlich die gleiche Qualität wie das Arbeits-Original z.B. aus cineform oder ProRes.
Um das zu gewährleisten müssen die anderen Parameter ebenso richtig gesetzt sein. Wer mehr Bit möchte muss neben dem Profil "High" auch das "Level" in den jeweiligen Spezifikationen richtig setzen (ist auch aus Premiere heraus machbar). Das wiederum ist entscheident wo das Material dann laufen soll. PC egal, aber auf welchem TV-Gerät (Baujahr) ganz und gar nicht. Wer auf Nummer sicher gehen will (muss), sollte mit "Baseline" oder "Main" und nicht über das Level "4.0" gehen. Die wiederum haben Einfluss auf die mögliche Datenrate ;))

Beispiel in "handbrake": CBR auf Einstellung "13", Profil "High", Level "5.0", Geschwindigkeit "slow"(!). Damit werden aus einem cinefom-file von ca. 70Gbyt (ca. 50 Minuten) um die 15GByt in x.264 HD-Qualität bei einer Datenrate um die 35MBit. Das ist vollkommend ausreichend und ist im Prinzip nicht vom Original zu unterscheiden.

Versuche ich das aus Premiere herauszurechnen, ohne die Möglichkeit der Geschwindigkeitsbeeinflussung, kann (!) es bei gleicher Datenrate zu sichtbaren Qualitätseinbrüchen kommen.
Insofern muss man wirklich experimentieren wo die eigene Qualitätsgrenze liegt. Nicht zu vergessen, das langsame(re) rendern wirkt sich natürlich auf die gesamte Dauer der Erstellung des Endproduktes aus. Mein 4,9GHz- Intel läuft für 50Minuten Material bei 100% CPU-Auslasten in dieser Konfiguration locker seine 3 Stunden. Aus Premiere heraus viel, viel weniger als die Hälfte...! Das muss man wollen ;))



Antwort von klusterdegenerierung:

Jörg hat geschrieben:
weil egal was ich in restricted eintippe am Ende immer mit 9Mbit rauskommt. vermutlich weißt nur du, warum du restricted wählst, wenn du hohe bitraten willst... Tja, wenn bei best und high nicht mehr als 24Mbit rauskommt.
Aber nun geht es ja und ihr könnt es weiter machen wie bisher.

Wahnsinn,
ich erkläre hier nur wie man die Bitrate bekommt die man möchte und schon will mir jeder eintrichtern das ich stattdessen handbrake benutzen soll.

Das ist ungefähr so wie wenn ich erkläre wie man mit Schaltung fährt und alle sagen man hat mit Automatik zu fahren!



Antwort von blueplanet:

klusterdegenerierung hat geschrieben:
Tja, wenn bei best und high nicht mehr als 24Mbit rauskommt. ...eine Schaltung (Getriebe) allein genügt nicht, um vorwärts zu kommen. Dazu braucht man auch einen Motor, ein Lenkrad... ;))
Und "High" allein ist nicht das Zauberwort. Nicht mehr oder weniger habe ich versucht Dir zu erklären.
"Hight" bedeutet nicht gleich bzw. mehr Mbit. Die bekommst Du nur in Verbimdung mit dem richtigen Level (möglichst jenseits der 4.0.) in Abhängigkeit (!) der FPS und der gewählten, jeweiligen Auflösung (SD, HD, UHD).

Und wenn Du das alles richtig kombiniert hast, kommt das Entscheidende: die richtige Encodier-Geschwindigkeit. Denn die vielen Bits sollen doch auch gut aussehen?!
Kannst Du das alles in resolve, premiere oder Magix oder...konfigurieren?
Mit handbrake geht das... ,)






Antwort von cantsin:

@kluster, mal weniger esoterisch erklärt: h264 ist nicht einfach ein Kompressionsverfahren, sondern eine ganze Sammlung von kombinierbaren Kompressionsverfahren, wovon einige einfacher sind und andere komplexer und sehr rechenaufwendig.

Kameras wie die GH5, Sony A6x00, Sony A7x, Fuji XT3 etc. verwenden wegen ihrer vergleichsweise schwachbrüstigen Chips nur eine anspruchslosere Untermenge der h264-Kompressionsverfahren. Das sorgt bei niedrigen Bitraten für schlechte Qualität mit Blockartefakten, verschmierten Details etc. Darum kompensieren sie das mit hõheren Bitraten.

Ein Top-h264-Encoder wie der in ffmpeg und Handbrake enthaltene x264 implementiert so ziemlich alle Kompressionsverfahren der h264-Spezifikation, darunter auch die rechenaufwendigen, braucht dafür allerdings auch auf schnellen Rechner viel Zeit in den höchsten Qualitätsstufen (Encoder-Preset "veryslow" etc.)

Das Resolve-interne h264-Encoding liegt qualitativ zwischen dem der Kamerachips und dem von x264. D.h. bei gleicher Bitrate liefert x264 in den hohen Qualitätseinstellungen deutlich - und zwar ganz klar sichtbar - bessere Bildqualität.

Durch das reduzieren der i-Frames schaltest Du nur die Kompression auf ein ineffizienteres Verfahren um, wodurch Du zwar höhere Bitraten erzielst, aber keine bessere Bildqualität.



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:


Wahnsinn,
ich erkläre hier nur wie man die Bitrate bekommt die man möchte und schon will mir jeder eintrichtern das ich stattdessen handbrake benutzen soll.

Weil du nur denkst du willst eine hohe Bitrate, da in deinem Kopf die Gleichung: Hohe Zahlen = immer besser, fest verdrahtet ist, und die Leute das sehen können und dir versuchen zu helfen.

Das erinnert mich an die Unbelehrbaren, die immer noch sagen "Schick mir das Logo, es muß aber mindestens 10 MB haben, weil wir das auf den Flyer drucken wollen". Nach 3 vergeblichen Erklärungsversuchen (Vector Datei und so) hab ich es dann aufgegeben, und das Logo entsprechend aufgeblasen und als TIF gespeichert - happy Custsomer - manche verdienen's halt nicht besser. .



Antwort von klusterdegenerierung:

Frank, schickst Du Deinen Kunden einen finalen Auftrag in 9Mbit, nachdem Du 2 Wochen mit Red, BMD & Arri durch Bolivien gekrakselt bist?
Na denn!



Antwort von Darth Schneider:

Verwirrende Diskussion.
Ich bin jahrelang sehr gut gefahren mit meiner alten Sony, mit hohen oder tiefen Bitraten, scheiss egal, halt je nach Motiv und der Delivery.
Einige (noch mehr ) Fragen:
Warum kann denn Resolve eigentlich kein h264x ? Oder kann es das und ich hab’s nicht gefunden...
Und warum bezeichnet man jetzt eine Gh5, eine Sony Alpha, oder ne XT3 als schmalbrüstig ? Welche preislich ähnlichen Kameras sind dann eurer Meinung nach nicht schwachbrüstig in dem Fall ?
Und wenn das normale H264 ja so schlecht sein soll, warum ist das der Standart bei eigentlich allen Playern abspielbar ist, Software, TVs und was auch immer ?
Und was soll dieses Handbreak ?
Ich denke wenn eine Schnittsoftware es nicht packt ein sehr gutes Ergebnis zu bringen am Schluss beim mastern, dann wären ja eigentlich alle für die Katz..:)

Also ich bin zufrieden was von Resolve ohne Handbreak am Schluss rauskommt, egal ob auf DVD oder in HD auf nem Stick oder auf BluRay, klar von der Pocket sieht es viel besser aus, aber das Material von der Sony ist auch schön...sogar wenn ich früher auch schon in einer sehr niedrigen Bitrate aufnehmen musste um Platz zu sparen.



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Frank, schickst Du Deinen Kunden einen finalen Auftrag in 9Mbit, nachdem Du 2 Wochen mit Red, BMD & Arri durch Bolivien gekrakselt bist?
Na denn! Netflix streamt 1080p "nur" mit 5Mbit/s, 4K mit maximal 16Mbit/s.



Antwort von rdcl:

"Darth Schneider" hat geschrieben:
Und wenn das normale H264 ja so schlecht sein soll, warum ist das der Standart bei eigentlich allen Playern abspielbar ist, Software, TVs und was auch immer ? Weil h264 ein Delivery Codec ist, der eigentlich nicht zur Bearbeitung gedacht ist bzw. war.
Und dafür ist er auch super geeignet.



Antwort von Darth Schneider:

Aber meine Rx10 nimmt doch auch in dem Format auf, oder bringe ich was durcheinander ? Dann müsste man das ja alles zuerst wandeln, was ja immer mit Verlusten behaftet ist.
Warum nehmen so viele Kameras so auf, wenn sich das Zeugs nur schlecht bearbeiten lässt ? Das ist witzlos.

An Kluster
Hast du nicht auch Profi Sony Kameras, ProRes können ?
Wenn nein hol dir ne Pocket, nur 1000 Pipen, mit ProRes aufnehmen...Master auf h264. Das sieht super aus.



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:
Frank, schickst Du Deinen Kunden einen finalen Auftrag in 9Mbit, nachdem Du 2 Wochen mit Red, BMD & Arri durch Bolivien gekrakselt bist?
Na denn! Kommt auf den Codec und die Zielplattform an. Ein unkomprimiertes Master hat ne andere Datenrate, wie ein IMF für Netflix oder eben ein Clip fürs Netz, der von YT sowieso nochmal zu Tode komprimiert wird.

Für Internet schick ich denen alles was Handbrake eben ausspuckt - meine Kunden haben keinerlei Interesse an irgendwelchen Datenraten, sondern ausschließlich an der Qualität, und wenn die stimmt (und die hat bei Handbrake bisher immer gestimmt) ist alles gut.



Antwort von cantsin:

"Darth Schneider" hat geschrieben:
Warum kann denn Resolve eigentlich kein h264x ? Oder kann es das und ich hab’s nicht gefunden... h264 ist ein Standard, in dem verschiedene darin beschriebene Kompressionsverfahren kombiniert werden können. x264 ist ein Open Source-Codec, der die h264-Spezifikation erfüllt. Ansonsten hat jedes Gerät/jede Software ihren eigenen h264-kompatiblen Codec, auf jeweils unterschiedlichen Qualitätsniveaus. Das ist genauso wie bei mp3, wo es bessere Encoder (wie z.B. lame) und schwächere (wie z.B. den ursprüngliche Fraunhofer-Encoder) gibt.
Und warum bezeichnet man jetzt eine Gh5, eine Sony Alpha, oder ne XT3 als schmalbrüstig ? Weil das kleine Kameras sind, die im Vergleich zu professionellen Videokameras (wie z.B. der Canon Cx00-Reihere) kleinere, weniger stromfressende Chips eingebaut haben, die weniger komplexes Encoding-Schaffen. Das bei Kameras nötige Echtzeit-Encoding ist ja ziemlich anspruchsvoll.

Welche preislich ähnlichen Kameras sind dann eurer Meinung nach nicht schwachbrüstig in dem Fall ? Die alte Canon C100 hatte einen sehr guten h264-Codec, trotz relativ geringer Bitraten.

Und wenn das normale H264 ja so schlecht sein soll, warum ist das der Standart bei eigentlich allen Playern abspielbar ist, Software, TVs und was auch immer ? Es gibt kein "normales" und "besseres" h264, sondern nur einen h264-Standard, der verschiedene (und verschieden anspruchsvolle) Verfahren beinhaltet. - Abspielen/Decodieren ist immer weniger anspruchsvoll zu implementieren und daher leichter in alle möglichen Chips einbaubar als Echtzeit-Encodieren.

Und was soll dieses Handbreak ? Handbrake ist eine GUI-Software, die h264 mit dem x264-Codec encodiert.

Ich denke wenn eine Schnittsoftware es nicht Schaft ein sehr gutes Ergebnis zu bringen am Schluss beim mastern, dann wären ja eigentlich für die Katz..:) Bei fast allen NLEs erzielst Du bessere Qualität, wenn Du erst in einen Codec wie ProRes und DNxHR encodierst und danach das Result mit Handbrake nach h264/mp4.

Also ich bin zufrieden was von Resolve ohne Handbreak am Schluss rauskommt, egal ob auf DVD oder in HD auf nem Stick Mach mal den Test, und encodiere stattdessen mit Handbrake in hoher Qualitätseinstellung, und vergleiche mal Framegrabs. Großer Unterschied.






Antwort von Darth Schneider:

Danke, vielmals, also Handbreak kaufen scheint wirklich die einzige Lösung, ganz sicher fürs Internet.
Wie teuer ist Handbreak, wie steht es mit den Systemanforderungen (Mac) ?



Antwort von rdcl:

"Darth Schneider" hat geschrieben:
Aber meine Rx10 nimmt doch auch in dem Format auf, oder bringe ich was durcheinander ? Dann müsste man das ja alles zuerst wandeln, was ja immer mit Verlusten behaftet ist.
Warum nehmen so viele Kameras so auf, wenn sich das Zeugs nur schlecht bearbeiten lässt ? Das ist witzlos.

An Kluster
Hast du nicht auch Profi Sony Kameras, ProRes können ?
Wenn nein hol dir ne Pocket, nur 1000 Pipen, mit ProRes aufnehmen...Master auf h264. Das sieht super aus. So viele Kameras sind es ja garnicht die h264 aufnehmen. Es ist halt insgesamt eine bestimmte Klasse von Kameras. Du wirst keine "Profi" Kamera finden die h264 movs aufnimmt. Wenn dann als Zusatzoption. Selbst die FS7 nimmt ja schon MXF auf.

Und das ganze gibt es ja so auch erst seitdem alles Tapeless läuft. Mini DV wurde früher als Quicktime oder AVI gecaptured, und Digi Beta, zumindest im Avid und zu meiner Zeit, auch schon als MXF oder DNxHD.

Ganz grob vereinfacht: Bei h264 ist nicht jedes Bild ein vollwertiges Bild, oder zumindest nicht immer. Spätestens Im Grading merkt man da den Unterschied zu Prores oder ähnlichem.



Antwort von Frank Glencairn:

"Darth Schneider" hat geschrieben:

Wie teuer ist Handbreak ? Gratis



Antwort von Darth Schneider:

Cool, aber irgendwie verstehe ich dann erst recht nicht warum diese Gratis App dann nicht einfach in die verschiedenen NLEs fix eingebaut ist...Wenn es ja eh gratis ist ? Ergibt doch keinen Sinn, wie machen die Handbreak Leute denn sonst ihr Geld ? Die leben nur von Luft, Liebe, und einem schönen Codec..;))
Ich teste das aufjedenfall morgen.
Danke



Antwort von eko:

cantsin schrieb:
Bei fast allen NLEs erzielst Du bessere Qualität, wenn Du erst in einen Codec wie ProRes und DNxHR encodierst und danach das Result mit Handbrake nach h264/mp4.


Sollte das auch für Edius 8.5x gelten?



Antwort von cantsin:

"Darth Schneider" hat geschrieben:
Cool, aber irgendwie verstehe ich dann erst recht nicht warum diese Gratis App dann nicht einfach in die verschiedenen NLEs fix eingebaut ist...Wenn es ja eh gratis ist ? Ergibt doch keinen Sinn, wie machen die Handbreak Leute denn sonst ihr Geld ? Wie gesagt, Handbrake ist nur ein GUI, der eigentliche Encoder unter der Haube ist x264. x264 ist Open Source unter der GNU General Public License und darf daher nur in Open Source-Software verwendet werden.



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:
Frank, schickst Du Deinen Kunden einen finalen Auftrag in 9Mbit, nachdem Du 2 Wochen mit Red, BMD & Arri durch Bolivien gekrakselt bist?
Na denn! Netflix streamt 1080p "nur" mit 5Mbit/s, 4K mit maximal 16Mbit/s. Wir reden hier aber a um lediglich eine Einstellmöglichkeit die hier zumindest bislang keiner offenlegen konnte und b geht es nicht um ein streamingportal, sondern einem Kunden der viel Geld für einen Film ausgegeben hat, den er in verschiedenen Qualitätsvarianten archivieren möchte, weil ich das nur ein Jahr anbiete.

Wenn euren Kunden Produktionsfilme von Millionen Maschinen in Handy quali reichen, schön.
Ach und falls die Frage kommt, wie geht mp4 und quali zusammen, nein sie bekommen auch DNxHR oder 10bit MFX.



Antwort von Darth Schneider:

An Cantsin
Oje...dann brauche ich noch eine andere Software wie Resolve und dieses gratis GUI Handbremse Ding ? Muss ich dann etwa auf Blender schneiden ???
Der Kluster, roki und der Frank schneiden doch auch mit Resolve...oder/und Premiere ? Wie geht dann der Workflow ?



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:


Wenn euren Kunden Produktionsfilme von Millionen Maschinen in Handy quali reichen, schön.
Du mußt dich von deinem Bitrate = Qualität Denken frei machen.

Die Bitrate ist nicht abhängig vom Preis der Maschine, die man im Bild sieht, sondern unter andrem von der Bewegung.
Wenn du ruhige Bilder hast, sieht deine Millionenmaschine auch bei 5mbit aus wie im Master. Wenn du mit besten Qualitätseinstellungen komprimierst, dauert das zwar länger, aber die Qualität ist tob und die Datenrate gering. Wenn du nicht die volle Qualität ausschöpfst, wird's halt ned ganz so gut, und die Datenrate steigt.

Ich mach mal ein Autobeispiel (was mit Fußballplätzen fällt mir gerade nicht ein).

Du kannst mit 7000 Umdrehungen im Ersten Gang rumeiern - macht soundmäßig mords Eindruck, verbraucht Sprit wie blöd, fährst dabei knapp über 60 kmh ...aber hey 7000 Umdrehungen!

Du kannst aber auch mit 1200 Umdrehungen im Overdrive mit 120 cruisen, brauchst deutlich wenige Sprit aber klingt halt ned so sportlich am Auspuff.






Antwort von Frank Glencairn:

"Darth Schneider" hat geschrieben:

Der Kluster, roki und der Frank schneiden doch auch mit Resolve...oder/und Premiere ? Wie geht dann der Workflow ? Normal brauch ich ja sowieso verschiedene Versionen, für verschiedene Plattformen/Endgeräte.

Mein üblicher Workflow ist also ein unkomprimiertes Masterfile aus Resolve raus zu schreiben.
Das schmeiß ich dann in Handbreake, wenn der Kunde z.B. was für's Netz braucht.

EInfaches DCP geht mittlerweile ganz ordentlich direkt aus Resolve, DNX, MXF, IDF sowieso - kommt hat immer drauf an was man alles an verschiedenen Formaten liefern muß.



Antwort von srone:

@darth

mein workflow: cineform video aus resolve, dann handbrake in super hq, das ergebnis full-hd in ca 20mbit, nicht vom 10mal grösseren cineform file zu unterscheiden.

lg

srone



Antwort von blueplanet:

...ebenso: Material kommt original in h.264 und h.265 von GH5 (10Bit), GoPro (8Bit), DJI (8/10Bit), wird erst in Premiere nach cineform YUV 10Bit (Quali 5) gewandelt, in der Timeline geschnitten, gegradet und wieder als Master mit cineform YUV 10Bit (Quali 5) rausgerendert.

Anschließend in handbrake den File importieren.
- Reiter "Video" öffnen
- ganz Rechts Oben den Reiter "Voreinstellungen" aufklappen
- ganz nach Unten zu "Produktion" scrollen
- "Production Max" auswählen
- "RF" auf "2 bis 17" setzen, (ich verwende "13")
- im Reiter "Optimiertes Video" Voreinstellung: "slower"
- Reiter Abstimmung: "none"
- Reiter Profil: "High"
- Reiter Level: für eine HD-Produktion, das Level auf max. "5.0" setzen (Bitraten so um die 35MBit/s ;))
- auf den Reiter "Audio" gehen und dort nach "Bedarf", den Codec AAC (avcodec) auf 512kBit/s erhöhen
- Encodierung starten
- Kaffee trinken ;))

handbrake ist kostenlos, kein Hexenwerk und für User die in h.264 filmen ein Segen ;)



Antwort von klusterdegenerierung:

"Frank Glencairn" hat geschrieben:
klusterdegenerierung hat geschrieben:


Wenn euren Kunden Produktionsfilme von Millionen Maschinen in Handy quali reichen, schön.
Du mußt dich von deinem Bitrate = Qualität Denken frei machen.

Die Bitrate ist nicht abhängig vom Preis der Maschine, die man im Bild sieht, sondern unter andrem von der Bewegung.
Wenn du ruhige Bilder hast, sieht deine Millionenmaschine auch bei 5mbit aus wie im Master. Wenn du mit besten Qualitätseinstellungen komprimierst, dauert das zwar länger, aber die Qualität ist tob und die Datenrate gering. Wenn du nicht die volle Qualität ausschöpfst, wird's halt ned ganz so gut, und die Datenrate steigt.

Ich mach mal ein Autobeispiel (was mit Fußballplätzen fällt mir gerade nicht ein).

Du kannst mit 7000 Umdrehungen im Ersten Gang rumeiern - macht soundmäßig mords Eindruck, verbraucht Sprit wie blöd, fährst dabei knapp über 60 kmh ...aber hey 7000 Umdrehungen!

Du kannst aber auch mit 1200 Umdrehungen im Overdrive mit 120 cruisen, brauchst deutlich wenige Sprit aber klingt halt ned so sportlich am Auspuff. Also gibst Du Deinen Kunden finale Videos in 9Mbit!?



Antwort von klusterdegenerierung:

blueplanet hat geschrieben:
handbrake ist kostenlos, kein Hexenwerk und für User die in h.264 filmen ein Segen ;) ...und geht einem mächtig auf den Sack, weil es nach zig updates immer noch nicht in der Lage ist die Audio Sektion mit ins Preset zu speichern!
Jedes mal muß man den kompletten DTS quatsch und vordifinierte Bitraten rausnehmen und anpassen.

Nur laufen lassen, klar!



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
...und geht einem mächtig auf den Sack, weil es nach zig updates immer noch nicht in der Lage ist die Audio Sektion mit ins Preset zu speichern!
Jedes mal muß man den kompletten DTS quatsch und vordifinierte Bitraten rausnehmen und anpassen. ja -- ich finde das aufrufen von ffmpeg mit hilfe einfacher scripts auch wesentlich zielführender und besser kontrollierbar...

wobei ich in der hier diskutierten frage ohnehin ausschließlich die "crf"-option nutzen würde, um die tatsächliche bandbreite an den erfordernissen des konkreten materials bzw. der angestrebten qualität auszurichten!

https://trac.ffmpeg.org/wiki/Encode/H.264
https://slhck.info/video/2017/02/24/crf-guide.html



Antwort von prime:

rdcl hat geschrieben:
So viele Kameras sind es ja garnicht die h264 aufnehmen. Es ist halt insgesamt eine bestimmte Klasse von Kameras. Du wirst keine "Profi" Kamera finden die h264 movs aufnimmt. Wenn dann als Zusatzoption. Selbst die FS7 nimmt ja schon MXF auf. Die Verpackung von H264 in MOV, MXF oder MP4 macht bei der Bildqualität keinen Unterschied. FS7 nimmt auch H264 auf, nur eben in MXF verpackt.
rdcl hat geschrieben:
Ganz grob vereinfacht: Bei h264 ist nicht jedes Bild ein vollwertiges Bild, oder zumindest nicht immer. Spätestens Im Grading merkt man da den Unterschied zu Prores oder ähnlichem. Diese Verallgemeinerung greift viel zu kurz, H264 ALL-I mit ProRes ähnlichen Bitraten ist definitiv besser von der Bildqualität als ProRes, da einfach viel moderner und viel bessere Kompressionsverfahren verwendet werden können.



Antwort von rdcl:

klusterdegenerierung hat geschrieben:
"Frank Glencairn" hat geschrieben:


Du mußt dich von deinem Bitrate = Qualität Denken frei machen.

Die Bitrate ist nicht abhängig vom Preis der Maschine, die man im Bild sieht, sondern unter andrem von der Bewegung.
Wenn du ruhige Bilder hast, sieht deine Millionenmaschine auch bei 5mbit aus wie im Master. Wenn du mit besten Qualitätseinstellungen komprimierst, dauert das zwar länger, aber die Qualität ist tob und die Datenrate gering. Wenn du nicht die volle Qualität ausschöpfst, wird's halt ned ganz so gut, und die Datenrate steigt.

Ich mach mal ein Autobeispiel (was mit Fußballplätzen fällt mir gerade nicht ein).

Du kannst mit 7000 Umdrehungen im Ersten Gang rumeiern - macht soundmäßig mords Eindruck, verbraucht Sprit wie blöd, fährst dabei knapp über 60 kmh ...aber hey 7000 Umdrehungen!

Du kannst aber auch mit 1200 Umdrehungen im Overdrive mit 120 cruisen, brauchst deutlich wenige Sprit aber klingt halt ned so sportlich am Auspuff. Also gibst Du Deinen Kunden finale Videos in 9Mbit!? Laut diesem Thread bist du scheinbar der Einzige, bei dem Resolve nur 9 Mbit ausgibt.



Antwort von rdcl:

prime hat geschrieben:
rdcl hat geschrieben:
So viele Kameras sind es ja garnicht die h264 aufnehmen. Es ist halt insgesamt eine bestimmte Klasse von Kameras. Du wirst keine "Profi" Kamera finden die h264 movs aufnimmt. Wenn dann als Zusatzoption. Selbst die FS7 nimmt ja schon MXF auf. Die Verpackung von H264 in MOV, MXF oder MP4 macht bei der Bildqualität keinen Unterschied. FS7 nimmt auch H264 auf, nur eben in MXF verpackt.
rdcl hat geschrieben:
Ganz grob vereinfacht: Bei h264 ist nicht jedes Bild ein vollwertiges Bild, oder zumindest nicht immer. Spätestens Im Grading merkt man da den Unterschied zu Prores oder ähnlichem. Diese Verallgemeinerung greift viel zu kurz, H264 ALL-I mit ProRes ähnlichen Bitraten ist definitiv besser von der Bildqualität als ProRes, da einfach viel moderner und viel bessere Kompressionsverfahren verwendet werden können. Zu Punkt 1: MXF macht aber die Bearbeitung wesentlich einfacher.

Zu Punkt 2: Ich habe doch gesagt, dass das ganz grob vereinfacht ist. Trotzdem stimmt das nicht was du sagst. Die Kompressionsverfahren mögen besser sein, aber weniger bis keine Kompression ingesamt ist dem immernoch klar vorzuziehen. Es geht dabei ja nicht u die Bildqualität an sich, sondern um die Kompression und daraus resultierend die Bearbeitungsmöglichkeiten.

Natürlich hat sich h264 mittlerweile über einen Deliverycodec hinaus entwickelt, RAW, Prores oder DNx liegt da Qualitätsmäßig immernoch meilenweit drüber. Man muss sich schon auch fragen, inwieweit All-I h264 überhaupt Sinn macht. Es hat schon seinen Grund, dass sämtliche Cine-Kameras kein h264 aufzeichnen.






Antwort von mash_gh4:

prime hat geschrieben:
rdcl hat geschrieben:
So viele Kameras sind es ja garnicht die h264 aufnehmen. Es ist halt insgesamt eine bestimmte Klasse von Kameras. Du wirst keine "Profi" Kamera finden die h264 movs aufnimmt. Wenn dann als Zusatzoption. Selbst die FS7 nimmt ja schon MXF auf. Die Verpackung von H264 in MOV, MXF oder MP4 macht bei der Bildqualität keinen Unterschied. FS7 nimmt auch H264 auf, nur eben in MXF verpackt. grundsätzlich stimme ich dir da zu! -- wobei es halt innerhalb von h.264 auch noch ein weites spektrum an umsetzungsmöglichkeiten bzw. qualitätsabstufungen gibt -- also, ob z.b. CABAC zum einsatz kommt od. deutlich einfachere, aber natürlich auch unbefriedigendere, kompressionstechniken...
prime hat geschrieben:
rdcl hat geschrieben:
Ganz grob vereinfacht: Bei h264 ist nicht jedes Bild ein vollwertiges Bild, oder zumindest nicht immer. Spätestens Im Grading merkt man da den Unterschied zu Prores oder ähnlichem. Diese Verallgemeinerung greift viel zu kurz, H264 ALL-I mit ProRes ähnlichen Bitraten ist definitiv besser von der Bildqualität als ProRes, da einfach viel moderner und viel bessere Kompressionsverfahren verwendet werden können. mit dem bandbeitenbedarf von ProRes kann man fast schon die mathematisch völlig verlustfreien h.264-kompressionsvarianten benutzen!

...allerdings werden die nur von sehr wenig software unterstützt und sie sind auch relativ rechenaufwendig, so dass es in der praxis kaum sinn macht, sie tatsächlich zu nutzen... ;)



Antwort von prime:

rdcl hat geschrieben:
Zu Punkt 1: MXF macht aber die Bearbeitung wesentlich einfacher. Wie das denn? Der Rechner muss immer noch exakt den gleichen H264 Stream dekodieren. Mag sein das die eine oder andere Software einfach ne schlechte MP4/MOV Implementierung hat, das liegt dann aber an der Software nicht am Container.
rdcl hat geschrieben:
Zu Punkt 2: Ich habe doch gesagt, dass das ganz grob vereinfacht ist. Trotzdem stimmt das nicht was du sagst. Die Kompressionsverfahren mögen besser sein, aber weniger bis keine Kompression ingesamt ist dem immernoch klar vorzuziehen. Nimm die gleiche Bitrate etc. und das H264 Bild wird besser aussehen, auch bei ALL-I.
rdcl hat geschrieben:
Es geht dabei ja nicht u die Bildqualität an sich, sondern um die Kompression und daraus resultierend die Bearbeitungsmöglichkeiten. Natürlich macht es keinen Sinn in H264/10bit aufzuzeichnen, wenn es die Schnitt-Software nicht verarbeiten kann aber welche "Profi"-Software kann das inzwischen nicht?
rdcl hat geschrieben:
Natürlich hat sich h264 mittlerweile über einen Deliverycodec hinaus entwickelt... Mittlerweile? Die FS7 gibt es seit 2014. Die Canon DSLRs die ja sehr oft für 'professionelle' Zweck verwendet wurden nehmen in H264/MOV auf. Die ganze Sony A7 Reihe, alles H264/MP4.

rdcl hat geschrieben:
Prores oder DNx liegt da Qualitätsmäßig immernoch meilenweit drüber. Nicht bei gleicher Bitrate, diese Codecs so toll sie sein mögen, sind kein Vergleich zu H264 mit allen verfügbaren Tools. Bitte nicht ProRes HQ mit den H264 aus nen 50€ China Handy vergleichen.
rdcl hat geschrieben:
Man muss sich schon auch fragen, inwieweit All-I h264 überhaupt Sinn macht. Es hat schon seinen Grund, dass sämtliche Cine-Kameras kein h264 aufzeichnen. Wer nicht weis wie ProRes oder DNxHD funktionieren, dem kommt der Vergleich zu H264 ALL-I natürlich eigenartig vor.



Antwort von Jott:

"Natürlich hat sich h264 mittlerweile über einen Deliverycodec hinaus entwickelt, RAW, Prores oder DNx liegt da Qualitätsmäßig immernoch meilenweit drüber. Man muss sich schon auch fragen, inwieweit All-I h264 überhaupt Sinn macht."

Seit Jahren gibt es Sonys XAVC als 10Bit Intraframe. Ist H.264 - tut überhaupt nichts zur Sache, in welchem Container das steckt. Von Netflix als Produktionscodec für die eigenen Hochglanzprogramme akzeptiert. Und die sind bekanntlich pingelig, vielleicht die pingeligsten überhaupt. H.264 = Consumer ist arg veraltete Denke.



Antwort von rdcl:

prime hat geschrieben:
rdcl hat geschrieben:
Zu Punkt 1: MXF macht aber die Bearbeitung wesentlich einfacher. Wie das denn? Der Rechner muss immer noch exakt den gleichen H264 Stream dekodieren. Mag sein das die eine oder andere Software einfach ne schlechte MP4/MOV Implementierung hat, das liegt dann aber an der Software nicht am Container.
rdcl hat geschrieben:
Zu Punkt 2: Ich habe doch gesagt, dass das ganz grob vereinfacht ist. Trotzdem stimmt das nicht was du sagst. Die Kompressionsverfahren mögen besser sein, aber weniger bis keine Kompression ingesamt ist dem immernoch klar vorzuziehen. Nimm die gleiche Bitrate etc. und das H264 Bild wird besser aussehen, auch bei ALL-I.
rdcl hat geschrieben:
Es geht dabei ja nicht u die Bildqualität an sich, sondern um die Kompression und daraus resultierend die Bearbeitungsmöglichkeiten. Natürlich macht es keinen Sinn in H264/10bit aufzuzeichnen, wenn es die Schnitt-Software nicht verarbeiten kann aber welche "Profi"-Software kann das inzwischen nicht?
rdcl hat geschrieben:
Natürlich hat sich h264 mittlerweile über einen Deliverycodec hinaus entwickelt... Mittlerweile? Die FS7 gibt es seit 2014. Die Canon DSLRs die ja sehr oft für 'professionelle' Zweck verwendet wurden nehmen in H264/MOV auf. Die ganze Sony A7 Reihe, alles H264/MP4.

rdcl hat geschrieben:
Prores oder DNx liegt da Qualitätsmäßig immernoch meilenweit drüber. Nicht bei gleicher Bitrate, diese Codecs so toll sie sein mögen, sind kein Vergleich zu H264 mit allen verfügbaren Tools. Bitte nicht ProRes HQ mit den H264 aus nen 50€ China Handy vergleichen.
rdcl hat geschrieben:
Man muss sich schon auch fragen, inwieweit All-I h264 überhaupt Sinn macht. Es hat schon seinen Grund, dass sämtliche Cine-Kameras kein h264 aufzeichnen. Wer nicht weis wie ProRes oder DNxHD funktionieren, dem kommt der Vergleich zu H264 ALL-I natürlich eigenartig vor. Du kannst das gerne noch so oft behaupten wie du möchtest, h264 hat meiner Erfahrung nach keine höhere Qualität als Prores bei gleicher Bitrate.
Und mit Bearbeitungsmöglichkeiten meine ich hauptsächlich das Grading, und da sehe ich einfach permanent wie schnell die h264 Files aus genau den Kameras, die du eben angesprochen, auseinanderfallen, wo bei Prores noch ein Haufen Luft ist.



Antwort von rdcl:

Jott hat geschrieben:
"Natürlich hat sich h264 mittlerweile über einen Deliverycodec hinaus entwickelt, RAW, Prores oder DNx liegt da Qualitätsmäßig immernoch meilenweit drüber. Man muss sich schon auch fragen, inwieweit All-I h264 überhaupt Sinn macht."

Seit Jahren gibt es Sonys XAVC als 10Bit Intraframe. Ist H.264 - tut überhaupt nichts zur Sache, in welchem Container das steckt. Von Netflix als Produktionscodec akzeptiert. Und die sind bekanntlich pingelig, vielleicht die pingeligsten überhaupt. H.264 = Consumer ist arg veraltete Denke. Am Anfang war es ein Deliverycodec, jetzt unter bestimmten Umständen nicht mehr. ALso hat es sich herausentwickelt, oder nicht? h264 = Consumer habe ich nirgendwo geschrieben.



Antwort von Jott:

Sollte man Netflix mal sagen, dass Material beim Graden auseinander fällt, das sie für die Produktion akzeptieren. Haben sie ja vielleicht noch nicht mitgekriegt. Man gibt ja gerne mal Newcomern einen Tipp.



Antwort von rdcl:

Jott hat geschrieben:
Sollte man Netflix mal sagen, dass Material beim Graden auseinander fällt, das sie für die Produktion akzeptieren. Haben sie ja vielleicht noch nicht mitgekriegt. Welches Material genau wäre das denn? Lass mich raten, die Alphas sind es nicht?



Antwort von Jott:

Nein, wir reden von XAVC Intra.



Antwort von prime:

rdcl hat geschrieben:
Du kannst das gerne noch so oft behaupten wie du möchtest, h264 hat meiner Erfahrung nach keine höhere Qualität als Prores bei gleicher Bitrate. Haha - passt schon, soll jeder verwenden wie er oder sein Kunde es mag.
rdcl hat geschrieben:
Und mit Bearbeitungsmöglichkeiten meine ich hauptsächlich das Grading, und da sehe ich einfach permanent wie schnell die h264 Files aus genau den Kameras, die du eben angesprochen, auseinanderfallen, wo bei Prores noch ein Haufen Luft ist. Von den genannten Kameras ist ja nur eine die H264 in wirklich ordentlich hohen (vergleichbaren) Bitraten schreibt und das wäre die FS7. Da ist ProRes auch besser als H264?






Antwort von rdcl:

Jott hat geschrieben:
Nein, wir reden von XAVC Intra. Nein du redest davon. Mein Post bezog sich auf das hier: "Die FS7 gibt es seit 2014. Die Canon DSLRs die ja sehr oft für 'professionelle' Zweck verwendet wurden nehmen in H264/MOV auf. Die ganze Sony A7 Reihe, alles H264/MP4." Da könnte man höchstens die FS7 ausklammern, aber da sind die Datenraten in 4k jetzt auch nicht wahnsinnig hoch.



Antwort von cantsin:

Wie schon weiter oben geschrieben: Es ist ein verbreitetes Missverständnis, dass es sich bei h264 um einen Codec handelt.

Vielmehr handelt es sich um einen technischen Standard, der eine komplexe Menge von Kompressionsverfahren beinhaltet, die in Codecs implementiert werden können. x264 (Open Source) ist einer davon, Sonys XAVC einer anderer, das Intraframe-h264 der GH5 wiederum ein anderer etc.etc.

Um bei Franks Auto-Vergleich zu bleiben: h264 ist so etwas wie ein Otto-Motor. Es gibt alle möglichen Otto-Motoren, von Zweitakter-Trabbis bis zu Zwölfzylinder-BMWs, in Mofas, Motorrädern, Rasenmähern etc. Die Motorenkonstruktion wird jeweils an die benötigte Bauform angepasst.

Genauso ist es auch mit h264 in seinen verschiedenen Implementierungen von 50-Euro-Actionkamera bis hin zur Sony FS7, oder sogar den komplett verlustfreien Modi für Postproduktions-Zwecke.

Genauso wenig, wie es sinnvoll ist, um vom Attribut "Otto-Motor" auf die Qualität/Stärke eines Motors zu schließen, ist es sinnvoll, um vom Attribut "h264" Rückschlüsse auf die Qualität eines Codecs zu ziehen. Und so, wie beim Otto-Motor Attribute wie PS/kw und Umdrehungen pro Minute nicht wirklich etwas über dessen Qualität aussagen, sagt (wie hier schon oft wiederholt) die Bitrate per se noch nicht viel über die Qualität des encodierten Videos.



Antwort von prime:

rdcl hat geschrieben:
Am Anfang war es ein Deliverycodec, jetzt unter bestimmten Umständen nicht mehr. ALso hat es sich herausentwickelt, oder nicht? Nein, die FS7 gibt es seit 2014, alles H264 abgesehen von den paar XDCAM Optionen. Panasonic AVCIntra Linie, auch nur delivery codec nicht wahr?



Antwort von blueplanet:

cantsin hat geschrieben:
Wie schon weiter oben geschrieben: Es ist ein verbreitetes Missverständnis, dass es sich bei h264 um einen Codec handelt.

Vielmehr handelt es sich um einen technischen Standard, der eine komplexe Menge von Kompressionsverfahren beinhaltet, die in Codecs implementiert werden können. x264 (Open Source) ist einer davon, Sonys XAVC einer anderer, das Intraframe-h264 der GH5 wiederum ein anderer etc.etc.

Um bei Franks Auto-Vergleich zu bleiben: h264 ist so etwas wie ein Otto-Motor. Es gibt alle möglichen Otto-Motoren, von Zweitakter-Trabbis bis zu Zwölfzylinder-BMWs, in Mofas, Motorrädern, Rasenmähern etc. Die Motorenkonstruktion wird jeweils an die benötigte Bauform angepasst.

Genauso ist es auch mit h264 in seinen verschiedenen Implementierungen von 50-Euro-Actionkamera bis hin zur Sony FS7, oder sogar den komplett verlustfreien Modi für Postproduktions-Zwecke.

Genauso wenig, wie es sinnvoll ist, um vom Attribut "Otto-Motor" auf die Qualität/Stärke eines Motors zu schließen, ist es sinnvoll, um vom Attribut "h264" Rückschlüsse auf die Qualität eines Codecs zu ziehen. Und so, wie beim Otto-Motor Attribute wie PS/kw und Umdrehungen pro Minute nicht wirklich etwas über dessen Qualität aussagen, sagt (wie hier schon oft wiederholt) die Bitrate per se noch nicht viel über die Qualität des encodierten Videos. ...auf den Punkt gebracht! Wer sich die verlinkten Artikel von @mash_gh4 durchgelesen hat, sollte das verstanden haben ;)) Und deshalb sind wohl Adobe-Aplikationen & Co. in diesem Punkt eben nie so gut, wie opensource-Anwendungen. Wer den "Vorhang" nicht hochheben möchte, verwendet halt die Implementierung aus "Fertigprodukten". Wer das Maximum sucht, es frei konfigurieren will, greift zu handbrake und Co.



Antwort von Jott:

rdcl hat geschrieben:
Jott hat geschrieben:
Nein, wir reden von XAVC Intra. Nein du redest davon. Mein Post bezog sich auf das hier: "Die FS7 gibt es seit 2014. Die Canon DSLRs die ja sehr oft für 'professionelle' Zweck verwendet wurden nehmen in H264/MOV auf. Die ganze Sony A7 Reihe, alles H264/MP4." Da könnte man höchstens die FS7 ausklammern, aber da sind die Datenraten in 4k jetzt auch nicht wahnsinnig hoch. Auch der Bordcodec der sechs Jahre alten FS7 ist Netflix genehm. Auch wenn die Datenraten "nicht so wahnsinnig hoch" sind! :-)

Gilt auch für andere Sony-Kameras - und auch solche von anderen Herstellern - mit H.264-Codec. Von wegen "keine Cine-Kamera nutzt H.264".

Am besten an der Quelle stöbern und sich auf den Stand bringen. Ich zähle dort immerhin aktuell 13 (!) Kameras, deren interne H.264-Aufzeichnung die höchsten Weihen erhalten hat.

https://partnerhelp.netflixstudios.com/ ... ge-Capture



Antwort von klusterdegenerierung:

rdcl hat geschrieben:
klusterdegenerierung hat geschrieben:


Also gibst Du Deinen Kunden finale Videos in 9Mbit!? Laut diesem Thread bist du scheinbar der Einzige, bei dem Resolve nur 9 Mbit ausgibt. Tja, selbstverständlich entscheidet das Resolve nach Inhalt, dennoch habe ich keine Lust meinem Kunden eine 9Mbit Datei auszuhändigen und auch nicht noch Umwege über Handbrake etc. zu gehen.
Ich möchte 3-4 veschiedene Varianten in die Resolve Batch Ausgabe laden und einmal durchrendern.

Warum man mich hier missionieren will, statt ganz sachlich auf meinen Hinweis mit dem von BMD schlecht formulierten i-frame settings einzugehen und sich im besten Fall sogar für den Hinweis zu bedanken, ist mir doch kein Rätsel mehr, so seit ihr halt hier.
Unsinnig noch weiter darüber zu streiten, ihr werdet eh immer Recht behalten!!!!



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Warum man mich hier missionieren will, statt ganz sachlich auf meinen Hinweis mit dem von BMD schlecht formulierten i-frame settings einzugehen und sich im besten Fall sogar für den Hinweis zu bedanken, ist mir doch kein Rätsel mehr, so seit ihr halt hier.
Unsinnig noch weiter darüber zu streiten, ihr werdet eh immer Recht behalten!!!! Kluster, noch mal: Mit Reduzierung der i-Frames machst Du Dein Material bildqualitativ nicht besser, sondern Du reduzierst nur die Prozessor-Belastung beim Abspielen. Also Trade-Off: Prozessorbelastung vs. Dateigröße/Kompressionseffizienz.

Das hat nur Sinn, wenn Du Deinen Kunden Material für deren eigenen Schnitt liefern willst.

Warum nicht in Resolve ein DNxHR oder Cineform-Master rausrendern, Deine benötigten 3-4 h264-Profile in Handbrake vordefinieren und als Presets abspeichern, und damit die DNxHR/Cineform-Datei zu 3-4 mp4 in Handbrake per batch rausrendern? Ist nur ein Schritt mehr, liefert Deinen Kunden aber mehr Qualität.

Der h264-Codec von Resolve ist leider Sch...



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:
Warum man mich hier missionieren will, statt ganz sachlich auf meinen Hinweis mit dem von BMD schlecht formulierten i-frame settings einzugehen und sich im besten Fall sogar für den Hinweis zu bedanken, ist mir doch kein Rätsel mehr, so seit ihr halt hier.
Unsinnig noch weiter darüber zu streiten, ihr werdet eh immer Recht behalten!!!! Kluster, noch mal: Mit Reduzierung der i-Frames machst Du Dein Material bildqualitativ nicht besser, sondern Du reduzierst nur die Prozessor-Belastung beim Abspielen. Also Trade-Off: Prozessorbelastung vs. Dateigröße/Kompressionseffizienz.

Das hat nur Sinn, wenn Du Deinen Kunden Material für deren eigenen Schnitt liefern willst.

Warum nicht in Resolve ein DNxHR oder Cineform-Master rausrendern, Deine benötigten 3-4 h264-Profile in Handbrake vordefinieren und als Presets abspeichern, und damit die DNxHR/Cineform-Datei zu 3-4 mp4 in Handbrake per batch rausrendern? Ist nur ein Schritt mehr, liefert Deinen Kunden aber mehr Qualität.

Der h264-Codec von Resolve ist leider Sch... NOCHMAL cantsin,
ich habe hier lediglich offen gelegt wie man die settings doch beeinflussen kann, mehr nicht!
Und cantsin, gibst Du Deinen Kunden 9Mbit Daten für das viele Geld? Komisch, da schweigt sich jeder aus.

"mich" interessiert weder Handbrake, noch i frames, oder fahren im ersten Gang!
Ich habe hier lediglich was offengelegt was mir hier nach zig Anfragen niemand sagen konnte!

Ein simples Danke oder gut zu wissen und nun bekomme ich endlich die Größe die ich eingetragen habe, hätte gereicht, aaaaaber weeeeit gefehlt.
Ich weiß auch nicht wie alle immer darauf kommen das wenn man von a spricht, b automatisch nicht kennt, auch wenn man b kennt braucht man vielleicht mal a.



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
NOCHMAL cantsin,
ich habe hier lediglich offen gelegt wie man die settings doch beeinflussen kann, mehr nicht!
Und cantsin, gibst Du Deinen Kunden 9Mbit Daten für das viele Geld? Komisch, da schweigt sich jeder aus. Kluster, bei aller Liebe: Gibst Du Deinen Kunden künstlich aufgeblasene 35Mbit/s-Dateien für ihr Geld, die nur die Bildqualität von 9Mbit/s-Dateien haben? (Wie ein Fotograf, der seine Bilder in Lightroom als JPEG mit 40% JPEG-Qualität rausrechnet und dann anschliessend in 90%-JPEGs konvertiert?)






Antwort von prime:

Was ein Irsinn, man kann die Bitrate in Resolve einstellen und erhält auch Dateien mit der gewünschten Bitrate, ohne an den I-Frame Einstellung rumzuspielen. Das Zitat aus dem ersten Post ist von dir gänzlich missverstanden worden, er beschreibt da lediglich wie man einen ALL-I Stream generieren kann.
So you like the quality of a certain encoder because it has all-I frames, but don't want the bit rate so high. Im Delivery Tab einfach H264 Master auswählen (Resolve 16), Quality auf "Restrict to" und dann Bitrate einstellen, I-Frames auf Automatic lassen. Fertig. Es kommt ziemlich genau die Bitrate die man gefordert hat.



Antwort von Jörg:

Es kommt ziemlich genau die Bitrate die man gefordert hat. sicher, bei dir und bei mir und so ziemlich jedem Anderen hier...
Ich denke cantsins Ausführung zur Ausgabe in einen codec wie DNxHR/Cineform
anschließend eine Verarbeitung nach Maß, je nach Darbietungszweck, ist doch wohl bei
allen qualitätsbewussten Nutzernseit langem Standard.
FrankG nimmt uncompressed Material, wenns gut werden muss, und es denn der Plattenplatz hergibt.
Perfekt.



Antwort von klusterdegenerierung:

prime hat geschrieben:
Es kommt ziemlich genau die Bitrate die man gefordert hat. Wenn dem so wäre würde ich mich hier wohl kaum so einem dreisten bullshitbingo aussetzen!
Macht nur weiter so, hier unten am Boden ist die Luft wenigstens besser!



Antwort von Bluboy:

...Es kommt ziemlich genau die Bitrate die man gefordert hat.

Gibts bei Resolve AVC keine Variable Bitrate die nur das nimmt was sie braucht und der eingestellte Wert die obere Grenze darstellt ?



Antwort von klusterdegenerierung:

Ach ja, was ich noch vergessen habe hier alle Profis zu fragen, gebt ihr euren Kunden finale Videos in 9Mbit?

Aaach stimmt, ihr gebt denen ja garkeine 9Mbit files, ihr rendert ja in DNxHD 10Bit und konvertiert in Handbrake zu 30-60 Mbit h264!
Naaa das ist ja auch was ganz anderes, daa machen ja mehr als 9Mbit ja auch Sinn.

Und sorry an alle, das ich schon in Resolve mehr als 9Mbit haben möchte und immer nur 9Mbit raus kommt, egal ob ich 10000kbs oder 2000000kbs eingebe.
Wisst ihr was, ich mache es einfach wie ihr mit Handbrake und da nehme ich jetzt nach dem Globoli Prinzip nur noch 5Mbit bei 4K, wieso ist doch top!



Antwort von klusterdegenerierung:

Bluboy hat geschrieben:
...Es kommt ziemlich genau die Bitrate die man gefordert hat.

Gibts bei Resolve AVC keine Variable Bitrate ? Es kommt ziemlich genau, immer nur 9 bei meinem Testvideo raus, egal was ich eingebe, deswegen doch dieser Thread, denn mit dem Hinweis auf das keyframe feature, ist es mir zum ersten mal Möglich eine Wunschbitrate zu erzielen!

Ich habe zu dem Thema wohl schon 3 Threads erstellt und immer sagten alle, da bekommt man nicht mehr als was Resolve einem gibt, liegt am internen Codec usw.
Nun wo ich eine Lösung habe, sagen alle nö da kommt das raus was man will und man braucht auch garnicht viel.

In Premiere erzielt dieses Projekt jede gewünschte h264 Bitrate. Komisch, ich glaub Adobe hat keine Ahnung von Codecs.

Mir wird es hier zu blöd, macht ohne mich weiter.



Antwort von Bluboy:

Kluster - ich kann schon lesen nur Du willst halt kein anderes Video, eins mit mehr Farbe oder Bewegung mit den gleichen Einstellungen Testen.



Antwort von Frank Glencairn:

cantsin hat geschrieben:


Kluster, noch mal: Mit Reduzierung der i-Frames machst Du Dein Material bildqualitativ nicht besser, sondern Du reduzierst nur die Prozessor-Belastung beim Abspielen. Also Trade-Off: Prozessorbelastung vs. Dateigröße/Kompressionseffizienz.

Das hat nur Sinn, wenn Du Deinen Kunden Material für deren eigenen Schnitt liefern willst.
Darum geht's nicht.

Kluster doch gesagt, daß er so unsicher ist, daß er Angst davor hat der Kunde könnte was wegen der Datenrate sagen, und dann weiß er nicht was er antworten soll.

Es geht also nur um die Show vor dem Kunden - hohe Zahlen sind immer besser, vor allem wenn der Kunde sowieso keine Ahnung hat.

Deshalb bläst er das File jetzt künstlich mit I-Frames auf.
Spätestens wenn der Clip auf YT oder sonstwo online geht is sowieso Schluß mit lustig, dann wird wieder auf normale Datenrate runterkomprimiert.



Antwort von klusterdegenerierung:

Bluboy hat geschrieben:
Kluster - ich kann schon lesen nur Du willst halt kein anderes Video, eins mit mehr Farbe oder Bewegung mit den gleichen Einstellungen Testen. Ich tue es nicht mehr, noch mal, mein Video ist voller Farbe, voller Bewegung usw.
Bloß weil ich ein Problem habe oder es anders läuft als bei euch bin ich noch lange kein Idiot, jetzt ist gut!






Antwort von klusterdegenerierung:

"Frank Glencairn" hat geschrieben:
cantsin hat geschrieben:


Kluster, noch mal: Mit Reduzierung der i-Frames machst Du Dein Material bildqualitativ nicht besser, sondern Du reduzierst nur die Prozessor-Belastung beim Abspielen. Also Trade-Off: Prozessorbelastung vs. Dateigröße/Kompressionseffizienz.

Das hat nur Sinn, wenn Du Deinen Kunden Material für deren eigenen Schnitt liefern willst.
Darum geht's nicht.

Kluster doch gesagt, daß er so unsicher ist, daß er Angst davor hat der Kunde könnte was wegen der Datenrate sagen, und dann weiß er nicht was er antworten soll.

Es geht also nur um die Show vor dem Kunden - hohe Zahlen sind immer besser, vor allem wenn der Kunde sowieso keine Ahnung hat.

Deshalb bläst er das File jetzt künstlich mit I-Frames auf.
Spätestens wenn der Clip auf YT oder sonstwo online geht is sowieso Schluß mit lustig, dann wird wieder auf normale Datenrate runterkomprimiert. HAAAALLOOO?
Ich kann eine Wunschrate eingeben und sie wird nicht so gerendert, verstanden??????

Und noch ein fünftes mal, gibst Du beim Kunden finale Filme mit 9Mbit ab???????????????????????????????????????



Antwort von prime:

@kluster verwendest du Resolve 16?



Antwort von Bluboy:

Also Kluster, Du bist schon ziehmlich eigensinnig ;-)
Hättest Du nicht so ein komisches NLE dann könntest Du

Varialbe Bitrate
Constant Bitrate
Constant quantizier
Constant Qualität

einstellen

umsonst ist halt nur bedingt umsonst.



Antwort von pillepalle:

Ich habe gerade einmal nachgeschaut und bei mir bekam ich in Resolve eine 1080/25p h.264 mp4-Datei mit ca. 15,6 Mbit/s heraus (60 Minuten ca. 7GB Datei).

Welche Rolle spielt eigentlich der Encoder bei Handbrake? Da gibt's neben dem normalen h.264 auch noch 10bit h.264, IntelQSV und Nvidia NVEnc. Würde es Sinn machen eine 10bit DNxHR444 Datei in eine 10bit h264 MP4-umzuwandeln, oder lieber nicht? Und was spricht eigentlich gegen h265? Läuft das auf schlappen Rechnern weniger flüssig, oder warum verwenden das scheinbar nicht so viele Leute?

VG



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:

Ich kann eine Wunschrate eingeben und sie wird nicht so gerendert, verstanden??????
Datenraten sind eine technisch-mathematische Angelegenheit, und kein Wunschkonzert.
klusterdegenerierung hat geschrieben:

Und noch ein fünftes mal, gibst Du beim Kunden finale Filme mit 9Mbit ab??????????????????????????????????????? Hab ich dir beim ersten mal schon beantwortet - aber nochmal nur für dich:

Selbstverständlich! Warum auch nicht?

Meine Kunden sind nicht an irgendwelchen dubiosen Bitraten interessiert,
sondern ausschließlich an Bildqualität, und die passt bei mir immer.



Antwort von roki100:

am liebsten lese ich von kluster dieses "HAAALLLOOOO" ;)



Antwort von cantsin:

pillepalle hat geschrieben:
Würde es Sinn machen eine 10bit DNxHR444 Datei in eine 10bit h264 MP4-umzuwandeln, oder lieber nicht? Und was spricht eigentlich gegen h265? Das hängt vom Abspielsystem ab. Wenn Du eine Datei willst, die von allen gängigen HD-Medienplayern (inkl. Smart TVs) abgespielt wird, ist 1080p 8bit 4:2:0 mit maximal 18Mbit/s die sichere Bank. Alles darüber wird dann halt von weniger Systemen abgespielt.



Antwort von Bluboy:

@Kluster
zu Deiner entlastung: Hast recht, da sind Schweinereien im Gange ;-((



Antwort von prime:

Könnt ihr mal eure genau Resolve Version schreiben?

Bei mir in 16.1.2 krieg ich i.d.R. +/- 1-2 Mbit/s genau die gewünschte Bitrate.






Antwort von Bluboy:

Resolve sagt: You have the Latest Version



Antwort von prime:

Kann ich nicht reproduzieren...

Eingestellt: 25 Mbit/s
Resultat: 26.9 Mbit/s

Eingestellt: 35 Mbit/s
Resultat: 33.6 Mbit/s

Eingestellt: 50 Mbit/s
Resultat: 49.7 Mbit/s

Eingestellt: 75 Mbit/s
Resultat: 72.6 Mbit/s



Antwort von cantsin:

Nur mal um zu testen, wie gut die Qualität von 9 MBit/s 1080p h264 sein kann, wenn man den qualitativ besten Weg wählt:

- Ausgangsmaterial war eine von Blackmagic auf dieser Seite zum Download bereitgestelltes, mit der Pocket 4K aufgenommenes CinemaDNG-Testmaterial. Die Szene ist sehr anspruchsvoll für jeden stark komprimierenden Codec, weil sie viele organische Details, viel Bewegung (sowohl der Kamera, als auch des Motivs) und große Tiefenschärfe hat, und weil bei CinemaDNG keine Rauschfilterung in der Kamera stattfindet und jeder Pixel scharf gezeichnet wird.

- importiert in Resolve 16, Farbkorrektur per LUT nach Rec709, weiter keine Anpassungen/Filter/Bildveränderungen, rausgerendert als unkomprimierte Quicktime-Datei.

- die unkomprimierte Quicktime-Datei (5.8 GB) in Handbrake umgewandelt nach 9 Mbit/s h264, mit Optimierungsprofil "Film", 2-Pass-Encoding und Encoder-Preset "veryslow", resultierend in einer 48 MB-Datei - also eine Schrumpfung auf 0.8% der ursprünglichen Dateigröße.

Hier verlustfrei komprimierte 1:1-Framegrabs aus den beiden Dateien:

Link: Unkomprimiertes .mov, 0'22" (PNG-Framegrab)
Link: 9 Mbit/s .mp4, 0'22" (PNG-Framegrab)

Link: Unkomprimiertes .mov, 0'29" (PNG-Framegrab)
Link: 9 Mbit/s .mp4, 0'29" (PNG-Framegrab)

Link: 48 MB mp4-Datei

- Leider waren die Dateien zu groß, um sie direkt ins Forum hochzuladen. 1:1-Bildausschnitte zum vergleichenden Pixelpeeping:
test-22-mov-crop.png unkomprimiertes .mov

test-22-mp4-crop.png 9 Mbit/s .mp4



Antwort von Bluboy:

@Prime

Was hast Du denn für einen Rechner



Antwort von prime:

Windows 10 Laptop, i7 5600U / 8 GB RAM... also nix Highend ;-)



Antwort von Bluboy:

Prime
Hast Di irgendwo den Level eingestellt
und welche Bitrate hat Deine Quelle



Antwort von blueplanet:

cantsin hat geschrieben:
Das hängt vom Abspielsystem ab. Wenn Du eine Datei willst, die von allen gängigen HD-Medienplayern (inkl. Smart TVs) abgespielt wird, ist 1080p 8bit 4:2:0 mit maximal 18Mbit/s die sichere Bank. Alles darüber wird dann halt von weniger Systemen abgespielt. ...und von der verwendeten/gerenderten .fps-Zahl ab (z.B. 25 vs. 50)!

Wenn Opa "Karschunke" den Urlaubsfilm vom Sohnemann in seinen 3 Jahren alten, also für ihn damit nagelneuen Smart TV von S O N I I E ;)), mit 1080p, 8bit 4:2:0 (18Mbit/s) und in 50fsp produziert reinschiebt, steht mit großer Wahrscheinlichkeit da: "Kann nicht wiedergegenben werden". Das ist einfach TV-Prozessor abhängig und nicht weil S O N I I E sch... ist.
Und um das zu umschiffen, gibt es h.264-Profile, wie "Baseline", "Main", "High" etc. Diese wiederum müssen mit den zugehörigen "Leveln" gepaart werden, 4.0, 4.1, 4,2, 5.0....etc. + der damit einhergehenden (!) maximalen Datenrate. Diese wiederum liegt in der Regel näher bei 9 MBit/s als bei jeseits der 30. Dann klappts auch mit der Wiedergabe am heimischen Smart TV ;)

Ergo und wie so oft im Leben, man (n) muss wissen, wofür etwas gemacht wird bzw. sich auch an "mathematische Regeln" halten. Wie gesagt, solange das auf einem PC laufen soll, kein Thema, kann man "wild" drauf los experimentieren. Gern auch mit Datenraten jenseits der 50MBit/s (wenn"s dem Gewisssen und damit dem Anspruch gut tut). Jedoch spätestens zur Weitergabe für einen TV-Konsumenten, werden ganz klare Linien gezogen.



Antwort von prime:

Bluboy hat geschrieben:
Prime
Hast Di irgendwo den Level eingestellt
und welche Bitrate hat Deine Quelle Quelle ist Crowd_run Test Sequenz von hier:
https://media.xiph.org/video/derf/

Zum runterladen auf die Seite gehen und die entsprechende Datei per Rechtsklick -> Speichern unter abspeichern, sonst versucht der Browser es zu öffnen.

Die Datei mit ffmpeg zu QTRLE gewandelt, da Resolve die Y4M Datei nicht öffnet. ffmpeg -i crowd_run_1080p50.y4m -an -c:v qtrle crowd_run_1080p50_qtrle.mov Importiert in Resolve, Timeline/Projekt auf 25p lassen. Dann der Export mit je 25/35/50/75 Mbit/s. Bild1 exemplarisch nur für 25 Mbit/s, ansonsten hier die Einstellungen:
Export_1.PNG Export_2.PNG Export_3.PNG Export_4.PNG Ergebnis: Ergebnis.png Ausschnitte aus MediaInfo (Video Teil): Bit rate : 25.3 Mb/s Bit rate : 35.9 Mb/s Bit rate : 50.4 Mb/s Bit rate : 71.8 Mb/s Die Werte, die ich oben gepostet habe sind mit der gleicher Prozedur enstanden, nur die Quelldatei war ProRes 422 statt QTRLE kodiert.



Antwort von Bluboy:

Danke Prime
Werd das bei nächster Gelegeheit mit Deinen Parametern probieren und dann berichten



Antwort von Jörg:

bluplanet gibt zu bedenken
Jedoch spätestens zur Weitergabe für einen TV-Konsumenten,
werden ganz klare Linien gezogen. Das ist genau der Grund, warum ich bei "Prasentationen" auf unbekannten Terrain
kleine Dateien mitnehme, bzw einen Himedia als "Highend" Abspieler dabei habe.



Antwort von prime:

Nachtrag mit dem Bike clip den cantsin oben verlinkt hat (interpretiert als 25p), gleiches Spiel; 25/35/50/75 Mbit/s als Ziel.

Ergebnis: Bit rate : 22.0 Mb/s Bit rate : 30.7 Mb/s Bit rate : 41.4 Mb/s Bit rate : 58.6 Mb/s Sprich der Encoder ist weitaus früher gesättigt. Da müsste man einfach etwas höherschrauben um auf eine gewünschte Zahl zu kommen (wenn das entscheidend ist). An den Keyframes würde ich nach wie vor nicht rumschrauben.



Antwort von Video Rookie:

Hallo zusammen,

der Thread ist zwar schon ein paar Tage alt, aber ich bin auf ihn gestoßen, da auch ich mit Resolve Probleme mit der Bitrate beim Export hatte. Und ich kann nur sagen GOTT SEI DANK!!!!

Leute, mir wurden hier die Augen geöffnet, was es mit Codecs, Containern und Bitraten WIRKLICH auf sich hat. Ich habe das in Handbrake nachgestellt und wäre fast vom Glauben abgefallen, als ich sah, welche Qualität ich mit 9 mbit/s in h264 rauskriegen kann, wenn der Encoder top ist.

Also nochmal Danke an Euch alle! Bin jetzt öfter hier, um zu lernen :)

Eine Frage habe ich auch gleich:
Ich habe UHD Material 25p als Canon XF-AVC Format (.MXF Container). Wenn ich dieses Ausgangsmaterial fertig bearbeitet habe und ich Handbrake zwecks h264 Codierung nutzen möchte - in welchem Format empfehlt Ihr den Export aus Resolve? Quicktime uncompressed habe ich mir schon überlegt, aber bei ner halben Stunde Film wäre die Datenmenge ja gigantisch. Was schlagt Ihr vor?

Hoffentlich wird mein post noch gelesen…

VG



Antwort von klusterdegenerierung:

Servus!
Erstmal Dein Nickname sorgt gerade bei mir für etwas Belustigung, aber das nur am Rande.

Als Thread Ersteller kann ich nur auf den Rat einiger hier hören und guten Gewissens das rausrendern mit Resolves eigenem h265 empfehlen, denn der ist extremst effizient.
So bekommst Du damit auch bei kleinster Bitrate extrem gute Resultate, womit sich das rüberfummeln zu Handbrake eigentlich erledigt hat.

Ich sehe da keinen nennenswerten Unterschied mehr, es sei denn man will doch in höhere Bitregionen delivern. :-)



Antwort von Video Rookie:

Hey,
ich konnte dein Ausgangsproblem übrigens gut verstehen, einem zahlenden Kunden ein 9 mbit/s Vid in die Hand zu drücken fand ich zunächst auch strange. Ich würde da als Kunde wahrscheinlich auch erst mal blöd gucken. Aber die Hintergründe wurden hier echt gut erläutert.



Antwort von klusterdegenerierung:

Ja das stimmt und mir ging es Anfangs auch nicht gut dabei, wo man doch schon aus alten DSLRs 50Mbit Quicktimes bekam, aber das ist ja auch schon wieder viele Jahre her.

Es ist wohl wie in einer guten jpg Kompressionen, erstens wenn es nichts zu komprimieren gibt braucht es auch nicht viel Platz und wenn man einen guten Komprimierer hat, ist das komprimieren effizient und Nullmengen werden einfach garnicht mit aufgeblasen.

Das ich bei dem h265 mit teils nur 25bit kaum einen (zumindest nicht auf die Schnelle) großen Unterschied zum Original sehen kann finde ich verblüffend.
Die Handbrake Nummer hat zumindest bei mir oft zu Problemen geführt und die Anwendung selbst hat mich auch eher genervt, da habe ich dann lieber zum Media Encoder oder XMedia Recode gegriffen. :-)



Antwort von cantsin:

"Video Rookie" hat geschrieben:
Ich habe UHD Material 25p als Canon XF-AVC Format (.MXF Container). Wenn ich dieses Ausgangsmaterial fertig bearbeitet habe und ich Handbrake zwecks h264 Codierung nutzen möchte - in welchem Format empfehlt Ihr den Export aus Resolve? Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren.

Bezüglich klusters Empfehlung, direkt aus Resolve h265 zu rendern (was dann i.d.R. über den Hardware-Encoder der Grafikkarte läuft), würde ich einfach mal Vergleichstests machen.



Antwort von Video Rookie:

Danke Dir!



Antwort von TomStg:

cantsin hat geschrieben:
Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren. Dieser Intermediate-Umweg macht nun wirklich keinen Sinn, kostet nur Zeit und erzeugt eine völlig überflüssige zusätzliche verlustbehaftete Rendergeneration.



Antwort von Video Rookie:

Was würdest du stattdessen vorschlagen?



Antwort von srone:

TomStg hat geschrieben:
cantsin hat geschrieben:
Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren. Dieser Intermediate-Umweg macht nun wirklich keinen Sinn, kostet nur Zeit und erzeugt eine völlig überflüssige zusätzliche verlustbehaftete Rendergeneration. doch das macht er, da das damit erzeugte mp4, qualitativ weitaus besser als selbiges direkt aus resolve ist, probiers aus...;-)

lg

srone



Antwort von MK:

Falls die Studio Version von Resolve verwendet wird das kostenlose Voukoder Plugin installieren und damit per x264 oder x265, NVEnc oder diverse andere Codecs exportieren... besser wird's nicht mehr.



Antwort von srone:

gibts dazu nen link? danke...:-)

lg

srone



Antwort von MK:

srone hat geschrieben:
gibts dazu nen link? danke...:-)

lg

srone https://www.voukoder.org/



Antwort von klusterdegenerierung:

MK hat geschrieben:
Falls die Studio Version von Resolve verwendet wird das kostenlose Voukoder Plugin installieren und damit per x264 oder x265, NVEnc oder diverse andere Codecs exportieren... besser wird's nicht mehr. Hast Du da zufällig einen Link greifbar? ;-)



Antwort von klusterdegenerierung:

Ups!
Und das ist normal?

Sieht jetzt nicht gerade vertrauenswürdig aus, oder? ;-)



Antwort von MK:

Die Meldung ist falsch positiv... was der Bauer (Windows) nicht kennt usw...

Der Entwickler kommt aus Deutschland.



Antwort von MK:

Vom Entwickler:

"Windows zeigt Warnungen da der Installer und das eigentliche Plugin nicht digital signiert sind. Ein solches "EV Codesigning Certificate" kostet mehrere hundert Euro, hält max. 3 Jahre und muss dann immer wieder neu gekauft werden. Das kann ich mir für ein kostenloses Plugin nicht leisten."



Antwort von klusterdegenerierung:

Das ergibt Sinn, Danke Dir! :-)



Antwort von cantsin:

TomStg hat geschrieben:
cantsin hat geschrieben:
Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren. Dieser Intermediate-Umweg macht nun wirklich keinen Sinn, kostet nur Zeit und erzeugt eine völlig überflüssige zusätzliche verlustbehaftete Rendergeneration. Da wäre ich mir nicht so sicher - hier das Ergebnis eines Vergleichstest mit frischgedrehtem Material, den ich gerade mal veranstaltet habe:

nvenc_vs_h264.png (anklicken für Ansicht in Originalgröße)

Das Bild links wurde direkt aus Resolve als h265 bei 9000 MBit/s (Nvenc) exportiert, das Bild rechts erst als DNxHR HQX exportiert und dann mit ffmpeg mit dem x264-Codec zu 9000 MBit/s-h264 umcodiert.

Wohlgemerkt, die linke Hälfte ist das eigentlich modernere, effizientere und bei niedrigeren Bitraten bessere h265, die rechte Hälfte das ältere (aber zu mehr Abspielhardware kompatible) h264, beide bei gleicher Bitrate. Hier könnte man höchstens noch argumentieren, dass der Nvidia/Resolve-h265-Codec für eine u.U. willkommene Weichzeichnung/Gesichtsretusche sorgt...

Das Quellmaterial ist übrigens schnödes Long-GOP-4K-Video aus einer Panasonic S1H mit dem ebenfalls schnöden 24-105mm/f4-Zoom. Also keine Highend-Sachen wie Raw aus einer Cinekamera mit Zeiss Supreme Primes....


- Natürlich sind die diversen x264/x265-Third Party-Plugin-Hacks für Resolve ein Mittel, um das beste beider Ansätzen zu kombinieren, bzw. sich den Zwischenschritt über DNxHR oder ProRes zu sparen. Ich nutze allerdings die Linux-Version von Resolve, für die es AFAIK noch keine entsprechenden Lösungen gibt.



Antwort von MK:

Die Qualität von NVEnc ist für live oder Previews akzeptabel, für Mastering aber selbst bei hohen Bitraten kritisch, egal wie man die Einstellungen tweakt... Grain wird nicht sauber wiedergegeben und in sehr dunklen Bereichen gibt es Posterisationseffekte. Und ich rede hier von 4k mit 50 Mbit mit dem NVEnc der 20xx Generation.



Antwort von Frank Glencairn:

Ja. für ne schnelle Vorschau geh ich auch schon mal über Resolve raus, aber wenn es ernst wird, immer erst ein unkomprimiertes Master (brauch ich ja sowieso) und von da aus über Handbrake.



Antwort von Darth Schneider:

Resolve Studio 17 vs. Handbreak:

Ich rendere MP4/h624/h265 mittlerweile wieder alles direkt von Resolve Studio 17 aus der Timeline raus, mit 2K und mit 4K (aktuelle Version) ganz ohne Handbreak.

Ich hab das wirklich bis zum geht nicht mehr, erst kürzlich im Januar mit beiden Tools wirklich, ausführlich getestet und mit zig verschiedenen Bitraten und Einstellungen, die Ergebnisse wirklich, auf zwei schönen LG/Samsung HD Screens, direkt nebeneinander, immer wieder miteinander, verglichen.

Das Material aus der Kamera war 4K BBaw mit Q1 und 4K BRaw 8:1, 12Bit (Film)
Timeline eingestellt auf 4K, heraus rendern nur mit Full HD.
Beziehungsweise für die Handbremse auf zuerst 4K DnXHR..

Single Pass, Multipass, Auto, manuell, niedrige Bitrate, mittlere Bitrate, hohe Bitrate, mit mp4, QuickTime, H624, h265.
Alles quer durchs Band mit den beiden Programmen.

Mein (persönliches) Fazit:
Die Qualität der Ergebnisse sind, für meine Augen mittlerweile mit (Resolve Studio 17) eher ein wenig besser, ganz bestimmt nicht schlechter, als mit Handbreak.
In gar keiner Hinsicht.
Glaubt es mir oder glaubt es mir nicht…;)

Weitere Vorteile von Resolve:
Das Rendern geht mit Resolve zumal gefühlt etwas schneller und die zusätzliche mit etwas Verlust behaftete Umwandlung zuerst in ProRes/DnXHR für die Handbremse entfällt so ganz.
Ich nutze Handbreak somit gar nicht mehr, weil für mich sehe ich dafür mittlerweile überhaupt keinen Grund.
Für mich stimmt es was da BMD mit Resolve direkt auf den Speicher Stick so zaubert…

Ich bin mir ganz sicher BMD hat diesbezüglich bei der Studio Version 17 sehr stark aufgeholt. Bei der Version 16 und 15 war das Ergebnis nicht so gut und der Mac ist mir früher beim rendern auch öfters abgestürzt.
Heute gar nicht mehr.

Wie sehen die erfahrenen Profi Augen das ?;)
Würde ich interessieren.
Gruss Boris



Antwort von TomStg:

Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar. Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu.

Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen. Aber auch in diesem Fall ist ein verlustbehafteter Intermediate-Codec keine Option. Eine Ausgabe mit einem verlustlosen Codec oder unkompromiert ist aus Qualitätsgründen klar sinnvoller.



Antwort von Darth Schneider:

Nun gut wenn jetzt jemand natürlich ein verlustloses Master braucht um später was auch immer damit zu machen, wird Handbreak sicher sinnvoll sein müssen.
Keine Ahnung ?
Ich weiss auch nicht was dann diesbezüglich in Resolve Studio überhaupt damit geht und was nicht.

Da oben beim kleinen Erfahrungsbericht, hab ich mich nur auf meine ganz eigenen Erfahrungen bezogen…
Gruss Boris



Antwort von dienstag_01:

TomStg hat geschrieben:
Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar. Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu.

Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen. Aber auch in diesem Fall ist ein verlustbehafteter Intermediate-Codec keine Option. Eine Ausgabe mit einem verlustlosen Codec oder unkompromiert ist aus Qualitätsgründen klar sinnvoller. Für PC ist das schon lange nicht mehr die Realität, siehe Voukoder, mit Mac kenne ich mich nicht aus. Dann müssten Resolve und Premiere in MAC/PC andere Codecs verbaut haben, weiß nicht.



Antwort von Frank Glencairn:

TomStg hat geschrieben:
Falls das Delivery-Modul eines aktuellen NLE mit H264/265 ... Daß x264 bessere Qualität und geringere Datenraten hat als 264, ist jetzt aber auch nix neues.
Allerdings stellt sich die Frage dank Voukoder auch nicht mehr.

Da ich immer ein unkomprimiertes Master raus rechnen muß, hab ich davon aber auch nicht wirklich was :D



Antwort von Video Rookie:

Frank, welches Format verwendest Du für Dein Master?



Antwort von Frank Glencairn:

Unkomprimiertes AVI



Antwort von klusterdegenerierung:

Avi!
Avi kenn ich nur von damals aus der Schmuddel oder Raubkopie Ecke, ist das was vernünftiges?



Antwort von roki100:

cantsin hat geschrieben:
"Video Rookie" hat geschrieben:
Ich habe UHD Material 25p als Canon XF-AVC Format (.MXF Container). Wenn ich dieses Ausgangsmaterial fertig bearbeitet habe und ich Handbrake zwecks h264 Codierung nutzen möchte - in welchem Format empfehlt Ihr den Export aus Resolve? Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren.

Bezüglich klusters Empfehlung, direkt aus Resolve h265 zu rendern (was dann i.d.R. über den Hardware-Encoder der Grafikkarte läuft), würde ich einfach mal Vergleichstests machen. also ich habe das schon öfter vergleichen und hab mich immer wieder doch für Handbrake entschieden. Die Files sind kleiner und dennoch bessere Qualität.



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:
Avi!
Avi kenn ich nur von damals aus der Schmuddel oder Raubkopie Ecke, ist das was vernünftiges? LOL :D

https://de.wikipedia.org/wiki/Audio_Video_Interleave



Antwort von cantsin:

TomStg hat geschrieben:
Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar. Das hat nichts mit dem NLE zu tun, sondern ist die Qualität von Nvidias Hardware-Encoder (Nvenc). D.h. auf jedem NLE, bei dem Du via Nvenc/mit Nvidia Hardware-Beschleunigung nach h264 oder h265 rausrenderst, kriegst Du diese Bildqualität.

Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu. Weil unter MacOS keine Nvidia-Karten und damit auch nicht Nvenc gebraucht werden.
Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen. Du glaubst doch nicht ernsthaft, dass man bei 9Mbit/s-h264 irgendeinen Unterschied sieht (bzw. sich auch nur ein relevanter Pixel dadurch verändert), wenn das Master unkomprimiertes Video ist oder mit einem niedrig komprimierten Codec wie ProRes oder DNxHR rausgerendert wurde...

Da stellst Du ja höhere Qualitätsansprüche als Hollywood-Postproduktionshäuser.



Antwort von klusterdegenerierung:

Ja und dann macht man den 4K unkomprimierten Master Max und anschliessend landet es mit 10Mbit und 720p in der Mediathek. :-)



Antwort von cantsin:

Es wäre übrigens interessant, mal einen Performance- und Bildqualitäts-Shootout der Hardware-h264/h265-Encoder von Nvidia (Nvenc), AMD (VCE), Intel (QuickSync) und Apple (M1-interner Encoder) zu machen: Wie schnell rendern sie jeweils auf grob vergleichbarer Hardware, und wie gut ist die Bildqualität ihres Outputs bei verschiedenen Bitraten?

Auch Nvenc hat, trotz seiner Qualitätsabstriche, ja durchaus seinen Platz, wenn man z.B. ein Blog-/Nachrichten-Video sehr schnell rausrendern, uploaden oder jemandem mitgeben will. Dann wählt man eben eine höhere Bitrate, um die Qualitätseinbußen zu kompensieren.

Auch bei meinem weiter oben geposteten Beispiel wäre ja die Frage, ob man die Qualitätsunterschiede zwischen Nvenc und Handbrake/ffmpeg/x264/x265 überhaupt noch sieht, nachdem das Video z.B. auf YouTube hochgeladen wurde. Bei anderen Social Media-Plattformen wie Facebook, Instagram und Twitter und deren mieser Videobildqualität wird es da garantiert keinen sichtbaren Unterschied geben, insofern spricht bei denen sowie nichts gegen Nvenc (und kann man sich den erhöhten Renderaufwand mit x264/x265 sparen)...



Antwort von klusterdegenerierung:

Unterm Strich heißt das, das Nvidia so schnelle ist, weil er das Bild nicht in so einer guten Quali bzw guten Kompression rausschickt?
Und das heißt auch, das dann selbst der h264 nicht Nvidia eine bessere Quali liefer und man nichtmal viel von der 10Bit Option hat?



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Unterm Strich heißt das, das Nvidia so schnelle ist, weil er das Bild nicht in so einer guten Quali bzw guten Kompression rausschickt?
Und das heißt auch, das dann selbst der h264 nicht Nvidia eine bessere Quali liefer und man nichtmal viel von der 10Bit Option hat? Ja, leider - Prinzip "quick and dirty". Ich werd' gleich noch mal einen Versuch machen mit dem Nvidia-Encoder in höchster Qualitätseinstellung und 10bit.


EDIT - Voilà:
x264 vs nvenc.png (2x anklicken für 1:1-Ansicht)



Antwort von klusterdegenerierung:

Mich hat Handbrake und dieses Theater mit den Profilen die nicht komplett so gespeichert werden können wie man möchte ziemlich angenervt.
Ständig diese abstellen von Audio 5.1 etc. als wenn das blöde Teil sich das nicht einfür allemal merken kann. ;-)



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Mich hat Handbrake und dieses Theater mit den Profilen die nicht komplett so gespeichert werden können wie man möchte ziemlich angenervt.
Ständig diese abstellen von Audio 5.1 etc. als wenn das blöde Teil sich das nicht einfür allemal merken kann. ;-) Kommandozeile und ffmpeg lernen, dann kannst Du die ganze Chose skripten und Dir sehr leicht verschiedene Presets bauen...



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
EDIT - Voilà: Hui, da hat man ja schon die Beautyretusche mit drin, easy! ;-)))



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
ffmpeg lernen Das ist für mich ungefähr wie mal eben Alu Schweißen lernen. ;-))



Antwort von klusterdegenerierung:

Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon?



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon? Dann kannst Du in der Tat direkt in x264/x265 rausrendern, als mit denselben Codecs (und in derselben Qualität) wie Handbrake, aber deutlich langsamer .



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:
Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon? Dann kannst Du in der Tat direkt in x264/x265 rausrendern, als mit denselben Codecs (und in derselben Qualität) wie Handbrake, aber deutlich langsamer . Also ich gehe dann jetzt genauso wie vorher auf mp4 Container und dann auf h264, oder auf h264 Nvidia, oder ganz anders?
Was muß ich dann für Werte anvisieren wenn ich was davon haben will?

Das heißt das ich dadurch jetzt sozusagen Handbrake in Resolve habe?



Antwort von MK:

Mit dem Voukoder kann man auch NVEnc nutzen. Dort mit mehr Einstellmöglichkeiten. x264 bzw. x265 ist doch auch in Handbrake nicht über die GPU beschleunigt?



Antwort von klusterdegenerierung:

Hatte ich mir auch gedacht denn das hat immer ne Ewigkeit gerendert.



Antwort von cantsin:

MK hat geschrieben:
Mit dem Voukoder kann man auch NVEnc nutzen. Dort mit mehr Einstellmöglichkeiten. x264 bzw. x265 ist doch auch in Handbrake nicht über die GPU beschleunigt? Ja, das meinte ich.

Es ist völlig egal, ob man x264/x265 via Vokouder, Handbrake, ffmpeg, Shutter Encoder oder welches Interface auch immer verwendet. Das Encodieren läuft bei x264 und x265 immer ausschließlich über die CPU und ist rechenaufwändiger, daher deutlich langsamer, aber eben auch im Resultat qualitativ besser als Nvenc und andere Hardware-Codecs.



Antwort von klusterdegenerierung:

Das verstehe ich nur bedingt, denn all die zusätzlichen features die man nun damit bekommen hat, befinden sich doch lediglich unter dem schlechteren Nvidia Codec, bei den anderen hat sich doch überhaupt nix geändert, was soll denn dann jetzt gleich sein wie bei Handbrake, sorry?



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Das verstehe ich nur bedingt, denn all die zusätzlichen features die man nun damit bekommen hat, befinden sich doch lediglich unter dem schlechteren Nvidia Codec, bei den anderen hat sich doch überhaupt nix geändert, was soll denn dann jetzt gleich sein wie bei Handbrake, sorry? Noch mal langsam:

h264 und h265 sind keine Codecs, sondern standardisierte Videoformate. Beide Videoformate haben ziemlich ausufernde Features. Wie wir wissen, werden nicht alle dieser Features auf allen Abspielgeräten unterstützt (z.B. 10bit h264 oder generell h264 "High" Profile i.d.R. nicht von einfachen Medienspielern). Das ist die Decoderseite.

Auf der Encoderseite sieht es ähnlich aus: Es gibt simplere und komplexere Encoder, die jeweils bestimmte Untermengen der Features von h264 und h265 unterstützen.

x264 und x265 sind zwei (sehr verbreitete) Open Source-Codecs für h264- bzw. h265-kompatibeles Video, die die Featuresets dieser beiden Formate weitgehend abdecken und auf Bildqualität getrimmt sind. Sie laufen, auch aus Kompatibilitätsgründen, ausschließlich auf der CPU und machen keinen Gebrauch von GPU-Beschleunigung. Programme wie ffmpeg, Handbrake, ShutterEncoder, Voukoder verwenden diese beiden Codecs und agieren letztlich nur als Interfaces dafür. Es ist also weitgehend egal, ob man h264-Video mit Handbrake oder Voukoder encodiert - in beiden Fällen arbeitet unter der Haube x264. Der Unterschied liegt allein darin, welche der ausufernden Features von x264 Handbrake, Voukoder oder andere Programme über ihre Benutzerinterface zugänglich machen, bzw. welche Presets sie für x264 verwenden.

Daneben gibt es noch alle möglichen anderen Encoder für h264 und h265, von anderen Softwareherstellern wie z.B. Main Concept. (Der Main Concept-h264-Encoder wird AFAIK in Adobe Premiere verwendet, und zwar immer dann, wenn man in Premiere h264-Video exportiert.)

Neben diesen reinen Software-Encodern gibt es noch die Hardwareencoder von Nvidia, AMD, Intel und Apple, die als feste Chipfunktion direkt ins Silizium der GPUs eingebaut sind. Wenn Resolve also per Nvenc h264 exportiert, schickt es einen unkomprimierten Videostrom an die Grafikkarte, die dann mit ihrer Chiphardware h264 erzeugt und an den Computer zurückschickt.

Diese Hardware-Codecs sind vor allem auf Schnelligkeit optimiert und unterstützen nur eine kleine Untermenge der möglichen Features des h264- und h265-Formats. Sie sind auch qualitativ nur so gut, wie sie im Chip implementiert bzw. fest eingegossen sind. D.h. es gibt (im Gegensatz zu den Software-Encodern) keine Möglichkeit, sie über neue Versionen bzw. Softwareupdates zu verbessern.



Antwort von dienstag_01:

Also für Resolve 17 muss ich meine Aussage auf jeden Fall dahingehend revidieren, dass das h264-Encoding sowohl mit Nvenc wie auch nativ direkt aus Resolve qualitativ keine Nachteile hat. Habe ich gerade nochmal getestet.
Damit sage ich nichts über die Effizienz, also dem Verhältnis von Qualität zu Datenrate, ich habe nur auf die Qualität geschaut.

D.h. für den Upload auf eine Plattform, die sowieso nochmal encodet, muß man den Weg über ein Intermediate eigentlich nicht gehen.

Mein persönlicher Workflow sieht so aus, dass ich mir angewöhnt habe, Previews mit 3,5 Mbits für 1080p25 zu versenden.
Ich denke, an diese Effizienz von x264 kommt h264 nicht ran.



Antwort von dosaris:

dienstag_01 hat geschrieben:
... das h264-Encoding sowohl mit Nvenc wie auch nativ direkt aus Resolve qualitativ keine Nachteile hat. Habe ich gerade nochmal getestet.
Damit sage ich nichts über die Effizienz, also dem Verhältnis von Qualität zu Datenrate, ich habe nur auf die Qualität geschaut.
...
Mein persönlicher Workflow sieht so aus, dass ich mir angewöhnt habe, Previews mit 3,5 Mbits für 1080p25 zu versenden.
Ich denke, an diese Effizienz von x264 kommt h264 nicht ran. hä?
x264 generiert h264.

Mit Avidemux geht encoding wahlweise via x264 als auch mit NVidia-Encoder.

Mein EIndruck dazu ist, ist dass X264 bei gleicher Datenrate bessere Bildqualität generieren kann,
bzw umgekehrt benötigt der NVidia-Encoder für gleiche Bildqualität höhere Datenrate.

Wenn's für den Empfänger machbar ist solltest Du bei x264 mit VBR encoden,
da das BW-budget stark von Komplexität und Varianz abhängt.
dto für x265 (was nur ein superset von 264 ist)
Da kann 3.5 Mbps manchmal zu knapp sein.

Leider fehlt mir noch ein gutes Tool, das 2 Videostreams messtechnisch vergleicht und Differenzen darstellen kann.

Was nutzt ihr dafür?



Antwort von Video Rookie:

Ich putze dafür meine Brillle mit Spezialtüchern.



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
Noch mal langsam:
h264 und h265 sind keine Codecs cantsin hat geschrieben:
x264 und x265 sind zwei (sehr verbreitete) Open Source-Codecs Aha!
Desweiteren hat Dein ellenlanger Text sogarnichts mit meiner Frage an Dich zu tun.
Du sagtest ja das ich nun durch die erweiterten settings von Voukoder im Grunde die gleichen features habe wie in Handbrake und das ich im Grunde Handbrake damit in Resolve bekomme, weil die Quali dann vergleichbar ist.

Aber wenn Du auf der einen Seite schreibst, das man dies den erweiterten settings von Voukoder zu verdanken hat, man aber auf der anderen Seite mit der Nvidia Option die schlechtere quali bekommt und dem so ist, dann muß man ja in dem normalen nicht Nvidia h264 codec nun auch die erweiterten settings habe, aber dem ist ja nicht so, es hat sich ja rein garnichts geändert, wieso sollte ich dann nun eine bessere Quali als vor Voukoder bekommen?

Vorher hatte ich ja auch kaum features und nun auch nicht und die vielen features im Nvidia Bereich sind ja uninteressant wenn der eh nix taugt.
Also was soll sich nun geändert haben und warum, ist doch alles wie vorher, ausser das ich bei h264 die Nvidia Option dazu bekommen habe, die man ja eh meiden sollte?



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
cantsin hat geschrieben:
Noch mal langsam:
h264 und h265 sind keine Codecs cantsin hat geschrieben:
x264 und x265 sind zwei (sehr verbreitete) Open Source-Codecs Aha! Die Verwirrung liegt wirklich in der Namensgebung. Bei h264 vs. x264 blickt halt niemand mehr richtig durch. Das wäre so, als wenn es nicht PDF und Acrobat gäbe, sondern (ein Format) "PDF" und (ein Programm) "QDF" und niemand mehr begreift, was nun was ist. (Vor allem, wenn da Dir dann Programme wie InDesign für den PDF-Export in ihrem Nutzerinterface noch "PDF" und "QDF" als Alternativen auflisten würden - da wird dann das Nomenklatur-Chaos komplett.)

Du sagtest ja das ich nun durch die erweiterten settings von Voukoder im Grunde die gleichen features habe wie in Handbrake Ja.
und das ich im Grunde Handbrake damit in Resolve bekomme, weil die Quali dann vergleichbar ist. Ja. Bzw., ganz korrekt: Handbrake und Voukoder benutzen unter der Haube denselben Encoder, nämlich x264 .

Aber wenn Du auf der einen Seite schreibst, das man dies den erweiterten settings von Voukoder zu verdanken hat, man aber auf der anderen Seite mit der Nvidia Option die schlechtere quali bekommt und dem so ist, dann muß man ja in dem normalen nicht Nvidia h264 codec nun auch die erweiterten settings habe, aber dem ist ja nicht so, es hat sich ja rein garnichts geändert, wieso sollte ich dann nun eine bessere Quali als vor Voukoder bekommen? Nochmals, x264 und der Nvidia-Encoder haben nichts miteinander zu tun. Es sind zwei völlig verschiedene Encoder-Programme, so wie z.B. Acrobat und Foxit zwei verschiedene PDF-Encoder sind, die jeweils auf ihre völlig eigene Weise Dateien erzeugen, die dem PDF-Standard entsprechen.

Es ist nicht so, dass es da ein Set von Software-Features gibt, und der Nvidia-Codec gibt Dir ein Teil davon und x264 gibt Dir obendrauf (sozusagen als Plugin) noch Extra-Features. Sondern das ist so, als wenn Du einen PDF-Erzeuger A hast, der nur rudimentäres PDF erzeugt , dafür aber sehr schnell, und einen anderen PDF-Erzeuger B, der Dir auch alle erweiterten Funktionen von PDF erschliesst und eingebettete Grafiken qualitativ besser abspeichert, aber dafür längere Rechenzeit braucht.


Vorher hatte ich ja auch kaum features und nun auch nicht und die vielen features im Nvidia Bereich sind ja uninteressant wenn der eh nix taugt.
Also was soll sich nun geändert haben und warum, ist doch alles wie vorher, ausser das ich bei h264 die Nvidia Option dazu bekommen habe, die man ja eh meiden sollte? Wenn Du in Vokouder x264 statt Nvidia verwendest, kriegst Du halt höherqualitatives Video (um den Preis längerer Renderzeiten).



Antwort von srone:

hast du denn auch alles in resolve ordentlich installiert?

es gilt 2 komponenten von der entwicklerseite zu laden und zu installieren.

und um es vielleicht noch einmal einfacher zu erklären, x-264 erreicht eben über seine lange renderzeit und "cpu-use only" seine finale qualität.

da gehts eben mal nicht um speed - wie wenn ich 8k in echtzeit auf eine sd-karte wegschreiben wöllte - sowas klappt nur in hardware, ist aber auf eine bestimmte qualität festgelegt.

der x-264 codec lässt sich zeit und das ist sehr gut so, weil finales codieren kein echtzeitszenario ist.

lg

srone



Antwort von roki100:

"Darth Schneider" hat geschrieben:
Wie sehen die erfahrenen Profi Augen das ?;)
Würde ich interessieren. Also wenn Du mich fragst, dann ganz klar Hanbrake.



Antwort von dienstag_01:

Wenn Du in Vokouder x264 statt Nvidia verwendest, kriegst Du halt höherqualitatives Video (um den Preis längerer Renderzeiten). Das ist nicht richtig.
Man bekommt mit Nvidia, also Nvenc, (und native) die gleiche Qualität bei höherer Datenrate.

Oder sagen wir so, ich wäre extrem vorsichtig mit so einer Aussage.



Antwort von srone:

dienstag_01 hat geschrieben:
Wenn Du in Vokouder x264 statt Nvidia verwendest, kriegst Du halt höherqualitatives Video (um den Preis längerer Renderzeiten). Das ist nicht richtig.
Man bekommt mit Nvidia, also Nvenc, (und native) die gleiche Qualität bei höherer Datenrate.

Oder sagen wir so, ich wäre extrem vorsichtig mit so einer Aussage. nein, diesselbe qualität, definitiv nicht, ich habe für meine kurzfilme beides getested, egal wieviel bitrate der nvidia encoder bekommt (open end), das ergebnis ist, wie soll ich sagen "weich" gegen den x-264, cantsin hat das sehr anschaulich oben gezeigt, aber vielleicht ist ja gpu codieren der neue pro-mist...;-)

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Das ist nicht richtig.
Man bekommt mit Nvidia, also Nvenc, (und native) die gleiche Qualität bei höherer Datenrate.

Oder sagen wir so, ich wäre extrem vorsichtig mit so einer Aussage. nein, diesselbe qualität, definitiv nicht, ich habe für meine kurzfilme beides getested, egal wieviel bitrate der nvidia encoder bekommt (open end), das ergebnis ist, wie soll ich sagen "weich" gegen den x-264, cantsin hat das sehr anschaulich oben gezeigt, aber vielleicht ist ja gpu codieren der neue pro-mist...;-)

lg

srone Nein, cantsins Beispiel ist nicht bei voller Datenrate. Und das ist auch das Problem.



Antwort von dosaris:

srone hat geschrieben:

nein, diesselbe qualität, definitiv nicht, ich habe für meine kurzfilme beides getested, egal wieviel bitrate der nvidia encoder bekommt (open end), das ergebnis ist, wie soll ich sagen "weich" gegen den x-264, cantsin hat das sehr anschaulich oben gezeigt, aber vielleicht ist ja gpu codieren der neue pro-mist...;-) ich gehe davon aus, dass beide Aussagen richtig sein können,
denn auch unterschiedliche GPUs - und deren interne Firmware - können unterschiedlich gute Encoder enthalten.

Es wäre sogar möglich, dass - zB per OpenGL - ein encoder-Prog in die GPU geschaufelt wird, dass gleich gute Resultate liefert
aber per starker Parallelisierung deutlich schneller ist als CPU-Encoding.

Macht aber mW niemand, leider!



Antwort von cantsin:

dienstag_01 hat geschrieben:
srone hat geschrieben:


nein, diesselbe qualität, definitiv nicht, ich habe für meine kurzfilme beides getested, egal wieviel bitrate der nvidia encoder bekommt (open end), das ergebnis ist, wie soll ich sagen "weich" gegen den x-264, cantsin hat das sehr anschaulich oben gezeigt, aber vielleicht ist ja gpu codieren der neue pro-mist...;-)

lg

srone Nein, cantsins Beispiel ist nicht bei voller Datenrate. Und das ist auch das Problem. Mein letztes Beispiel sehr wohl - einmal volle Datenrate Nvenc (10bit 4:4:4), einmal Nvenc 9MBit/s, einmal x264 9Mbit/s. Allerdings ist meine Grafikkarte eine nicht mehr ganz taufrische GTX1080-Ti. Könnte also sein, dass der NVenc in den neueren GPU-Generationen besser ist.



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:


Aha! Die Verwirrung liegt wirklich in der Namensgebung. Bei h264 vs. x264 blickt halt niemand mehr richtig durch. Das wäre so, als wenn es nicht PDF und Acrobat gäbe, sondern (ein Format) "PDF" und (ein Programm) "QDF" und niemand mehr begreift, was nun was ist. (Vor allem, wenn da Dir dann Programme wie InDesign für den PDF-Export in ihrem Nutzerinterface noch "PDF" und "QDF" als Alternativen auflisten würden - da wird dann das Nomenklatur-Chaos komplett.)

Du sagtest ja das ich nun durch die erweiterten settings von Voukoder im Grunde die gleichen features habe wie in Handbrake Ja.
und das ich im Grunde Handbrake damit in Resolve bekomme, weil die Quali dann vergleichbar ist. Ja. Bzw., ganz korrekt: Handbrake und Voukoder benutzen unter der Haube denselben Encoder, nämlich x264 .

Aber wenn Du auf der einen Seite schreibst, das man dies den erweiterten settings von Voukoder zu verdanken hat, man aber auf der anderen Seite mit der Nvidia Option die schlechtere quali bekommt und dem so ist, dann muß man ja in dem normalen nicht Nvidia h264 codec nun auch die erweiterten settings habe, aber dem ist ja nicht so, es hat sich ja rein garnichts geändert, wieso sollte ich dann nun eine bessere Quali als vor Voukoder bekommen? Nochmals, x264 und der Nvidia-Encoder haben nichts miteinander zu tun. Es sind zwei völlig verschiedene Encoder-Programme, so wie z.B. Acrobat und Foxit zwei verschiedene PDF-Encoder sind, die jeweils auf ihre völlig eigene Weise Dateien erzeugen, die dem PDF-Standard entsprechen.

Es ist nicht so, dass es da ein Set von Software-Features gibt, und der Nvidia-Codec gibt Dir ein Teil davon und x264 gibt Dir obendrauf (sozusagen als Plugin) noch Extra-Features. Sondern das ist so, als wenn Du einen PDF-Erzeuger A hast, der nur rudimentäres PDF erzeugt , dafür aber sehr schnell, und einen anderen PDF-Erzeuger B, der Dir auch alle erweiterten Funktionen von PDF erschliesst und eingebettete Grafiken qualitativ besser abspeichert, aber dafür längere Rechenzeit braucht.


Vorher hatte ich ja auch kaum features und nun auch nicht und die vielen features im Nvidia Bereich sind ja uninteressant wenn der eh nix taugt.
Also was soll sich nun geändert haben und warum, ist doch alles wie vorher, ausser das ich bei h264 die Nvidia Option dazu bekommen habe, die man ja eh meiden sollte? Wenn Du in Vokouder x264 statt Nvidia verwendest, kriegst Du halt höherqualitatives Video (um den Preis längerer Renderzeiten). Hallo Cantsin, ich glaube wir reden aneinander vorbei, oder Du hast noch nicht gesehen, das sich in der normalen h264 Sektion nichts durch Voukoder geändert hat, alles beim alten.

Warum sollte nun also das rendern mit h264 im gegensatz zu vorher plötzlich eine hohe dem handbrake ähnlich quali liefern, dann hätte es doch vorher auch schon so sein müßen. Es ist doch alles identisch, nix neues, nix dazu gekommen. Nvidia klammern wir da jetzt mal komplett aus, denn das liefert ja eh nur brei.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


nein, diesselbe qualität, definitiv nicht, ich habe für meine kurzfilme beides getested, egal wieviel bitrate der nvidia encoder bekommt (open end), das ergebnis ist, wie soll ich sagen "weich" gegen den x-264, cantsin hat das sehr anschaulich oben gezeigt, aber vielleicht ist ja gpu codieren der neue pro-mist...;-)

lg

srone Nein, cantsins Beispiel ist nicht bei voller Datenrate. Und das ist auch das Problem. wie gesagt, ich habe das für meine kurzfilme getestet, beide encoder open end, das ergebnis entspricht genau cantsins, der nvidia encoder ist einfach weicher.
ist aber vielleicht auch einem seheindruck geschuldet, wir benutzen beide gerne weiche optiken, während der nvidia encoder wie oben schon erwähnt, bei einer scharfen optik den "pleasant effekt" hervorruft, während der x-264 hier eher harsch wirkt?

lg

srone



Antwort von srone:

cantsin hat geschrieben:
Könnte also sein, dass der NVenc in den neueren GPU-Generationen besser ist. rtx-2070...nö...;-)

aber ich probier mal meine rtx-3060 laptop, damit wir sicher sind...;-)

lg

srone



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Hallo Cantsin, ich glaube wir reden aneinander vorbei, oder Du hast noch nicht gesehen, das sich in der normalen h264 Sektion nichts durch Voukoder geändert hat, alles beim alten.

Warum sollte nun also das rendern mit h264 im gegensatz zu vorher plötzlich eine hohe dem handbrake ähnlich quali liefern, dann hätte es doch vorher auch schon so sein müßen. Es ist doch alles identisch, nix neues, nix dazu gekommen. Ja, wir reden wohl aneinander vorbei. Die Verwirrung entsteht dadurch, dass Resolve in seinem Interface Dir einmal "h264", einmal "h264" mit Encoder "NVIDIA" und, wenn Du Vokouder installiert hast, dann nochmal "Nvenc" sowie "x264" anbietet. Da gehen die Nomenklaturen fröhlich durcheinander. Das wäre - wie gesagt - so, als wenn Dir InDesign einen PDF-Export alternativ als "PDF", als "Acrobat" und als (ein hypothetisches) "QDF" anbietet. Denn h264 ist kein Programm, sondern ein Datenformat.

Resolve selbst enthält gar keinen eigenen h264-Encoder (weil Blackmagic sich hier Lizenzkosten spart). Wenn Du Standard-h264-Export wählst, da wird der im jeweiligen Betriebssystem enthaltene h264-Encoder verwendet. Bei Windows ist das ein relativ rudimentärer Encoder von Microsoft, bei MacOS ist es der in MacOS-CoreVideo enthaltene h264-Encoder, und bei Linux gar keiner - da kriegst Du nur NVenc bzw. den jeweiligen Hardware-Encoder Deiner Grafikkarte.

Wenn Du jetzt Vokouder installierst, kannst Du neben den obengenannten Encodern auch noch den Open Source x264-Encoder direkt aus Resolve verwenden, der qualitativ besser (aber wie gesagt auch langsamer ist). Zu diesem Zweck wurde Vokouder überhaupt entwickelt.



Antwort von dienstag_01:

Wie lade ich hier ein Bild rein?



Antwort von srone:

antwort erstellen/dateianhänge/dateien hinzufügen/nach upload in den post einbetten.

lg

srone



Antwort von dienstag_01:

Vergleich, nicht tiefgründig
vergleich encoder_beschriftet.png meine GPU ist übrigens eine 950



Antwort von klusterdegenerierung:

Wer hatte jetzt gesagt das ganze läuft nicht über GPU?
Habe gerade mal einen Test angeworfen mit 1080p bei h264 Native quali Best.

GPU 94% & CPU 40% Auslastung!



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:
Hallo Cantsin, ich glaube wir reden aneinander vorbei, oder Du hast noch nicht gesehen, das sich in der normalen h264 Sektion nichts durch Voukoder geändert hat, alles beim alten.

Warum sollte nun also das rendern mit h264 im gegensatz zu vorher plötzlich eine hohe dem handbrake ähnlich quali liefern, dann hätte es doch vorher auch schon so sein müßen. Es ist doch alles identisch, nix neues, nix dazu gekommen. Ja, wir reden wohl aneinander vorbei. Die Verwirrung entsteht dadurch, dass Resolve in seinem Interface Dir einmal "h264", einmal "h264" mit Encoder "NVIDIA" und, wenn Du Vokouder installiert hast, dann nochmal "Nvenc" sowie "x264" anbietet. Da gehen die Nomenklaturen fröhlich durcheinander. Das wäre - wie gesagt - so, als wenn Dir InDesign einen PDF-Export alternativ als "PDF", als "Acrobat" und als (ein hypothetisches) "QDF" anbietet. Denn h264 ist kein Programm, sondern ein Datenformat.

Resolve selbst enthält gar keinen eigenen h264-Encoder (weil Blackmagic sich hier Lizenzkosten spart). Wenn Du Standard-h264-Export wählst, da wird der im jeweiligen Betriebssystem enthaltene h264-Encoder verwendet. Bei Windows ist das ein relativ rudimentärer Encoder von Microsoft, bei MacOS ist es der in MacOS-CoreVideo enthaltene h264-Encoder, und bei Linux gar keiner - da kriegst Du nur NVenc bzw. den jeweiligen Hardware-Encoder Deiner Grafikkarte.

Wenn Du jetzt Vokouder installierst, kannst Du neben den obengenannten Encodern auch noch den Open Source x264-Encoder direkt aus Resolve verwenden, der qualitativ besser (aber wie gesagt auch langsamer ist). Zu diesem Zweck wurde Vokouder überhaupt entwickelt. Nö, nix der gleichen.
Kein x kein Nix! :-)

ich fand ja schon den Pfad im Explorer merkwürdig, denn die Unterpfade des plugins waren ja im io Ordner schon viel weiter oben.
Hast Du mal einen screenshot wo der bei Dir liegt? :-)



Antwort von srone:

dienstag_01 hat geschrieben:
Vergleich, nicht tiefgründig

vergleich encoder_beschriftet.png

meine GPU ist übrigens eine 950 wo man gut sieht, dass dem x-264 auch fast 3,5 mbit reichen für die auflösung, wie wirds dann bei bewegung im bild?

lg

srone



Antwort von srone:

@kluster
srone hat geschrieben:
hast du denn auch alles in resolve ordentlich installiert?

es gilt 2 komponenten von der entwicklerseite zu laden und zu installieren.

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:
Vergleich, nicht tiefgründig

vergleich encoder_beschriftet.png

meine GPU ist übrigens eine 950 wo man gut sieht, dass dem x-264 auch fast 3,5 mbit reichen für die auflösung, wie wirds dann bei bewegung im bild?

lg

srone Ja, x264 ist schon sehr effizient, aber dass man einfach sagen kann, er liegt qualitativ vorn, sehe ich nicht.
Dann müsste man eigentlich mathematische Vergleiche mit dem Ausgangsmaterial machen.

Bei Bewegung sieht man dann gar keinen Unterschied mehr ;)



Antwort von srone:

doch genau bei bewegung, denn dann schnellt die bitrate hoch, ich hatte im vergleich folgende einstellung, model, ganze figur, ca 20m kamera abstand am strand vor tosendem meer, brennweite >400mm, x-264 detailliertes meer, nvidia ein sumpf, dienstag01 nimm mal kritisches material und dir zeit, der unterschied ist frappierend...:-)

lg

srone



Antwort von klusterdegenerierung:

srone hat geschrieben:
@kluster
srone hat geschrieben:
hast du denn auch alles in resolve ordentlich installiert?

es gilt 2 komponenten von der entwicklerseite zu laden und zu installieren.

lg

srone Ja, aber mit dem Ordner kopieren hats vielleicht nicht geklappt, hab ihn aber auch schon verschoben, ändert sich aber nix.



Antwort von dienstag_01:

srone hat geschrieben:
doch genau bei bewegung, denn dann schnellt die bitrate hoch, ich hatte im vergleich folgende einstellung, model, ganze figur, ca 20m kamera abstand am strand vor tosendem meer, brennweite >400mm, x-264 detailliertes meer, nvidia ein sumpf, dienstag01 nimm mal kritisches material und dir zeit, der unterschied ist frappierend...:-)

lg

srone Du kannst ja auch mal ein Beispiel zeigen.

Ich mach das auch nicht erst seit gestern ;)



Antwort von srone:

der test war vor 1 1/2 jahren, aber ok, ich versuch das zu replizieren, dann gibts morgen stills.

lg

srone



Antwort von klusterdegenerierung:

Jetzt hats geklappt, habe jetzt unter Codecs die Option Voukoder.
Was nimmt ihr denn da jetzt h264 oder h265 und welches Profil?



Antwort von dienstag_01:

srone hat geschrieben:
der test war vor 1 1/2 jahren, aber ok, ich versuch das zu replizieren, dann gibts morgen stills.

lg

srone Wegen mir brauchst du nicht.
Die Datenrate lässt sich hochsetzen, von daher ist dein Einwand keiner.



Antwort von srone:

dienstag_01 hat geschrieben:
Ich mach das auch nicht erst seit gestern ;) ich weiss...;-)

lg

srone



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:
der test war vor 1 1/2 jahren, aber ok, ich versuch das zu replizieren, dann gibts morgen stills.

lg

srone Wegen mir brauchst du nicht.
Die Datenrate lässt sich hochsetzen, von daher ist dein Einwand keiner. wir reden permanent, von max datenrate gegen max datenrate, dass ist dir schon bewusst?

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Wegen mir brauchst du nicht.
Die Datenrate lässt sich hochsetzen, von daher ist dein Einwand keiner. wir reden permanent, von max datenrate gegen max datenrate, dass ist dir schon bewusst?

lg

srone x264 mit 15Mbit ist natürlich nicht die maximale Datenrate, das ginge höher. Ob man Nvenc in Resolve erhöhen kann, müsste ich mal noch testen.
Das sehe ich aus meiner Erfahrung heraus nicht als Problem.
Aber ich lasse mich gerne eines besseren belehren.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


wir reden permanent, von max datenrate gegen max datenrate, dass ist dir schon bewusst?

lg

srone Ob man Nvenc in Resolve erhöhen kann, müsste ich mal noch testen.
Das sehe ich aus meiner Erfahrung heraus nicht als Problem.
Aber ich lasse mich gerne eines besseren belehren. mach das, ich mache meins...;-)

lg

srone



Antwort von Darth Schneider:

@roki
Witzig das ausgerechnet du dich als Profi angesprochen fühlst..;)))
Unglaublich !
Egal, das musst du selber wissen.
Mit Resolve Studio 17, jedenfalls sieht das h264/265 Ergebnis in keiner einzigen Hinsicht irgendwie schlechter aus als mit Handbreak.
Probiere es doch mal.
Oder arbeitest du immer noch nicht mit der neusten Resolve Studio Version 17 ?
Gruss Boris



Antwort von roki100:

"Darth Schneider" hat geschrieben:
@roki
Witzig das ausgerechnet du dich als Profi angesprochen fühlst..;)))
Unglaublich ! Der Boris ist wieder als Ernst auferstanden. ;) Mit Resolve Studio 17, jedenfalls sieht das h264/265 Ergebnis in keiner einzigen Hinsicht irgendwie schlechter aus als mit Handbreak.
Probiere es doch mal. Habe ich. Handbrake+H264/5 ist qualitativer und die Filesize dazu auch noch kleiner.



Antwort von Darth Schneider:

@roki
Du hast meine letzte Frage gar nicht beantwortet ?
Liest du den eigentlich nur was du willst ? ;)
Zum zweiten Mal, halt denn:
Arbeitest du mit Resolve Studio Version 17 ?

Wenn nicht, dann könnte das ein Grund dafür sein warum.
Weil bei mir das Ergebnis mit Version 17 eindeutig besser aus sieht als es mit Version 16 noch ausgesehen hat.
Aber egal, du glaubst es mir ja eh nicht.;)
Ich brauche die Handbremse jedenfalls gar nicht mehr.
Weil die Filme streat aus Resolve 17 in h264/h265…gewandelt sehen mittlerweile super aus..Handbreak kann das ganz bestimmt nicht besser.
Ich hab das wirklich getestet und miteinander verglichen.

Und die File Grössen sind für mich eigentlich jetzt wirklich gar kein Thema mehr.
Grösser sieht besser aus, kleiner eben schlechter.
Das ist eine Grundregel.
Ich beweg mich meistens so um 25000 kbps, bei einer HD Delivery, beim End Medium USB Stick.
Das heisst ein ein stündiger HD Film braucht dann zirka 10 Giga Speicherplatz.
Guter Mittelwert für meine Augen, zwischen Qualität und Kompatibilität.
Gruss Boris



Antwort von roki100:

"Darth Schneider" hat geschrieben:
@roki
Du hast meine letzte Frage gar nicht beantwortet ?
Liest du den eigentlich nur was du willst ? ;)
Zum zweiten Mal, halt denn:
Arbeitest du mit Resolve Studio Version 17 ? Ja. Mit 17er habe ich aber andere Probleme und wechsele bald vorübergehend (für ein Jahr oderso) zu FCPX.
Davinci 16 ist noch der einzige Grund warum ich Hakintosh nutze. Später kommt das alles weg und dann nur noch M1 Pro.



Antwort von Darth Schneider:

Ich will auch einen M1.
Ich weiss aber noch nicht welchen, der Mac Mini ist mit Abstand der günstigste.
Aber auf der anderen Seite gibts jetzt den M1 Pro, und den M1Max…
Wobei der zweite dann eh viel zu teuer für mich ist.
Was kaufst du dir denn für eine Kiste ?
Ich weiss auch nicht was noch kommen wird von Apple ?
Für mich fehlt von Apple immer noch ein Einsteiger Mac Pro….
Früher gab es das immer bei den Mac Pros, so ab 3000€…
Mit dem günstigen M1 Prozessor dürfte sowas heute eigentlich schon für 2000€ machbar sein…
Ich verstehe eigentlich nicht wirklich worauf Apple wartet…
Gruss Boris



Antwort von roki100:

"Darth Schneider" hat geschrieben:
Was kaufst du dir denn für eine Kiste ? viewtopic.php?f=5&t=148642&start=1155#p1124161



Antwort von Darth Schneider:

Sieht sehr toll aus.
Zu haben ab 2000€.
Praktisch, damit kann man auch im Bett Filme schneiden….;)))
Was braucht man da alles ? 16 Giga RAM sicher und 512 Ssd im Minimum.

Ist etwas knapp, aber ich bräuchte den eh nur zum schneiden.
Und auslagern muss man die Projekte und Filme ja eh…
Hmm..
Wie viel interner Speicher nimmst du ?

Warum ist so ein bisschen mehr interner Speicher bei Apple eigentlich so unverschämt, scheiss teuer ???? ;(

Auf der anderen Seite blicke ich schon auch neidisch auf das neue, coole PC Gamer Laptop von meinem Kollegen…
2500€ riesiger, schöner Bildschirm, schneller Prozessor, gute Grafikkarte, mehr als genug Speicher, alle Anschlüsse gleich dran.
Er nutzt darauf das Gratis Resolve und schneidet Material ganz locker von seiner XT4….
Uff !
Gruss Boris



Antwort von klusterdegenerierung:

"Darth Schneider" hat geschrieben:
Ich beweg mich meistens so um 25000 kbps, bei einer HD Delivery Das muß Du uns mal erklären.
Wie bewegt man sich da, bzw was und wo?



Antwort von Darth Schneider:

@Kluster
So.
Meine Einstellungen in Resolve mit dem iMac.
Timeline: 4K
Codec :
MP4
Format:
H624
Qualität:
(Manuell) Bitrate: 25000, beziehungsweise, Automatic sind es ca: 20000.
Durchgänge mehrere.
Auflösung: HD
speichern wo auch immer, ich speichere normalerweise gleich auf dem Ziel Medium, also einem USB Stick oder auf einer Harddisk.

Du wirst das doch auch nicht gross anderes machen zumindest in Resolve…
Klar du kannst den Wert auch auf 18000 oder 12000 geben.
Aber ich persönlich fange so ab 18 000 an abwärts langsam an deutliche Spuren von Kompression in dunklen Bereichen zu sehen….
Und ich geb halt die Filme praktisch immer nur auf Sticks, früher auf Scheiben weiter.
Gruss Boris



Antwort von roki100:

"Darth Schneider" hat geschrieben:
Was braucht man da alles ? 16 Giga RAM sicher und 512 Ssd im Minimum. das mit RAM funktioniert bei M1 irgendwie anders. 16GB reichen da m.M. völlig aus.
Datenspeicher für Videos, da nutze ich externe SSD und von da aus lade ich die videos in der Timeline und raus rendern auf interne. Funktioniert super.



Antwort von Darth Schneider:

Danke roki
Dann reicht wahrscheinlich theoretisch eine interne 512 Ssd..;)
Ist der Bildschirm gross genug ?
Gruss Boris



Antwort von roki100:

"Darth Schneider" hat geschrieben:
So.
Meine Einstellungen in Resolve mit dem iMac.
Timeline: 4K
Codec :
MP4
Format:
H624
Qualität:
(Manuell) Bitrate: 25000, beziehungsweise, Automatic sind es ca: 20000.
Durchgänge mehrere.
Auflösung: HD
speichern wo auch immer, ich speichere normalerweise gleich auf dem Ziel Medium, also einem USB Stick oder auf einer Harddisk.

Du wirst das doch auch nicht gross anderes machen zumindest in Resolve…
Klar du kannst den Wert auch auf 18000 oder 12000 geben.
Aber ich persönlich fange so ab 18 000 an abwärts langsam an Spuren von Kompression zu sehen….
Gruss Boris und nun mach mal das selbe mit handbrake (in 10Bit): Konstante Qualität auf 16 oder 17 und schau dir die Files dann an. Du kannst unter Davinci die Bitrate sogar erhöhen oder was auch immer... die Qualität bei Handbrake ist einfach nur besser und die Files trotzdem kleiner.



Antwort von roki100:

"Darth Schneider" hat geschrieben:
Ist der Bildschirm gross genug ? 14 Zoll, für mich ja. Die Auflösung ist sowieso perfekt.



Antwort von Darth Schneider:

@roki
Das habe ich ja eben gemacht, roki !!!

Das hatte ich doch weiter oben ausführlich geschrieben.
Nix anderes, tagelang im Januar ;))
Ich wollte und musste es wissen.
Weil ich 70 USB Sticks mit einem Film von mir darauf liefern musste.

Direkt die Ergebnisse von Resolve 17 Studio und von Handbreak auf zwei schönen grossen TV Screens nebeneinander verglichen, hab ich, wie ein verrückter Pixel Peeper..
Das alle erdenklichen Varianten…
Handbreak macht das meiner Meinung nach ganz klar eben nicht besser, nicht als Resolve Studio 17, sorry.
Jedenfalls ganz sicher nicht mit MP4 und auch nicht mit h264 oder mit h265…
Wenn du mir nicht glaubst probiere es doch einfach mal selber.
(Das geht aber ne Weile ( und nicht mit Standbildern) wenn du wirklich vergleichst)

Aber am Schluss ist es doch auch sicher Geschmackssache, mir gefällt halt das jetzt besser was aus Resolve da raus kommt….

Und ich weiss nicht ob den da halt doch noch der ganze BRaw Workflow doch noch mit drin hängt….
Bei mir verlässt dann halt so das BRaw Material bis zum Schluss gar nicht erst die BMD Umgebung…wird nur ein einziges Mal nur in Resolve gewandelt.

Je weniger Umwandlung desto besser bleibt die Qualität…
Noch eine Grundregel…
Aber das wird heute gerne alles ignoriert, ist ja schliesslich Digital.

Für mich, Quatsch, jede Umwandlung ist und bleibt eine Umwandlung, somit nix anderes als eine Veränderung des Originals !
Gruss Boris



Antwort von klusterdegenerierung:

"Darth Schneider" hat geschrieben:
@Kluster
So.
Meine Einstellungen in Resolve mit dem iMac.
Timeline: 4K
Codec :
MP4
Format:
H624
Qualität:
(Manuell) Bitrate: 25000, beziehungsweise, Automatic sind es ca: 20000.
Durchgänge mehrere.
Auflösung: HD
speichern wo auch immer, ich speichere normalerweise gleich auf dem Ziel Medium, also einem USB Stick oder auf einer Harddisk.

Du wirst das doch auch nicht gross anderes machen zumindest in Resolve…
Klar du kannst den Wert auch auf 18000 oder 12000 geben.
Aber ich persönlich fange so ab 18 000 an abwärts langsam an deutliche Spuren von Kompression in dunklen Bereichen zu sehen….
Und ich geb halt die Filme praktisch immer nur auf Sticks, früher auf Scheiben weiter.
Gruss Boris Wir reden aneinander Vorbei.
Meine Frage war, wie Du auf 25Mbit kommst, denn erstmal gibt es ja nur Qualitätseinstellungen statt Mbit Raten und wer Mbit Raten festsetzt muß, wie hier im Thread schon ausreichend diskutiert, damit rechnen das unter Umständen die 25Mbit für nix draufgehen, weil der Codec dies im Zweifel auch hätte genauso gut mit 8Mbit realisieren können.

Darum die Frage, wiese 25Mbit, wo kommen die her und warum überhaupt.
Aber nun weiß ich es ja und auch dass das nix aufe Hacken hat. :-)



Antwort von Darth Schneider:

Also ich hab halt ausprobiert. Und bildete mir wahrscheinlich ein bei 18 immer noch im Hintergrund auf dem Backdrop der Bühne bei eher dunklen Stellen irgend welche kleinen Kompression Artefakte erkennen können…
Da entschied ich mich halt für 25 mips. Wollte auf der sicheren Seite sein….
Beziehungsweise ich sagte mir wenn das stündige HD Video 10 Giga Speicher braucht und auf denn usb Sticks eh 16 Giga Platz ist, warum auch sparen.

Ich persönlich finde es eigentlich auch sinnvoll das Material eben nicht bis zum geht nicht mehr herunter zu komprimieren nur um ein bisschen Speicherplatz zu sparen.
Gruss Boris