slashCAM Forum

cantsin hat geschrieben: ↑Do 20 Feb, 2020 11:16

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.

Bluboy hat geschrieben: ↑Do 20 Feb, 2020 18:00 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!

Frank Glencairn hat geschrieben: ↑Do 20 Feb, 2020 18:01
cantsin hat geschrieben: ↑Do 20 Feb, 2020 11:16

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???????????????????????????????????????

@kluster verwendest du Resolve 16?

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.

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

klusterdegenerierung hat geschrieben: ↑Do 20 Feb, 2020 18:04
Ich kann eine Wunschrate eingeben und sie wird nicht so gerendert, verstanden??????

Datenraten sind eine technisch-mathematische Angelegenheit, und kein Wunschkonzert.

klusterdegenerierung hat geschrieben: ↑Do 20 Feb, 2020 18:04
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.

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

pillepalle hat geschrieben: ↑Do 20 Feb, 2020 18:45 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.

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

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.

Resolve sagt: You have the Latest Version

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

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

@Prime

Was hast Du denn für einen Rechner

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

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

cantsin hat geschrieben: ↑Do 20 Feb, 2020 19:31 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.

Bluboy hat geschrieben: ↑Fr 21 Feb, 2020 00:33 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.

Code: Alles auswählen

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):

Code: Alles auswählen

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.

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

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.

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

Ergebnis:

Code: Alles auswählen

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.

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

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. :-)

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.

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. :-)

Video Rookie hat geschrieben: ↑Di 01 Feb, 2022 19:40 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.

Danke Dir!

cantsin hat geschrieben: ↑Di 01 Feb, 2022 21:29 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.

Was würdest du stattdessen vorschlagen?

TomStg hat geschrieben: ↑Di 01 Feb, 2022 21:40
cantsin hat geschrieben: ↑Di 01 Feb, 2022 21:29 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

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.

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

lg

srone

srone hat geschrieben: ↑Di 01 Feb, 2022 22:15 gibts dazu nen link? danke...:-)

lg

srone

https://www.voukoder.org/

Ups!
Und das ist normal?

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

slashCAM Forum

mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!

Re: mp4 Bitraten Problem gelöst!