*offizielles deutsches flaskmpeg & dvdtoogm board* (http://www.flaskmpeg.info/index.php)
- *virtualdub(mod) & avisynth* (http://www.flaskmpeg.info/board.php?boardid=27)
-- Neue Gripfit.dll ;) (http://www.flaskmpeg.info/thread.php?threadid=5901)
Zitat: | ||
Änderungen: - Neuer Avisynth.h Header beim kompilieren genutzt. - Kleine Verbesserungen bei der internen PAR Berechnung. Neben anderen Kleinigkeiten werden jetzt auch 544xYYY Zielgrößen richtig auf dem SAP wiedergegeben. - Wenn eine 720er Source auf 704er Breite gebracht wird und die Source anamorph ist, so bleibt per default der anamorphe Zustand erhalten. Bisher war das nur bei 720er Sourcen der Fall, wenn nicht manuell die Parameter entspr. gesetzt wurden. Download:GripFit2006 (Beta, --> keine Gewähr) Die Nutzung ist wie gehabt:
Wenn die Source in 720px und anamorph daherkommt wird anamorphic beibehalten und zu 704 konvertiert. Hierbei wird intern richtigerweise zu 704 hin lediglich gecroppt. GripCrop(352,576, source_anamorphic=false, resize_round_width=2, resize_round_height=2) GripSize("Lanczos4Resize") GripBorders() Skaliert einen nicht anamorphen Source Stream hin zu 352x576 und nutzt MOD2 anstatt von MOD16 beim Resizing (nicht empfohlen). Die gleiche Logic kommt auch bei "crop_round_width" und "crop_round_height" zum Zuge. Hier wird der cropping MOD verändert (2,4,8,16,32). "luma_threshold" und "samples" beziehen sich auf die Border Detection, also den Schwellenwert (threshold) und die genutze anzahl der Referenz-Frames (samples) über den gesamten Stream hinweg. Bei XVID/x264 oder generell mpeg4 Ziel-Encodings bitte so wie hier beschrieben vorgehen: Mit mpeg4 meinte ich auch PAR 1:1 (jetzt fange ich auch schon so an). Generell würde ich eh bei guten Backups empfehlen entweder nix an der Bildproportion zu ändern und somit wenns geht MOD16 croppen, oder eben, wenn die Dateien kleiner werden sollen genau das Prinzip von SVCD und Co. zu nutzen, also warum sollte man nicht z.B. ein Capture auf 544x576 bringen und am ende lediglich GripBorders() weglassen und sodann via z.B. x264 mit der entspr. PAR codieren Denn sodann wirds auch via llen Software Playern richtig unterstützt. Generell sollte bei mpeg4 targets somit GripBorders weggelassen weden. Demnach hier die richtigen PAR/SARs bei folgenden Zielformaten via GripFit: PAL non-Anamorph (AKA ca. 4:3): Output___ PAR/SAR ___Anzeige Bilschirm / Beamer ------------------------------------------------- 720x576 = 128/117 ___(788xXXX) 704x576 = 128/117 ___(770xXXX) 544x576 = 397/272 ___(794xXXX) 528x576 = 397/264 ___(794xXXX) 480x576 = 128/78 ____(788xXXX) 352x576 = 256/117 ___(770xXXX) 352x288 = 128/117 ___(385xXXX) PAL Anamorph (AKA ca. 16:9) Output___ PAR/SAR ___Anzeige Bilschirm / Beamer ------------------------------------------------- 720x576 = 512/351 ___(1050xXXX) 704x576 = 512/351 ___(1027xXXX) Alles weitere würde zu unscharf enden. Somit bei mpeg4 mit Einbehalten des anamorphen Bildes der DVD Source: GripCrop(720x576, source_anamorphic=true, dest_anamorphic=true) GripSize("LanczosResize") # oder welchen auch immer SAR/PAR wäre hier eben bei 720 anamorph : 512/351 Wenn man einen anamorphen DVD stream auf non-anamorph encodieren will, dann: GripCrop(720x576, source_anamorphic=true, dest_anamorphic=false) GripSize("LanczosResize") # oder welchen auch immer SAR/PAR wäre hier eben bei 720 non-anamorph : 128/117 Ein Beispiel für ein analog Capture (welche btw. nie anamorph daherkommen): GripCrop(544x576, source_anamorphic=false, dest_anamorphic=false) GripSize("LanczosResize") # oder welchen auch immer SAR/PAR wäre hier eben bei 544 : 397/272 Voraussetzung bei einem richtigen Resizen von analog Captures ist hierbei, dass bei 704x576 oder 720x576 die Karte proportional richtig aufnimmt (siehe Doom9 capture Faq). Ich habe bewusst 544 genommen, da captures im original nie die Güte von 720 o. 704 px ausschöpfen. |
Forensoftware: Burning Board 2.3.6, entwickelt von WoltLab GmbH