Beiträge von Lugia25000

  • VFR-Encoding notwendig für Anime?

    Das mit dem "diskutiere drum herum" liegt eher daran, dass ich nicht weiß, ob ihr mir noch helft, wenn ich einen Cut poste.
    Ich gucke halt gern wo es Quellen gibt und lad mir dazu den Japanischen Untertitel, dann Encode ich es mir zu einer erträgliche Größe und hab dann Hör- Lese Verständnis, bei etwas, was ganz lustig ist zum schaun. Da ich eh voll viel lerne und mitte des Jahres für ein Jahr hinfliege..., naja anderes Thema.

    Encoden ist "allerdings" auch ein Hobby und da interessiert es mich sehr, was es da für Methoden gibt und ob man daran vorbei kommt.

    Cut -> http://www.mediafire.com/?7earpteazdpk487
    17,8 MB
    Ist eine Stelle vorm Ending und wo das Ending anfängt, sonst wirds auch zu groß.
    Vorm Ending dann tfm().tdecimate(mode=1)
    Beim Ending nix(?)

    Problem wäre dann 23.976 und 29.970, könnte zwar alles auf 29.970 belassen, aber das wären 8000 Frames mehr (=größeres File, längere Encode dauer....)
    Deswegen VFR... der rest steht eh oben.

    Meine Methode...
    TDecimate(mode=4, hybrid=2,output="sometext.txt") # 1. Pass
    TDecimate(mode=5, hybrid=2,input="sometext.txt",mkvout="sometextv2.txt") # 2.Pass

    Übrigens Thx für Topic Änderung, war mir eh null sicher beim Titel.

  • VFR-Encoding notwendig für Anime?

    Das tut es wohl, denn ist auch egal mit welchen Filter ich reduziere.
    Habs auch mal mit einem einfachen "Bob()" probiert, wegen dem "sehen" und eigentlich war ich mir eh schon sicher, das kein Frame am Ende gleich ist und man dementsprechend nix löschen kann.

    Directshowsource hatte ich nur verwendet, um nur mal Unterschiede zu sehen. DSS2 tut automatisch zu einer Framerate konvertieren und deswegen stockte es da schon, wenn ich es einfach nur reingeladen habe, also schlechter zum "nur anschaun"

    Weswegen es aber bei deren abspielen nicht stockt.
    Übrigens sind alle MKV.

    Also müssen sie nach meiner Meinung nach Timecodecs verwendet haben, aber müsste sie dann nicht 29.970 Frames haben, wenn die höchste Framerate genommen wird?

    Ich denk dann auch einfach, das sie eine andere Quelle haben, da ich mir echt keine andere Methode vorstellen kann.

    Zitat


    Modus der Bildwiederholungsrate : variabel
    Bildwiederholungsrate : 23,976 FPS

    Zeigt mir Mediainfo bei deren Ergebnis an.
    Gibt es da eigentlich noch bessere Methode um das auszulesen? Möchte es nämlich schon echt gern auf "23.976" bringen und das Ende auf 29.970 belassen. Auch weil ich dann weniger Frames encoden muss.

    Mein Ergebnis:

    Zitat

    Bildwiederholungsrate : 29,970 FPS
    originale Bildwiederholungsrate : 24,386 FPS

    Haben die das dann schon von vorne rein in x264 Variable Encoded? Wenn jemand mir Links geben kann, wo ich es nachlesen kann oder Tipps wo ich suchen kann, wäre ich schon sehr dankbar. Verwende nämlich normal "Megui", und da geht es denke ich nicht, lasse mich aber gern eines besseren belehren.

  • VFR-Encoding notwendig für Anime?

    Ich habe ein kleines Problem. Das Video was ich hab, hat im Video Interlaced, was ich dann normal per Trim und Tdecimate von 29.970 -> auf 23.976 bringe und es ein Ergebnis ist, mit dem ich leben kann, da es wohl keine andere Möglichkeit gibt (?)
    NTSC übrigens, ein Anime.

    Am Ending allerdings ist es Progessive, das bedeutet, wenn ich Frames lösche, stockt es.

    Also hab ich mir gedacht -> VFR, was auch alles super klappt, keine Interlaced Effekte, Ending stockt nicht, super.

    Das zur Ausgangslage.
    ----------------------------------------

    Da es mir hier nur zur Methode geht und ich nicht weiß, wo ich Anhaltspunkte bekomme oder wo ich Suchen muss:

    Ich habe gesehen das eine Fansub Gruppe, naja sogar 2, konstant bei dem Video 23.976 haben(!) laut Mediainfo.
    Wenn ich deren Video allerdings mit Directshowsource("...",convertfps=true,fps=23.976) lade per AVSP, stockt deren Ending. Beim Abspielen aber wie gesagt nicht, obwohl er 23.976 anzeigt.

    Hat jemand auch nur die Hauch einer Idee?
    Weil, wenn ich es mir Theoretisch vorstelle, sollte es doch nicht möglich sein, denn entweder wird das Video im Ending länger 29.970->23.976 = Ton passt nicht oder es muss halt sofort stocken, da Frames gelöscht wurden.

  • XviD 1.x - aktuelle Version

    Xvid 1.3.0-rc1

    http://www.xvid.org/
    Leider hab ich noch kein Build zum testen gefunden.

  • MeGui Bug nervt bitte um Hilfe

    Woar manche Sätze sind etwas schwer zu lesen bei dir~

    Bring Megui x64 mal auf den aktuellen Stand -> http://forum.doom9.org/showthread.php?t=153904

    Sonst musst einfach mehr Infos geben...

    Zitat

    -[Error] An error occurred: Usage : xvid_encraw [OPTIONS]


    Da sollte dir übrigens Megui schon selbst sagen, an was es scheitert.

    Zitat

    Hab mir MeGUix64 gezogen nutzt diese Version auch XviDx64? Wo ist der Unterschied zwischen XviD x86 und x64?


    Gibt genug Threads, auch hier. Es sollte einfach gesagt u.a. schneller laufen. Xvid ist aber eh schon schnell.

    Zitat

    da ich nur 2Pass VBR mache

    VBR ging doch nie bei Xvid und der Bug wurde nie gefixxt~ Wenns falsch ist, kann mich gern wer korregieren.

  • MeGUI auf ältere Version zurücketzen...?

    Ich hatte auch Probs, wenn ich auf die neuste Version mit 0.3.4.13 geupdatet hatte, dann konnte ich die Oberfläche nicht mehr sehen, egal was ich auch machte.

    Eine Deinsterlation und eine Neuinstallation von http://sourceforge.net/projects/megui/ 0.3.3 bzw. dann das gemachte Update auf 0.3.4.15, hat bei mir alle Probleme gelöst.

    ---------------------------------
    Ich wüsst eigentlich nicht, wieso du dir jetzt 0.3.3 + alle alten Probs wünschst. An allem was Megui so aktualisiert, hat Megui eh nix mit zutun.

    Sonst halt 0.3.3 oder älter -> http://sourceforge.net/projects/megui/files/ installieren und halt nix updaten.
    Oder halt im englischen Forum erzählen, was genau dein Problem is, ist ja nicht so, das sie einem nicht helfen.

    Und wenn dein Englisch vielleicht ganz ganz schlecht sein sollte...
    Zathor hat hier auch was in Deutsch geschrieben, also solltest ihn auch so ansprechen können, ob hier im Forum per PN (da weiß ich nicht ob er vorbeischaut) oder halt da~

  • [suche] VSFilter von MPC-HC

    Wenn du schon sammelst -> https://code.google.com/p/vsfiltermod/

    Ach und stimmt, hab mich vertan. E war experimental...
    http://forums.animesuki.com/showthread.php…131#post2134131

    Eh schon über ein Jahr her. Der hatte auch mal irgendwo geschrieben das er nicht mehr an dem Sourcecode rumwerkeln wird, weil da eh schon x verschiedene Leute dran rumgemacht haben und man da lieber ein neues Format erstellen soll.

    Zitat

    ich vermute mal das das die art der versionierung ist

    Genau.

  • Framefehler?

    Zitat von MegaDeath

    Ich verstehe mal wider nur Banhof :) DSS2 = DirectShowSource ?

    Im Haali Media Splitter gibts eine dll -> avss.dll, das ist Haalis Directshow Filter -> Directshowsource2, aufruf Dss2("....",fps=..) Konvertiert automatisch Variable Frameraten von Videos in Konstante.

    Ich kann auch nur raten, woran es lag. Muss wohl deswegen erstmal alte Rev verwenden, damit es auch überall klappt.

  • Framefehler?

    Nene, ich encode schon unkomprimierte AVI-Dateien, aber in x264 mit mp4 Container.
    Deswegen auch das "Xvid geht z.B." in Klammern paar Posts zuvor.

    Ich konnt den Fehler nur durch das aufrufen per Avisynth mit DSS2 nachvollziehen, weil ihn nicht sehe und ich mit FFDShow decodiere.

    Zitat

    Der Splitter kann da auch nicht viel dran ändern - jetzt müssen eben noch mehr Frames decodiert werden, bevor der Inhalt des angesprungenen Frames korrekt berechnet werden kann.

    Nach x264 1374 wurd aber kein MBTree oder andere neue Funktionen, die den Prozessor mehr beeinträchtigen, hinzugefügt.
    Muss übrigens zwischen 1374 und 1391 liegen. Da 1391 gleichen Fehler hatte wie 1400, dachte ich das es nicht dran liegt.

  • Framefehler?

    Zitat

    b) In deinem Skript verwendest du AVI-Dateien. Das hat also nichts mit x264 zu tun ..

    Und doch hat es was damit zutun gehabt...
    Verwende Megui und rev1400, hab aber auch offizielle verwendet und paar Patches, nix...
    Hab gerade aus fun mal 1376 verwendet und schon hat der Splitter keine Probleme mehr mit und zeigt mir auch alle Frames so an, wie sie sein sollten.

    Das war aber auch von mir eher das letzte gewesen, was ich vermutete, kam wohl der Splitter mit irgendwas nach 1376 nicht klar.
    Mir aber egal, muss ich aber mal später drauf achten bei neueren Revisionen.

    Vielen dank LigH für deine Antwort :)

  • Framefehler?

    Zitat

    a) In deinem Skript verwendest du AviSource. Das hat also nichts mit DDS2 zu tun.
    b) In deinem Skript verwendest du AVI-Dateien. Das hat also nichts mit x264 zu tun ...

    Kay, aber wieso springt er dann bei meinem Freund am Anfang viele Frames weiter und beginnt erst dann den Ton abzuspielen? und auch wenn h264 so komplex ist, ein Quad Core sollte es können und es ist immer die selbe stelle.
    Ich weiß auch das der Encode so richtig ist, sonst wäre was anderes verschoben...
    Ich kann es nur mit dss2 schaun, das wenn ich das skript am ende, also die mp4 mit dss2 anschaue, das er frames springt.

    Zitat

    Der Haali Media Splitter ist kein Decoder, sondern ein Splitter.

    Wobei avss.dll doch mit Haali Media Splitter dekodiert oder den erzwingt.

    Durch deinen Beitrag hab ich auch erst durchs springen an Keyframes gedacht, nur sind die Frames, wenn man den Splitter verwendet nicht da, sodass springen eh egal wäre.
    Eine Erhöhung brachte auch nix...

    Und ja AviSource, in der Vorschau bei Megui, AVSP und überall wird es richtig dargestellt. Framerate ist nicht Variable, alle Decoder können es abspielen, aber wenn der Haalis Media Splitter dazu verwende wohl nicht.
    Achja nochmal... die Frames die er springt sind nach dem Encode mit dss2 z.B. nicht mehr da, gelöscht, weg. Wenn ich den Ausschnitt nur mit dss2 anschaue, springt er erst weiter, dann gehts normal weiter das anschaun, dann fängt er wieder von vorne an und dann stürzt er ab.
    Ich bin ratlos, deswegen überhaupt der Thread.

  • Framefehler?

    Ich hab ein dickes Problem...

    Ich hab ein Video mit x264 encodiert, auch ganz normal wie immer. Bei mir spielt er es normal ab, ob ich FFDShow, CoreAVC, DXVA oder FFMPEG2 verwende.
    Auch wenn ich die internen Decoder von MPCHC verwende, alles super.

    Jetzt kommt der Fehler, den ich auch nur so reproduzieren kann. Verwende ich DSS2, also decodiert es mein Freund (der nämlich das Problem bei sich hat...) mit dem Haali Media Splitter, so springt das Video beim 2. Bild einfach viele Frames weiter (seh ich nur per Dss2) und dann geht der Ton erst los. (alles asynchron...)
    Das Problem tritt nur bei x264 auf (Xvid z.B. nicht) und mit dem Haali Media Splitter als Decoder, soweit ich das sehe.

    Ich hab keine Ahnung woran es liegt...
    Kleiner Ausschnitt ohne Ton (1,24MB) http://www.mediafire.com/?wdedd2tjdmw
    Ich kann es hier gut sehen per AVSP und DSS2...

    Ich hab echt alles probiert, das Skript ist ganz einfach:
    Teil1 = AVISource("C:\...\Desktop\KaraokeOP.avi")
    Teil2 = AVISource("C:\...\Desktop\Episode 01.avi").trim(1438,30571)
    Teil3 = AVISource("C:\...\Desktop\KaraokeED.avi")
    Teil4 = AVISource("C:\...\Desktop\Episode 01.avi").trim(32365, 0)
    Teil1 + Teil2 + Teil3 + Teil4

    Da ich auch noch UT verwende, die aber korrekt zur richtigen Zeit eingeblendet werden, kann es doch nur am Haali Media Splitter liegen?
    In der Vorschau und so seh ich es auch immer richtig und andere x264 Versionen hab ich auch probiert.

  • MeGui encoded nach update 2/3 langsamer (x264)!

    Zitat

    Wie siehts denn mit dem VLC Player aus? Dort sind die Pixelblöcke gut zu erkennen, währen der MPC HD dort keine Pixelblöcke zeigt. Für mich ist jetzt halt nur die frage, ob der MPC das kaschiert oder der VLC Probleme bereitet.


    Der VLC Player verwendet, wenn man nix anderes eingestellt hat, doch noch immer seine eigenen (veralteten?) Decoder.
    Der MPCHC nutzt auch seine eigenen internen Decoder, wenn man es einstellt, aber sonst CoreAVC, FFDShow oder was man sonst als Decoder hat.

    Meine Geschwindigkeit ist die selbe wie früher, kommt halt auf die Einstellungen an.
    Kann auch sein das ich das nicht ganz mitbekommen hab, weil ich aus Faulheit mit Megui weitergarbeitet hatte, die x264 immer selber aktualisiert hatte und den Rest über die Kommandoline geregelt hab.
    Dann kam aufeinmal das Patch Build, aber nur die neue Megui Version hat bei mir nix langsamer gemacht.

    Zathor, hätte jetzt nicht gedacht das du deutscher bist. ;)

  • MeGUI 0.3.1.1060 CUVIDServer

    Probiere es doch mit der DGMultiDecodeNV.dll, die geht ohne CUVID Server, wenn der mit Megui immer noch Probleme macht.

    Halt mit DGMultiSource() statt DGSource(). Laut der Readme geht es mit früheren Megui Versionen nicht und er vermutet das es mit aktuellen auch fehlschlägt, da Zathor aber gut dran gearbeitet hat, kann es nicht mehr der Fall sein.

    Ich habs noch nicht probiert, da ich im Moment zu selten etwas mit GPU Decoding mache.

  • MeGUI Encoding-Frontend: aktuelle Versionen

    Jetzt hat er die Versionsnummer doch geändert und jetzt geht es wohl wie gewohnt weiter. Hätte nicht gedacht das sich wer findet, der den Stress übernimmt.
    Auch ein neues Build ist oben. Änderungen zu dem obigen Patch Build: