Beiträge von De-M-oN

    Dann öffne die AVS Datei halt mit media player classic home cinema.


    Den Bereich bis zur Stelle wählen, encoden, dann 2. Script mit dem Bereich nach der Stelle. und 3. script für das Austauschding für die stelle


    Dann in MKVMergeGUI 1. Video hinzufügen, dann anhängen button, austauschvideo + 3. video öffnen, muxen.

    Speed und Kompressionseffizienz hängt vom Material ab.


    Schwer komprimierbares Material braucht viel längere Encodierzeit als einfaches.


    Und gehen wir mal von einer einzigen Kompressionsmöglichkeit aus:


    b-frames.


    Wenn du nun als mehr als 3 b-frames verwendest, x264 aber aufgrund der Komplexität des Materials kaum mehr als 3 b-frames einsetzen kann - dann ist der Kompressionsgewinn entsprechend niedrig, als wenn man einfaches Material hat wo der Encoder dann sogar hauptsächlich die höhere Zahl nutzen kann.


    Daher ist es auch falsch zu sagen Einstellung X bringt kaum etwas. Jede Einstellung kann helfen. Es kommt immer aufs Material an, welche Einstellung wo viel profitieren kann oder eben weniger als andere.


    Mehr als slow eignet sich für Spielevideos nicht, da die meisten Spiele eh sehr schwer komprimierbar sind, vor allem aktuellere mit außenterrain ala gräser etc. Bei viel außenterrain mit gräsern usw (sprich massiv komplexes Material) kann sogar slow schon zu ineffizient sein, so das sich sogar eher medium lohnt..

    Wenn du Audio mitschneiden möchtest nicht vergessen die Schnitt Datei unten mitzuladen.


    Bitte rein nur dann, wenn du in Audio Input NICHT die AVS Datei ebenfalls hast. (Sprich zb eine AVI oder WAV oder so.)


    Ansonsten wenn es die AVS ist, die Cutliste NICHT laden, sonst kann es sogar zum fehlerhaften Audioencode kommen.


    @RalFingerLP: Kann dein Problem nicht nachvollziehen, alles ok bei mir ;)


    Daher ka woran es liegt..


    verdammt wieso schreib ich gerad wieder hier... verdammter supportdrang beim eigenen Thread wohl ... --- ja ich bin mit der LPF Moderation mega unzufrieden, aber wie man gesehen hat in bestimmten Threads steh ich echt nicht alleine da...

    Zitat

    wird das dann über dieses "upsampling" so hergerichtet, dass es "richtig" aussieht? bzw. wenn ich das so hochlade, stellt youtube es dann richtig dar?


    und warum gibt es diesen "fehler" überhaupt? also, dass der encoder das vermurxt hab ich glaubsch verstanden, aber warum erkennt er das falsch?


    Der Encoder hat gar nix falsch gemacht. Das ist ein simpler Darstellungsfehler wie in dem anderen Thread erklärt.
    Der Renderer stellt den YUV Farbraum falsch dar..


    Und ja der Flashplayer stellt selbstverständlich YUV Farbraum korrekt dar.


    Zitat

    Das müsste über das Menü Tools -> AVS Cutter gehen. Die .clt-Datei, die dann erstell wird, muss bei den Audiotracks aber auch noch eingfügt werden, damit die Tonspuren auch geschnitten werden.


    Die CLT Datei muss nur dann geladen werden, wenn beim Audio Input nicht ebenfalls die AVS Datei, sondern eine andere Quelle, wie zb eine WAV Datei dort geladen ist. Einfach weil er so dann ja nicht die Cut Information aus der AVS hat.


    Ist im Audio Input ebenfalls die AVS Datei, sollte sogar die CLT Datei NICHT geladen werden, da es sonst Fehler geben kann. Wäre nämlich dann auch doppelt. Denn der Trim Filter berücksichtigt durchaus auch Audio.


    wegen CRF 21 vs 19.


    Ist sichtbar an komplexen / dunklen Stellen.


    CRF 19 sieht da schon durchaus besser aus. Wird aber auch entsprechend größere Datei.


    Zitat

    Dürfte wirklich nur noch absoluten Profis bei genauem Hinschauen auffallen. Lohnt sich aber auch erst bei 1080p oder besser Original, bei den kleineren Bitraten reicht CRF 25 vermutlich schon vollkommen aus. :P


    a) youtube benutzt auch Qualitätsfaktor und keine feste Bitrate. (Bin aber unsicher ob fester Quantizer oder CRF. Ich vermute Quantizer, weil die Qualitätsdifferenz auf Dunkelheit zu immens absinkt gegenüber hellen Stellen und es bei komplexen Videos wie Arma 2 etc zu deutlich mehr Artefakten kommt als bei einfachem Material. Das deutet auf Quantizer hin und nicht CRF, wo die Qualität eher einheitlich wäre.
    b) Nein es lohnt sich nicht nur bei 1080 und Original.


    Gerade bei den kleineren Qualitätsstufen bleibt noch mehr über, wenn das hochgeladene Material höherwertiger ist. Jemand sah bei der 360er sogar ein Unterschied als ich von 20 auf 19 ging.


    CRF 21 vs CRF 19 ist an gewissen kritischen Stellen noch sehr gut sichtbar.


    CRF 25 würde ich NIE empfehlen. Das würde ich rein nur dann empfehlen, wenn einem das Internet absolut dazu zwingt.
    Nur weil Youtubes 1080p encode dank besseren Qualitätsfaktor seitens denen mit CRF 25 noch immer besser aussieht, als 720p @ CRF 21 und deren 720p Encode, ist CRF 25 noch lange nicht etwas hochwertiges ;)

    Zitat

    2.) Fraps nimmt meine videos immer wesentlich dunkler auf, als sie sind. Camtasia und handbrake haben dies korrigiert und es sah hinterher wunderbar aus. avidemux scheint dies allerdings nicht zu tun. gibts ne einstellung, an der das liegt/liegen könnte?


    Siehe hier:


    Magix Video Deluxe: Problem mit Farben


    Das Dunklere ist das KORREKTE Bild.


    Getrennt encodieren und hinterher dann muxen.


    Der ChangeFPS Filter hat nichts mit dem Quellmaterial zu tun, welches identische Eigenschaften haben muss.


    Zitat

    Verlustfrei sollte mit CRF 0 sein.


    Lossless = Constant Quantizer @ 0. CRF 0 dürfte aber auch gehen.
    Verlustfrei encoden find ich aber unelegant. Da würd ich lieber mehrere Encodes machen und die dann muxen.
    Den Ton kannst ja direkt in einem Stück encodieren.
    Die Videos dann anhängen und den Ton hinzufügen, dann haste alles zusammen.



    Viel zu umständlich. Statt AVISource einfach FFVideoSource benutzen.
    Oder wie du unten schon sagst: Haali Splitter + DirectShowSource. Sofern man sich sein System nicht mit Codecpacks oder ähnlichem versaut hat, ist Lossless Material per DirectShow auch kein Problem.


    Zitat

    So ein Aufwand für eine 7 sec Cutscene... :rolleyes:


    Eig nicht. Ihr habt es nur so umständlich angegangen ;D


    Denn das war die ganze Zeit das einfachste. Einfach getrennte Encodes und gut ;D

    Zudem würde ich (wenn man denn Premiere wegen Bearbeitung oder so nutzen will) mit Frameserver arbeiten und den encode mit x264 tätigen, wie schonmal in dem Thread gesagt.


    Deutlich besserer Encoder und qualitätsbasiertes Encodingverfahren. Ergo bräuchtest du dich so gar nicht mehr mit der Bitrate rumschlagen. Bitratenfixiertes Encoding ist eh suboptimal.

    AssumeFPS geht mit FFVideoSource doch, ist ein externer Filter und nicht an dem Decoder gebunden, sorry hab das verwechselt gerad.


    Zitat

    Das muss ich nochmal checken.


    Aber bitte doch ;)


    Und auch das mit dem [x] Force CPU Processing & proc. Threads = 2 nicht vergessen wie angesprochen.


    Mit RGB und ohne Compress war die Aufnahmeperformance sicher genauso beschissen, wie mit x264vfw, wenn nicht noch beschissener oder? ;)


    Daher mache bitte die Einstellungen korrekt ;)


    Edit: Ja ist klar das es mit High zu großen Dateien kommt ;)


    Ist ja dann höheres Chroma Subsampling (Mehr Farbinfos, die spätestens nachm Lossy Encode aber so oder so dem Medium (4:2:0 entsprechen) Von daher ist eine Aufnahme in höheres nur unnötig mehr Speicherplatzverbrauch und Systembelastung.