Beiträge von Bitspyer

    LigH:
    Ich vertraue jetzt mal ganz auf das alte Sprichwort: "Es gibt keine dumme Fragen." und frage mich, welche Deblock Option ein gutes Mittelmaß ist (cpu=1, cpu=2)?

    Zitat

    es sind tatsächlich die meisten MPEG2-Videos im Interlaced-Modus encodiert worden, auch wenn sie nicht "combed" sind.

    Schliesse ich daraus, das ein generelles TDeint() oder Yadif() dann nicht verkehrt ist? Wenn mich bei DGIndex das interlaced Flag anlacht, suche ich mir schnelle Scenen und Bildwechsel und schaue, ob es Kämme gibt. Falls nicht, gehe ich von Progressive aus.

    LigH: Brother John erwähnte auf seiner Website, das man stattdessen pyramid einsetzen sollte...

    @Mulder:
    Das mit den Flächen ist mir jetzt bei einem letzen Encoding aufgefallen, zT. auch an meinem LCD-TV.

    Mein Build ist x264-r1369. Wobei ich da mal mit dem Build direkt von x264.nl arbeite, aber auch schon mit den optimierten Builds von http://komisar.gin.by/ gearbeitet habe, da die nochmal etwas mehr output haben.
    Des Weiteren habe ich Deinen Tipp aus dem anderen Thread übernommen und meine Einstellung mit den Presets und Tunings abgeglichen und diese dann weggelassen.
    --deblock -1:-1 hat mir halt bei einem Encoding mal richtig fiese Blöcke verschafft. Leider habe ich das Orginal nicht mehr, daher kann ich nicht sagen, ob die Quelle nicht schon in dem Bereich verblockt war.

    Ein Gedanke war auch, das es vielleicht zu niedrige Bitrate ist, aber eigentlich arbeite ich fast durchgängig mit --crf18. (Im Mittel kommen dann Bitraten von 1800-3200 kbit/s raus, je nach Quelle).

    Meine Stellschrauben sind bis jetzt, was ich so nach mehrmaligen Studium von Encodingwissen glaube gelernt zu haben: deblock, psy-rd und trellis.

    Vielleicht ist meine Fehlerquelle ja auch wo anders.
    Ist es ratsamer die Quelle per Mpeg2Source("film.d2v") einzubinden, wie es zB. Staxrip macht, oder beeinflusse ich mit (Mpeg2Source("film.d2v",idct=4) den Decoder zu sehr?
    Oder zB. ColorMatrix. MeGUI hat das fast immer mit drin. StaxRip nicht...
    Wobei ich da jetzt durch einlesen von ColorMatrix wegkomme, da die Farbräume eigentlich stimmen.
    Dh. meine Avisynth-Scripte sehen eigentlich nur wie folgt aus:

    Code
    Mpeg2Source("film.avs")
    crop()


    Eventuell deinterlace, falls Quelle interalced ist. Aber zu 90% ist das Zeug meistens falsch geflaggt. Zumindestens das, was ich dann habe.

    So, vielleicht fällt mir nachher noch mehr ein....
    Danke für Antworten!

    Gruss,
    Bitspyer

    Mir ist jetzt nach einigen Encodings einiges Aufgefallen:

    Bei schwarzen Flächen, bzw. einfarbigen vollflächigen Bereichen, neigt es irgendwie zu Blöcken.

    Wie kann ich dem entgegen wirken? Hat es was mit den bei Brother John erwähnten Effekt von mbtree zu tun oder hilft daher vorsichtiges Optimieren mit deblock?
    Lt. DGIndex passt eigentlich auch der Farbraum, ohne Colormatrix nutzen zu müssen.

    Das sind jetzt alles Sachen die mir auffallen, wo ich bei MPEG2 keine Probleme hatte.

    Bitspy

    OK, ich habe wohl die Lösung gefunden...

    mit dem avs2yuv wrapper muss man ja die Auflösung mit übergeben

    Zitat


    pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe <viele Flags> --output film.h264 - 720x576 : 4

    Übergibt man nicht die korrekte, weil zB. cropping, dann geht die Bitrate durch die Decke.

    Alles nochmal in DGIndex laden, dann unten bei den Kontroll-Buttons einmal auf ">" klicken und dann auf "["

    Projekt abspeichern. Jetzt sollte bei den Audio-Dateien eventuell 0ms drin stehen.

    Wenn das immer noch nicht hilft:
    oben in der Fensterleiste steht [VOB1][Cell1], solange auf ">" klicken, bis [Cell2] erscheint und dann auf "[" klicken und abspeichern.

    Ich setz' das mal hier mit rein...

    Facts: Vista Ultimate 64bit, StaxRip 1.1.2.3beta, bzw. x264_64.exe (build 1369)

    Encoding Flags: --crf 18 --ref 4 --no-mbtree --rc-lookahead 60 --bframes 4 --b-adapt 2 --direct auto --subme 8 --trellis 2 --me umh --sar 16:11 --fps 25 --deblock 0:0 --psy-rd 1.0:0.15 --threads auto --thread-input

    Ich habe folgendes Phänomen:

    Encodiere ich den Film mittels Staxrip (32bit) mit erhalte ich eine mittlere Bitrate von ~2500kbit/s.

    Encodiere ich den Film per Console mit 64bit Encoder, geht die Bitrate durchs Dach und pendelt sich bei 7000kbit/s und mehr ein.

    Aufruf ist wie folgt:

    Zitat


    pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe <flags> --output film.h264 - 720x576 : 4

    Hat da jemand eine Erklärung? Das Script ist immer das gleich!

    Gruss,
    Bitspyer
    </flags>

    OK, Prolem selbst gelöst!

    Das Indexieren der Videospur habe ich selbst vorgenommen und mich nicht auf die automatik von Staxrip verlassen. Das Problem ist wohl, das dieses Video nicht mit einer sauberen GOP beginnt.

    In so einem Fall geht man wie folgt vor (grobe deutsche Übersetzung aus der Anleitung von DGIndex):

    Die VOBs in DGIndex laden und dann einmal auf den Knopf > drücken. DGIndex springt dann auf den nächsten I-Frame. Als nächstes klickt man den Knopf [ und markiert ab da den Beginn des Filmes. DGIndex demuxt auch dann entsprechend die Audiospuren.

    Und schon ist nach dem Encoden nach H264 und muxen die Tonspur synchron.

    Gruss,
    Bitspyer

    Hi!

    Da ich jetzt einen kleinen Mediatank habe, der h264 wiedergibt, habe ich mich nun mal der Encodierung nach h264 im mkv-Container gewidmet.
    Nach dem ich Jahre mit DVD-RB gearbeitet habe und dachte, mich könnte so leicht nichts mehr aus der Bahn werfen, wurde ich nun eines bessern belehrt. :(

    Die Video-Spur habe ich nach Brother Johns - Encodingwissen angepackt und zwar nach der CRF-Methode. Staxrip habe ich da entsprechend eingestellt. Staxrip hat auch die Audiospuren demuxed. Den Ton habe ich nicht neu encodiert. Aus mangel eines AAC-Fähigen Verstärkers ziehe ich da die original AC3 Tonspuren vor.
    Und da schein jetzt mein Problem zu sein. Bild und Ton sind ständig asynchron und ich kann einfach die Ursache nicht finden.

    Staxrip schreibt in die Tonspuren einen Delay von 6ms. Nehme PGCdemux, dann werden 0ms angezeigt.
    Muxe ich mit MKVmergeGUI und gebe einmal 0ms, bzw. 6ms an, ist der Ton aber auch asynchron.

    Kann eventuell mich jemand auf die richtige Fährte bringen?

    Danke für Antworten!

    Bitspyer, der Verzweifelte

    Hmm... ich sehe da nur xvid 1.1.2 bzw. 1.1.3 oder ist das die 1.2????

    Ich wollte die Multiprozessor FUnktion testen, aber irgendwie hat das xvid was staxrip runtergeladen hat bei prozessoren das feld ausgegraut, obwohl ich einen core2duo habe.....

    Und da in brother johns wissen von 1.2 die rede war, und ich wohl die 1.1.3 hatte, dachte ich, ich müsste nach einer xvid version 1.2 suchen....

    Gruss,
    Bitspyer

    Hi,

    ich habe ein kleines Verständnisproblem. Hier wird gezeigt, das mit dem WinampEncoder höhere Bitrate mit AAC erreicht werden können. Wenn ich jetzt BeLight anwerfe kann ich zwar den Winamp Encoder auswählen, aber nur Bitraten bis 128 auswählen.
    Wähle ich Nero, kann ich höhere nutzen.

    Hat da jeman 'en Tipp für mich?

    Danke für Antworten.

    Bitspyer