Beiträge von LigH

StaxRip unterstützt AviSynth als Filter-Skriptsprache, und in AviSynth fallen mir mindestens drei Möglichkeiten ein: GreyScale(), Tweak(sat=0.0) oder das Löschen der Chrominanzkanäle in einem YUV-Format (ConvertToY8 und zurück oder MergeChroma)... also kurze Antwort wäre "ja"; Tweak findet man im Untermenü Color - ColorYUV, wenn man AviSynth-Filter in den Filterstapel einfügt.

Die ganze "weitere Bearbeitung" sollte man schon vor der endgültigen Encodierung tun, denn das H.264-Videoformat hätte für weitere Bearbeitung Nachteile: Erstens kann man dann nicht mehr schneiden, wo man will (wegen GOPs), zweitens verliert man bei jedem weiteren Encodieren über die "Generationen" mehr und mehr Qualität.

Außerdem sollte man sich gut überlegen, welche Anpassungen vor und welche nach dem Deinterlacing besser wirken. Bei QTGMC in AviSynth kann man z.B. das Entrauschen in den Deinterlacing-Prozess integrieren. Bildstabilisierung funktioniert vielleicht hinterher mit progressiven Vollbildern besser. Allerdings weiß ich hier nicht im Detail alles am besten aus praktischer Erfahrung, da werden sicher gern noch andere ihre Tipps beisteuern.

Wer ihn noch nicht kannte: Es ist ein Media-Player in JavaScript. Daher ein Release als Quelltext.

Das exakte Modell zu kennen wäre schon mal hilfreich, dann findet man sicher auch Dritt-Informationen darüber.

VirtualDub hilft auch: Wenn der Capture-Modus ein Eingabegerät erkennt, kann er wahrscheinlich auch unkomprimiertes Video liefern. Erkennt VirtualDub keins, und ohne die beigelieferte Software kann man gar nichts aufnehmen (und mit ihr nur MPEG-2), dann ist da wohl ein simpler MPEG-2-Encoder drin, der die Datenrate auf USB-1.x-freundliche Bitraten mit max. 12 Mbps komprimiert (unkomprimiertes YUV hätte eine sehr viel höhere, aber schon USB 2.0 High Speed schafft theoretisch bis 480 Mbps; YUV 4:2:2 bräuchte ~165 Mbps).

Der VLC schaltet zur Wiedergabe am PC-Monitor u.U. einen Deinterlacer dazu, wenn er typische Standard-SD-Videoformate erkennt; der ist kein sicheres Kriterium.

Ich kenne nicht "alle"; aber die Wahrheit liegt irgendwo dazwischen. Für C) spricht vor allem die Wahl des Codecs im Videograbber. Wenn er nur stärker komprimiertes Video liefert (z.B. MPEG-2), dann kannst du nur hoffen, dass die Firmware vernünftig ist – A) bei SD-Analog-Video wird "interlaced" als Standard angenommen – oder oder er B) per Software konfiguriert werden kann. Auch wenn er dann eigentlich komplett nicht empfehlenswert ist, wenn er nur das kann. Besser wäre, wenn er unkomprimiert UYVY oder YUY2 (YUV 4:2:2) liefern kann. Dann liegt es allein an der Software, die das aufgezeichnete Video weiter verarbeitet. Denn dann sind alle Videozeilen voneinander unabhängig. Und dann bestimmst du im Schnittprogramm, was du da aufgenommen hast.

MediaInfo analysiert nur Headerdaten. Dafür aber ganz detailliert.

Bei MPEG2 ist der Bitraten-Angabe im Header nicht immer zu trauen. Bestimmte Standards erfordern, dass im Header eine Zielbitrate für einen Multiplexer eingetragen wird, aber die tatsächliche Bitrate kann deutlich geringer sein. In anderen Situationen kann der Encoder da aber auch die mittlere Bitrate eintragen. Korrekte Werte bekommt man jedoch nur nach vollständiger Analyse der Spieldauer.

Tut mir leid, ich habe noch nie Kdenlive benutzt...

Der AVI-Container selbst hat keine Flags für Interlacing. Und auch nicht jeder Videocodec hat intern unterschiedliche Arbeitsmodi. Es kommt dann also nur darauf an, ob man u.U. in der Software irgendwelche Projekt-Eigenschaften hat, oder ob man den finalen Codec entsprechend konfigurieren kann. Was Kdenlive kann und ob das fehlerfrei funktioniert, weiß ich persönlich gar nicht.

"Full luma range" ist hier sicherlich falsch. Warum es damit nicht ruckelt, kann ich mir im Moment aber nicht recht vorstellen.

DV (Digital Video) ist digital aufgezeichnet (encodiert ähnlich dem MJPEG-Verfahren) und verwendet laut Standard IEC 61834-2 / SMPTE 314M die Dominanz BFF; Hi8 ist analog (ähnlich S-VHS) und verwendet meist TFF, entsprechend dem PAL-Fernseh-Standard. Ursache ist das ursprünglich aufzeichnende Videosystem.

Zitat von av22

Nimmt Avisynth immer an, daß es BFF ist ... ?

Reicht es aus, nun in Avisynth einfach "AssumeTFF ()" voranzustellen ?

Ja. Bei AviSource wird BFF voreingestellt, weil DV-AVIs praktisch immer BFF sind. Nach AviSource "AssumeTFF()" zu verwenden genügt, wenn AVI-Dateien geladen werden, deren Field-Dominanz tatsächlich TFF ist.

AssumeField/FrameBased braucht man eigentlich nicht zu ändern, Quellfilter liefern das Video normalerweise Frame-Based, und lediglich Filter wie SeparateFields() und Weave() ändern das sinnvoll in ihrer Anwendung. Diese Assume-Funktionen können in seltenen Fällen für interessante Effekte nützlich sein, in der herkömmlichen Filterung muss man sie aber praktisch nicht verwenden.

Am Ende der Filterung kann es nötig sein, die Field-Dominanz im Encoder noch mal explizit einzustellen. Die Schnittstelle, mit der AVIs oder die AviSynth-Videoausgabe an Encoder weitergeleitet werden, hat u.U. gar keine Information darüber. Falls du den x264-Encoder in VirtualDub2 verwendest, müsstest du z.B. den Kommandozeilen-Parameter --tff in das Feld "Extra command line (for advanced users)" hineinschreiben, weil dieser Dialog keine Eingabeelemente für Interlaced-Encodierung anbietet.

Je nach dem ... ich bin mit MediaFire auch recht zufrieden, wenn es länger bleiben soll, und für kurzzeitigen Austausch ist WeTransfer auch geeignet. Allerdings kenne ich den Horst noch nicht so gut. Muss ich mal genauer anschauen.

Genau. Weil DV auch überall Schlüsselbilder hat, ginge das auch im Video-Modus "Direct Stream Copy".

Ich nehme an, VirtualDub2 würde bei DV von sich aus BFF vermuten, wo das nötig und automatisierbar wäre. Beim Ausschneiden eines AVI-Clips in VirtualDub sollte das aber keine Rolle spielen. Nur bei Neukomprimierung mit anderen Codecs, bei denen das wichtig ist, oder beim Filtern (z.B. Deinterlacer).

Bei DV gilt so gut wie sicher: Bottom Field First.

Es liegt nur schon digital auf Band vor. Also wäre es unsinnig, es analog über ein Videokabel einzuspielen und neu zu digitalisieren, anstatt es einfach digital per FireWire nur zu kopieren.

Wenn ich mich recht erinnere, bevorzugen Programme, die AVI-Dateien verarbeiten, den DV-Typ 2 mit getrennt gespeicherter Tonspur.

Seit ewigen Zeiten: WinDV (bei VideoHelp oder eigene Homepage) liest DV-Video direkt und ohne Neukodierung via FireWire (IEEE 1394) in AVI-Dateien.

Das Ausgabeformat sieht für mein kurzes Drüberschauen korrekt aus. Als Einstellung im Video-Modus würde ich "Fast Recompress" empfehlen. Das Format muss sich ändern, wenn du mit Ut komprimiert hattest, in dem Fall ist "Direct Stream Copy" nicht möglich, denn es kann ja nicht Ut-Video bleiben.

Ich habe leider nicht genug Zeit, stellvertretend für dich meine Freizeit zu opfern, um eine halbe oder ganze Stunde lang für dich das Internet zu durchsuchen, nur weil du so ungern Grundlagen lernen willst...

Zumindest habe ich entdeckt, dass es für Dropouts in analogen VHS- oder Sat-Aufnahmen "Despot" oder "RemoveSpots" als AviSynth-Filter gab. Allerdings kann ich nicht garantieren, dass die bei der doch erheblichen Länge in deinem Beispiel noch zuverlässig arbeiten. Und die sind auch schon relativ alt, ich weiß also nicht, ob die in einem moderneren AviSynth+ noch ordentlich funktionieren.

Video - Compression - Uncompressed (RGB / YCbCr) ... dann wird so gespeichert, wie es unkomprimiert am Ende der Filterung herauskommt – oder bei "Pixel Format" eingestellt ist.

Du meinst, du willst das Video völlig unkomprimiert speichern, als UYVY oder YUY2? Ja, gut, das kann man machen. Das braucht denn nur viel mehr Platz als ein verlustfrei komprimiertes Video. Dann aber ist auch jedes Frame ein Keyframe.

Ich habe dir doch schon in Antwort #101 erklärt: Ohne Neukomprimierung kannst du nur an Schlüsselbildern schneiden. Gut komprimierende Videocodecs verwenden aber nur selten Schlüsselbilder. Du kannst hier also kein Direct Stream Copy für das Video verwenden. Aber verlustfrei komprimierende Codecs wie Ut speichern das Video trotz Neukomprimierung identisch im Modus "Fast Recompress".

"Fische" filtern ist schwierig. Erst recht nur mit VirtualDub-Filtern.

Die Auswahl an guten VirtualDub-Filtern ist gering, da die Einschränkungen dieser Technik anfangs zu groß waren und AviSynth oder VapourSynth sich mittlerweile viel besser entwickelt haben, bevor VirtualDub2 dann ein paar Verbesserungen gebracht hat. Hat sich dann wohl für viele Autoren nicht mehr gelohnt, dafür nun auch noch mal zu programmieren. Was besseres als Yadif oder ELA im internen Deinterlacer-Filter wirst du in VirtualDub2 wohl nicht bekommen.

In der Tat ist für so ein Vorhaben ein "Nicht-Linearer Video-Editor" mit einer Timeline besser geeignet. Wenn du kräftige Hardware hast, könnte auch schon das kostenlose DaVinci Resolve geeignet sein; ich weiß, dass einige Dashcammer für YouTube damit ihre Clips arrangieren (und nebenbei noch die Kennzeichen mit Motion-Tracking DSGVO-konform verpixeln). Aber auch für einfachere Anforderungen gibt es passende kostenlose Software (z.B. OpenShot, Shotcut, Kdenlive).

Yadif ist ein relativ guter, aber vor allem schneller Deinterlacer. Qualitativ gibt es besseres, gerade QTGMC unter AviSynth ist da sehr leistungsstark. Leider braucht man sehr viele Plugins in aktuellen Versionen, das zu installieren ist etwas aufwändig. Dann aber bekommt man einen Deinterlacer, der Bewegungskompensation nutzt und sogar gleich noch mit EDI hochskalieren kann, falls du ohnehin vorhast, von SD (576i) auf HD (720p²) zu gehen.