• Ich habe mal in den code von GripFit reingesehen und ein paar kleine Änderungen vorgenommen.
    Es wurde ab und zu berichtet, dass die alte Version von GripFit unter (wenn auch sehr seltenen) Umständen in komplexen Scripten abstürzt. Ich vermute, dass es daran liegt, dass die alte Version mit einem der allerersten avisynth_25.h Header kompiliert wurde. Diese Version wurde mit dem neueren avisynth.h Header kompiliert.

    Der original Code stammt von SansGrip.

    Ä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:

    Zitat

    GripCrop(int width, int height, bool source_anamorphic, bool dest_anamorphic, int overscan, int crop_round_width, int crop_round_height, int resize_round_width, int resize_round_height, int luma_threshold, int samples)

    GripSize(string resizer)

    GripBorders()

    Bei einer 720 source z.B.:

    GripCrop(704,576)
    GripSize("Lanczos4Resize")
    GripBorders()

    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:
    http://forum.gleitz.info/showpost.php?p=294861&postcount=6

  • Warum sollte MPEG4 nicht unterstütz sein, nur weil 1:1 als PAR fehlt? MPEG4 kann genauso wie MPEG 1 und 2 verschiedene PAR haben. HDTV kennt nur 1:1. Verwechselst du da irgentwas?

    AC-Sama(Robert Vincenz)
    (werde für das -Chan zu alt :zunge: )

  • Da hast du vollkommen recht.
    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.


    Nochmal zusammengefasst:

    Ich habe eine DVD mit 720x576 anamorph und will sie bestmöglich als backup in x264 oder xvid encodieren und am ende auch anamorph mit voller vertikalen Auflösung sehen können (am PC oder Beamer via HTPC).

    Das Original mit 720x576

    [Blockierte Grafik: http://img163.imageshack.us/img163/699/720x576un9.jpg]


    1. Das Script:

    dgdecode_MPEG2Source("X:\MyMovie.d2v")
    gripcrop(704,576)
    Gripsize("LanczosResize")
    Colormatrix(...)

    wie man sieht ist kein GripBorders() angehangen! Ich habe bewusst 704 genutzt, da sodann auf 1027xXXX am ende am PC oder z.B. Beamer via HTPC angezeigt wird. Alles größere wie bei 720 würde eh im *off* verschwinden, da die meisten besseren Beamer max. eh nur 1024xXXX wiedergeben können.

    dabei kommt das hier raus:

    [Blockierte Grafik: http://img46.imageshack.us/img46/8711/704x432ho9.jpg]

    mit korrekten MOD16.

    ... und ab in den Encoder und in diesem Beispiel wie o.g. SAR/PAR = 512/351 einstellen.

    Am PC, bzw. Beamer via HTPC kommts am Ende so richtig rüber wenn die PlaybackSoftware richtig die PAR/SAR des Encodings auslesen kann:

    [Blockierte Grafik: http://img65.imageshack.us/img65/7947/1027x432rp9.jpg]


    Was für Vorteile habe ich noch bei der o.g. PAR/SAR Methode:
    Nehmen wir an, ich hätte ein interlaced capture, welches ich ohne deinterlacing via XVID oder x264 encodieren möchte.
    Da wirds problematisch, aaaber ich kann hingehen, GripCrop() und GripSize() nutzen, sowie einen MotionCompensating Bobber nutzen um auf volle Bildgröße bei fpsx2 zu kommen = flüssige Bewegung und keine Interlacing artefakte.
    D.h. der Encoder müsste die doppelte Framerate beim encodieren unterstützen.
    Da dies aber in eine irre große Datei enden würde, gehen wir hin und nutzen

    Avisource(...)
    xMotionCompBobber()
    GripCrop(352,576)
    GripSize("LanczosResize")

    und beim encodieren eine PAR/SAR von 256/117.
    Damit habe ich zwar ein etwas unschärferes Bild, kann aber die "flüssige" Wiedergabe beibehalten und die Dateigröße klein halten.

Jetzt mitmachen!

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