Beiträge von Bluedan

    Oh...wie lieblich Dein knappes posting, so reizend der Klang Deiner Worte.... es ist wahr, es läuft jetzt. Magie mit Nullen und Einsen... Toll! Danke.
    ---
    WIeso kommt eigentlich nach jedem update folgende Fehlermeldung?

    Scheint nicht von Belang zu sein, da Megui trotzdem läuft?!
    Bei OK kommt aber keine online Suche zustande.

    OKay: gleiche Meldung:

    Process exits with error: 0xC0000135 STATUS_DLL_NOT_FOUND (-1073741515)

    Diese Meldung kriege ich mit x64 version bei dem Versuch mkv, die ich per HD Stream extractor (EAC) von BluRay erzeugt habe, ducrh den Fileindexer fürs Recoden zu jagen.
    Ich fummel jetzt schon seit 2 Tagen damit rum. Habe soweohl Avisynth als auch MeGUI x64 komplett neu installiert.
    Die Installation hatte ich davor für Monate nicht mehr anfassen müssen (autoaupdate via dev.upd.server).

    Die x86 version macht es, warum nur??

    Kann mir jemand sagen, was da kaputt ist?

    BTW: win7pro.x64

    Ich habe gerade festgestellt, dass der Script creator mal DirectShowSource und mal FFMPegSource verwendet, um mkv Dateien zu öffnen, welche in allen Fällen ein AVC Video, frisch von der BD (via eac3to) enthielten. In MeGui selber scheint man das nicht beeinflussen zu können (Einstellungen).
    Mir ist nicht ganz klar, warum DSS überhaupt verwendet wird. Wenn ich anschließend das Script ändere, um FFMS2 zu verwenden, klappt alles reibungslos.
    Ich dachte, soweit wie meine Forensuche mich gebracht hat (u.a. Doom9 & 10), dass letzterer eigentlich mit allen mkv klar kommen soll, frame akurat ist und obendrein multithreaded läuft und deshalb zu bevorzugen ist, oder?

    Immer und immer wieder die selbe Empfehlung:

    Wenn die exakte Zielgröße nicht wirklich interessiert, dann nimm für x264 den CRF-Modus mit nur einem Durchlauf. [...]

    Das tut mir aufrichtig leid. Die Suchfunktion ist mir bestens vertraut. In diesem Fall, hätte ich
    a) aber auch gar nicht nach CRF gesucht, weil mir der Begriff völlig neu ist - bei XVID hieß das noch CQ und das habe ich seit dem gehackten DIVX3 nicht mehr benutzt - und
    b) habe ich in Anbetracht einer recht ungenauen Suche mit typischen Begriffen wie "x264 - BluRay - beste Qualität" keine zufrieden stellenden Ergebnisse gehabt.

    Einen Sticky mit diesem Thema gibt es auch nicht. Wäre ja mal vielleicht etwas. U.U. kommt dann diese Frage nicht mehr so häufig.

    OK. Einen Beitrag von Dir habe ich doch noch gefunden. o_O

    Vielen Dank für die trotzdem ausführliche Erläuterung, ich werde mich gleich mal ransetzen.

    Bzgl. interlaced content: megui wird aber doch wie gewohnt via avisynth script creator mit der analyze Funktion dies zuverlässig detektieren, oder?

    Wieso überhaupt croppen?

    Das hat man mir in den langen Jahren bei Doom9 beigebracht :) : die schwarzen Balken verbrauchen unnötig Bits, wenn auch nicht viele. Da die Gesamtgröße des Videos durchaus in meinem Fall variieren darf, fällt dieser Aspekt nicht wirklich ins Gewicht, da hast Du recht. Ich hätte es auch sein lassen können.
    Für mich war jetzt aber wichtig, herauszufinden, ob man nicht bei bestmöglichster Ausnutzung von x264 nicht ein mind. 90%ig qualitativ vergleichbares Video hinbekommt bei kleinerer Filegröße und geringerer Bitrate. 13GB sind eben ganz schön happig.

    Nach langen Jahren des DVD-Backups habe ich mich nun an BluRay herangewagt.
    Die meisten Fragen und Anleitungen hier drehen sich um BluRay Backup für z.B. PSP oder BluRay konform.
    Ich vermisse eher die Fraktion, die die Videos eher auf der Festplatte archiviert. Dazu gibt es hier irgendwie keine Diskussionen.

    Ich beabsichtige nicht, die resultierende Datei zu irgendwelchen Stand-alone-Playern oder Media-Boxen kompatibel zu gestalten. Insofern bin ich in der Hinsicht ziemlich frei.

    Dennoch: Einen zweistündigen Hauptfilm, welcher 12,5 GB auf der Festplatte beansprucht, wollte ich aber doch nicht 1:1 übernehmen. Einerseits vielleicht zu geizig :D , andererseits muss ich eh wegen des Croppens rekodieren, da kann man ja gleich sehen, ob das Material sich nicht noch etwas verdichtet lässt....

    Abgesehen davon, dass ich die Audiospuren in 5.1 Ogg (wenn Multichannel im Original) und die Untertitel via OCR in Subrip konvertiere, war ich aber unsicher, welche Einstellungen ich für die Video-Transkodierung wählen kann, ohne zu viel Details zu verlieren.

    In meinem ersten Projekt hat das Original-Video eine Auflösung von 1920*1080 (16:9) mit einer Bitrate von 13.7Mbps, AVC-High@L4.1. In meinen ersten Versuchen habe ich mit einer Ziel-Filegröße von ~8GB eine Bitrate von etwa 8Mbps gehabt und irgendwie keinen Unterschied gesehen: in MeGui x264 unrestricted Profile mit der Preset-Einstellung "slower" und "Film" gewählt.

    Geht es noch kleiner? Jetzt habe ich eine Zielgröße von 4,1GB (DVD) gewählt, Bitrate war 3,8Mbps. Diesmal habe ich aber in Anlehnung an die DVD-Konversion, Degrain eingesetzt, um die Kompressibilität zu erhöhen - das Original war recht körnig, also "film"-like.
    Was soll ich sagen: Ich sehe kaum einen Unterschied: vielleicht etwas Detailverlust z.B. bei Flächen, die nicht im Fokus sind, sondern knapp dahinter. Aber keine Blockartefakte.

    Überraschend für mich, dass mein PC mit einem Phenom X4 3GHz mal wieder "zu langsam" geworden ist. 4,2fps im 2.Durchgang sind schon arg wenig.

    Was mich interessiert ist, was ihr so für Einstellungen wählt, was eure Überlegungen sind. Die Auflösung will man ja eher nicht ändern - wenn man wie ich auf einem fullHD-TV schaut - würde aber viele Bits sparen, wenn man auf 720p ginge.
    Die Filter-Möglichkeiten in Avisynth sind bezogen auf die mögliche Kodiergeschwindigkeit ja ganz schön limitiert, selbst mit einem 6-Kerner. Allerdings sehe ich in Anbetracht der enormen Bitrate und hohen Bildqualität im Ausgangsmaterial auch keine Veranlassung zu ausgedehnten Spielereien. Bis auf im wesentlichen das Deinterlacen und die Farbkorrektur waren bei DVD->AVC darüber hinausgehende Filter eher eine Verschlimmbesserung in meinen Augen, es ergab eher ein recht künstliches Bild.

    Was meint ihr?

    - Film spielt normalerweise 29.97 Bilder/Sekunde -> nach einer Sekunde sind knapp 30 Bilder gespielt
    - nun spielst du diesen Film mit 25 Bildern/Sekunde -> die ersten 30 Bilder sind erst nach ~1,2 Sekunden abgespielt

    rechne das mal hoch auf deine 108 Minuten.....


    Simmt. Aber dieses Vorgehen von BeSweet ist Quatsch, weil PAL und NTSC-DVD ganz anders generiert werden - siehe 1.post - diese zeitliche direkte Beziehung stimmt so doch gar nicht. Demnach wäre ja eine PAL-DVD später zu Ende. Genau das Gegenteil ist der Fall!

    Zitat


    Der Ton wurde für PAL um ~4,27% beschleunigt, dies musst du rückgängig machen egal ob dein Video mit 29,97 oder 23,976 läuft.


    Nee. Nehme aus Qualitätsgründen das PAL-video...

    Hallo zusammen.

    Ein und derselbe Film, PAL Video wegen besseren Bildes aus der deutschen Veröffentlichung in mkv container. Um die englische Tonfassung verwenden zu können, kommt der Ton von einer US-Amerikanischen DVD, laut dgindex NTSC 29,970fps.
    Zu meinem Erstaunen fruchten meine Versuche nicht, die richtige Abspiellänge zu erzielen. Ich habe sowohl BeSweet als auch den BeLight-Abkömmling ausprobiert. Bei beiden wächst die Datei von 108 min auf 129min !!

    Nur zum Verständnis: Verglichen mit dem Original-Cinema-Filmmaterial ist PAL um 1fps beschleunigt (video: früher zu Ende; audio: ebenso: höherer Pitch) - 1:1 frame für frame vom Kinofilm, aber 1 frame mehr pro sekunde abgespielt.
    Bei NTSC ist die Dauer fast gleich (30fps) - aus 24 frames werden die übrigen generiert/dupliziert - aber wegen technischer Dinge (Farbe) ganz gering langsamer -> 29,970fps.

    Ergo: PAL ist etwa 1,030 frames schneller und KÜRZER als NTSC (29,970).
    Warum wird meine audiodatei dann länger?

    Einen Audioeditor zu verwenden habe ich spaßeshalber auch probiert. selbst wenn ich die exakten Prozentzahlen weiß, um die beschleunigt werden muß (time stretching), ist man fast Minuten off synch, für lip synch reicht das nie im Leben...

    Jemand Ideen?

    Was mich wundert, dass sich niemand dieses besweet problem beklagt hat... deshalb vermute ich, es liegt vielmehr bei mir!