Gehst Du so mit Deinen Kunden um? Hola!
Welcher Filmer & Kunde kennt nicht YT und war das die Frage?
Danke für den Tipp.
Wen interessierts und was ändert das an der Frage bzw Datenrate?
Danke prime.prime hat geschrieben: ↑Fr 21 Aug, 2020 15:11 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
Bin mit 6Mbit bei 4,3GB, versuche es mal mit 2,5Mbit. Früher hat man ja Xvid genommen. ;-))
Hallo cantsin,cantsin hat geschrieben: ↑Fr 21 Aug, 2020 15:40 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...
Du schreibst doch nur so unverständlich damit Du durch Rückfragen auf mehr Beiträge kommst, oder? :-)
Da brauch man keine Erfahrungswerte, man kann das ganz genau ausrechnen - je nach gewünschter Endgröße (200 MB, 400 MB, 1 GB etc.).klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:23 ich dachte da gäbe es schon Erfahrungswerte. Danke!
Ich meinte zb. in Bezug auf Resolve und seine Presets.prime hat geschrieben: ↑Fr 21 Aug, 2020 16:23Da brauch man keine Erfahrungswerte, man kann das ganz genau ausrechnen - je nach gewünschter Endgröße (200 MB, 400 MB, 1 GB etc.).klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:23 ich dachte da gäbe es schon Erfahrungswerte. Danke!
mh
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.
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.klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:46
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?
Alles. Da kommt’s extrem drauf an. Mit Talking Heads zum Beispiel kann man viel kleiner gehen als oben empfohlen.klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:19 Wen interessierts und was ändert das an der Frage bzw Datenrate?
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.klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 11:35Habe 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.
@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):freezer hat geschrieben: ↑Sa 22 Aug, 2020 12:06Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 11:35
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.
Mag, sein, bei mir kommen aber nun mal solche Werte raus und da bevorzuge ich natürlich lieber FHD.freezer hat geschrieben: ↑Sa 22 Aug, 2020 12:06Du hast rund 2 Mio Pixel bei 1080p und etwas mehr als 900k bei 720p, was sehr wohl relevant ist.klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 11:35
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.
Danke Dir, ja daran kann es liegen, aber der Kunde möchte 1080p. :-)prime hat geschrieben: ↑Sa 22 Aug, 2020 12:54 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.
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:klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 12:55Mag, sein, bei mir kommen aber nun mal solche Werte raus und da bevorzuge ich natürlich lieber FHD.
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?mash_gh4 hat geschrieben: ↑Sa 22 Aug, 2020 13:38 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.
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.klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 13:42 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?
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 ;-)mash_gh4 hat geschrieben: ↑Sa 22 Aug, 2020 13:38generell 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.
auch in dem fall kombiniert man am besten CRF mit einer fest gesetzten obergrenze (Capped CRF Encoding).prime hat geschrieben: ↑Sa 22 Aug, 2020 16:52 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 ;-)