Posts by LigH

    noch was:

    wäre es sinnvoll das file vor avisynth+ durch mkv toolnix zu jagen um

    von 720x576 in 4:3 auf 720x576 in 5:4 zu kommen?

    Das spielt überhaupt keine Rolle. Videofilter interessieren sich nicht für Seitenverhältnisse, nur für den Bildinhalt, wie er encodiert ist (so wie SAR 1:1). Seitenverhältnis-Markierungen (Aspect Ratio Flags) ändern nur die Wiedergabe auf dem Bildschirm in einem Mediaplayer, eventuell wird entzerrt.

    Es gibt Workflows, in denen Remultiplexing nach MKV nützlich sein kann. Aber bei AVI-Dateien mit im System installierten VfW-Codecs ist das nicht notwendig, da funktioniert AviSource in Avisynth gut genug.

    es sind die Bitraten, die man einstellen sollte

    Das ist für Privatanwender völlig irrelevant. Bei verlustlosen Codecs kann man die Bitrate gar nicht beeinflussen, die Kompression ist deterministisch (für den selben Videoinhalt immer das selbe Ergebnis). Bei qualitätsbasierter Encodierung (z.B. x264 CRF) hängt die Bitrate vom Bedarf für den Qualitätserhalt ab. Bei Encodierung für einen übergeordneten Standard (z.B. x264 2-pass VBR mit VBV für Kompatibilität zu Blu-ray o.ä.) werden Bitraten durch den VBV vorgegeben. Eine CBR- (ABR-) Encodierung ist immer die am wenigsten empfehlenswerte Methode, da sie zu schwankender Qualität führt, so etwas kann man nur empfehlen, wenn man eine Übertragung durch ein Medium hat, das eine begrenzte Bitrate hat, und man in einem Durchgang fertig sein muss, wie beim Live-Streaming über ein Netzwerk, und darum muss sich RextheC überhaupt nicht kümmern. Er braucht noch nicht einmal "professionelle" 10-Bit-Codecs, wenn er sowieso vermutlich ziemlich verrauschtes VHS-Material als Quelle hat, anstatt Top-Studio-Qualität aus dem Computer mit glattpolierten Farbverläufen, wo man Banding vermeiden müsste. Deine Tipps sind mal wieder für eine ganz andere Zielgruppe...

    Das hieße es ist schon empfehlenswert nach PAR 1:1 zu resizen...

    Mangels praktischer Erfahrung kann ich hier keine konkreten Empfehlungen geben; ich würde davon ausgehen, dass es sicherer wäre, gecropptes Material mit zusätzlichen Rändern wieder auf ein von höheren Standards typischerweise verwendetes Bildformat aufzufüllen und sowohl dem Videoencoder als auch dem Container-Multiplexer die passenden Seitenverhältnis-Flags mitzugeben.

    Mit anderen Worten: 688×548 Pixel 11:12 auf 768×576 Pixel 1:1 skalieren kann funktionieren; 688×548 Pixel 11:12 auf 704×576 Pixel 11:12 umranden und x264 die SAR 11:12 mitteilen (und evtl. noch dem Multiplexer eine DAR 4:3) sollte ziemlich sicher funktionieren, auch wenn man dann den Bildschirm nicht komplett ausgefüllt hat.

    Oder 688×548 zu 720×576 skalieren und eine SAR von 15:16 in x264 wählen, falls das wirklich das richtige Verhältnis ist.

    spline36resize(360,576).spline36resize(720,576).spline36resize(768,576)

    Mehrfach hintereinander skalieren ist grundsätzlich eine schlechte Idee. Können wir nicht das Problem der senkrechten Streifen erst einmal lösen, also mal etwas Beispielmaterial sehen, um eventuell die Ursache dafür zu erahnen? Und es gab ja auch mal Filter von Fitzick, die darauf spezialisiert waren, so Ewigkeiten her...

    704 x 576, 4:3 und 720 x 576, 4:3 sind quadratische Pixel. Dann ist der Ball rund und nicht eliptisch.

    Ziemlich missverständlich formuliert.

    Der Encoder speichert so viele Pixel, wie das Video hat, egal zu welchem Seitenverhältnis das dann führt. Vielleicht 704 Pixel pro Zeile, vielleicht 720, vielleicht auch nur 696, wenn so beschnitten wurde.

    Bei der Wiedergabe entscheidet sich dann, ob der Inhalt auf dem Bildschirm korrekt aussieht. Bei 1:1-Pixeln wird das Bild so dargestellt, wie das Video encodiert wurde.

    Bei einem Hinweis auf ein gewünschtes Bildseitenverhältnis (DAR Flag), wie bei MPEG-2 üblich, das z.B. bei DVB oder DVD Video verwendet wird, bedeutet das eine Anweisung an den Decoder: Entzerre mir mal das Video so weit, dass es auf dem Bildschirm z.B. 4 Mal so breit wie hoch aussehen wird. Bei 576 Bildschirmzeilen, wie für PAL üblich, entspricht das einer Breite von 768 Zeilenhöhen auf dem Bildschirm. Egal wie viele Pixel das encodierte Video breit ist.

    MPEG-4 dagegen verwendet Entzerrungsfaktoren (SAR Flag), hier wird also angegeben, wie viel breiter jedes Pixel (im Durchschnitt) bei der Wiedergabe aussehen soll. Beim analogen Capturing hat man bei PAL also üblicherweise einen Faktor (exakt 702, vereinfacht) 704 : 768, gekürzt um 64 also 11:12, um den der Bildinhalt in der Breite gestaucht gespeichert wurde. Zur korrekten Wiedergabe muss er also um 12:11 wieder entzerrt werden. Auf einer DVD Video dagegen wurde das Video bei 4:3-Inhalten meist eher mit 720 Pixeln Breite digital gespeichert, das Verhältnis 720 : 768 entspricht gekürzt mit 48 also 15:16, bei der Wiedergabe auf einem 4:3-Bildschirm muss es also um 16:15 entzerrt werden. Und da spielt keine Rolle, ob ein Teil des Bildes kein interessanter Bildinhalt, sondern nur schwarzer Rand ist.

    Die Spezifikationen einer DVD Video erfordert bei PAL entweder 352, 704 oder 720 Pixel Breite bei 576 Zeilen Höhe, 696 Pixel sind nicht erlaubt. Bei analogem Capturing ist es relativ egal. Wer ein Video mit 696 Pixeln Breite in MPEG-4 AVC (H.264) von einem Smart-TV abspielen lässt, kann Glück oder Pech haben, dass es verzerrt oder korrekt aussieht. Ein guter Mediaplayer auf dem PC wird sich an die Markierungen halten, die entweder im Videostream oder im Container (MP4, MKV o.ä. / SAR oder DAR) eingestellt wurden.

    Hallo.

    Soweit ich mich erinnere (VHS ist ja verdamp lang her): 720 Pixel Breite werden bei DVD in MPEG-2 encodiert, aber analoge Signale im PAL-Fernsehen und auf VHS haben eigentlich nur eine horizontale Auflösung von ~702 Samples pro Zeile; um auf Vielfache von 16 zu kommen, wird häufig einfach die nächste MPEG-typische Auflösung von 704 Pixeln Breite encodiert. {PS: Falls Matrox hier die Ausnahme ist und tatsächlich lieber mit 720 als 704 Pixeln arbeitet, ist etwas Umdenken notwendig.}

    Lass diese Auflösung bis zum endgültigen Videocodec (z.B. x264) so und stelle dort nur ein, dass bei der Wiedergabe ein Seitenverhältnis von 4:3 dargestellt werden soll. Weil H.264 mit einem Entzerrungsfaktor arbeitet (SAR), wird dort ein geeigneter Umrechnungsfaktor zum Bildseitenverhältnis (DAR) angeboten, z.B. 768:704 ~ 12:11.

    Warum du die horizontale Auflösung halbieren musst, also 352 Samples pro Zeile, müsste man mal anhand eines Videoschnipsels beurteilen, um die mögliche Ursache senkrechter Streifen zu identifizieren, vielleicht sind es Störsignale im Composite-Kabel.

    Composite ist ein leichter Nachteil, weil Helligkeit und Farbigkeit frequenzmoduliert in einem analogen Signal vorliegen. Wenn du die Möglichkeit hast, S-Video zu verwenden (oft mit "Hosiden" Mini-DIN-Stecker), wäre dieser Weg zu empfehlen.

    Interlacing muss nicht zwingend entfernt werden, man kann den finalen Encoder (x264) auch so einstellen, dass er das Videobild originalgetreu im Interlaced-Modus (bei VHS meist TFF, oberes Halbbild zuerst) speichert (und dieses erst bei der Wiedergabe auf einem Flachbildschirm passend aufbereitet wird). Aber wenn du das vorher hochwertiger in der Filterung vor der Encodierung tun willst, ist QTGMC sicher der qualitativ beste Filter; nur die Installation aller beteiligter Komponenten ist etwas aufwändig. Es wird dann von 50 Halbbildern pro Sekunde auf 50 Vollbilder pro Sekunde hochgerechnet, es sei denn, du lässt die Bildrate entweder innerhalb von QTGMC mit FPSDivisor=2 oder nachträglich halbieren.

    Hier noch etwas ausführlichere Dokumentation zu den Grundlagen analoger Videosignale und Capturing: Exotisches Interlacing (by scharfis_brain)

    Ganz ganz früher, als Radium noch per Maultier beschafft wurde, hatte ich mal Soft Encode 5.1 von Sonic Foundry irgendwo gesehen (wie auch Sound Forge als genereller Audio-Editor). Die wurden dann von Sony übernommen, und deren kommerzieller AC3-Encoder wurde u.a. in Acid und Vegas weiter verwendet. Da eigentlich nur DVD-Studios so etwas brauchten, wurde der Codec auch sauteuer vermarktet...

    Aften ist als AC3-Encoder relativ simpel, hatte noch keine besonders komplexe Psychoakustik, aber bei ausreichend Bitrate sehr arm an Artefakten und sehr gut steuerbar, hat auch Metadaten spezifikationsgetreu umgesetzt. Der in ffmpeg (libavcodec) verwendete (E-) AC3-Codec hat mittlerweile eine recht gute Qualität, durchaus mit LAME für MP3 vergleichbar.

    Der Codec Huffyuf v2.1.1 existiert wahrscheinlich nur in einer Version mit 32-bit-Code. Deshalb kannst du ihn auch nur in Programmen mit 32-bit-Code benutzen. Wenn du keine 64-bit-Version zusätzlich in deinem System installiert hast, dann ist er in 64-bit-Programmen nicht verfügbar.

    Es gibt verlustlos komprimierende Videocodecs, die auch heute noch gepflegt werden und sowohl in 32-bit-Code als auch in 64-bit-Code zum Installieren in das Windows-System verfügbar sind, beispielsweise das UtVideo-Paket.

    Die Codecs, die in VirtualDub2 mit einem "Driver name: (...).vdplugin" angezeigt werden, sind nur innerhalb von VirtualDub2 durch ein Plugin verfügbar. Im System installierte VfW-Codecs sind an "Driver name: (...).dll" im Video-Compressor-Dialog erkennbar.

    Von all dem bist du relativ unabhängig, wenn du dich nicht auf AviSource verlässt, wenn du Videos in AviSynth mit einem Decoder-Plugin öffnest.

    Offizielle Dokumentationen:

    PS: Dass VLC Probleme mit Huffyuv-Video verschiedener Varianten in AVIs hatte, lag an einem Fehler in der Codec-Erkennung, die ich man an die Entwickler gemeldet hatte, und das müsste eigntlich in aktuellen Versionen behoben sein, dachte ich. Wer weiß.

    In DaVinci Resolve kann man vielleicht auch was ähnliches animieren?

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.