Ihr Lieben,
zwölf Jahre nach der "ersten Klappe" bin ich dabei, meinen Dokumentarfilm fertig zu stellen.
Die Endlänge werden 2,5h , damit will ich zu den Festivals und die wollen alle inzwischen
die Ansichtskopie online, am besten über Vimeo.
Als es noch vor zwei, drei Jahren das 20gb Limit gab null Problem,
doch mit fünf habe ich noch weniger Bock, mich bei Vimeo für 5gB "einzukaufen".
Und es sieht nicht danach aus, als wenn 2020 was neues hinzukommen wird.
Also. 5gB Limitz,die iuch gerne voll nutzen möchte.
Normalerweise nutze ich zum Codieren mpeg Streamclip,
doch wenn ich bei h.264 (h.265 würde ich gerne nicht nehmen) über das "Grundsetting" hinausgehe,
explodiert quasi die Datenmenge.Mit dem Kompromiss, von HD auf SD herunterzugehen-
lande ich entweder bei ca. 3.2gB ode, wenn ich nur wenige Prozent in der Qualitätsangabe
raufgehe, sch weit drüber.
Zu guten alten DVD/MPEG2 - Zeiten war die Lösung recht einfach:
Wollte ich den Speicherplatz einer DVD voll nutzen,
habe ich auf mehr als 4,3 gB codiert - und dann das Tool DVD2oneX, genutzt,
um von z.B. von 6,5 gB auf die 4,3gB zu kommen, die eine Single Layer DVD an Platz bietet.
Der Vorteil: Es konnte wirklich mehr als ein Drittel an Datenmenge eingespart werden,
bis man eine Verschlechterung in der Bildqualität gesehen hatte
und man hatte Speicherplatzmässig seine Punktlandung
Nun geistern ja offen gesagt genug Kopien von Blu-Rays durch Netz, die von vielleicht 20gB
Ausgangsmaterial auf sehr ansehnliche 4gb geschrumpft wurden.
Daher schwebt mir auch vor, einfach auf Blu-ray hin zu codieren, und dann mit entsprechender Software
aud 5gB Limit zu "schrumpfen"
Mit welchen Tools wird das gemacht? ich bin zwar in der Mac Welt zu hause und nehme an,
dass es PC Software war/ist, habe aber auch einen PC, der ein paar Tage am reencoding rödeln könnte …
Salcanon hat geschrieben: ↑Di 12 Mai, 2020 16:02
(h.265 würde ich gerne nicht nehmen)
warum?
das ist doch die naheliegenste lösung um gleiche od. sogar spürbar bessere qualität in weniger großen files unterzubringen bzw. sie effizienter zu übertragen.
mittlerweile dauert auch das encodieren nach h.265 kaum mehr länger als bei h.264.
und mit vernünftigen "-crf" einstellungen kannst du im x265 auch eine ziemlich optimale balance zwischen qualität und filevolumen sehr einfach realisieren.
bei VP9 und AV1 ist die verarbeitungsgeschwindigkeit und rechenlast noch immer deutlich problematischer, aber dank der SVT encoder ist es mittlerweile auch einigermaßen erträglich umsetzbar
Zuletzt geändert von mash_gh4 am Di 12 Mai, 2020 16:14, insgesamt 1-mal geändert.
srone hat geschrieben: ↑Di 12 Mai, 2020 19:08
oder so, ist aber halt nicht jeder der kommendozeilen-held so wie du...:-)
das spielt auch weiter keine rolle, so lange man nur wenigstens tatsächlich die relevanten optionen gezielt setzten kann und nicht irgendeine undurchsichtige fertigbackmischung.
Salcanon hat geschrieben: ↑Di 12 Mai, 2020 16:02
Die Endlänge werden 2,5h , damit will ich zu den Festivals und die wollen alle inzwischen
die Ansichtskopie online, am besten über Vimeo.
[...]
Also. 5gB Limitz,die iuch gerne voll nutzen möchte.
Wenn Du den Ton als aac mit 160Kbit/s encodierst, bleiben Dir noch 4280 Kbit/s Videobitrate (ich nutze für solche Berechnungen immer dieses Online-Tool: https://www.dr-lex.be/info-stuff/videocalc.html ). Das ist bei 1920x1080/24p alles andere als schlecht, wenn Du den x264-Codec in ffmpeg/Handbrake mit 2-Pass-Encoding, dem Tune-Parameter "Film" oder "Grain" (falls Du das Grain erhalten willst) sowie dem Preset "Veryslow" verwendest.
Meine Erfahrung ist, dass h265 zwar theoretisch die effizientere und damit bei gleicher Bitrate bessere Encodingtechnologie ist als h264 - aber... der (bei ffmpeg, Handbrake & Co.) verwendete x264-Codec in der Praxis jedoch qualitativ besser ist und das Bild weniger vermatscht als der freie x265-Codec, und zwar bei gleicher Bitrate.
cantsin hat geschrieben: ↑Di 12 Mai, 2020 21:06
Meine Erfahrung ist, dass h265 zwar theoretisch die effizientere und damit bei gleicher Bitrate bessere Encodingtechnologie ist als h264 - aber... der (bei ffmpeg, Handbrake & Co.) verwendete x264-Codec in der Praxis jedoch qualitativ besser ist und das Bild weniger vermatscht als der freie x265-Codec, und zwar bei gleicher Bitrate.
nein, dass ist leider wirklich eine völlig unhaltbare legende aus fernen zeiten.
du braucht nur mit visuellen vergleichstools od. guten messmethoden (VMAF) die tatsächlichen resultate direkt gegenüberstellen:
cantsin hat geschrieben: ↑Di 12 Mai, 2020 21:06
Meine Erfahrung ist, dass h265 zwar theoretisch die effizientere und damit bei gleicher Bitrate bessere Encodingtechnologie ist als h264 - aber... der (bei ffmpeg, Handbrake & Co.) verwendete x264-Codec in der Praxis jedoch qualitativ besser ist und das Bild weniger vermatscht als der freie x265-Codec, und zwar bei gleicher Bitrate.
h.264 u h.265 sind grundsätzlich sehr eng verwandt (Im Gegensatz zu MPEG2).
H.265 ist als Weiterentwicklung aus 264 hervor gegangen.
Die bessere Kompression ist auch nur statistisch wirksam indem größere Macroblöcke zur Anwendung kommen können und längere GOPs eingesetzt werden können.
Umgekehrt bedeutet dies, das bei gleich langen GOPs und ohne großen strukturlosen Uni-Flächen kaum Unterschiede bestehen.
Wenn dennoch Unterschiede wahrgenommen werden, dann ist die Ursache wohl eher in unterschiedlicher Encoder-Parametrisierung zu finden.
Vorausgesetzt die internen Algorithmen sind gleichwertig. Aber davon gehe ich bei x.264 u x.265 aus.
cantsin hat geschrieben: ↑Di 12 Mai, 2020 21:06
Meine Erfahrung ist, dass h265 zwar theoretisch die effizientere und damit bei gleicher Bitrate bessere Encodingtechnologie ist als h264 - aber... der (bei ffmpeg, Handbrake & Co.) verwendete x264-Codec in der Praxis jedoch qualitativ besser ist und das Bild weniger vermatscht als der freie x265-Codec, und zwar bei gleicher Bitrate.
nein, dass ist leider wirklich eine völlig unhaltbare legende aus fernen zeiten.
Ich hatte schon mit Deinem Protest gerechnet! :-)
Tatsächlich hatte ich mit eigenem Material vor einer Woche einen Vergleichstest zwischen x264 und x265 gemacht und kam eben zum überraschenden Resultat, dass x264 im "Veryslow"-Preset bessere Ergebnisse lieferte.
...in Resolve importiert, ohne weitere Bearbeitung als Rec709 Extended Video interpretiert und von der 120fps-SlowMo wieder auf 24fps 1:1-Geschwindigkeit beschleunigt, um den Codec mehr zu stressen. Den resultierenden 9-Sekunden-Clip exportiert als unkompromiertes .avi, und dann (um beim Szenario des TO zu bleiben) in Handbrake einmal umcodiert nach x264/mp4 (Preset "veryslow", Tune "film") und einmal nach x265/mp4, beide mit 4280 Kbit/s und 2-pass-Codierung.
Hier 3 PNG-Framegrabs (aus Resolve bzw. bei den komprimierten Dateien per ffmpeg) zum Vergleich:
6-uncompressed_1.1.1.png
unkomprimiert
6-codec_test-x264-1.png
x264
6-codec_test-x265.png
x265
Hier 1:1-Bildausschnitte:
crop-middle-6-uncompressed_1.1.1.png
unkomprimiert
crop-middle-6-codec_test-x264-1.png
x264
crop-middle-6-codec_test-x265.png
x265
crop-low-6-uncompressed_1.1.1.png
unkomprimiert
crop-low-6-codec_test-x264-1.png
x264
crop-low-6-codec_test-x265.png
x265
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von cantsin am Mi 13 Mai, 2020 00:29, insgesamt 1-mal geändert.
Die bessere Kompression ist auch nur statistisch wirksam indem größere Macroblöcke zur Anwendung kommen können und längere GOPs eingesetzt werden können.
es gibt schon auch noch bei den predictions und der flexibilität der transformations organisation ganz beachtliche unterschiede bzw. fortschritte in dieser nachfolgeneration!
bei sehr hohen übertragungsdatenraten ist der unterschied natürlich ohnehin kaum der rede wert, sehr wohl aber in jenen bereichen, die für die auslieferung im netz relevant sind.
das größere problem in diesem zusammenhang ist ja eher die tatsache, dass h.256 in keinem browser, der nicht von apple stammt, unterstützt wird, sehr wohl aber VP9 und AV1, die damit für die netzauslieferung bereits einen deutlich größeren anteil an endgeräten abdecken
cantsin hat geschrieben: ↑Di 12 Mai, 2020 22:43
Ich hatte schon mit Deinem Protest gerechnet! :-)
Natürlich -- ich's kann's ja nicht lassen! :)
cantsin hat geschrieben: ↑Di 12 Mai, 2020 22:43
Tatsächlich hatte ich mit eigenem Material vor einer Woche einen Vergleichstest zwischen x264 und x265 gemacht und kam eben zum überraschenden Resultat, dass x264 im "Veryslow"-Preset bessere Ergebnisse lieferte.
prinzipiell ist dein vergleich recht gut, weil man eben tatsächlich am besten ausgaben mit gleichem bandbreitenbedarf od. gleicher objektiver bildqulität zueinander in beziehung setzten muss, da die preset, crf und tuning einstellung von den verschiedenen codecs intern völlig anderes interpretiert und gehandhabt werden. die bewegung im bild ist halt bei all diesen vergleichen immer ein ziemlich problematischer faktor, den man nur schwer objektivieren kann.
dual pass habe ich selber schon seit ewigkeiten nicht mehr genutzt, da in der praxis vernünftige crf settings im regelfall viel sinnvoller sind.
es ist aber natürlich interessant, dass man vielleicht tatsächlich exotische fälle provozieren kann, in denen der alte codec vergleichsweise gut abschneidet. fälle, wo u.u. auch ein uralter intra-codec besser abscheiden könnte als ein hoch komplexer zeitgemäßer encoder. im prinzip sind ja beide hier verglichenen codecs sogar in der lage, völlig verlustfrei zu encodieren, nur dass das halt in puncto kompatibilität auch ziemlich sinnfrei ist. da aber die von dir beobachteten vorzüge weit eher die ausnahme als die regel darstellen, macht's auch nicht sehr viel sinn, dem übermäßige aufmerksamkeit zu schenken od. auf den grund zu gehen. aber ich denke, das ist dir ohnehin selbst bewusst. ;)
beim ausliefern im netz werden ja dann die videos ohnedies wieder mit deutlich gebräuchlichern und effizienteren einstellungen transcodiert, wo eben die neueren codes im normalfall die nase sehr weit vorne haben.
Zuletzt geändert von mash_gh4 am Di 12 Mai, 2020 23:43, insgesamt 1-mal geändert.
mash_gh4 hat geschrieben: ↑Di 12 Mai, 2020 23:09
da aber die von dir beobachteten vorzüge weit eher die ausnahme als die regel darstellen, macht's auch nicht sehr viel sinn, dem übermäßige aufmerksamkeit zu schenken od. auf den grund zu gehen. aber ich denke, das ist dir ohnehin selbst bewusst. ;)
Naja, immerhin waren meine Ergebnisse bisher reproduzierbar. Meinen Test vor einer Woche hatte ich mit einem selbstgedrehten Video gemacht, das ich hier nicht teilen kann - daher habe ich ihn jetzt mit dem Blackmagic-Testvideo und der vom TO angepeilten Bitrate wiederholt, und komme wieder zum gleichen Ergebnis.
Dabei stelle ich nicht in Frage, dass h265 die avancierteren Kompressionsmethoden hat. Es scheint mir nur, als ob der x265-Codec noch keine so gute bzw. hochoptimierte Implementierung des h265-Standards ist wie x264 für den h264-Standard.
cantsin hat geschrieben: ↑Di 12 Mai, 2020 23:48
Dabei stelle ich nicht in Frage, dass h265 die avancierteren Kompressionsmethoden hat. Es scheint mir nur, als ob der x265-Codec noch keine so gute bzw. hochoptimierte Implementierung des h265-Standards ist wie x264 für den h264-Standard.
ich glaube, dass das nicht zutrifft.
wenn du dir z.b. die jährlichen MSU codec vergeleichstests ansiehst, hat x265 mittlerweile in seinem feld eine ganz ähnlich vorbildliche rolle eingenommen wie sein vorgänger. es gibt zwar tatsächlich ein paar kommerzielle produkte, die tlw. noch besser abschneiden, aber auch dort ist kaum etwas darunter, mit dem wir im alltag tatsächlich in berührung kommen würden.
x264 dagegen liegt praktisch in allen derartigen wertungen immer weit dahinter, weil eben wirklich jede menge forschung und verbesserungsbemühung gerade in diese codecs eingeflossen ist.
zur frage der bandbreite bzw. qualität im zusammenhang mit dual pass encoding finde ich übrigens jenen punkt, der vermutlich nicht ganz zufällig gleich an erster stelle im ffmpeg x264 FAQ zu lesen ist, ganz nützlich:
die empfohlene bandbreite für 1080p/25 od. 30 ist normalerweise eher so um die 6 Mbps, aber natürlich geht's zur not auch mit 4. genau einen solchen unterschied können aber eben die neuen codecs wettmachen -- wie es z.b. auch dem unterschieden in den tabellen 2 u. 3 in der diesbezüglich gebräuchlichsten empfehlung zu entnehmen ist.
Die Frage des TE -also mir- ging auch dahin, welche netten Tools zur weiteren Datenreduktionvon Blu Ray genutzt werden.
Denn eine Blu - Ray Version meines Filmes wird es geben.
Nutzen die Produktpiraten wirklich alle Handbrake?
Zu h.265: ich will mich nicht darauf verlassen, dass das Endnutzergerät schnell genug dafür ist.
Viile im Bekanntenmkreis sind nicht Technkiaffin und haben alte PC-Hardware...
Salcanon hat geschrieben: ↑Mi 13 Mai, 2020 16:15
Zu h.265: ich will mich nicht darauf verlassen, dass das Endnutzergerät schnell genug dafür ist.
Viile im Bekanntenmkreis sind nicht Technkiaffin und haben alte PC-Hardware...
ich glaube, dass diese sorge eher unberechtigt ist.
h.265, VP9 und AV1 benötigen zwar in der tat weit mehr rechenleistung beim encodieren, aber das abspielen bzw. decodieren ist auch mit sehr bescheidener hardware möglich.
es ist eher ein problem, dass manche geräte (z.b. smartTVs od. player diverser scheiben), diesbezüglich oft nur eine sehr begrenzte unterstützung bieten, die sich auch nachträglich auch kaum mehr ändern lässt, aber zumindest auf PCs aller art ist das problem sehr einfach zu lösen, indem man dem auslieferungsdatenträger auch noch portable player-versionen von VLC od. mpv beilegt, so dass sich damit die videos auch auf uralten installationen befriedigend abspielen lassen.
generell würde ich sagen: für das abspielen am fernseher vie USB-stick od. bei apple geräten nimmt man besser h.265 od. sieht im hinblick auf die rückwärtskompatibilität ein fallback nach h.264 vor.
auf PCs bzw. im bowser auf nicht apple-devices ist VP9 dagegen neben dem nicht so effizienten h.264 momentan am durchgängisten unterstützt. dieses option bedient sich ja auch z.b. youtube, um videos möglichst befriedigend an den großteil der zuseherschaft auszuliefern.
Neben all den Codierungsempfehlungen muss ich mal darauf hinweisen, dass Vimeo Basic doch sowieso nur 500 MB zulässt. Vimeo Plus erlaubt 5 GB für 6 € im Monat und Vimeo Pro 20 GB für 16 €.
Im Grunde brauchst Du auf jeden Fall eine Bezahlversion, dann kann man doch auch gleich die 20 GB nehmen.
Hallo Markus
500mB pro Woche, 5gb insgesamt im Jahr.
Wenn Vimeo über 500mB abbricht, klar, dann ist das unnötig.
Lässt Vimeo einen großen upload bis 5gbzu, dann bleibt die Frage bestehen.
Teste gerade Handbrake...
prinzipel gibt's auch ganz gute andere möglichkeiten, um videos im netz völlig gratis zu hosten.
z.b. auf GitLab bzw. den dortigen gitlab-pages stehen dir in jedem projekt 10GB speicherplatz gratis zur verfügung. du kannst aber beliebig viele solche repos anlegen und mit ein bisserl kreativem mitdenken in wahrheit natürlich sogar mehrere davon gemeinsam für die auslieferung eines films nutzen, wenn du mit den 10GB kein auslangen findest. die tatsächliche auslieferung des betreffenden contents im netz erfolgt in dem fall übrigens mittlerweile über die infrastruktur von cloudflare CDN und gehört damit zu den schnellsten weltweit replizierenden lösungen.
es bleibt aber natürlich das problem, wie du deine videos für eine auslieferung im netz auf eigenen webpages ohne zuhilfenahme von service-plattformen wie vimeo, youtube od.ä. aufbereitest. das ist leider nicht ganz trivial, aber in wahrheit auch nicht derart kompliziert, dass man es nicht hinbekommen könnte. es ist eher dem allgemeinen desintresse bzw. der faulheit und relativ unkritischen herangehensweise vieler zeitgenossen zuzuschreiben, dass sich nur wenige von uns mit den dafür nötigen arbeits- bzw. aufbereitungsschritten tatsächlich auseinandersetzten.
Salcanon hat geschrieben: ↑Do 14 Mai, 2020 15:08
Die Festivals wollen zur Einreichung Bewegtbild -und keine Datei zum Download...
sagt ja keiner, dass man dort nicht auch eine webpage mit einem gängigen html-videoplayer und die DASH/HLS video-fragemente unsichtbar für die benutzer im hintergrund platzieren kann!
nach außen hin bietet das genau die selbe funktionalität wie vimeo od. youtube, nur dass man z.b. in puncto bildqualität selbst bestimmen kann, wie gut man es haben möchte...
Bluboy hat geschrieben: ↑Do 14 Mai, 2020 15:22
Da bietet sich eigentlich nur H.264 (18-24 MB/s) an.
die meisten festivals bieten eigene upload-möglichkeiten an, fordern in der regel immer noch h.264 und akzeptieren nur eine maximale bitrate von 10-12Mbps für 1080p -- was auch durchaus sinn macht, weil es nur unnötig speicherplatz verschlingt, wenn jeder glaubt, seine sachen mit noch absurderen und völlig übertriebenen einstellungen abgeben zu müssen, als wäre sein film der einzige auf der welt...
Zuletzt geändert von mash_gh4 am Do 14 Mai, 2020 16:34, insgesamt 1-mal geändert.
Originalzitat Dok Leipzig:
"In unserem Einreichformular haben Sie die Möglichkeit einen Sichtungslink einzufügen.
Ein passwortgeschützter Vimeo-Link bietet sich z.B. an."
PS:
Mit 4400 whatever und 320kb ton komme ich bei 1080p/h265 auf 5.38gb.
Sieht recht gut aus... Mit 720p und weniger Datenrate wird es wohl hinkommen.
Weiss wer, ob Vimeo die 5 gigs auf einmal blocken wird? Am besten aus eigener Erfahrung?
Salcanon hat geschrieben: ↑Fr 15 Mai, 2020 16:43
Mit 4400 whatever und 320kb ton komme ich bei 1080p/h265 auf 5.38gb.
Sieht recht gut aus... Mit 720p und weniger Datenrate wird es wohl hinkommen.
versuche es besser mit einem geeigneten "crf" wert als mit einer fixen bandbreitenvorgabe!
das liefert deutlich bessere resultate, weil für die bereiche, wo sich im bild nicht viel tut kein unnötiger platz verschwendet wird, dort aber wo es tatsächlich sinn macht mit der bandbreite raufzugehen, um die vorhandene bildinformation korrekt abzubilden, kein behinderndes limit nach oben störend im weg steht.
es gibt auch noch die variante crf zusammen mit einer banbreitenlimit zu benutzen, was für manche zwecke notwendig ist, aber in deinem fall vermutlich nicht erforderlich sein dürfte.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
