Gloster
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Folgendes script wird ausgeführt : #!/bin/sh
for f in *.ts;do ffmpeg -i "$f" -vcodec libx265 -crf 13 -c:a copy "$(basename "$f" .ts).mp4";done Ist es möglich anhand von Rückgabe Parametern ffmpeg im script abzubrechen und wieder neu zu starten, mit neuem crf : Rückgabe Parameter : time = 5min und Ist size < 270 Mbyte nach time = 5min , dann wird crf-- solange bis >= 270 MByte Ist size >= 270 Mbyte nach time = 5 min, dann wird crf++ bis der Wert unter 270 MByte liegt, dann wird der letzte wert >= 270 MByte genommen. In beiden Fällen muss ffmpeg (aber auch mit der aktuellen Datei, neu starten), bis der optimale Wert erreicht ist. Der optimale Wert ist erreicht wenn size >= 270Mbyte ist, und aktueller Wert von crf-1 führt zu size < 270M Byte. Danke, im voraus. ,
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 10978
|
Meinst du sowas? ffmpeg kennt -t HH:MM:SS , um nach einer bestimmten Zeitspanne abzubrechen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28 | #!/bin/sh
declare -i crf_guess=13
declare -i target_size_bytes=$(( 270 * 1000 * 1000 )) # use 1024 as factor for MiB instead of MB
declare -i filesize=0
for f in *.ts
do
target_filename="$(basename "$f" .ts).mp4"
ffmpeg -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
if (( filesize_bytes > target_size_bytes ))
then
while (( filesize_bytes < target_size_bytes ))
do
ffmpeg -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( --crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
else
while (( filesize_bytes > target_size_bytes ))
do
ffmpeg -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( ++crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
(( --crf_guess ))
fi
ffmpeg -i "$f" -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$(basename "$f" .ts).mp4"
done
|
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
@seahawk1986 :
Danke erst mal, ja natürlich. ffmpeg fängt mit crf = 0 an, auch nach erreichen der Zeit und Neustart von ffmpeg bleibt crf = 0. Problem gelöst, es lag an : "sh → dash" : Ich habe es in beide Richtungen getestet : filesize_bytes > (<) target_size_bytes, es läuft. Ich habe noch für ffmpeg den Parameter -y ergänzt, um die Abfrage nach dem Löschen der Datei zu vermeiden.
Für Testzwecke (sonst dauert es zu lange) habe ich die Zeit auf 15 Sekunden und entsprechend auch die Dateigröße auf 8MB, bzw. 4MB für die andere Richtung gesetzt. #!/bin/bash
declare -i crf_guess=15
declare -i target_size_bytes=$(( 8 * 1000 * 1000 )) # use 1024 as factor for MiB instead of MB
declare -i filesize_bytes=0
for f in *.ts
do
target_filename="$(basename "$f" .ts).mp4"
ffmpeg -y -i "$f" -t '00:00:15' -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
#echo ${filesize_bytes} for testpurpose
#echo ${crf_guess}
#echo ${target_size_bytes}
if (( filesize_bytes > target_size_bytes ))
then
while (( filesize_bytes > target_size_bytes ))
do
ffmpeg -y -i "$f" -t '00:00:15' -vcodec libx265 -crf $(( ++crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
(( --crf_guess ))
else
while (( filesize_bytes < target_size_bytes ))
do
ffmpeg -y -i "$f" -t '00:00:15' -vcodec libx265 -crf $(( --crf_guess )) -c:a copy "$target_filename"
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
fi
ffmpeg -y -i "$f" -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$(basename "$f" .ts).mp4"
done
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Noch eine Ergänzung :
Im script wurde target_size_bytes als Konstante eingetragen. Letztendlich wird dieser Wert aber aus der Länge des Films und der Größe der Datei berechnet. Ich habe das script ergänzt indem ich via ffprobe die Länge des Films einlese (man erhält zwar eine Fehlernachricht, aber der Ganzzahlige Wert wird richtig eingetragen).
Auch wird jetzt source_file_size eingelesen und aus beiden Werten target_size_bytes berechnet : #!/bin/bash
declare -i crf_guess=13
declare -i target_size_bytes=0 #$(( 1000 * 1000 )) # use 1024 as factor for MiB instead of MB
declare -i filesize_bytes=0
declare -i source_file_size=0
declare -i source_file_duration=0
declare -i h_264_or_vp9_compression=2 #if source file is h.264 then 2, if vp9 or av1 then 1
for f in *.ts #if webm : *.webm, if AV1 : ../*.mp4, the source files must be in the upper directory
do
source_file_duration=$( printf "%.0f" $( ffprobe -i "$f" -show_entries format=duration -v quiet -of csv="p=0"))
source_file_size=$( stat --printf="%s" "$f")
target_size_bytes=source_file_size*5*60/source_file_duration/h_264_or_vp9_compression #5min to get target size
#echo ${source_file_duration}
#echo ${source_file_size}
echo ${target_size_bytes}
#read pause
target_filename="$(basename "$f" .ts).mp4" #.webm or .mp4
ffmpeg -y -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$target_filename" #if webm dann -c:a aac
filesize_bytes=$( stat --printf="%s" "$target_filename")
if (( filesize_bytes > target_size_bytes ))
then
while (( filesize_bytes > target_size_bytes ))
do
ffmpeg -y -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( ++crf_guess )) -c:a copy "$target_filename" #if webm dann -c:a aac
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
(( --crf_guess ))
else
while (( filesize_bytes < target_size_bytes ))
do
ffmpeg -y -i "$f" -t '00:05:00' -vcodec libx265 -crf $(( --crf_guess )) -c:a copy "$target_filename" #if webm dann -c:a aac
filesize_bytes=$( stat --printf="%s" "$target_filename")
done
fi
ffmpeg -y -i "$f" -vcodec libx265 -crf $(( crf_guess )) -c:a copy "$(basename "$f" .ts).mp4" #if webm dann -c:a aac
done
|
shinichi
Anmeldungsdatum: 14. März 2008
Beiträge: 537
|
Darf ich fragen, wozu die filesize 2,1 Gbit sein muss? Warum darf das Video nicht so groß sein, wie es sein muss? Und lieber einfach das H-262-Material in MKV packen (nicht diesen MPEG-Abzockunsinn MP4) und gut statt diese eh schon lossy Kodierung in andere MPEG-lossy-Pampe (H.264) zu konvertieren und so noch mehr an Qualität einzubüßen.
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Zum Verständnis : Ausgangsmaterial = h.264, VP9 und AV01 Dateien Konvertierung von H.264 nach H.265 bringt ungefähr halb so große Dateien ohne Qualitätsverlust ⇒ Faktor 2 (so muss es sein)
H.264 Dateien (HD-Filme TV, 720p, 50 Bilder/sek) im Transportstream-Container mit einer Filmlänge von 90min haben eine ungefähre Dateigröße von 12GByte. Nur mal so, damit du weißt wovon ich rede. VP9 und AV01 sind letztendlich h.265 Derivate, wenn man vom gleichen Kompressionsgrad ausgeht, sollten die Dateien nach der Konvertierung, auch hier wieder ohne Qualitätsverlust, etwa die gleiche Größe haben wie das Ausgangsmaterial ⇒ Faktor 1 (so muss es sein) Ein Hinweis zu Qualitätsverlusten usw. : https://slhck.info/posts/, einfach mal lesen. Ob man nun mp4 oder mkv oder Ts Container nimmt, ist völlig irrelevant. Mp4 mit Abzocke in Verbindung zu bringen, ist gelinde gesagt Unsinn. Konvertiere mal keine ursprüngliche "Pampe", z.B: UHD Filme, ganz umsonst auf youtube. Die höchsten Auflösungen werden allerdings nur in AV01
(wieder diese "Abzocke", weil im mp4-Container) oder VP9 bereitgestellt (kann dein Fernseher VP9 (webm) via DLNA ?).
|
shinichi
Anmeldungsdatum: 14. März 2008
Beiträge: 537
|
Gloster schrieb: Zum Verständnis : Ausgangsmaterial = h.264, VP9 und AV01 Dateien
Ahja stimmt, TS erlaubt ja auch anderen Kram. Hatte ich vergessen.
Konvertierung von H.264 nach H.265 bringt ungefähr halb so große Dateien ohne Qualitätsverlust ⇒ Faktor 2 (so muss es sein)
Lossy nach lossy bringt immer Qualitätsverlust. Selbst wenn man den selben lossy codec benutzt und damit neu kodiert, kommt es zu Qualitätsverlusten.
H.264 Dateien (HD-Filme TV, 720p, 50 Bilder/sek) im Transportstream-Container mit einer Filmlänge von 90min haben eine ungefähre Dateigröße von 12GByte. Nur mal so, damit du weißt wovon ich rede.
Ja und? Dann sind sie halt so groß. Ich hab Videos aufm Datenspeicher, die verbrauchen noch mehr Platz. 100 Gbit sind heute eigentlich nichts mehr.
VP9 und AV01 sind letztendlich h.265 Derivate,
Es sind trotzdem andere codecs und wenn man umkodiert in lossy, dann fällt IMMER Qalitätsverlust an!
wenn man vom gleichen Kompressionsgrad ausgeht, sollten die Dateien nach der Konvertierung, auch hier wieder ohne Qualitätsverlust, etwa die gleiche Größe haben wie das Ausgangsmaterial ⇒ Faktor 1 (so muss es sein)
Das stimmt halt nicht, weil immer Qualitätsverlust entsteht.
Ein Hinweis zu Qualitätsverlusten usw. : https://slhck.info/posts/, einfach mal lesen.
Qualitätsverluste entstehen immer, wenn man in lossy umkodiert.
Ob man nun mp4 oder mkv oder Ts Container nimmt, ist völlig irrelevant.
Mp4 mit Abzocke in Verbindung zu bringen, ist gelinde gesagt Unsinn
Ist es nicht. MP4 ist von der MPEG, der vor allem MPEG-codecs unterstütz und quasi unterbewusst vermarktet. Dieser Drecksladen verdient aber NULL Aufmerksamkeit. Dieser Laden erfindet immer irgendwelche unnötigen codecs und lässt die ganze Welt Lizenzzahlungen bezahlen, weil alle Anwnedungen und was nicht alles warum auchh immer diese codecs in ihre Produkte bauen, weil die alle denken, MPEG braucht man und ohhne geht AAudio/Video nicht. Dabei gibt es längst freie und ebenbürtige Alternativen, die jeder kostenfrei nutzen kann. So machen wir alle, ob gewollt oder nicht, diesen Decksladen sinnlos reicher und reicher. Niemand braucht schon seit Jahren diese MPEG-Wegelagerer mehr, die der ganzen Welt ihre sinnlosen codecs aufdrängenund alle bezahlen lassen. MKV ist frei und technisch besser als MP4. Niemand braucht MP4.
Konvertiere mal keine ursprüngliche "Pampe", z.B: UHD Filme, ganz umsonst auf youtube. Die höchsten Auflösungen werden allerdings nur in AV01
(wieder diese "Abzocke", weil im mp4-Container) oder VP9 bereitgestellt (kann dein Fernseher VP9 (webm) via DLNA ?).
Das ist genau das Problem: Niemand sollte überhaupt Geräte oder software kaufeen/nutzen, die nur MPEG-Lizenzscheiße abspielen kann. Ja natürlich, ich kann VP9 und AV1 abspielen auf meinem Monitor, weil daran ein normales Linux hängt und ich nicht irgendwelche auf MPEG restriktivierte Scheiße kaufe. Die Welt wäre besser dran ohne MPEG. Und ich konvertiere Videos garantiert nicht nochmal in ein lossy-Format um, erst recht nicht in MPEG-Müll. Ich belasse Videos von Quellen in ihrem codec. Wenn ein 4K-Video in VP9 ist, dann belasse ich das so. Dann verbraucht es nunmal den Platz, den es verbraucht. Und in 15 Jahren ärgere ich mich dann nicht, dass ich nur eine minderwertige PPixelsoße habe statt das (für mich mögliche) Quellmaterial, was ich vor 15 Jahren mal in der Hand hatte und absichtlich weggeworfen habe für Pixelsoße. Leider speichern so immens viele ihre Videos in H.264 und neuerdings in H.265, was einfach nur Müll ist (und wir alle ezahlen indirekt auch noch für diese überflüssigen codecs). Und MP4 nutzen behält bei den Leuten leider dieses mindset bei, dass die denken, man bräuchte MPEG. Das ist eben falsch. Deswegen konsequent freie Formate benutzen, so auch Containerformate. 😉
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Noch einmal, einfach mal LESEN : https://slhck.info/posts/ Irgendwelche Verluste anzuzeigen, die bei einer Kompression entstehen, ist Unsinn, und wird noch zu einem größeren Unsinn, wenn man sich die Filme auf einem PC Monitor anschaut. Warum ???? Weil man es noch nicht einmal mit technischen Hilfsmitteln sehen kann, s.o., bitte lesen !!! shinichi : "Niemand sollte überhaupt Geräte oder software kaufeen/nutzen, die nur MPEG-Lizenzscheiße abspielen kann" Dazu ein anderes Zitat : "Abstinenzler : ... Ein totaler Abstinenzler ist jemand, der sich aller Dinge enthält, nur nicht der Abstinenz und vor allem nicht der Einmischung in die Angelegenheiten anderer.". @shinichi : Siehst du hier die Überschrift : "Grundsatzdiskussion mp4 usw. ????" Wenn ja, lerne bitte lesen !!!
|
shinichi
Anmeldungsdatum: 14. März 2008
Beiträge: 537
|
Gloster schrieb: Noch einmal, einfach mal LESEN : https://slhck.info/posts/
Nochmal: Wenn man unkodiert in lossy, entstehen Qualitäsverluste. Die Bilder werden dann nochmals durch Kompressionsalgoritmen gejagt, die wieder irgendwelche Pixel rausrechnen. Deshalb heißt es lossy. Es entstehen Verluste. H.264 in H.265 lossy umzukodieren ist idiotisch.
Irgendwelche Verluste anzuzeigen, die bei einer Kompression entstehen, ist Unsinn,
Es geht darum, dass lossy aus Material Zeug entfernt, um kleinere Dateien zu erreichen. Verluste kann man nicht anziegen, die sind weg! Und das unwiderbringlich. Deswegen sollte man das nicht tun,wenn einem das Material was wert ist.
und wird noch zu einem größeren Unsinn, wenn man sich die Filme auf einem PC Monitor anschaut.
Wieso sollte das Unsinn sein? Ich hab sogar einen großen 4K-Monitor, der steht im Wohnzimmer vor dem Sofa. Selbst auf einem 1080-px-panel kann man gut Filme schauen.
Warum ???? Weil man es noch nicht einmal mit technischen Hilfsmitteln sehen kann, s.o., bitte lesen !!!
Doch natürlich. Vo allem in dunklen Szenen (ws nun wirklich nicht selten vorkommt) sieht richtige Artefaktsoße. Und bei Animationssachen großflächigen Verläufen und harten kannten sieht man recht schnell Artefakte.
shinichi : "Niemand sollte überhaupt Geräte oder software kaufeen/nutzen, die nur MPEG-Lizenzscheiße abspielen kann" Dazu ein anderes Zitat : "Abstinenzler : ... Ein totaler Abstinenzler ist jemand, der sich aller Dinge enthält, nur nicht der Abstinenz und vor allem nicht der Einmischung in die Angelegenheiten anderer.".
Und was hat das jetzt mit dem Argument zu tun, dass MPEG sinnlose kostenpflichtige codecs rausbringt und alle warum auch immer diesen hinterher rennen und man das alles zu zahlen hat? Weder H.264 noh H.265 sind notwendig. Niemand braucht das und trotzdem wird das einem überall aufgezwungen und man muss das zahlen.
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Offensichtlich immer noch nicht gelesen !!!!!!!!!!!!!!!!!!
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7529
|
Das Problem ist daß die ersten x Sekunden (oder Minuten) ja nicht repräsentativ sein müssen fürs ganze restliche Material. Im 2pass Verfahren wird daher der ganze Film bearbeitet - und dadurch dann die gewünschte Zielgröße relativ genau erreicht. Du versuchst das 2pass Rad anhand von CRF irgendwie neu zu erfinden. Kannst du machen, aber der Sinn ergibt sich irgendwie nicht. Wenn du eine Dateigröße erreichen möchtest, warum nicht gleich 2pass nehmen, dafür ists ja da?
|
shinichi
Anmeldungsdatum: 14. März 2008
Beiträge: 537
|
Gloster schrieb: Offensichtlich immer noch nicht gelesen !!!!!!!!!!!!!!!!!!
Was soll ich da lesen? Da steht nix, was meinen Aussagen entgegen steht: Du kodierst zu lossy, dann erhälst du Qualitätseinbußen. Das ist nunmal Fakt. Und ich sehe halt den Sinn nicht, gutes Quellmaterial für Videos, an denen einem anscheinend was liegt, absichtlich zu verschlechtern (für ein paar Bit Speicherplatzeinsparung, obwohl Speicherplatz günstig wie nie ist). Ich sehe auch den Sinn nicht, H.265 zu nutzen, erstens, weil es hässlich lossy ist (für lossless benutzt es eh niemand) und zweitens weil es überflüssiger, von MPEG aufgequatschter MPEG-Lizenzscheiß ist, den niemand braucht.
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
@Frostschutz : Ich stimme dir zu, ich habe auch schon daran gedacht, es mit dieser Variante zu versuchen. Nur ein Durchlauf dauert etwa 24h, das mal 2 ... (4 Kerne, 8 Threads, alle fast zu 100%, stört aber eigentlich nicht während der täglichen Arbeit. Außer vielleicht mal kurzfristig, wenn nach yt-dlp ein merge gemacht wird, dann ruckelt es etwas, nur man muss eben 2 Tage warten, und dann stört es dann doch mal) Aber noch etwas, die Dateigröße ist nicht Priorität, optimaler crf ist das Optimum. H265 = VP9, Av01 hinsichtlich der Dateigröße, deswegen die gleiche Dateigröße, und h.264 ist ungefähr 2* H.265 Dateigröße. Ich bin mir nicht sicher ob das 2Pass macht. Deswegen bin ich gegenwärtig bei der Analyse wie man eine Art repräsentativen Mittelwert ermitteln kann, der eben etwas Zeit spart. ich nehme gegenwärtig für diesen Zweck eine Tabelle auf, die die Differenz zwischen erwünschter Dateigröße (bei "idealem crf") und ffmpeg Dateigröße ermittelt, in Abständen von etwa 5min (ffmpeg Filmzeit). Und das nochmal mit Werten wenn der crf nicht stimmt usw.. Aber ich bin erst bei den Anfängen der Analyse. Grob kann ich die ersten Messreihen so darstellen : Wenn crf zu niedrig ist, erhöht sich fast approximativ linear auch die Dateigröße "zu viel" gegenüber der gewünschten Dateigröße, und vice versa wenn crf zu hoch ist. Wenn crf "richtig" gestellt wurde, schwankt die Abweichung um einen konstanten Wert.
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
@shinichi
"Du kodierst zu lossy, dann erhälst du Qualitätseinbußen ..." Ja genau, h.264, h.265 und das bereits präsente h.266 ist alles Müll. H.262 ist das Optimum, völlig Verlustfrei. Aber noch einmal : Wo steht das in der Überschrift, dass das hier das Diskussionsthema ist ???? Bitte lesen lernen !!!
|
Gloster
(Themenstarter)
Anmeldungsdatum: 9. April 2020
Beiträge: 158
|
Das ist jetzt etwas für subjektive Anwender, im Gegensatz zu objektiven Pampe Erkennern.
Nach der Kompression kann man mit vivictpp eben subjektiv die Qualität der Kompression analysieren :
s. https://github.com/svt/vivictpp/issues/16 Das tool ist noch in der Beta Phase, aber mit den Hinweisen, s.link hat man ein Programm mit dem man selbst Filme von unterschiedlichen Quellen analysieren kann (der Zeitstempel (pts,dts) ist nicht trivial in h.264, h.265 !). Aber wenn man auf das erste I-Frame in beiden Filmen verzichtet, kann man die Filme vergleichen, selbstverständlich nur subjektiv. Bitte keine Hinweise von objektiven Analysatoren, außer diese stellen ein zugängliches tool vor !
|