Beiträge von fileman

    Na ja, ist auch Glück dabei - z.B. hatte ich Triple X erst vor ein paar Tagen gesehen - sonst hätte ich die Rammstein-Szene nicht zuordnen können. War schon mehrere Male so, dass ich genau den Film gerade erst gesehen hatte.

    Ich weiß auch nicht, woher die weißen Balken kommen könnten... ich schätze mal es ist irgendwas abspielseitiges - aber das kann man eigentlich leicht herausfinden: einfach mal auf einem anderen System abspielen... Durch falsches Cropping hatte ich auch schon merkwürdige Effekte (aber da waren irgendwelche Balken immer grün, nicht weiß).

    Sorry, weiß auch gerade nicht weiter... vielleicht auch mal mit dem DivX-Codec abspielen, wenn's da die gleichen Probleme gibt, ist es ziemlich sicher, dass du beim Erstellen der Filme was falsch gemacht hast.

    Welchen Player verwendest du, und wichtiger: welches Codec zum abspielen? Original-DivX oder ffdshow? Hast du irgendwas geändert (DirectX aktualisiert oder sowas)? Tritt das Problem bei allen Filmen auf, auch bei welchen, die früher keine Balken hatten?

    Ich dachte, bei Quarter Pixel geht es darum, die Bewegungsweite nicht nur auf minimal ein halbes Pixel genau zu schätzen, sondern auf minimal ein viertel Pixel genau, dadurch könnten Bewegungen weicher werden, vielleicht läßt sich damit der Effekt der "schwimmenden Wände" sogar vermindern. Dürfte aber etwas mehr Bitrate benötigen.

    Ansonsten kann ich mich aber den Einschätzungen durchaus anschließen: GMC ist zu riskant (und mit B-Frames zusammen erst recht), B-Frames lohnen sich nur bei geringerer Datenrate, und QPel nur bei kleinen Bilddimensionen. Wer außerdem Hardware-Profil-treu bleiben will, kann sie alle z.Z. eh vergessen.

    Was haltet ihr von den Aussagen:

    GMC:
    Soll an sich bei Kameraschwenks und Zooms etwas Bitrate sparen. Meist ist jedoch der Overhead den man braucht um GMC zu benutzen größer als das was man einspart. GMC im DivX5.0.3 kann nur von DivXDecoderFilter ordentlich dekodiert werden
    => GMC nicht benutzen

    B-Frames:
    Diese Art von Frames betrachtet bei der Berechnung nicht nur vorangegangene, sondern auch nachfolgende Frames. Was meist zu beachtlichen Einsparungen an Datenrate führt, jedoch bei hohen Datenraten eher die Bildqualität senkt, da B-Frames mit höheren Quantizern als ihre Umgebung codiert werden.
    => B-Frames nur bei niedrigen Datenraten
    (so <900KBit/s würd ich sagen)

    Qpel = QuarterPel:
    Quarter Pixel verfeinert die Standard-Aufteilung der Makroblocks von 16x16 Pixeln auf 8x8 Pixel. Meist scheint Qpel nur was zu bringen wenn man ne relativ niedrige Auflösung hat.
    => Qpel nur bei niedrigen Auflösungen
    (< 576*y würd ich sagen)

    Cu Selur

    Im Grunde arbeitet DivX 5.0.3 jetzt etwa so wie die MPEG2-Encoder: Im ersten Durchlauf wird nun wirklich schon ein richtiges AVI geschrieben, und zwar mit konstanter durchschnittlicher Bitrate (DivX 5.0.2 schrieb nur ein leeres Pseudo-AVI, verwendete aber maximale Qualität). Dadurch wird nun in einfachen Szenen Bitrate verschwendet, in schwierigen Szenen jedoch gibt es zu schlechte Qualität. Das wird beim ersten Durchlauf jetzt protokolliert (bei früheren Versionen war es die erreichte Größe bei maximaler Qualität, jetzt ist es die erreichte Qualität bei beschränkter Bitrate).

    In den nächsten Durchläufen wird nun die Bitrate abhängig von dieser Statistik so verändert, dass von der mittleren Bitrate weg die einfachen Szenen weniger, die schwierigeren Szenen mehr Bitrate bekommen (in früheren Versionen wurde statt dessen von der ohne Beschränkung theoretisch erreichten Größe auf die gewünschte Zielgröße heruntergerechnet). Dabei regelt die Bitraten-Modulation, ob eher die einfachen oder eher die schwierigen Szenen etwas mehr Bitrate als der Durchschnitt erhalten - dadurch kriegen entweder die Action-Szenen zu wenig und werden blockiger, oder die ruhigen Szenen kriegen weniger und kriegen stufige Farbverläufe und "schwimmende Wände".

    Interessant wird es erst bei einem eventuellen dritten Durchlauf: Wenn der zweite Durchlauf die Statistik des ersten überschrieben hat, optimiert der dritte Durchlauf die Qualität ausgehend vom Resultat des zweiten Durchlaufs weiter - das Überschreiben ist für den zweiten Durchlauf also mit Sicherheit sinnvoll. Will man jedoch den dritten Durchlauf dazu nutzen, eben diese angesprochene Bitraten-Modulation zu optimieren, wird man vermutlich "mehrere dritte" Durchläufe machen wollen, die alle auf dem Ergebnis des zweiten Durchlaufs aufbauen sollen - dann sollte man das Überschreiben der Statistik-Datei für diese "dritten Durchläufe" wieder deaktivieren.

    Falls der Mpeg 2 stream mal ne Macke hat kann mal auch malfolgendes versuchen um ihn zu fixen:

    1. Eventuell reichts schon den Film zu remuxen. (geht z.B. mit dem Freewaretool ][muxer welches es bei http:// https://localhost/www.moonlight.co.il/download/#Xmuxer gibt)

    2. Klappt das nicht kann man mal versuchen den Film durch vcdgear (mit aktivierter ErrrorKorrektion aktiviert mit dem Setting mpg=>mpg) laufen zu lassen. (vcdgear ist auch freeware und gibt's bei https://localhost/www.vcdgear.com )

    3. Bringt auch nix mal versuchen pvastrumento drüber laufen zu lassen. (freeware die's bei http://www.offeryn.de/dv.htm gibt)

    Cu Selur