Für den letzten Feinschliff

    Hallo,

    ok das mag sich nun sehr komisch anhören, aber da wie ich festgestellen musste die meisten Interlaced Teile gar keine sind sondern in Wirklichkeit astreines Progressive Material, würde ich gerne wissen wie man diesen Flag in der VOB Datei ändert (falls man das überhaupt kann).

    MfG

    -=IceMan=-

    Dat ist Quatsch was du da vorhast. Im einfachtsen Fall ist es nutzlos im schlechtesten sogar schädlich!

    Wenn "interlaced" Material in Wirklichkeit progressive ist (was ja bei DVDs eher die Regel ist) dann gleich progressicve encoden - dann stimmt auch das flag... :ja:

    Gruß Karl

    Ja das ist mir nun auch klar ... aber wenn ich nun ne VOB hab die ich nicht encoden muss.. dann stört mich eben dass dieser Flag flasch gesetzt ist.
    Es geht mir dabei eben um das Sahnehäubchen auf der Torte. :D

    MfG

    -=IceMan=-

    Nee- du hast mich nicht verstanden. Das Material ist interlaced encodet!
    Der Inhalt (progressive) spielt erstmal keine Rolle. Die Änderung des "progressive-flags" ist kontaproduktiv -
    wie bereits geschrieben - im besten Fall nutzlos!

    Das ist also kein I-tüpfelchen, sondern sinnloses gemurkse...

    Höö ?? Ok das musst du mir nun mal genauer erklähren. Du sagst also, dass es Interlaced encodet ist, sich aber in Wirklichkeit um Progressive handelt. Wie soll das funktionieren ? Das hört sich irgendwie nach einer Verschachtelung an die für mich atm keinen Sinn ergibt.

    Man kann progressives Material interlaced kodieren. Das geht, hat aber den Nachteil, dass der Encoder nicht den optimalen Algorithmus wählt (halt nicht den für progressiv) und so die Kompression nicht optimal ist.
    Da so ein Material aber nun mal interlaced kodiert wurde, muss man auch den passenden Dekoder-Algorithmus wählen, nämlich den interlaced. Und dies geschieht nur, wenn das progressiv Flag nicht gesetzt ist.

    Warum die Hersteller so etwas machen, siehe hier.

    Gruß
    Arlsair

    Um es noch mal genauer zu beschreiben:

    Wenn der DVD-Hersteller das Video interlaced encodiert hatte, dann wurden die Halbbilder (Fields) unabhängig voneinander encodiert, und werden nach der Decodierung wieder miteinander verwoben. Wurde ein Video jedoch progressiv encodiert, wurde das ganze Bild (Frame) als Fläche encodiert.

    Würde man ein "interlaced" codiertes Video nachträglich durch Patchen von Headern zu "progressiv" markieren, würden die Fields bei der Decodierung wohl nicht wieder zu einem Frame gemischt werden, sondern vielleicht untereinander dargestellt, oder abwechselnd, oder wie auch immer ein Decoder mit diesem Datenmüll dann umgehen würde...

    Gut das hab ich ja alles soweit verstanden. Aber ich habe das Video bei dem der Interlaced Flag gesetzt wurde nun Progressive reencodet und es sieht fantastisch aus. Keine Fieldüberschneidungen wie sie auftreten würden wenn das Ausgangsmaterial Interlaced gewesen wäre. Solches Material kann man doch ohne bedenken Progressive reencoden oder sollte man ja weil die Qualität bei gleichem Platzbedarf ja besser ist. Also muss mein Ausgangsmaterial ja wohl echtes Progressive sein bei dem der Flag nur falsch gesetzt wurde. Natürlich hätte ich es auch Interlaced reencoden können - das macht in dem Falls aber überhaupt keinen Sinn.

    Bitte klährt mich eines Besseren auf falls ich irendwelchen Gulagg rede, ich will bei Gott kein Besserwisser sein.

    MfG

    -=IceMan=-

    Nochmal:

    Die Behauptung, beim Original wäre nur das Flag falsch gesetzt, ist auf jeden Fall falsch - das Interlaced-Flag ist richtig gesetzt gewesen, weil der Encoder auf Interlaced-Encodierung eingestellt war.

    Ob jedoch Interlaced-Encodierung für das vorliegende, anscheinend progressive Material, auch sinnvoll war, kann wohl mit Recht angezweifelt werden. Deshalb darfst du gern das Video im progressiven Encoder-Modus recodieren, denn gerade wenn man nur eine begrenzte Bitrate zur Verfügung hat, ist das Verhältnis Qualität/Bitrate bei progressiver Encodierung von Progressiv-Material etwas günstiger.


    Fazit: Der Video-Stream ist technisch gesehen korrekt, nur der Encoder wurde von der Produktionsfirma wohl nicht "optimal" auf das Material eingestellt. ("Das Flag ist falsch" würde dagegen heißen "der Stream ist defekt", und das ist ja nicht der Fall.)

    Achsooooo !! Nun habe ich verstanden. Bist wohl nicht umsonst ein ErklährBär :D . Das heißt das Ausgangsmaterial ist kein Material mit Halbbildern (Fields) sondern mit ganzen Bildern (Frames), welche mit dem Interlaced Algorythmus zu dem encodiert wurden was sie nun sind. Das heißt ich darf desshalb neu progressive encoden weil ich Ganze Bilder vorliegen habe.

    Aber wieso sagt mit der BitRate viewer dann der DCT Type wäre Field. Oder gehört das zusammen mit dem Frame Type Flag ? Also wenn der Interlaced Flag gesetzt wurde damm muss auch der Field Flag gesetzt sein.

    IceMan

    Eine Frage bleibt dann aber noch... wieso machen die, die die DVD erstellen das so ...dass das Progressive Material Interlaced encodiert wird. Von der Kamera kommt es ja als Interlaced dann machen die das Progressive und dann kommt es wieder auf die DVD als Interlaced encodiertes Progressive Material Was soll das für einen Sinn ergeben. Um die Leute zu täuschen die eine Sicherheitskopie anfertigen wollen ?

    IceMan

    Hat arlsair's Link nicht darauf hingewiesen?

    Wenn man Interlaced-Material progressiv encodieren würde, wäre das Ergebnis mieserabelste Qualität (der Encoder müsste die zeilenweisen Unterschiede zwischen den Fields encodieren, das würde sehr viel Bitrate kosten). Interlaced-Encodierung von Progressivmaterial jedoch kostet nur ein wenig mehr Bitrate.

    Anstatt bei jedem Film Arbeitszeit dafür zu investieren, das durch Nachschauen zu überprüfen, lässt man deshalb den Encoder lieber immer auf "Interlaced" stehen, das ist sicherer, als ihn jedes Mal neu und deshalb versehentlich mal falsch einzustellen.

    Ich hab mich zwischenzeitlich auch (theoretisch) mit einer interlaced -> progressive Reecodierung von progressive Film befasst.
    Man sollte es nicht bedenkenlos einsetzen, denn das bringt den Farbraum durcheinander!
    aus interlaced YV12 wird progressives YV12 gemacht, und das kann nicht verlustlos geschehen. Man erhaelt vielmehr 2x4 Pixel grosze Farbeinheiten.

    Uii das ist alles sehr verwirrend. Ok immer auf Interlaced stellen hab ich gefressen. Und wie sieht es mit der ScanOrder aus. Die stellt man in CCE so ein wie es der BitRate Viewer ausspuckt ? Und generell nur das Progressive Encoden was im BitRate Viewer auch als solches deklariert wird.

    Und noch ein Beispiel : BitRateViewer sagt mir Interlaced, DCT Type ist Field, und die ScanOrder ist ZigZag. Das passt ja nun gar nicht zusammen. ZigZag wird doch nur bei Progressive verwendet.
    Und das Teil ist beim besten willen nicht als Interlaced zu erkennen. Wie passt das zusammen ?

    Sorry wenn ich mit meinen Fragen nerve und nicht alles so schnell kapiere.

    IceMan

    Zitat

    DCT Type ist Field, und die ScanOrder ist ZigZag.

    Moin,

    das ist natürlich oberquatsch... ;D

    Das liegt mit Sicherheit daran, daß die Typen, die die DVDs produzieren eben nicht wissen, was sie da tun.
    Sie drücken irgendwelche Knöpfe, die sie schon immer gedrückt haben und weil kein Auftraggeber das reklamiert hat - muß das wohl richtig sein.... :hm: :nein:

    Hier gings diesbezüglich scon sehr zur Sache.....

    Gruß Karl

    Ich hab das in nem anderen Board gepostet. Kann mal jemand checken ob das stimmt was ich da schreibe ?

    Ich habe hier eine seltsame Konstellation :

    Pic. structure: Frame
    Field topfirst: Yes
    DCT type: Field
    Quantscale: Nonlinear
    Scan type: ZigZag
    Frame type: Interlaced

    Diese DVD ist definitiv kein Real Interlaced sondern Progressives Material das Interlaced encodet wurde. Definitiv wurde hier dann wohl auch noch die falsche Scan-Order angewandt, da das Progressive Ausgangsmaterial ja beim Interlaced encoden in Halbbilder zerlegt wird und diese sollten dann ja vom Encoder mit der Alternate-Scan-Order abgearbeitet werden.

    Wenn ich das also richtig verstanden habe, liegen auf meiner DVD nun Frames vor in denen jeweils die 2 Halbbilder (Fields) liegen die zusammen wieder das Original Progressive Frame ergeben (abgesehen von der Scan Order). Also liegen auf meiner DVD doch richtige Vollbilder die sich vom Original nur dadurch unterscheiden, dass sie komprimiert und durch die falsche Scan-Order ein wenig verpfuscht wurden ?!?

    Wenn ich dieses Material nun in echtes Progressive umwandeln (reencoden) möchte, wäre es ja blödsinn es zu deinterlacen da es nicht wirklich interlaced ist. Interlaced Material hätte ja die doppelte Anzahl an Bildern (Halbbilder). Ich könnte es ja im Encoder als Progressive Material angeben
    (weil es ja eigentlich auch Progressive ist).

    Im Gleitz Forum stand dazu aber folgender Beitrag :

    Ich hab mich zwischenzeitlich auch (theoretisch) mit einer interlaced -> progressive Reecodierung von progressive Film befasst. Man sollte es nicht bedenkenlos einsetzen, denn das bringt den Farbraum durcheinander! aus interlaced YV12 wird progressives YV12 gemacht, und das kann nicht verlustlos geschehen. Man erhaelt vielmehr 2x4 Pixel grosze Farbeinheiten.

    Wie ernst muss man das nehmen ? Heißt das nun, dass ich nicht drum herum komme solches Material Interlaced zu reencoden und ein reencode ins Progressive Format nicht ohne zusätzliche Verluste im Farbraum geschieht ?

    MfG

    -=IceMan=-

    scharfis_brain meinte damit vor allem: Echtes Interlaced-Material ist im Farbraum YV12 schwer weiterzureichen, man muss in dem Fall also mit AviSynth 2.5.x sehr gut aufpassen. Denn wenn aus AviSynth 2.5.x dann YV12-Video herauskommt, weiß das lesende Programm nicht, ob das interlaced ist. YUY2 auszugeben ist sicherer, das ist zeilenweise (gepackt) codiert, nicht flächig (planar).

    Da aber die meisten MPEG-Encoder sowieso kein YV12 lesen können, ist schon deshalb sinnvoll, das AviSynth-Skript bei AviSynth 2.5.x grundsätzlich immer mit "ConvertToYUY2(interlaced={false|true})" abzuschließen (je nach dem, ob das Video tatsächlich interlaced ist - in dem Fall sollte MPEG2Source() auch den Parameter "iPP=true" erhalten). - Viel Spaß beim Lesen der Dokumentationen von AviSynth, MPEG2Dec3, den Grundlagen der YUV-Versionen usw. ... ;)

    Moin,

    leider wenig Zeit....

    Wenn man das aus aktueller Sicht (durchgängige YV12-Unterstützung in AVISynth) betrachtet, ist das zumindest überlegenswert, was mit dem interlaced YV12 passiert, wenn "man" (bzw. hier der CCE) da progressive draus macht.

    Ich habe definitiv nicht die Zeit das zu untersuchen - vielleicht sagt scharfi ein wenig mehr dazu....

    Gruß Karl

    ..naja - LigH kam früher ;)

    Soweit ich mich erinnere, kann ein MPEG-Encoder YV12 lesen, wenn ein VfW-Codec installiert ist, der die Konvertierung übernimmt (DivX 5 oder XviD), aber die können wohl das Interlaced-Flag nicht erkennen; oder?!

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden