slashCAM Forum

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

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.

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

Jott hat geschrieben: ↑Fr 21 Aug, 2020 15:01 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: ↑Fr 21 Aug, 2020 15:01 Und erzähl ihm vielleicht mal von der Erfindung YouTube.

Welcher Filmer & Kunde kennt nicht YT und war das die Frage?

Jott hat geschrieben: ↑Fr 21 Aug, 2020 15:01 Ansonsten: nimm 30 Sekunden und probier selber verschiedene Datenraten

Danke für den Tipp.

Jott hat geschrieben: ↑Fr 21 Aug, 2020 15:01 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?

2000-6000 kb/s wie DVB ist noch akzeptabel ergibt aber bei 90 Minute immeer noch 3-4 GB ;-((

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

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!

Bluboy hat geschrieben: ↑Fr 21 Aug, 2020 15:21 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. ;-))

MP4 ist das neue XVid

Probiere jetzt mal das dazu: https://transferxl.com/de

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

Bluboy hat geschrieben: ↑Fr 21 Aug, 2020 15:31 Gueer msl ein Beusoeö von /Gin TV

Jooh mei!

Kann man das rendern eigentlich irgendwie beschleunigen, der braucht ja halb so lang wie das Video, ist das nicht very lahm?

1 Finger Blind ist nicht so Einfach ;-(

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

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

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?

Bluboy hat geschrieben: ↑Fr 21 Aug, 2020 15:38 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? :-)

klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:23 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.).

prime hat geschrieben: ↑Fr 21 Aug, 2020 16:23

klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:23 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.

cantsin hat geschrieben: ↑Fr 21 Aug, 2020 15:40 ...
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?

dosaris hat geschrieben: ↑Fr 21 Aug, 2020 16:33 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.

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?

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.

@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! ;-))

klusterdegenerierung hat geschrieben: ↑Fr 21 Aug, 2020 15:19 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.

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%.

freezer hat geschrieben: ↑Sa 22 Aug, 2020 11:20 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.

klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 11:35

freezer hat geschrieben: ↑Sa 22 Aug, 2020 11:20 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.

freezer hat geschrieben: ↑Sa 22 Aug, 2020 12:06

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.

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.

freezer hat geschrieben: ↑Sa 22 Aug, 2020 12:06

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.

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.

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.

Danke Dir, ja daran kann es liegen, aber der Kunde möchte 1080p. :-)

klusterdegenerierung hat geschrieben: ↑Sa 22 Aug, 2020 12:55

freezer hat geschrieben: ↑Sa 22 Aug, 2020 12:06 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:



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.

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.

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?

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?

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.

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?

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.

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

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

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