Beiträge von Renntiger

Das wäre durchaus interessant. Ich hab mich dort mal angemeldet, jedoch muss man 5 Tage warten bis man dort als neuer User etwas posten darf. Mal sehen...

Also meine Vermutung ist auch gewesen, dass die meisten Software-Player das mit den Flags hinbekommen. Aber deinen Vorschlag mit dem Test finde ich gut und hab ihn mal gemacht. Mit folgendem Ergebnis:

Überraschenderweise haben alle Player, bis auf VLC, den Flag ignoriert und das Video mit dem Gammawert 2,2 angezeigt. Noch überraschender fand ich, dass die jeweiligen Player beim Anzeigen der Codec-Infos alle angegebenen Flags richtig anzeigen und diese dann im Video doch ignorieren.

Ich habe noch ein paar Screenshots gemacht und die Flags für die Transfer characteristics markiert.

Vgl_FFplay.jpg Vgl_MPC.jpg Vgl-VLC.jpg

Damit habe ich nicht gerechnet. Umso besser den Test gemacht zu haben. Ich werde dann wohl auf Gamma 2,2 mit den Flags -color_primaries bt470bg -color_trc gamma22 -colorspace bt470bg kodieren. Damit habe ich zwar System M und System BG gemischt, aber die meisten Player scheint das eh nicht zu interessieren, und die die auf die Flags schauen kommen (zumindest im Gamma, die Farbechtheit prüfe ich jetzt nicht auch noch) gut mit dem Mix an Informationen klar.

Ach gehen die Flags nur mit Software die auf libav basiert? Das heißt im Umkehrschluss, dass ich besser aufgestellt bin, wenn ich auf Gamma 2,2 encode. Das wird zukünftig in den meisten Fällen korrekt abgespielt?

Oder ignorieren die Player die Flags und schauen auf Auflösung und FPS und raten dann: PAL, Gamma 2,8?

Oh mann was mache ich denn jetzt für ein Gamma für meine PAL aufnahmen...

Jetzt ist mir doch noch etwas aufgefallen. Und zwar das Gamma bzw. die Transfer characteristics...

VirtualDub entnimmt dem avisynth-script keine Gamma-Information und zeigt (das ursprüngliche Gamma 2,8 - PAL Video) mit Gamma 2,2 an, also zu hell. Nun sind die meisten Aufnahmen sowieso etwas dunkel, weshalb die Aufhellung eigentlich ganz gut ist, lediglich die Sättigung muss ich noch etwas erhöhen.

Um nun aber den helleren Gammawert nach der h.264-Kodierung beizubehalten habe ich meinen ffmpeg-Befehl dahingehend geändert, dass ich für die Transfer characteristics den Wert für BT.470 System M (--> Gamma 2,2) verwende. Jetzt habe ich einen Mix aus BT.470 System M für die Transfer characteristics und BT.470 System B/G für den colorspace.

1) Ist das OK oder soll ich lieber einheitlich im System B/G bleiben?

2) Wie zukunftssicher ist das System B/G mit seinem Gamma 2,8 noch? Aktuellere Standards verwenden alle ein Gamma von 2,2. Die (Software-)Player sollten aber das alte PAL format auch noch in einigen Jahrzehnten unterstützen oder was meint ihr?

3) Gibt es in VirtualDub Einstellungen für die transfer characteristics?

Stabilisieren geht auch in VirtualDub ganz gut, ich nutze das Plugin "Deshaker" von Gunnar Thalin. Ich weiß nur nicht ob das auch in VDUB2 funktioniert...

Den CCD-Filter kannte ich noch nicht. Habe den soeben ausprobiert und er bringt tatsächlich noch eine kleine Verbesserung. Danke!

Eine Chroma-Shift-Korrektur war bis jetzt bei den ersten beiden VHS-Kassetten nicht nötig.

Danke für die Tipps.

Danke für den Hinweis auf die Beiträge von Bogilein. Insbesondere hier hat er ja verschiedene Capturing-Verfahren beschrieben.

Dass meine Aufnahmen auf DVD durch die MPEG-komprimierung nicht an die Qualität einer direkten unkomprimierten Aufnahme herankommen ist mir schon klar. Dafür muss ich mich nicht um sync-Probleme und andere Querelen einer Capturing-Karte kümmern.

Die oben beschriebene Nachbearbeitung möchte ich machen, da mich die unsauberen Ränder (->crop) und das Interlacing stören und ich am Ende ein gängiges Format (mp4/h.264) haben möchte.

Wenn ich die Antwort richtig verstanden habe kommt es bei meinem Ausgangsmaterial nicht mehr so genau darauf an den absolut korrekten Farbraum usw. beim Konvertieren zu erwischen, da meine Aufnahme durch die Komprimierung sowieso schon etwas verfälscht ist. Wenn sich das im Rahmen hält ist das OK für mich.

Hallo zusammen,

Beim Digitalisieren meiner VHS musste ich aufgrund diverser Fehler nochmal von vorne anfangen und habe nun endlich einen Workflow der zu funktionieren scheint. Bevor ich nun mit der Konvertierung beginne wäre es klasse, wenn ihr über meinem Workflow schauen könnt und mir sagt ob das eurer Meinung nach so OK ist oder ob ihr noch etwas anders machen würdet.

Ausgangslage: VHS abgespielt und mit Panasonic DMR-EH675 auf DVD aufgenommen. Video mit PGCdemux aus der DVD als ein zusammenhängendes .VOB extrahiert. Das .vob-Video hat folgende Eigenschaften (Info aus ffmpeg):

[mpeg @ 00000236bda76640] max_analyze_duration 5000000 reached at 5000000 microseconds st:1
Input #0, mpeg, from 'C:\Users\Renntiger\Desktop\VHS_Restauration\inputvideo.VOB':
  Duration: 00:35:38.43, start: 0.237711, bitrate: 9447 kb/s
    Stream #0:0[0x1bf]: Data: dvd_nav_packet
    Stream #0:1[0x1e0]: Video: mpeg2video (Main), 1 reference frame, yuv420p(tv, bt470bg, top first, left), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Side data:
      cpb: bitrate max/min/avg: 9282000/0/0 buffer size: 1835008 vbv_delay: N/A
    Stream #0:2[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s
Stream mapping:
  Stream #0:1 -> #0:0 (mpeg2video (native) -> wrapped_avframe (native))
  Stream #0:2 -> #0:1 (ac3 (native) -> pcm_s16le (native))

Workflow:

1) Mit dgmpgdec Audiofile und .d2v file für avisynth erstellen

2) Avisynth-Script:

video=MPEG2Source("C:\Users\Renntiger\Desktop\VHS_Restauration\inputvideo.d2v")                                                      # Video laden
audio=NicAC3Source("C:\Users\Renntiger\Desktop\VHS_Restauration\inputvideo T80 2_0ch 384Kbps DELAY 0ms.ac3")         # Audio laden

# DEINTERLACING
video=QTGMC( video, Preset="Very Slow" )

# ENTRAUSCHEN
video=TemporalDegrain(video,degrain=1,ov=4,GPU=true)

# CROP
video=Crop(video,20,12,-10,-12)

# RESIZE
video=Spline64Resize(video,704,528)  # Resize zu einem Output 1:1 Pixelverhöltnis im Format 4:3 (durch 16 teilbar)

AudioDub(video,audio)

Wo ich mir noch unsicher bin ist ob ich mit dem Farbraum noch etwas machen muss ConvertToYV12(interlaced=true)? Das Script funktioniert allerdings ohne und das Ergebnis sieht eigentlich auch OK aus (Die Qualität der Aufnahme ist allerdings eh nicht die Beste, da oft etwas überbelichtet etc.).

3) Zwischenspeichern des Avisynth-Ergebnisses verlustfrei, unkomprimiert (mit VirtualDub) als .avi.

4) Konvertieren in .mp4(h.264/AAC) mit ffmpeg:

ffmpeg -i avisynthvideo.avi -c:v libx264 -preset veryslow -crf 20 -vf format=yuv420p -aspect 4:3 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg -c:a libfdk_aac -b:a 128k fertigesvideo.mp4

Ergebnis: Die fertige .mp4-Videodatei hat folgende Eigenschaften (Info aus ffmpeg):

[h264 @ 000001c5a4fa0f80] Reinit context to 704x528, pix_fmt: yuv420p
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\Renntiger\Desktop\VHS_Restauration\fertigesvideo.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.46.101
  Duration: 00:02:37.20, start: 0.000000, bitrate: 1798 kb/s
    Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(tv, bt470bg, left), 704x528 [SAR 1:1 DAR 4:3], 1661 kb/s, 50 fps, 50 tbr, 12800 tbn, 100 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
  Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))

- Was habe ich vergessen oder übersehen?

- Bitte auch um Rückmeldung, wenn aus eurer Sicht so OK

Danke und viele Grüße