Frage von klusterdegenerierung:Hallo Erfahrene,
ich muß hier einen 1,5 stünden Film rendern, den der Kunde auch gerne mal versenden möchte, allerdings geht das auch schon bei 2K in die GBs.
Habt Ihr da eine art Faustformel, welche Bitrate in Resolve noch akzeptabel ist, oder soll ich da mit Handbrake dran etc.?
Wie macht Ihr das?
Danke! :-)
Antwort von Jott:
1,5 Stunden zum Versenden - frag den Kunden mal, was er sich so vorstellt als Größe.
Und erzähl ihm vielleicht mal von der Erfindung YouTube.
Ansonsten: nimm 30 Sekunden und probier selber verschiedene Datenraten, klar, Handbrake. Kein Mensch weiß, was für ein Video das ist: ein Vortrag mit Talking Head vom Stativ und Folien kann viel kleiner gedrückt werden als ein moderner Wackelcam-Film.
Antwort von prime:
Da gibt es so viele Möglichkeiten..
- max. 2 GB (dann kann man es via Wetransfer senden)
- mehrere Größen generieren (360p, 720p, 1080p etc.)
- Eigener Webserver/FTP etc.
Den Kunden nett darauf verweisen das sie alle Größen auf Google Drive/Dropbox etc ablegen können und dann entsprechend einfach nur Link dem Empfänger mitteilen. Ansonsten können die natürlich brav jedesmal neu hochladen oder stückchenweisen per email ;-P
Antwort von klusterdegenerierung:
Jott hat geschrieben:
1,5 Stunden zum Versenden - frag den Kunden mal, was er sich so vorstellt als Größe.
Gehst Du so mit Deinen Kunden um? Hola!
Jott hat geschrieben:
Und erzähl ihm vielleicht mal von der Erfindung YouTube.
Welcher Filmer & Kunde kennt nicht YT und war das die Frage?
Jott hat geschrieben:
Ansonsten: nimm 30 Sekunden und probier selber verschiedene Datenraten
Danke für den Tipp.
Jott hat geschrieben:
Kein Mensch weiß, was für ein Video das ist: ein Vortrag mit Talking Head vom Stativ und Folien kann viel kleiner gedrückt werden als ein moderner Wackelcam-Film.
Wen interessierts und was ändert das an der Frage bzw Datenrate?
Antwort von Bluboy:
2000-6000 kb/s wie DVB ist noch akzeptabel ergibt aber bei 90 Minute immeer noch 3-4 GB ;-((
Antwort von klusterdegenerierung:
prime hat geschrieben:
Da gibt es so viele Möglichkeiten..
- max. 2 GB (dann kann man es via Wetransfer senden)
- mehrere Größen generieren (360p, 720p, 1080p etc.)
- Eigener Webserver/FTP etc.
Den Kunden nett darauf verweisen das sie alle Größen auf Google Drive/Dropbox etc ablegen können und dann entsprechend einfach nur Link dem Empfänger mitteilen. Ansonsten können die natürlich brav jedesmal neu hochladen oder stückchenweisen per email ;-P
Danke prime.
Andere Größe kommt nicht in Frage, aber 720p zu 1080p machen bei gleicher Raten den Braten nicht fett, sind höchstens 20%.
Ich probiere mal die Raten durch, ich dachte da gäbe es schon Erfahrungswerte. Danke!
Antwort von klusterdegenerierung:
Bluboy hat geschrieben:
2000-6000 kb/s wie DVB ist noch akzeptabel ergibt aber bei 90 Minute immeer noch 3-4 GB ;-((
Bin mit 6Mbit bei 4,3GB, versuche es mal mit 2,5Mbit. Früher hat man ja Xvid genommen. ;-))
Antwort von Bluboy:
MP4 ist das neue XVid
Antwort von klusterdegenerierung:
Probiere jetzt mal das dazu:
https://transferxl.com/de
Antwort von Bluboy:
Hier mal ein Beispiel von ///Fun TV
Allgemein
ID : 1 (0x1)
Vollständiger Name : G:\Das Morgan Projekt.ts
Format : MPEG-TS
Dateigröße : 1,73 GiB
Dauer : 1 h 27 min
Modus der Gesamtbitrate : variabel
Gesamte Bitrate : 2 830 kb/s
Video
ID : 2901 (0xB55)
Menü-ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4
Format-Einstellungen : CABAC / 4 Ref Frames
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für RefFrames : 4 frames
Format settings, GOP : M=2, N=16
Codec-ID : 27
Dauer : 1 h 27 min
Bitrate : 2 496 kb/s
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 25,000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scantyp : Interlaced
Scan type, store method : Separated fields
Scanreihenfolge : oberes Feld zuerst
Bits/(Pixel*Frame) : 0.048
Stream-Größe : 1,53 GiB (88%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2902 (0xB56)
Menü-ID : 1 (0x1)
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 2
Codec-ID : 3
Dauer : 1 h 27 min
Bitraten-Modus : konstant
Bitrate : 192 kb/s
Kanäle : 2 Kanäle
Samplingrate : 48,0 kHz
Bildwiederholungsrate : 41,667 FPS (1152 SPF)
Compression mode : Lossy
Stream-Größe : 120 MiB (7%)
Sprache : Deutsch
Antwort von klusterdegenerierung:
Bluboy hat geschrieben:
Gueer msl ein Beusoeö von /Gin TV
Jooh mei!
Antwort von klusterdegenerierung:
Kann man das rendern eigentlich irgendwie beschleunigen, der braucht ja halb so lang wie das Video, ist das nicht very lahm?
Antwort von Bluboy:
1 Finger Blind ist nicht so Einfach ;-(
Antwort von cantsin:
Handbrake bringt ggü. Resolve sehr viel, besonders wenn Du das "veryslow"-Preset nutzt, auf "Film' optimierst und 2-Pass-Encoding machst.
Bei einer Audio-Bitrate von 128MBit/s (die Du bei reiner Sprach-Tonspur ggfs. noch auf 64MBit/s drücken kannst), sitzt Du dann auf einer Video-Bitrate von 2832 MBit/s. Das ist nicht schlechter als die meisten Streamingdienste.
Spielfilmlänge innerhalb 2GB bei 1080p ist dann absolut machbar - und sowieso der Standard in der ganzen BitTorrent-Szene...
Antwort von klusterdegenerierung:
cantsin hat geschrieben:
Handbrake bringt ggü. Resolve sehr viel, besonders wenn Du das "veryslow"-Preset nutzt, auf "Film' optimierst und 2-Pass-Encoding machst.
Bei einer Audio-Bitrate von 128MBit/s (die Du bei reiner Sprach-Tonspur ggfs. noch auf 64MBit/s drücken kannst), sitzt Du dann auf einer Video-Bitrate von 2832 MBit/s. Das ist nicht schlechter als die meisten Streamingdienste.
Spielfilmlänge innerhalb 2GB bei 1080p ist dann absolut machbar - und sowieso der Standard in der ganzen BitTorrent-Szene...
Hallo cantsin,
Audio ist garnicht dabei. Very slow heißt dann für mich ewig aufs konvertieren warten, oder heißt das Profil nur so?
Antwort von klusterdegenerierung:
Bluboy hat geschrieben:
1 Finger Blind ist nicht so Einfach ;-(
Du schreibst doch nur so unverständlich damit Du durch Rückfragen auf mehr Beiträge kommst, oder? :-)
Antwort von prime:
klusterdegenerierung hat geschrieben:
ich dachte da gäbe es schon Erfahrungswerte. Danke!
Da brauch man keine Erfahrungswerte, man kann das ganz genau ausrechnen - je nach gewünschter Endgröße (200 MB, 400 MB, 1 GB etc.).
Antwort von klusterdegenerierung:
prime hat geschrieben:
klusterdegenerierung hat geschrieben:
ich dachte da gäbe es schon Erfahrungswerte. Danke!
Da brauch man keine Erfahrungswerte, man kann das ganz genau ausrechnen - je nach gewünschter Endgröße (200 MB, 400 MB, 1 GB etc.).
Ich meinte zb. in Bezug auf Resolve und seine Presets.
Antwort von dosaris:
cantsin hat geschrieben:
...
Bei einer Audio-Bitrate von 128MBit/s (die Du bei reiner Sprach-Tonspur ggfs. noch auf 64MBit/s drücken kannst), sitzt Du dann auf einer Video-Bitrate von 2832 MBit/s. Das ist nicht schlechter als die meisten Streamingdienste.
mh
Audio-Bitrate von 128MBit/s
gibbet nich
aber was sind schon NULLen?
Antwort von cantsin:
dosaris hat geschrieben:
Audio-Bitrate von 128MBit/s
gibbet nich
aber was sind schon NULLen?
Stimmt. M durch K ersetzen. Je älter ich werde, desto weniger kann ich mir den Sch*ss merken. Die Rechnerei in Bit versus Byte nervt zusätzlich.
Antwort von cantsin:
klusterdegenerierung hat geschrieben:
Hallo cantsin,
Audio ist garnicht dabei. Very slow heißt dann für mich ewig aufs konvertieren warten, oder heißt das Profil nur so?
Das heißt das schon - je nach Rechnerleistung über Nacht laufen lassen. Bringt dann aber auch ungefähr die Bildqualität von Resolve's h264-Encoding bei 10000 Kbit/s. Die Berechnung von Handbrake/ffmpeg skaliert dabei voll auf Deine vorhandenen CPU-Kerne.
Antwort von klusterdegenerierung:
@cantsin
Oh man, das dauerte mir dann doch viel zu lange.
Hab nun in Resolve "low" im h264 ohne Audio genommen, sind 1,7GB bei 2,7Mbit, das ist besser als ich erwartet habe.
Dann gibt es eben eine anständige Version beim nächsten Besuch auf Datenträger, das passt dann schon.
Ich hatte Anfangs gedacht es gäbe ein Art magische Grenze die man nicht unterschreiten sollte, bei der es quasi albern wird und man besser die Finger von läßt und das 2,5Mbit noch so gut sind, hätte ich dann doch nicht vermutet.
Üblicherweise sind meine Videos max 20min, wenns hoch kommt, 1,5 Std ist für mich Neuland, da habe ich kaum Erfahrung.
Danke für den support und das Du nicht die Nerven verloren hast, scheint bei dem Wetter ja nicht unüblich zu sein! ;-))
Antwort von Jott:
klusterdegenerierung hat geschrieben:
Wen interessierts und was ändert das an der Frage bzw Datenrate?
Alles. Da kommt’s extrem drauf an. Mit Talking Heads zum Beispiel kann man viel kleiner gehen als oben empfohlen.
Antwort von freezer:
Wenn Du den Film vor der Kompression auch noch ein bisschen entrauscht, geht schon einiges. Auch der Unterschied 720p zu 1080p ist größer als Du vermutest, nämlich 50%.
Antwort von klusterdegenerierung:
freezer hat geschrieben:
Auch der Unterschied 720p zu 1080p ist größer als Du vermutest, nämlich 50%.
Habe ich schon zig mal bei anderen Projekten probiert und wenn sie bei FHD zb. 1,5GB hatten, waren es bei 720p 1,2GB, dat lohnt nicht.
Antwort von freezer:
klusterdegenerierung hat geschrieben:
freezer hat geschrieben:
Auch der Unterschied 720p zu 1080p ist größer als Du vermutest, nämlich 50%.
Habe ich schon zig mal bei anderen Projekten probiert und wenn sie bei FHD zb. 1,5GB hatten, waren es bei 720p 1,2GB, dat lohnt nicht.
Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.
Antwort von prime:
freezer hat geschrieben:
klusterdegenerierung hat geschrieben:
Habe ich schon zig mal bei anderen Projekten probiert und wenn sie bei FHD zb. 1,5GB hatten, waren es bei 720p 1,2GB, dat lohnt nicht.
Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.
@kluster, die Dateigrößen allein sind nicht hilfreich. Bei der Reduzierung der Auflösung kann man fast linear auch die Bitrate reduzieren. Auch wenn es selten erwähnt wird aber es gibt noch den Bits pro pixel Wert (BPP):
1920x1080@25 bei 1000 kBit/s -> 0.01929 bits/pixel
1280x720@25 bei 1000 kBit/s -> 0.04340 bits/pixel
1280x720@25 bei 500 kBit/s -> 0.02170 bits/pixel (vom BPP Wert und der Qualität also wie FHD bzw sogar noch etwas besser).
Es bringt also nix bei reduzierter Auflösung die gleicher Bitrate zu versuchen, der Encoder wird u.U. gesättigt und generiert unnötig große Dateien. Die Dateien mögen zwar kleiner als die Variante mit höherer Auflösung sein, könnten aber ohne Probleme und Qualitätsverlust noch kleiner sein. Bei H264 wird ein BPP von 0.1 (Internet/Streaming etc.) bzw höher (0.4 bei Blu-ray, Master etc.) empfohlen.
Antwort von klusterdegenerierung:
freezer hat geschrieben:
klusterdegenerierung hat geschrieben:
Habe ich schon zig mal bei anderen Projekten probiert und wenn sie bei FHD zb. 1,5GB hatten, waren es bei 720p 1,2GB, dat lohnt nicht.
Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.
Mag, sein, bei mir kommen aber nun mal solche Werte raus und da bevorzuge ich natürlich lieber FHD.
Antwort von klusterdegenerierung:
prime hat geschrieben:
Es bringt also nix bei reduzierter Auflösung die gleicher Bitrate zu versuchen, der Encoder wird u.U. gesättigt und generiert unnötig große Dateien. Die Dateien mögen zwar kleiner als die Variante mit höherer Auflösung sein, könnten aber ohne Probleme und Qualitätsverlust noch kleiner sein.
Danke Dir, ja daran kann es liegen, aber der Kunde möchte 1080p. :-)
Antwort von mash_gh4:
klusterdegenerierung hat geschrieben:
freezer hat geschrieben:
Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.
Mag, sein, bei mir kommen aber nun mal solche Werte raus und da bevorzuge ich natürlich lieber FHD.
was den zusammenhang zw. optimaler bildgröße bzw. auflösung, kompression und bildqulität betrifft, gibt's ganz klare erkenntnisse, die sich mit den bekannten convex hull curves recht einprägsam beschreiben lassen:
https://miro.medium.com/max/404/0*1doDPDDnCRZJj7YR.
generell ist es aber sinvoll, nicht zu sehr an irgendwelchen
konstanten bitrate-einstellungen zu orientieren, wie es früher einmal bzw. von eher einfach gehaltenen kompressionsimplementierungen benutzt wird, sondern statt dessen besser
CRF (contstant rate factor) od.ä. zu nutzen, wo vielmehr automatische eine
gleichmäßige bildqualität für die verschiedene abschitte eines videos angestrebt wird, was deutlich befriedigender ausfällt als beim sturen festhalten an einer statischen bandbreitenvorgabe. unterschiedliche bildinhalte (bewegung im bild, strukturen im bild, etc.) brauchen einfach jeweils andere übertragungskapazitäten für eine zufriedenstellende abbildung bzw. umschreibung.
Antwort von klusterdegenerierung:
mash_gh4 hat geschrieben:
generell ist es aber sinvoll, nicht zu sehr an irgendwelchen konstanten bitrate-einstellungen zu orientieren, wie es fürhert einmal bzw. von eher einfach gehaltenen kompressionsimplementierungen benutzt wird, sondern statt dessen besser CRF (contstant rate factor) od.ä. zu nutzen, wo vielmehr automatische eine gelichmäßige bildqualität für die verschiedene abschitte eines videos angestrebt wird, was deutlich befriedigender ausfällt als beim sturen festhalten an einer statischen vorgaben. unterschiedliche bildinhalte (bewegung im bild, strukturen im bild, etc.) brauchen einfach jeweils andere bandbreiten für eine zufriedenstellende abbildung und übertragung.
Aber das erledigt Resolve doch von Haus aus schon, oder, denn feste Bitraten im Sinne von CBR benutzt doch eh kein NLE in den Standards, oder hab ich Dich falsch verstanden?
Antwort von mash_gh4:
klusterdegenerierung hat geschrieben:
Aber das erledigt Resolve doch von Haus aus schon, oder, denn feste Bitraten im Sinne von CBR benutzt doch eh kein NLE in den Standards, oder hab ich Dich falsch verstanden?
leider sind die entsprechenden einstellungsmöglichkeiten und die umsetzung der komprimierung im resolve alles andere als vorbildlich gelöst, weshalb ja viele von uns externe programme zum komprimieren verwenden, wenn man wirklich befriedigende qulität in kleinen h264/5, VP9 od. AV1 files benötigt.
allerdings kann man das nur sehr schwer objektivieren, da es ja leider bei allen resolve-ausgaben (mac vs. pc, frei version vs. studio, version...) intern immer ein bisserl anders gehandhabt wird, und daher in wahrheit natürlich auch kein einheitliche beurteilung zulässt.
Antwort von klusterdegenerierung:
Naja, das einzige was gegenüber PR fehlt ist CBR oder VBR und bei den encoding profilen die Versionen, aber das finde ich nicht so wichtig, denn ob High 5.1 oder 5.7, ändert ja nix an der eigenen Bitrate.
Sonst ist doch das meiste wie anders wo auch, oder?
Antwort von prime:
mash_gh4 hat geschrieben:
generell ist es aber sinvoll, nicht zu sehr an irgendwelchen konstanten bitrate-einstellungen zu orientieren, wie es früher einmal bzw. von eher einfach gehaltenen kompressionsimplementierungen benutzt wird, sondern statt dessen besser CRF (contstant rate factor) od.ä. zu nutzen, wo vielmehr automatische eine gleichmäßige bildqualität für die verschiedene abschitte eines videos angestrebt wird, was deutlich befriedigender ausfällt als beim sturen festhalten an einer statischen bandbreitenvorgabe. unterschiedliche bildinhalte (bewegung im bild, strukturen im bild, etc.) brauchen einfach jeweils andere übertragungskapazitäten für eine zufriedenstellende abbildung bzw. umschreibung.
Für live streaming hat man i.d.R. eine statische Bandbreitenvorgabe (Limit), die will man dann eher nicht überschreiten. Bei CRF würde die Bitrate u.U. über die Bandbreitenvorgabe drüber gehen. Auch wenn man eine gewünschte Dateigröße erreichen möchte ist CRF allein nicht sehr nützlich. Es gibt schon einen Grund warum es so viele Optionen gibt ;-)
Antwort von mash_gh4:
prime hat geschrieben:
Für live streaming hat man i.d.R. eine statische Bandbreitenvorgabe (Limit), die will man dann eher nicht überschreiten. Bei CRF würde die Bitrate u.U. über die Bandbreitenvorgabe drüber gehen. Auch wenn man eine gewünschte Dateigröße erreichen möchte ist CRF allein nicht sehr nützlich. Es gibt schon einen Grund warum es so viele Optionen gibt ;-)
auch in dem fall kombiniert man am besten CRF mit einer fest gesetzten obergrenze
(Capped CRF Encoding).
siehe bspw.:
https://streaminglearningcenter.com/enc ... oding.html
Antwort von prime:
mash_gh4 hat geschrieben:
prime hat geschrieben:
Für live streaming hat man i.d.R. eine statische Bandbreitenvorgabe (Limit), die will man dann eher nicht überschreiten. Bei CRF würde die Bitrate u.U. über die Bandbreitenvorgabe drüber gehen. Auch wenn man eine gewünschte Dateigröße erreichen möchte ist CRF allein nicht sehr nützlich. Es gibt schon einen Grund warum es so viele Optionen gibt ;-)
auch in dem fall kombiniert man am besten CRF mit einer fest gesetzten obergrenze.
siehe bspw.:
https://streaminglearningcenter.com/enc ... oding.html
Ich schrieb ja "CRF allein".
Antwort von mash_gh4:
prime hat geschrieben:
Ich schrieb ja "CRF allein".
in der praxis ist dieses "CRF allein" in den allermeisten fällen ohnehin völlig ausreichend...
Antwort von prime:
mash_gh4 hat geschrieben:
in der praxis ist dieses "CRF allein" in den allermeisten fällen völlig ausreichend...
Wüsste nicht warum man sich mit einer solchen Pauschalaussage so sehr auf einen Modus beschränken sollte. Wie ich bereits geschrieben habe, es gibt schon Gründe warum es so viele Optionen gibt. Die "Praxis" für den einen ist völlig anders als für jemand anderen.
Antwort von mash_gh4:
wenn du selber streaming-services betreibst bzw. korrekt konfigurieren musst od.ä., kann es natürlich schon notwendig sein, dass du dich auch mit solchen esoterischen details herumschlagen musst. dort aber, wo es nur darum geht, ein video-file für die weitergabe einigermaßen vernünftig und qualitativ befriedigend aufzubereiten, so wie es der kluster hier thematisiert, ist das wirklich reichlich verzichtbarer luxus. dagegen kann die ganz einfache verwendung von CRF-einstellungen statt fixen bandbreitenvorgaben auch in einem derart alltäglichen kontext ein durchaus sinnvolle und realtiv einfach zu handhabende verbesserung darstellen, um auch anspruchsvollen qualitätsvorstellungen mit vertretbarem aufwand gerecht zu werden.
Antwort von prime:
"esoterische Details" - alles klar, na dann ;-)
