Video riesig nach Schnitt

Es hat damit nichts zu tun. Typisch CB Rechthaberei. Viele clients fragen nur die extension ab . Wenn Containerinhalt Codecs technisch passt, läuft. Es geht um Abspielbarkeit und nicht Eitelkeit.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: S K Y N E T
Ich habe verstanden. Ohne 12 Kerne, ffmpeg skripte, Premiere Stapeln läuft hier gar nicht.
 
@ss5 Davon abgesehen brauch ich eine GUI, wo ich das Audiosignal visuell sehe, sodass ich zuordnen kann, an welcher Stelle ich schneiden muss.

Habe jetzt von einem Bekannten den Tipp bekommen Handbrake auszuprobieren. Es klappt echt gut, die ursprünglich 90MB große Datei (nach Schnitt) ist nun auf 18,5MB ohne merklichen Qualitätsverlust runterkomprimiert worden (habe die Standardeinstellung 720p30 ohne weitere Anpassungen verwendet). Angeblich kann man handbrake auch von der Kommandozeile aufrufen, dann werd ich mir also wohl ein kleines Skript schreiben, das man nur noch per Klick aufrufen muss.
 
Ach was. Reicht es nicht Abspielen, Zeiten notieren und anschließend rudimentär schneiden?
Selber mit Profi Tools unterwegs. Da wo notwendig.
Ergänzung ()

Photon schrieb:
dann werd ich mir also wohl ein kleines Skript schreiben, das man nur noch per Klick aufrufen muss.
Skripte habe ich geschrieben im 2000. Der Grund: Pentium 2 brauchte Avisynth um Cinema Craft Encoder effektiv zu befüttern. 20 Jahre später bin ich zu faul für solche sado macho Spiele. Erst jetzt, wenn paar Klicks für mein Vorhaben reichen.
Wenn man alt ist, der Workflow wird wie Bayern Spelweise bei Luis de Gall. Minimalismus plus Qualität Erhalt im Vordergrund. Deshalb:
1. Rudimentärer Schnitt wenn ausreicht.
2. Smart rendering (nur Start, Endframes und timecode Korrekturen).
3. Reencoding nur wenn nicht anders geht.
 
Zuletzt bearbeitet:
Irgendwas ist hier aber auch grundsätzlich seltsam^^ 17 Minuten Video und eine Größe von 25MB? Das macht ohne Audio eine Bitrate von ~200kbps etwa für den Videostream. Das ist schon sehr sehr wenig xd
Angenommen du hast jetzt noch eine Tonspur mit 64kbps enthalten, dann hast du für den Videostream ja nur noch ~130kbps.
 
Zuletzt bearbeitet:
@ss5: Für mich ist es einfacher einen Einzeiler zu schreiben und bei einem Eintrag im Rechtsklickmenü des Dateimanagers zu hinterlegen, sodass ich auf jedes Video rechtsklicken und den Vorgang mit einem Klick starten kann, als die grafische Oberfläche von Handbrake zu starten, die Datei dort zu laden, einen Speicherort für die Ausgabedatei zu wählen usw. Ist das jetzt zu archaisch für dich oder aus irgendeinem anderen Grund verwerflich?

@Angel Of Death: Das liegt wohl daran, dass es eine Bildschirmaufnahme ist und das Bild sich nur wenig ändert (es gibt auch längere Abschnitte, wo ein Standbild zu sehen ist und das Interessante in der Audiospur passiert). Das lässt sich wohl ziemlich gut komprimieren.
 
Meine Meinung ist hier sekundär. Wenn Ergebniss passt und das kein Hexenwerk für dich ist?
Reencoding, wenn nicht zwingend erforderlich und gleichzeitig fundiertes Wissen nicht vorhanden, ist für mich verwerflich. Einfacher Schnitt(I frames ohne Umwandlung) für dein Anwendungsfall sollte reichen. Trifftige Gründe für Reencoding(personliche Meinung) :
1. Posproduction
2. Dedizierte Abspielbarkeit, Zielformat
3. Resizing für mobile Geräte
4. Authoring, Erstellung von optischen Medien.
5. Alternativen nicht bekannt.

Es spricht aber nichts dagegen Encodinng zu ergründen und sicheren Workflow für eigene Bedurfnisse erarbeiten. Es braucht Zeit, Systematik und potente Hardware.
 
Zuletzt bearbeitet:
5. Es braucht sehr viele und sehr exakte Schnitte.

So sieht meine Schnittübersicht aus:

Auswahl_15-01-2021_19:25:11.png
 
Zurück
Oben