weird video!

    hulla leutz :)

    wie immer hängts bei mir mal wieder an ner source, die zum einen animiert und zum anderen interlaced ist. wäre alles kein problem, wenn nicht folgendes auftreten würde ( ich beziehe mich erstmal NUR auf die preview funktion )...

    wenn ich das material UNCROPPED ( jedoch resized ) previewe [lanczos resize, neutral bicubic - egal ob tomsmocomb oder no blend], ist alles super.
    wenn ich das material CROPPED ( überall je 2 pixel ) previewe [egal welche filter]
    spinnt das video, sämtliche bewegung ist gefolgt von BLAUEN nachziehungen ..
    man stelle sich vor, eine figur bewegt sich und zieht eine art blauen schleier nach sich ( und das permanent ). SUPER nervig. dachte zuerst, das wäre ein problem vom interlacing, oder vom filter. is es aber nicht. ohne croppen scheint alles ok zu sein ( encoded hab ichs nicht, weil uncropped encoden suckt ).

    hat jemand ne idee? wäre euch heftigst dankbar

    Da habe ich ganz ähnliche Erfahrungen gemacht, jedoch gab es bei mir bei Schnittwechseln und Bewegungen jeweils grüne Schleier.

    Du solltest aber auch nicht nur jeweils 2 Pixel, sondern besser jeweils 4 Pixel croppen. Sicherheitshalber solltest Du aber immer so croppen, dass die verbliebene Auflösung sich sowohl vertikal als auch horizontal durch 16 teilen lässt, dann treten diese Schleier überhaupt nicht auf.
    Außerdem solltest Du einmal den aktuellen DeComb 5.1.1-Filter "installieren". Seit ich den nutze, reicht es auch, wenn Du so croppst, dass sich die verbliebene Auflösung durch 8 teilen lässt, ohne irgendwelche Schleier zu produzieren (natürlich nur mit dem Field Deinterlacer und Seperate Fields, die anderen Deinterlacer sind ja in anderen Plugins enthalten).

    oh, hm ... jo habe gestern abend noch rumprobiert, bei oben/unten je 4 ist das problem weg (obwohl dann immer noch nicht durch 16 teilbar ). komisch, dass mir das bisher noch nie untergekommen ist ...

    ist das nur der fall bei filmen, die man deinterlacen muss, oder gilt das allgemein, also dass vor resizing durch 16 teilbar sein soll? dachte, das bezöge sich nur auf nachm resizen ( und darauf achtet z.b. gknot ja automatisch )...

    ich beantworte die frage mir mal gleich selbst .. wenn ich keinen deinterlace filter laufen lassen ( bei preview ) ist das bild, egal wie ich croppe, 1a...

    aber sehr komisch das .. hoffentlich habe ich bei alten encodes nix übersehen

    Nach dem Resizen sollten die Bilddimensionen durch 16 oder gar 32 teilbar sein, damit MPEG effizient encodiert (Makroblöcke sind 16*16 Pixel groß) und die Grafikkarte das Video schnell ausgeben kann (besonders die Matrox Millenium G400 wurde ansonsten extrem langsam).

    Vor dem Resizen sollten die Breite und Höhe durch 4 teilbar sein, weil MMX-beschleunigte Resize-Algorithmen nur damit schnell und fehlerfrei arbeiten.

    ups :)
    darauf hab ich noch nie geachtet ( allerdings auch nie probleme gehabt... )
    aber gut zu wissen ....gilt das also auch für filme, die nicht deinterlaced werden, ja ?

    *ps*

    erkennbar ist bei diesem film das problem nur, wenn tomsmocomb oder ein anderer deinterlacer verwendet wird ( fürs preview ). sonst nicht... egal, ob ich auf die teilbarkeit achte. bei der ausgabe achte ich immer auf 16/32

    *ps2*

    wenn ich oben + unten + rechts + links jeweils 2 pixel croppe SIND Breite und Höhe durch 4 teilbar .. also liegts scheinbar nicht mal daran :(

    Hi,

    wäre schön, wenn du mehr "Eckdaten", also genaue Cropping Werte und Quell/Zielauflösung posten würdest.

    Ich denke mal du arbeitest mit Avisynth. Wenn das Problem am croppen liegt, dann lass doch das croppen weg, das geht ja auch direkt mit den ResizeFilter:
    Beispiele:
    BicubicResize(640,480,0,0.75,0,0,720,576) <-- das croppt gar nicht, sondern reduziert nur die Pal Auflösung nach 640x480.

    Jetzt das gleiche nur das ich horizontal also links und rechts 12 croppe und oben unten 14:
    BicubicResize(640,480,0,0.75,12,14,696,548)

    so jetzt erkläre ich noch mal schnell die parameter:
    640 <-- horizontale Zielauflösung
    480 <-- vertikale Zielauflösung
    0 <-- weiss ich nicht mehr genau
    0.75 <-- weiss ich nicht mehr genau
    12 <-- horizontaler Anfangspunkt also X Wert
    14 <-- vertikaler Anfangspunkt also Y Wert
    696 <-- horizontaler Endpunkt
    548 <-- vertikaler Endpunkt

    du erkennst: die letzten vier Parameter sind entscheident, das Prinzip ist denkbar einfach:
    eine Bild wo man oben links einen Punkt festlegt (12/14) und von da eine Fläche aufspannt (696/548).

    Probier das mal, und poste bitte dein Script, falls noch probleme auftreten.


    ....cu

    @ VALi:

    Nicht von der Parameteranzahl verwirren lassen! Fit2Disc verwendet das effiziente 2in1-Verfahren: Resize() mit integriertem Cropping. GordianKnot jedoch verwendet zwei Funktionen nacheinander: Erst Crop(), dann Resize() ohne Cropping. Welche Variante bei dir verwendet wurde, werden wir ja sehen...

    so, hier also mal verschiedene settings, die unterschiedliche reaktionen zur folge haben, source bild ist 720x576

    1. uncropped und nur resized

    LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
    LoadPlugin("C:\PROGRA~1\GORDIA~1\TomsMoComp.dll")
    mpeg2source("F:\scooby doo und die cyber jagd\scoob.d2v")
    crop(0,0,720,576)
    TomsMoComp(1,5,1)
    LanczosResize(640,464)

    2. cropped um jeweils 2 pixel überall ( so wie es sein muss, damit die schwarzen ränder weg sind )

    crop(2,2,716,572)
    TomsMoComp(1,5,1)
    LanczosResize(640,464)

    Hierbei treten die erwähnten blauen Effekte auf

    3. cropped um jeweils 2 pixel links/rechts und jeweils 4 pixel oben/unten

    crop(2,4,716,568)
    TomsMoComp(1,5,1)
    LanczosResize(640,464)

    Hierbei scheint das Bild einwandfrei zu sein


    4. cropped um jeweils 2 pixel links/rechts, oben 4 und unten 2


    crop(2,4,716,570)
    TomsMoComp(1,5,1)
    LanczosResize(640,464)


    hierbei tritt der nächste lustige event auf. zwar ist das BILD einwandfrei, allerdings ist unten ( wo eigentlich
    einwandfrei gecropped sein muesste ) jetzt ein 2 pixel breiter, grüner ( oder grün-gelber ) Rand zu sehn!

    Hi,

    deinterlacer folgen grundsätzlich direkt nach der Quelle, Bildveränderungen werden erst nach dem deinterlacer eingebaut, dazu gehört auch das croppen.

    *Edit:
    ich zitiere mal:

    Zitat

    Bei allen diesen Filtern zur Größenänderung kann eine erweiterte Syntax verwendet werden, die vor dem Verkleinern bzw. Vergrössern das Bild abschneidet. Die gleiche Operation wird durch Crop vor dem Resize erreicht.


    bei dir wird zwischen durch deinterlaced, das nicht gut :so-nicht:


    ....cu

    hm.

    sag das gknot ... normal änder ich nix an dem, was gknot mir ins .avs schreibt, ausser dass ich die undot einträge rausnehme ....
    dass das deinterlacing vorm resizen stehn muss find ich auch plausibel ...
    warum können nicht die ränder geschnittet werden bevor das bild mit irgendwas behandelt wird? hmm *g*
    ka. wenn das echt so schlimm ist, werd ichs ändern .. allerdings sollte man das gknot dann auch mal sagen :D

    *edit*

    wenn ich das deinterlacen VOR das croppen setze sind sämtliche fehler weg, auch der mit dem grünen rand unten. sehr sehr komisch. bei futurama hatte ich das prob nie ( dort auch zuerst croppen, dann deinterlacen, dann resizen )..

    naja, auf jeden fall danke .... werd dann wohl in zukunft mitm interlacen ein bischen vorsichtiger sein müssen :D

    Wenn du über und unter dem Video mit ungeraden Zeilenanzahlen schneidest, dann stimmt für die folgenden Deinterlacer die Field-Reihenfolge nicht mehr. GordianKnot erlaubt mit seinen Crop-Reglern nur Sprünge um Vielfache von 2, insofern ist das Risiko vielleicht nicht so groß...

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden