Recodierung bereits digitalisierter ehemaliger VHS-Inhalte

  • Hallo!

    Eine Ausnahme die in Sachen Digitalisieren besser keine Schule macht:
    Mir ist gerade ein DVD-Rohling in die Hand gefallen, mit einem Fernseh-Film, den ich vor ein paar Jahren mit einem MD9025 aus dem Analog-Kabel auf VHS aufgenommen hatte, und dann von diesem mit einem Sony-DVD-Recorder mit 8MBit/s auf DVD überspielt hatte...die Original-VHS ist bereits überspielt.
    (Das soll keine Schule machen, wie man digitalisiert wissen wir seit 1 Jahr alle heute alle besser - Stichwort: Panasonic, Intensity, Uncompressed).
    Naja...(einmalige Sache)

    Auf jeden Fall wollte ich den Film gerade für meine Film-Festplatte klar machen (um den Rohling zu entsorgen). Jitter war dank frischer VHS-Aufnahme vor der Überspielung kaum vorhanden, und das Bild ist durch die Sony-Wandler eben leicht weichgezeichnet...Rauschen ist noch moderat vorhanden (soll so bleiben)...
    Ich hatte die DVD jetzt gerade mit XMedia Recode 1:1 in ein MKV gepackt (MPEG2+AC3), in VDub geöffnet, den Ton normalisiert, gesplittet (2-Kanal-Ton mit Blindenbeschreibung), 15kHz-Lowpass (Analog-TV), Resample 32kHz, Video gecropped, und mit JPSDR den Chroma-Shift korrigiert...dann als UtVideo zwischengespeichert.
    Material ist nativ rein progessiv.

    Jetzt kommts:
    Mir geht es schon lange auf die Nerven, dass der "Über-Codec" H.264 sehr viele Details verwischt (sieht dann aus wie ein Öl-Gemälde) - zumindest wenn man einen mit Rest-Rauschen behafteten 80-Minuten-Film auf handliche 1,5 GB bringen will. Nun habe ich von dem Zwischenergebnis ausgehend mal mit XMedia Recode verschiedene Codecs durchprobiert, und bin gerade bei VP8 (!) hängengeblieben! Der liefert bei gleicher Größe ein deutlich detailreicheres Bild ab als H.264! Dicht gefolgt von DivX/Xvid (bzw. MPEG4 Part-2)...
    Ich habe den Eindruck, dass sich H.264 gerade hier NICHT besonders gut eignet! Der scheint mir für hochauflösende Videos mit geringem Rauschanteil eher angebracht. Bei kleinen Auflösungen (SD und darunter) mit hoher Detaildichte (Restrauschen!) macht VP8 *etwas* mehr Artefakte, dafür bleiben wesentlich mehr Details erhalten! Bei MPEG2 und MPEG4 ist es ähnlich (wobei MPEG2 wesentlich ineffizienter ist).

    Ich halte VP8 für sehr gut, wenn man progressives Material encodiert - interlaced kann der Codec leider nicht. Da würde sich dann wieder DivX anbieten...
    Und VP8 braucht in der Einstellung "good" SEHR lange - "Real Time" ist eher nicht empfehlenswert...
    Jedenfalls werde ich künftig von H.264 eher absehen, wenn es um VHS-Encodings geht!

    Wie sind da eure Erfahrungen? Das würde die Sache zudem soweit vereinfachen, dass man alles in VirtualDub machen kann (Cropping, Chroma-Shift - DNR im Panasonic-Recorder), und anschließend einfach als DivX in AVI abspeichert (Ton als MP3, AC3 oder AAC mit ACM-Codec)...

    Gruß Alex

    PS.: Stelle später noch ein paar Vergleiche rein!

    2 Mal editiert, zuletzt von Gubel (13. Februar 2015 um 00:12)

  • Äh, Moment, da bist du hier falsch. Das Thema "Analoges Video-Capturing" behandelt die Aufzeichnung direkt aus analogen Videoquellen (wie terrestrisches Fernsehen oder von VHS) mit einer TV-Karte. Da du aber schon eine Digitalisierung mit einem DVD-Recorder vorgenommen hast, ist dieses Thema ja schon längst vorbei.

    Deshalb bin ich jetzt auch verwirrt, weil ich allein aus deinem Thementitel eigentlich an Huffyuv / Lagarith / Ut dachte. Aber du hast ja schon MPEG-2. Also geht es hier um ganz andere Probleme als bei der Live-Digitalisierung durch einen PC. Es geht um Qualitätsverluste bei einer Konvertierungs-Kaskade. Und außerdem um "subjektiven Qualitätseindruck".

    Warum du den Ton mit einer Samplingfrequenz von 32 kHz dann auch noch inkompatibel zu vielen Consumer-Standards machst, ist mir zusätzlich noch unbegreiflich.

    Aber über die Art der Verluste bei der Recodierung in AVC (H.264) können wir gern mal diskutieren, wenn die Videoschnipsel fertig sind. Ich hoffe, du hast an Interlaced-Encodierung gedacht.

    Auf eine Variante als ACM-Audiocodecs für VfW würde ich bei den heutigen erstklassigen Audio-Encodern nicht hoffen, gerade bei AAC (z.B. QuickTime) wird die niemand mehr programmieren. Stattdessen unterstützt VirtualDub ab Version 1.10 auch externe Encoder und Multiplexer.

  • Ich weiß jetzt nicht, welchen Encoder XMedia Recode für h.264 verwendet (wahrscheinlich nicht x264), aber ich habe die Erfahrung gemacht, dass der Effizienzvorsprung von x264 gegenüber MPEG2 stark schwindet, sobald man leichtes oder mittleres Bildrauschen (und andere Bilddefekte von VHS gezwungenermaßen) beibehalten will (eben weil es sonst wie ein Ölgemälde aussieht).

    Man kann über diverse Tunings und Settings (und genügend Datenrate bzw. niedriger CRF!) x264 dazu bewegen, so ziemlich alles an Rauschen beizubehalten – das Ergebnis ist dann ganz ähnlich dem von MPEG2 bei höheren DVD-Datenraten, aber die von x264 benötige Datenrate ist dann gerade noch ca. ein Viertel unter der von MPEG2. Deshalb sehe ich gerade bei VHS eigentlich keinen so großen Vorsprung von h.264 gegenüber MPEG2 und verwende außer für YouTube immer MPEG2 vom CCE (natürlich auch weil es bei mir normalerweise auf DVD kommt). Soll das Video nicht (nur) auf DVD, kann man immer noch genauso gut das MPEG2 Video und den Ton verlustlos in ein MKV packen. Dass das Video dabei etwas größer als mit x264 ist, würde mich angesichts niedriger Festplattenpreise nicht wirklich stören.
    Nicht zu verachten ist auch, dass das Encodieren in MPEG2 um ein vielfaches schneller ist, als mit moderenen Codecs. Mit einer halbwegs moderen CPU erreicht man locker dreistellige fps Werte bei der Encodierung.

    Einmal editiert, zuletzt von Skiller (13. Februar 2015 um 16:57)

  • Entscheidend ist nicht nur allein, welcher Encoder für die Konvertierung verwendet wird, sondern auch, wie er eingestellt ist.

    Analogfernsehen wurde interlaced übermittelt, VHS hat leichte Schwächen in der Zeilensynchronisation ... damit ist ziemlich offensichtlich, dass der Interlaced-Modus bei der Encodierung verwendet werden sollte. Tut man dies nicht, encodiert also im progressiven Modus, dann treten bei der Betrachtung als Vollbild vertikal hohe Frequenzen auf, die schlecht komprimierbar sind, wenn die Halbbilder mal nicht ganz synchron sind. Im Internaced-Modus hat x264 speziell den Vorteil, durch die Unterstützung von MBAFF sogar teilbildweise entscheiden zu können, wo eine Encodierung im Progressiv- oder Interlaced-Modus effizienter ist.

    Bevor wir also darüber diskutieren, welches Programm wie gut geeignet ist (wobei letztlich herauskommen dürfte, dass viele verschiedene Programme im Grunde den gleichen Encoder benutzen), wäre es vorteilhaft, wenn hier auch die exakten Einstellungen dokumentiert werden. Einfach nur "H.264" auszuwählen und die Konvertierung zu starten, ist zu kurz gedacht.

    "Ölgemälde"-Effekte entstehen eventuell bei Anwendung eines technisch nicht besonders fortgeschrittenen Deinterlacers, deshalb wäre hier auch interessant zu wissen, womit das MEPG-2-Video während der Konvertierung decodiert wurde. Bei AviSynth-basierten Konvertern könnte man das Skript analysieren. Bei ffmpeg-basierten würde ich befürchten, dass der Aufruf vor dem Anwender bestmöglich versteckt wird.

  • Hallo!

    Also erstmal:
    Das betreffende Beispiel war ein Spielfilm von ZDF aufgenommen. Das Material ist 100% progressiv. Die Übertragung spielt keine Rolle. Und da die VHS-Aufnahme auch praktisch keinen Jitter hat, kann ich im "Rohmaterial" (hier MPEG2-interlaced) absolut keine Kammartefakte sehen. Deswegen progressive...da gibt es meiner Meinung nach nichts zu deinterlacen...

    An sonsten vorab erstmal Entwarnung:
    H.264 hat letztendlich doch gewonnen - beim Vergleich mit VP8 hatte ich irrtümlicherweise doch nicht die die gleiche Durchschnittsbitrate verwendet! VP8 kann nur progressive. H.264 kann beides, obwohl ich bei progressivem Bildmaterial auch immer progressiv encodiere.

    Die MPEG2-Decodierung erolgte mit ffdshow libavcodec (direkt in VirtualDub importiert), als YUY2 vom Decoder abgerufen (Video->Colorspace). Dann im Filter-Chain nach YV24 gewandelt (da ist man flexibler), die Farbverschiebung korrigiert und gecroppt. Dann als UtVideo 4:2:0 zwischengespeichert.

    Danach mit XMedia Recode encodiert. Ich verwende üblicherweise diese Einstellungen:
    [Blockierte Grafik: http://fs1.directupload.net/images/150215/7kqyf5cf.png]

    ...den Rest (Bewegungsschätzung, Bitratensteuerung, Deblocking, B-Frame, Makroblock, etc.) habe ich auf "Standard" gelassen, weil ich diesbezüglich nicht "studiert" habe...:hm:

    Was XMedia Recode für einen Encoder verwendet wusste ich nicht, hatte immer geadacht es wäre x264 ??

    @ Skiller: Da hast du also auch die Erfahrung gemacht. Wie genau "bewegst" du x264 dazu, möglichst wenig zu "pastellisieren"? Nur durch hohe Bitrate (entsprechend 3/4 von dem was man für MPEG2 benutzen würde)? Oder noch ein paar andere Kniffe?

    Wo war nochmal das Tutorial, wie man x264 als externen Encoder in VirtualDub einbinden kann?
    An sonsten gibt es durchaus aktuelle AAC- und AC3-Codecs für ACM (siehe fccHandler): http://gral.y0.pl/~fcchandler/.
    Auch Lame-MP3 3.99 ist als ACM-variante vervügbar (natürlich nur CBR)...

  • ...habe das gerade mal gemacht:

    Ich gehe bei den Encoder-Scripts ja mal davon aus, dass alle Parameter, die man NICHT angibt dann auf Standard belassen werden. Also kann ich mir jetzt verschiedene Profile anlegen mit verschiedenen CRF-Faktoren (ja, ist besser als ABR ;) ), und für Interlaced und Progressive?

    Ich habe jetzt erstmal alles 1:1 übernommen. QAAC macht Probleme - das kommt:

    [Blockierte Grafik: http://fs1.directupload.net/images/150215/wbrwff8q.png]

  • Hast du auch ein Log von der Konsolenausgabe, die VirtualDub abgefangen hat?

    Möglicherweise meint QAAC, das Audioformat nicht zu erkennen. Ich erinnere mich schwach, das vor kurzem anderswo gelesen zu haben, vielleicht im VideoHelp-Forum? Könnte sein, dass man da noch die Checkbox braucht, dass VirtualDub den Audio-Stream mit WAV-Header ausgeben muss. Ach ja, und die CoreAudioToolbox aus iTunes oder QuickTime muss natürlich auch verfügbar sein (installiert oder extrahiert mit makeportable.cmd).

  • Hallo Gubel,


    Jetzt kommts:
    Mir geht es schon lange auf die Nerven, dass der "Über-Codec" H.264 sehr viele Details verwischt (sieht dann aus wie ein Öl-Gemälde) - zumindest wenn man einen mit Rest-Rauschen behafteten 80-Minuten-Film auf handliche 1,5 GB bringen will. Nun habe ich von dem Zwischenergebnis ausgehend mal mit XMedia Recode verschiedene Codecs durchprobiert, und bin gerade bei VP8 (!) hängengeblieben! Der liefert bei gleicher Größe ein deutlich detailreicheres Bild ab als H.264! Dicht gefolgt von DivX/Xvid (bzw. MPEG4 Part-2)...
    Ich habe den Eindruck, dass sich H.264 gerade hier NICHT besonders gut eignet! Der scheint mir für hochauflösende Videos mit geringem Rauschanteil eher angebracht. Bei kleinen Auflösungen (SD und darunter) mit hoher Detaildichte (Restrauschen!) macht VP8 *etwas* mehr Artefakte, dafür bleiben wesentlich mehr Details erhalten! Bei MPEG2 und MPEG4 ist es ähnlich (wobei MPEG2 wesentlich ineffizienter ist).


    Irgendwo war etwas mit Mpeg-2!
    Ich hatte einen Schipsel hochgeladen der grauenhaft war und ich hatte es der Eile nicht bemerkt. Erst mit deinen Tipp mit dem Mpeg-Plugin für VirtualDub kam ich weiter.
    Der Verursacher für die schlechte Qualität war eine Steckkarte. Kanns du dich erinnern?
    Nach dem Entfernen dieser Karte stimmte die Qualität. Ich kann jetzt beim Betrachten des Mpeg2- Videos fast keine Abweichungen zur Original-Avi in der Schärfe.
    Bei dem angehängten Screenshot der Standbilder für den Vergleich sind logischerweise Unterschiede erkennbar.
    Ich kann mir vorstellen, dass die schlecht ausfallende Beurteilung von den Codec's nicht am Codec selbst liegen muss, sondern auch von dem Algorithmus des benutzten Programms kommen kann.

    Mpeg-2 und Original-AVI.jpg

  • @ Skiller: Da hast du also auch die Erfahrung gemacht. Wie genau "bewegst" du x264 dazu, möglichst wenig zu "pastellisieren"? Nur durch hohe Bitrate (entsprechend 3/4 von dem was man für MPEG2 benutzen würde)? Oder noch ein paar andere Kniffe?

    --tune grain hilft schon enorm, es beinhaltet folgende Kniffe (nur zur Info):

    --aq-strength 0.5 --no-dct-decimate
    --deadzone-inter 6 --deadzone-intra 6
    --deblock -2:-2 --ipratio 1.1
    --pbratio 1.1 --psy-rd <unset>:0.25
    --qcomp 0.8

    Dazu einen CRF kleiner als 23 wählen; ein sinnvoller Bereich ist meiner Meinung nach 17 (normalerweise recht groß) bis ca. 22. 20 ist meist ein guter Kompromis. So ab 23 kann man sich die Geschichte mit dem Grain-Tuning auch wieder sparen, weil dann einfach zu stark komprimiert wird, um das Rauschen augenfreundlich beizubehalten.


  • Wo war nochmal das Tutorial, wie man x264 als externen Encoder in VirtualDub einbinden kann?


    Diese Variante: (Ich nenne Sie mal: )
    x264.exe (eigenständiger Encoder) + AAC Audio über qaac = Im MP4 Container mit MP4Box > muxen / und das ganze über VirtualDub extern speichern!!
    dürfte auch für Gubel und seinem Tutorial (Zeitgemäßes hochwertiges analoges Capturing per USB oder HDMI) interessant sein!
    Ich werd Ihn mal auf diesen Beitrag hier aufmerksam machen...

    Freut mich, das du auf diese Encoding Variante zurück gekommen bist...
    Bzw.. Dich daran Erinnert hast :)

    ...habe das gerade mal gemacht:

    Ich habe jetzt erstmal alles 1:1 übernommen. QAAC macht Probleme - das kommt:

    Außerdem erwartet es .wav-Ausgabe. Für den Audio-Encoder gibt es bei Virtual Dub einen extra Reiter, wo Du auf "WAV file" umstellen kannst.


    Also kann ich mir jetzt verschiedene Profile anlegen mit verschiedenen CRF-Faktoren (ja, ist besser als ABR )
    und für Interlaced und Progressive?

    Jepp :)

    #52
    Hast du Dir schon mein kleines Video Tutorial angesehen? ;)
    -----------------------------------------------------------------------------------------

    PS: Ich würde den x264 Export, ohne Audio Ausgabe encodieren!
    Siehe: #51
    VirtualDub-Export_x264-(Ohne.Audiospur)_im-MP4-Container.vdprof
    Der Grund ist folgender:
    Das Fertige Expotierte Video + Audio per VirtualDub im MP4 Container, ist nicht V/A exakt :(
    Da enstehen Syncrone Abweichungen!
    Das fertige Ergebniß, kann man gut einem AviSynth Script testen und per VirtualDub unter FileInfo sich anschauen.
    Wahrscheinlich liegt der Fehler beim gemeinsamen V+A Export Encoding per VirtualDub.. ??
    Die Tonspur, würde ich vorher seperat Encodieren und hinterher im MP4 Container (dem reinen x264 VideoInhalt) mit zufügen (muxen)

    8 Mal editiert, zuletzt von H264x (17. Februar 2015 um 18:20)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!