agkp - akapuma's GKnot Personalisierer

  • Ist auch so. XviD_Encraw erzeugt nur VfW-Streams, wenn man ihm AVI als Ausgabeformat angibt.

    Brother John
    ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
    DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!

  • Hallo Brother John,

    Deine Anleitung find ich Klasse, aber das war ich ja bereits von Deinem Encodingwissen gewohnt. Du mußt agkp ja sehr ausführlich getestet haben. Deshalb hab ich auch nur ein paar Kleinigkeiten zu bemerken:

    Du beschreibst intensiv XviD_Encraw. Sind denn XviD-VfW-Streams in mkv genau so problematisch wie x264-mkv-Streams. Falls ja, dann würde ich mich mal intensiver mit XviD-Encraw beschäftigen und es vielleicht fest einbinden. Das wäre vorteilhaft, da dann auch CompChecks mit XviD-Encraw durchgeführt werden könnten.

    Zitat von Brother John

    War dir eigentlich bewusst, dass agkp ziemlich problemlos mit XviD_Encraw zusammenarbeitet?

    Nein, das hast Du entdeckt.

    Aus Diskussionen über amorphes und anamorphes Encoding hab ich mich bisher mangels Ahnung hier im Forum immer herausgehalten. Da Du dies aber auch ausführlich beschreibst, hab ich hier mal einen Thread dafür aufgemacht.

    Ansonsten nochmal: große Klasse!

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Zitat

    Sind denn XviD-VfW-Streams in mkv genau so problematisch wie x264-mkv-Streams.


    Ins Detail kann ich da auch nicht gehen. Sicher weiß ich, dass MPEG-4 ASP mit B-Frames in AVI den Standard verletzt. Matroska benutzt bei einem VfW-Encoding standardmäßig den AVI-Kompatibilitätsmodus und übernimmt den verbogenen Stream so wie er ist.

    Der Encraw-Thread auf doom9.org:
    http://forum.doom9.org/showthread.php?t=98469

    Brother John
    ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
    DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!

  • Ich wusste doch, da war noch ein Thread, in dem ich was schreiben wollte... ;)

    Zitat von LigH

    ^ genau so wie x264-VfW (statt native)?


    Ein bisschen pauschalisiert gesagt aber grundsätzlich richtig: Wenn man die Specs nicht verletzen will, ist MPEG-4-Video in AVI immer eine miese Idee. Und sämtliche VfW-Encoder erzeugen AVI-kompatible Streams.

    Warum, weshalb und wann genau die Probleme anfangen, ist zumindest im englischen Forum sicher schon mal ausführlicher diskutiert worden. Da müsste ich jetzt selbst suchen.

    Brother John
    ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
    DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!

  • Zitat von changelog v38

    Version 38, 18.05.06
    • Bei Beendigung des Previews kam es zu einem Fehler => behoben

    • Änderungen an der agkp200.ini:[INDENT]• Postprocessor-Default ist nun nicht mehr „deblock+dering“, sondern nur noch „deblock“
    [/INDENT][INDENT]• Filter „DeGrainMedian“ in 3 Stärken hinzugefügt, Default ist „mittel“
    [/INDENT]• Änderungen an der Anleitung:[INDENT]• Beschreibung hinzugefügt, daß bei Verwendung des x264-VfW-Codecs nur native-Streams erzeugt werden, wenn das Muxen mit mkvmerge gewählt wurde (Problem von scrat)
    [/INDENT][INDENT]• Link zu Brother John's Anleitung hinzugefügt[/INDENT]


    Geändert wurden:
    - ein kleines Fehlerchen wurde behoben

    - früher hatte ich bei GKnot den "medium noise noise filter" (FluxSmoothST(7,7)) und zusätzlich beim Postprocessor "deblock+dering" gewählt. Das gab zwar einen ordentlichen Kompressionsgewinn, war aber vom Bild her nicht optimal. Jetzt wähle ich in GKnot keinen noise filter mehr, beim Decodieren nehme ich nur noch "deblock", verwende aber dafür zusätzlich DeGrainMedian(limitY=5,limitUV=7,mode=2). Das bringt zwar nicht ganz so viel Kompressionsgewinn (filmabhängig), ist aber viel schöner. Die agkp200.ini wurde daraufhin angepasst.

    - Änderungen in der Anleitung aufgrund dieses Threads

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • hey!

    Zitat

    Beschreibung hinzugefügt, daß bei Verwendung des x264-VfW-Codecs nur native-Streams erzeugt werden, wenn das Muxen mit mkvmerge gewählt wurde (Problem von scrat)

    hehe :)


    mfg
    scrat

    Matroska Guide - Encoden mit GordianKnot, VirtualDubMod im x264/Xvid Format *Update: 25.09.2005*

  • hey!

    so, nachdem ich ewig keine zeit hatte mich weiter mit agkp zu beschäftigen habe ich es heute mal wieder versucht und wieder funktioniert das zeugs bei mir nicht.

    wenn ich bei mkvmerge fourcc "H264" wähle soll ja mkvmerge anstelle von virtualdubmod zum muxen verwendet werden - tut es bei mir aber nicht sondern nimmt virtualdubmod, obwohl auch im agkp logfile drinnen steht dass mkvmerge verwendet werden soll.
    was hab ich denn jetzt schon wieder falsch gemacht?


    mfg
    scrat

    Matroska Guide - Encoden mit GordianKnot, VirtualDubMod im x264/Xvid Format *Update: 25.09.2005*

  • Hallo Scrat,

    bist Du sicher, dass virtualdubmod zum Muxen verwendet wurde? Je nach dem, was Du eingestellt hast, wird zwar vdm aufgerufen, allerdings nicht zum Muxen, sondern zum encodieren. Das Muxen geht dann meist so schnell, dass man es garnicht sieht.

    Guck mal in Deinem Filmverzeichnis, ob dort eine agkpmux.bat angelegt wurde. Weiterhin sollte im Filmverzeichnis eine agkpmux.txt existieren, die das Muxen dokumentiert.

    Gruss

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Hallo!
    Nachdem ich in Brother Johns Encodingwissen von agkp gelesen habe wollte ich es auch ausprobiern.
    Leider konnte ich das Programm nicht mal starten.
    Nachdem ich alle Schritte aus der Anleitung befolgt habe kommt bei mir die Fehlermeldung
    Fehler agkp-v 38 . 1 . 12705

    Die agkp200.ini habe ich unverändert gelassen, ich habe die neueste x264-Version von x264.nl, die LastJob.vcf ist auch da.
    Der Fehler tritt sowohl auf, wenn ich agkpv.exe mit Virtualdub (x264, mkv) starte, als auch wenn ich agkpv.exe einfach so starte.

    Über Hilfe wäre ich sehr dankbar.
    akapuma Tolles Programm!

  • hey!

    Zitat von akapuma

    bist Du sicher, dass virtualdubmod zum Muxen verwendet wurde? Je nach dem, was Du eingestellt hast, wird zwar vdm aufgerufen, allerdings nicht zum Muxen, sondern zum encodieren. Das Muxen geht dann meist so schnell, dass man es garnicht sieht.


    sry, hab irgendwie total vergessen dass ich ja was gepostet habe (schei** stress)...
    bin mir ganz sicher, weil nach dem 2pass encoden vdm sich öffnet und mit sage und schreibe 0fps muxt (bis ich es halt händisch abbreche).
    ich schaue mal heute abend wegen der beiden dateien und berichte dann.


    mfg
    scrat

    Matroska Guide - Encoden mit GordianKnot, VirtualDubMod im x264/Xvid Format *Update: 25.09.2005*

  • Hallo,

    bezüglich crop/resize unterstützt GKnot 3 mehr oder weniger sinnvolle Möglichkeiten:

    • Die Ränder werden passend gecroppt. Anschließend wird auf die "richtige" Auflösung resized. Bei dieser Methode wird immer resized.
    • Die Ränder werden passend gecroppt. Die Auflösung soll möglichst 1:1 erhalten bleiben. Da horizontale und vertikale Auflösung aber in den seltensten Fällen jeweils durch 16 teilbar sind, resized GKnot ein bischen nach. Hierbei wird in über 98% aller Fälle resized.
    • Die Ränder werden so gecroppt, daß sich jeweils eine horizontale und eine vertikale durch 16 teilbare Auflösung ergibt. Dann soll nicht mehr resized werden, was ja auch der Sinn des ganzen ist.

    GKnot ist aber für Fall 3 nicht richtig gerüstet, denn der Resizer läßt sich nicht abschalten. Ich glaube zwar nicht, daß ein Resizer bei Eingangsauflösung = Ausgangsauflösung großen Schaden anrichtet, würde dafür aber auch nicht meine Hand in's Feuer legen. Den Resizer zu entfernen war zwar in bisherigen agkp-Versionen halb-manuell möglich, es widerspricht aber der agkp-Philosophie, etwas von Hand machen zu müssen, wenn's auch automatisch geht. Deshalb gibt's jetzt den neuen agkp-Befehl "sr" = suche Resizer, der unnötige Resizer erkennt, die dann einfach deaktiviert werden können. Dies wird auch so in der Vorlagedatei agkp200.ini gemacht, so daß unnötige Resizer nun entfernt werden.

    Zitat von Changelog v41

    Version 41, 16.08.06

    • Der agkp-Befehlssatz wurde um den sx-Befehl „sr“ entsprechend „suche Resizer“ erweitert.
    • Die x264-CLI-Aufrufe in der Vorlagedatei agkpx264.bat wurden um die Parame*ter „--aq-strength 0.4“ und „--thread-input“ erweitert.


    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Ins Detail kann ich da auch nicht gehen. Sicher weiß ich, dass MPEG-4 ASP mit B-Frames in AVI den Standard verletzt. Matroska benutzt bei einem VfW-Encoding standardmäßig den AVI-Kompatibilitätsmodus und übernimmt den verbogenen Stream so wie er ist.

    Vielleicht mal eine kleine Erklärung dazu :)

    A) Die Spezifikation
    Zunächst muss man sich einmal klarmachen, wie normalerweise ein der mpeg4 Spezifikation entsprechender stream aussieht. Er besteht im Grunde nach immer aus einer bestimmten Abfolge von I, P und B frames.
    Ein b-frame bezieht sich hierbei immer auf 2 frames, auf das vorherige I/P frame und auf das folgende I/P frame.

    Die Wiedergabe funktioniert also so:
    I B B P


    B) Zum Problem des VFW Codecs
    Der VFW Codec arbeitet nun nach dem Schema, "ein frame rein und ein frame raus". Also für jedes frame das reinkommt, wird auch ein frame rausgegeben. Dies ist natürlich nicht mit b-frames möglich, da diese sich ja auf 2 andere I/P frames beziehen und die sind bei "ein frame rein und ein frame raus" zu diesem Zeitpunkt nicht "drin". Das Grundproblem besteht also darin, dass der VFW Codec eigentlich keine Speicherung von b-frames beherrscht.

    Also wenden Encoder einige Tricks an um b-frames doch noch möglich zu machen.

    Trick 1 (Packed Bitstreams)
    Man packt das erste b-frame zusammen mit einem P-frame und gibt sie gemeinsam aus. Da nun auf der Ausgabeseite durch diese Verschmelzung (=Packet Bitstreams) ein frame im Gegensatz zur Anzahl der frames fehlt, fügt der VFW-Codec am Ende einen Platzhalter ein, ein so genanntes N-frame.

    Die neue Abfolge sieht dann so aus:
    I PB B N


    Trick 2 (Delay Frames)
    Wenn wir nun in der Encoder-Konfiguration Packed Bitstreams abgeschaltet haben, dann muss der VFW Codec sich was einfallen lassen und das macht er so:
    Zuerst bekommt er ein I-frame. Das ist kein Problem, das speichert er ab. Dann sollte eigentlich ein b-frame folgen. Das kann er aber nicht darstellen, da das P-frame noch fehlt. Er muss aber etwas abspeichern ("ein frame rein und ein frame raus") - also speichert er ein sogenanntes Delay frame (1-byte 0x7f frames). Das macht er ebenso beim nächsten B-frame. Schliesslich kommt das P-frame und der Encoder kann alles abspeichern. Geschaffen hat er einen stream mit zusätzlichen Delay frames.

    C) Fazit
    Bekanntermassen kann man die vom VFW Codec erstellten avi´s abspielen, Das liegt daran, dass die Decoder mit diesen Hacks umgehen können. Ab und zu versagt zwar ein SA dabei - aber eigentlich haben wir uns alle daran gewöhnt.

    Tatsache ist aber, dass wir einen stream vollkommen ausserhalb der Spezifikation erzeugen und das wir dies bei den Kontainern mkv und mp4 nicht benötigen. mkv und mp4 können native mpeg4 streams speichern und sind ja auch dafür entwickelt worden. :D

    Hier wird etwas für den AVI-Kontainer mit vielen Tricks erstellt, das eigentlich in den mp4 Kontainer oder auch mkv Kontainer gehört.

    cu

    Joe
    __________________
    Freedom ist just another word for nothing left to loose.

  • Hallo JoeB,

    danke für Deine ausführliche Erklärung. Da bin ich ja direkt froh, daß agkp direkt 2 Möglichkeiten hat, x264-native-Streams in eine mkv-Hülle zu packen.

    XviD native stream's mit GKnot/agkp sind im Moment nur mit Brother John's "Trick" möglich. Ich hatte schon daran gedacht, dies fest als Feature einzubauen, um z.B. auch Credits verwenden zu können. Zwei Punkte haben mich aber zunächst davon abgehalten:

    1: Man müßte xvid_encraw mit mkv-output-support verwenden. Den haben aber nicht die aktuelleren celtic_druid-Build's, sondern "nur" die von squid_80.

    2: Erste Tests (auch von Drachir) haben ergeben, daß sich mkv's mit native-XviD nicht so einfach abspielen lassen, wie mkv's mit VfW-XviD drin.

    Daher ist native-XviD bei agkp auf der ToDo-Liste erstmal etwas nach hinten gerutscht.

    Mehr über meine Vortests (die ich immer mache, bevor ich etwas einbaue) hier.

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info


  • 2: Erste Tests (auch von Drachir) haben ergeben, daß sich mkv's mit native-XviD nicht so einfach abspielen lassen, wie mkv's mit VfW-XviD drin.


    Bei VLC scheint sich etwas in Bezug auf native MPEG 4 ASP in mkv getan zu haben, habe es selber noch nicht getestet:
    http://forum.videolan.org/viewtopic.php?t=21189&start=15

  • Hallo,

    leider mußte ich feststellen, daß der CompCheck mit agkp und dem x264-CLI nicht funktioniert. Der x264-VfW-Codec ist davon nicht betroffen. Im Kopf hab ich auch schon eine Lösung, bis die umgesetzt ist, wird's aber noch etwas dauern.

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Zitat von changelog v42

    Version 42, 07.09.06

    • Vor Benutzung des x264-CLI's wird eine eventuell vorhandene vdenc.log gelöscht.
    • Nach Benutzung des CompCheck's mit dem x264-CLI wird von agkp eine vdenc.log erzeugt.
    • Kleine Ergonomieverbesserungen an agkpAR.
    • Änderungen an der Vorlagedatei agkpx264.bat:

    [INDENT]

    • Parameter von --aq-strength von 0.4 auf 0.5 erhöht

    [/INDENT][INDENT]

    • --no-ssim hinzugefügt

    [/INDENT][INDENT]

    • Neuen 1-Pass mit konstanter Qualität (--crf 25) hinzugefügt

    [/INDENT]

    Das von mir berichtete Problem mit dem CompCheck ist damit behoben.

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Zitat von hier:

    Zitat

    x264 rev.575.
    The Haali's AQ patch is gone, it's incompatible with the latest changes.

    Damit sind die Voreinstellungen in der agkpx264.bat nicht mehr kompatibel mit der aktuellen x264-Version von sharktooth. Jetzt gibt's 2 Möglichkeiten:

    • Vorerst sharktooth's Version 569 weiterverwenden und auf einen neuen Patch warten (hoffen).
    • Die "--aq-strength"-Parameter in der agkpx264.bat entfernen.

    Vorerst bleibe ich bei der 1.

    Gruß

    akapuma

    Edit: Umsonst aufgeregt, seit der 577A ist --aq-strength wieder drin.

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

Jetzt mitmachen!

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