MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von Haaligaali

    Da Job22 mit 7.25FPS lief und Job24 gerade mit 7.07FPS runterrattert


    Das ist eine recht leichte Schwankung und akzeptabel.


    Vielmehr interessant ist der Fehler "Process exits with error: 0xFFFFFFFF (-1)"
    Könnte mir vorstellen das es am alten [lexicon]AVISynth[/lexicon] liegt das du nutzt.
    Weil eigentlich wäre v2.6.0 besser. Kann mir auch vorstellen das du das [lexicon]MeGUI[/lexicon] interne [lexicon]AVISynth[/lexicon] noch nimmst.


    Desweiteren [lexicon]MeGUI[/lexicon] mal updaten lassen auf 2496 und auch den Haali Media Splitter mal updaten lassen.

    Zitat von Sagaras

    Haaligaali Den Skript mal posten der verwendet wurde bei dem Video wo es abgeschmiert ist und zusätzlich dazu die passende Log von [lexicon]MeGUI[/lexicon].


    Die Log enthält das Script.


    Und warum skaliert ihr immer noch mit [lexicon]lanczos[/lexicon] ^^ Spline16 müsste doch sich schon rumgesprochen haben ^^


    --[Information] [15.05.2014 16:43:31] Haali Matroska Splitter: 1.11.96.14 (03-03-2011)


    updaten: http://www.free-codecs.com/haa…ska_splitter_download.htm


    --[Information] [15.05.2014 16:43:32] Connecting to server: [lexicon]megui[/lexicon].org/auto/stable/


    nimm ma den development update server. Irgendeine [lexicon]x264[/lexicon] Version war nämlich etwas buggy. Die vom dev update server aber definitiv nicht. (options - settings - update server auf dev update server umstellen und [lexicon]megui[/lexicon] updaten lassen)


    Zitat von Haaligaali

    Interessanter Weise scheint hier im Log ein Fehler zu sein, der Job stand nie bei 100%, war also nicht "completed", ebenso war die angezeigte FPS bei 4.x zum Zeitpunkt des Abbruchs (sonst hätte ich ja nicht abgebrochen).


    Der Job ist auch bei 'nem Fehler "completed". [lexicon]x264[/lexicon] gibt dir aber ja aus, das er abgebrochen hat mit dem Fehlercode: 0xFFFFFFFF (-1)


    Zitat von Sagaras

    Könnte mir vorstellen das es am alten [lexicon]AVISynth[/lexicon] liegt das du nutzt.


    Nein eher sehr unwahrscheinlich. Wurd ja auch von mir jahrelang verwendet. Bin ja erst mit MT umgestiegen.


    Zitat von Sagaras

    Weil eigentlich wäre v2.6.0 besser. Kann mir auch vorstellen das du das [lexicon]MeGUI[/lexicon] interne [lexicon]AVISynth[/lexicon] noch nimmst.


    Auch das würde in der Log stehen. Nein er benutzt ein extern installiertes 2.5.8.

    Zitat von Sagaras

    Das ist eine recht leichte Schwankung und akzeptabel.


    War auch eher darauf bezogen dass Job20 mit 5.35FPS lief.


    @De-M-oN :
    Danke für die Tipps, werd das mal umstellen. Da die weiteren Aufträge jetzt anscheinend richtig funktionieren (Job26 7.09FPS und Job28 gerade bei 6.85FPS) werde ich es die nächsten Aufnahmen im Auge behalten und hoffen dass der Fehler bei aktuelleren Versionen dann nicht mehr auftaucht. Wenn doch meld ich mich nochmal. ^^

    Darf ich mich unverschämterweise mal einmischen? ;-)


    Ich habe mir ein Tutorial angesehen wie man [lexicon]MeGUI[/lexicon] und [lexicon]Sony Vegas[/lexicon] bzw. Movie Studio dazu bringen kann, zusammen zu arbeiten.
    Nachdem ich sah, dass [lexicon]MeGUI[/lexicon] ein AVS-Script benötigt, dachte ich mir, ich erstelle mir eine einfache BAT-Datei.
    Wer den "[lexicon]DebugMode FrameServer[/lexicon]" nutzt kennt das sicherlich: Es wird eine AVI-Datei ausgespuckt, die man in ein [lexicon]AviSynth[/lexicon]-Skript lädt. Und dieses Skript lädt man dann in [lexicon]MeGUI[/lexicon].


    Meine BAT-Datei macht so etwas Ähnliches. Die AVI-Datei die vom [lexicon]FrameServer[/lexicon] kommt, zieht man einfach auf die BAT-Datei. Daraufhin erstellt das Skript die nötige AVS-Datei, ruft ffmpeg auf und löscht am Ende die AVS-Datei.
    Warum ich ffmpeg gegenüber [lexicon]MeGUI[/lexicon] vorziehe? Es ist nicht auf [lexicon]x264[/lexicon] beschränkt. Wer seine [lexicon]Let's Play[/lexicon] Videos z.B. auf die eigene Seite einbinden will, ohne auf [lexicon]YouTube[/lexicon] zu bauen (Stichwort "HTML5"), kann so z.B. auch [lexicon]WebM[/lexicon] oder [lexicon]OGG[/lexicon] Theora Videos erstellen.
    Und natürlich braucht man dann auch keine [lexicon]GUI[/lexicon] mehr. Auch MKVMerge fällt dann weg, da ffmpeg das direkt [lexicon]muxen[/lexicon] kann. Das bedeutet dann auch, dass keine unnötigen Dateien auf dem PC entstehen, die man nachher wieder löschen muss.


    Ich poste hier mal das von mir verwendete Script. Vielleicht nützt es ja jemandem. Zeilen die mit REM anfangen, sollen das Skript lediglich ein wenig erklären.



    Wichtig ist vor allem Zeile 23. Sie startet den eigentlischen Encode.

    Dein [lexicon]AVISynth[/lexicon] Sript besteht nur aus AVISource. Sehe ich das richtig? AVISource ohne AssumeFPS. Weißt du warum [lexicon]MeGUI[/lexicon] bei AVISource ein AssumeFPS dahinter macht? ^^ Um die kleine Verschiebung der FPS die mit AVISource eventuell auch mal falsch sein kann zu korrigieren.
    Desweiteren frage ich mich wieso du überhaupt [lexicon]AVISynth[/lexicon] verwendest, wenn du eh mit FFMPEG das ganze kodieren tust? Warum machste es dann nicht direkt?
    Die Fake AVI vom [lexicon]DebugMode Frameserver[/lexicon] wird FFMPEG gewiss lesen und verarbeiten können.
    Des weiteren sehe ich keine Farbraumkonvertierung. Aber der [lexicon]DebugMode Frameserver[/lexicon] gibt kein YV12 aus. Sprich wenn ich mich nicht irre encodierst du in YUY2, wenn das nicht automatisch von FFMPEG geregelt wird.


    Ein bisschen Fail dann würde ich sagen xD
    Nur weil [lexicon]MeGUI[/lexicon] [lexicon]AVISynth[/lexicon] nutzt, heißt es noch lange nicht das FFMPEG AVS Datein als Input braucht. Und wenn du die AVS Datein schon erstellst dann auch korrekt.
    Kein Mensch der mit [lexicon]AVISynth[/lexicon] arbeitet würde AVISourcen ohne AssumeFPS laden.
    Wenn du FFMPEGSource im AVS Skript verwendest oder andere Sourcen, die brauchen kein AssumeFPS unbedingt. Aber AVISource brauch es auf jeden Fall.

    Zitat von anihex

    Warum ich ffmpeg gegenüber [lexicon]MeGUI[/lexicon] vorziehe? Es ist nicht auf [lexicon]x264[/lexicon] beschränkt. Wer seine [lexicon]Let's Play[/lexicon] Videos z.B. auf die eigene Seite einbinden will, ohne auf [lexicon]YouTube[/lexicon] zu bauen (Stichwort "HTML5"), kann so z.B. auch [lexicon]WebM[/lexicon] oder [lexicon]OGG[/lexicon] Theora Videos erstellen.


    Als wenn MKVMerge nicht in einen [lexicon]webm[/lexicon] [lexicon]Container[/lexicon] speichern kann^^ Das ist nämlich nix weiter als ein [lexicon]MKV[/lexicon] [lexicon]Container[/lexicon] mit anderer Endung. ^^ MKVMerge hat einen Haken für [lexicon]webm[/lexicon]. Das Video muss für [lexicon]webm[/lexicon] bloß ein paar Anforderungen erfüllen. Und darauf hätt ich schon wieder kein Bock. Und bereits Firefox unterstützt schonmal kein [lexicon]H.264[/lexicon] bei HTML5. Also müsst ich auf einen anderen ineffizienteren [lexicon]Codec[/lexicon] ausweichen. Warum tust du dir das an?


    Hier:


    http://killerinstinct.ath.cx:2…lien-vs-IconofSin666.html
    Die erste Map hat allerdings gewagte Texturen ;D


    Ansonsten:


    http://killerinstinct.ath.cx:2…ulletstorm-Level12_2.html (hier aber ist die 1440er Codierung noch nicht durch, also bitte noch nicht anwählen ^^)


    Normale Flashbasis und alles top daran. Warum soll ich mich mit HTML5 einschränken?


    Und über Flash ist mit jedem Browser [lexicon]H.264[/lexicon] kompatibel, da hier nicht der Browser [lexicon]H.264[/lexicon] decodieren können muss.


    zero latency brauchst du nicht, wenn du schnelle Reaktionszeit willst, kannste etwas kürzere [lexicon]GOP[/lexicon] nehmen. Ich komm aber mit der standardmäßigen recht gut zurecht.


    Die Puffergröße kleiner als die Max [lexicon]Bitrate[/lexicon] zu machen, macht irgendwo auch wenig Sinn. Und ich hoffe du nimmst diese Kombination bei nichts größeres als 720p. 1080p mit nur 2000 kbit wäre etwas mager und macht nicht mal yt so.
    Die Puffergröße würd ich sogar auf 200000 oder so stellen, so das [lexicon]x264[/lexicon] nicht bei der Peak [lexicon]Bitrate[/lexicon] eingeschränkt wird, sondern nur bei der max durchschnittsbitrate - welche die einzige ist die relevant ist. Puffergröße benötigen nur Hardware Player, da diese mit zu großen Puffergrößen auf Probleme stoßen würden.


    Zitat

    Auch MKVMerge fällt dann weg, da ffmpeg das direkt [lexicon]muxen[/lexicon] kann.


    Kann [lexicon]MeGUI[/lexicon] auch. AutoEncode button.


    Zitat

    Das bedeutet dann auch, dass keine unnötigen Dateien auf dem PC entstehen, die man nachher wieder löschen muss.


    [IMG: http://abload.de/img/unbenannt63mik0m.png]


    Einfach mal ein Blick in die Options werfen kann viele Seelsorgen heilen xD

    Zitat von Sagaras

    Dein [lexicon]AVISynth[/lexicon] Sript besteht nur aus AVISource. Sehe ich das richtig? AVISource ohne AssumeFPS. Weißt du warum [lexicon]MeGUI[/lexicon] bei AVISource ein AssumeFPS dahinter macht? ^^ Um die kleine Verschiebung der FPS die mit AVISource eventuell auch mal falsch sein kann zu korrigieren.


    Ich könnte mich jetzt irren. Aber wenn die FPS "korrigiert" werden soll, ist "ChangeFPS" eigentlich besser. Oder?


    Zitat von Sagaras

    Desweiteren frage ich mich wieso du überhaupt [lexicon]AVISynth[/lexicon] verwendest, wenn du eh mit FFMPEG das ganze kodieren tust? Warum machste es dann nicht direkt?
    Die Fake AVI vom [lexicon]DebugMode Frameserver[/lexicon] wird FFMPEG gewiss lesen und verarbeiten können.

    Das dachte ich auch. Bei mir streikte ffmpeg jedoch.


    Zitat von Sagaras

    Des weiteren sehe ich keine Farbraumkonvertierung. Aber der [lexicon]DebugMode Frameserver[/lexicon] gibt kein YV12 aus. Sprich wenn ich mich nicht irre encodierst du in YUY2, wenn das nicht automatisch von FFMPEG geregelt wird.

    Warum den Farbraum ändern? [lexicon]AviSynth[/lexicon] kommt mit den RGB und auch mit YUY2 bestens klar. Nur mischen von Farbräumen mag [lexicon]AviSynth[/lexicon] nicht. Und ffmpeg übernimmt die Farbraumkonvertierung dann automatisch.


    Zitat von Sagaras

    Und wenn du die AVS Datein schon erstellst dann auch korrekt.
    Kein Mensch der mit [lexicon]AVISynth[/lexicon] arbeitet würde AVISourcen ohne AssumeFPS laden.
    Wenn du FFMPEGSource im AVS Skript verwendest oder andere Sourcen, die brauchen kein AssumeFPS unbedingt. Aber AVISource brauch es auf jeden Fall.


    Hier muss ich widersprechen. Ich habe [lexicon]Let's Play[/lexicon] Videos komplett mit [lexicon]AviSynth[/lexicon]+ffmpeg erstellt. Anfangs habe auch ich AssumeFPS verwendet. Das Ergebniss war aber ... suboptimal. AssumeFPS führte oft zu einem asynchronen Audio. "ChangeFPS" wirkte jedoch Wunder.


    Zitat von De-M-oN

    Als wenn MKVMerge nicht in einen [lexicon]webm[/lexicon] [lexicon]Container[/lexicon] speichern kann^^ Das ist nämlich nix weiter als ein [lexicon]MKV[/lexicon] [lexicon]Container[/lexicon] mit anderer Endung. ^^


    Ich habe nie behauptet, dass MKVMerge kein [lexicon]WebM[/lexicon] speichern kann. Aber da ich für gewöhnlich nicht mit MKVMerge arbeite, konnte ich das auch nicht nachsehen.
    Und technisch ist [lexicon]WebM[/lexicon] ein klein wenig anders als [lexicon]MKV[/lexicon]. [lexicon]WebM[/lexicon] ist für [lexicon]MKV[/lexicon], was [lexicon]MP4[/lexicon] für MOV ist. Ein abgespeckter [lexicon]Container[/lexicon] mit weniger Features.


    Zitat von De-M-oN

    Und bereits Firefox unterstützt schonmal kein [lexicon]H.264[/lexicon] bei HTML5. Also müsst ich auf einen anderen ineffizienteren [lexicon]Codec[/lexicon] ausweichen. Warum tust du dir das an?

    Ich lehne mich einfach mal aus dem Fenster indem ich behaupte, dass du nicht auf dem neusten Stand in Sachen HTML5 bist.
    Firefox unterstützt h264+[lexicon]aac[/lexicon] schon seit einigen Versionen. Vorraussetzung ist lediglich, dass der h264 [lexicon]CODEC[/lexicon] auf dem PC installiert ist. Das betrifft standard mäßig alle Windows 7 User. Aber eben nicht nur.


    Zitat von De-M-oN

    http://killerinstinct.ath.cx:2000/LP/ZDW - Macho Tournament/ZDW-Tournament-Alien-vs-IconofSin666.html
    Die erste Map hat allerdings gewagte Texturen ;D


    Ansonsten:


    http://killerinstinct.ath.cx:2…ulletstorm-Level12_2.html (hier aber ist die 1440er Codierung noch nicht durch, also bitte noch nicht anwählen ^^)

    Sorry, aber das würde mein Download-Volumen sowas von sprengen. xD


    Zitat von De-M-oN

    Normale Flashbasis und alles top daran. Warum soll ich mich mit HTML5 einschränken?


    Und über Flash ist mit jedem Browser [lexicon]H.264[/lexicon] kompatibel, da hier nicht der Browser [lexicon]H.264[/lexicon] decodieren können muss.

    Leider falsch. Zumindest der "jeder Browser" Teil. Der Trend lautet "mobiles Internet". Und auf Smartphones und Tablets ist Flash praktisch nicht vorhanden.


    Zitat von De-M-oN

    zero latency brauchst du nicht, wenn du schnelle Reaktionszeit willst, kannste etwas kürzere [lexicon]GOP[/lexicon] nehmen. Ich komm aber mit der standardmäßigen recht gut zurecht.

    Gut. Ich hatte im [lexicon]x264[/lexicon] Guide von ffmpeg einfach gelesen, dass "zerolatency" für Streamen sein soll. Und da [lexicon]YouTube[/lexicon] da regelmäßig meckert ... xD


    Zitat von De-M-oN

    Und ich hoffe du nimmst diese Kombination bei nichts größeres als 720p. 1080p mit nur 2000 kbit wäre etwas mager und macht nicht mal yt so.
    Die Puffergröße würd ich sogar auf 200000 oder so stellen, so das [lexicon]x264[/lexicon] nicht bei der Peak [lexicon]Bitrate[/lexicon] eingeschränkt wird, sondern nur bei der max durchschnittsbitrate - welche die einzige ist die relevant ist. Puffergröße benötigen nur Hardware Player, da diese mit zu großen Puffergrößen auf Probleme stoßen würden.

    Stimmt. Die 2000k waren auch nur ein Test von mir. Ich habe auf dem PC hier kein Video-Material mit dem ich vernünftig testen könnte. Und für den Demo-Clip den ich erstellt habe, würde fast schon 1000l reichen. In der Praxis sollte so ein geringer Wert natürlich nicht genommen werden.
    Was die Buffergröße angeht, habe ich mich wieder einfach auf die ffmpeg-Referenz verlassen. Dort hab ich einfach gelesen, dass die Buffergröße angibt, wie hoch der [lexicon]Encoder[/lexicon] maximal über dem "Max-Wert" gehen darf. Zumindest mit [lexicon]WebM[/lexicon] hat mir das echt Kopfzerbrechen bereitet.


    Zitat von De-M-oN

    Kann [lexicon]MeGUI[/lexicon] auch. AutoEncode button.


    Okay, das ist dann natürlich praktisch.


    Ich behaupte nicht, dass mein Script perfekt ist. Genau genommen habe ich mir das in ein paar Minuten geschrieben, weil ich meist ziemlich faul bin. Alles was über "Datei auf BAT-Script ziehen" hinaus geht, ist mir meist schon zuviel Aufwand. (Kaum zu glauben, dass ich Let's Plays mit [lexicon]AviSynth[/lexicon] gemacht habe...)


    Schöne Grüße. :)

    Zitat von anihex

    Ich könnte mich jetzt irren. Aber wenn die FPS "korrigiert" werden soll, ist "ChangeFPS" eigentlich besser. Oder?


    Nein. AVISource gehört zum DirectSource und diese Input Filter sich nicht 100% akkurat beim einlesen von Daten.
    SagaraS Scriptmaker (GUI)
    Warum meinste mache ich mir die Mühe bei AVISource beim [lexicon]SSM[/lexicon] das ganze mit AssumeFPS zu korrigieren? Was meinste warum [lexicon]MeGUI[/lexicon] sich die Mühe macht es mit AssumeFPS zu korrigieren? ;D
    ChangeFPS kommt bei einen AVISource immer nach einem AssumeFPS


    Bei FFMS2 kann ChangeFPS auch ohne AssumeFPS gleich kommen, da FFMS2 schon akkurat laden tut.


    Zitat von anihex

    Ich könnte mich jetzt irren. Aber wenn die FPS "korrigiert" werden soll, ist "ChangeFPS" eigentlich besser. Oder?


    RGB und YUY2 Material wie vom [lexicon]Frameserver[/lexicon] ausgegeben dauern länger beim Encode. Das wird immer so sein. Wenn der [lexicon]Encoder[/lexicon] bereits vom [lexicon]Frameserver[/lexicon] YV12 Material bekommen würde, wäre der [lexicon]Encoder[/lexicon] schneller.
    Was meinste warum [lexicon]MeGUI[/lexicon] es automatisch zuerst immer in den Skript schreiben möchte? ;D


    Und was meinst du mit mischen von Farbräumen? xD Was willst du da mischen jetzt? YUY2 ist ein 4:2:2 Planer, wärend YV12 ein 4:2:0 Planer ist und RGB sowie YV24 4:4:4 Planer sind.
    Der Unterschied wie das Material behandelt wird liegt im Detail. Bei RGB und YV24 ist die Verarbeitung extrem hoch, da sowohl Luma als auch Chroma beim Encode als gestochen scharf behandelt werden müssen.
    Bei YUY2 muss Luma als gestochen Scharf behandelt werden und Chroma im 2:2 Verhältnis.
    Den schnellsten Encode bekommste jedoch mit YV12.


    Du verlängerst dir selbst den Encode wenn du bereits die ganze Zeit mit YV12 aufnimmst, es in YUY2 konvertierst und es dann in YUY2 [lexicon]encodieren[/lexicon] solltest. Die Datei wird einfach größer dadurch.


    Sollteste dir vllt noch mal genau anschauen diese Problematik.


    Zitat von anihex

    (Kaum zu glauben, dass ich Let's Plays mit [lexicon]AviSynth[/lexicon] gemacht habe...)


    Allein bei diesen Satz sollteste dich mal fragen warum du es in der [lexicon]Batch[/lexicon] verwendest, wenn du [lexicon]AVISynth[/lexicon] an sich meiden möchtest ;D
    Warum denkste das [lexicon]AVISynth[/lexicon] das decodieren kann das Material vom [lexicon]DebugMode Frameserver[/lexicon]?
    Aber sobald du [lexicon]AVISynth[/lexicon] verwendest, sollteste es auch korrekt anwenden und nicht nur lieblos und 0850 nur mit AVISource.
    Wenn du [lexicon]AVISynth[/lexicon] meiden willst, dann lass es halt weg und überleg dir einen anderen Weg. ^^
    Aber so wie jetzt in der [lexicon]Batch[/lexicon], wendeste es A) an und B) wendeste es falsch an.


    Wie gesagt... bau in dein [lexicon]AVISynth[/lexicon] Skript in deiner [lexicon]Batch[/lexicon] wenigstens AssumeFPS mit ein, damit es korrekt ist. Die FPS kannste die vom [lexicon]Quellvideo[/lexicon] nehmen. Entweder automatisch erkennen lassen wie im [lexicon]SSM[/lexicon] oder selbst irgendwie eine Eingabe dafür einbauen.


    Zitat

    rate1 = (Round(Float(clip0.framerate * 1000)) / 1000) / 2
    rate2 = Round(clip0.framerate) / 2
    rate = (rate1 == rate2) ? 1 : 1001
    ratefaktor = (rate == 1001) ? 1000 : 1
    clip1 = (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate)


    Dieser Teil wende ich im [lexicon]SSM[/lexicon] an dafür. Der regelt das für AssumeFPS automatisch.


    Denn 29.970 FPS sollten akkurat mit 30 / 1,001 angegeben werden und 30 FPS z.B. mit 30 / 1
    Ansonsten kann es auch mal vorkommen das AVISource halt auch mal inkorrekte FPS nimmt.



    Zudem verstehe ich auch nicht warum du von [lexicon]AVISynth[/lexicon] dich so distanzieren willst? Es gibt dort Resizer die zig mal besser sind als das Bicubische oder Bilineäre in NLEs wie [lexicon]Sony Vegas[/lexicon]. Gerade Spline16 in Kombination mit ResampleHQ ist ein Segen wegen dem kaum Sichtbaren Ringing und den neutralen Encode. Ist viel besser als das andere was NLEs oft verwenden.


    Dafür das du deine LPs mit [lexicon]AVISynth[/lexicon] mal gemacht haben solltest, haste dich nicht sonderlich mit beschäftigt.


    Und die Idee mit der [lexicon]Batch[/lexicon] hatten schon viele vor dir gehabt. Auch mit FFMPEG. Nur waren da schon welche bei wo es auch gleich via [lexicon]Batch[/lexicon] auf [lexicon]Youtube[/lexicon] hochgeladen wird nach dem Encode. Auch das [lexicon]AVISynth[/lexicon] dort richtig angewandt wurde bereits. Deswegen sage ich das deine [lexicon]Batch[/lexicon] keine Neuheit in diesem Forum darstellt und auch sonst nix besonderes ist. Weil es halt schon vor dir welche gab die da schon bessere Sachen präsentiert haben.


    Zudem ist es einfach so das [lexicon]MeGUI[/lexicon] durch seine schon eingebaute Jobliste und dem AutoEncode viel besser ist als eine [lexicon]Batch[/lexicon]. Da kann man gleich mehrere Sachen nacheinander hinweg reinschmeißen und ohne dabei zu sein [lexicon]encodieren[/lexicon] lassen.
    In deiner [lexicon]Batch[/lexicon] müsste alles einzeln gemacht werden. Unpraktisch an sich.


    Dazu auch noch das es viele User noch gibt die vllt noch was anderes machen wollen damit. So zwingst du ihnen aber etwas regelrecht auf.


    Ich hatte vor dem [lexicon]SSM[/lexicon] auch eine Batchdatei gehabt dafür. Nur war es so das jeder es anders haben wollte. Zum einen wollten welche die FPS ändern lassen, die anderen wollten wieder das es gleich encodiert wurde. Dann gab es wieder welche die sagten das das mit der [lexicon]Batch[/lexicon] zu unübersichtlich ist und wollten lieber eine [lexicon]GUI[/lexicon] dafür.
    Auch war es für viele ein Fail den [lexicon]Encoder[/lexicon] jedesmal in der [lexicon]Batch[/lexicon] umzustellen mit Parametern die sie so nicht verstanden.


    Dann habe ich mich entschlossen den [lexicon]Encoder[/lexicon] wegfallen zu lassen und lieber ein reinen Skriptmaker zu entwickeln. Entstanden aus einer [lexicon]Batch[/lexicon] man glaube es kaum xD Somit hatte nun jeder eine [lexicon]GUI[/lexicon] für die Skripte und [lexicon]MeGUI[/lexicon] für die Jobliste und Encodersettings.


    Vorteil am [lexicon]SSM[/lexicon] ist das es mit weiteren Plugins schon ausgestattet wurde die jeder selbst festlegen kann. Und in [lexicon]MeGUI[/lexicon] dank AutoEncode und Jobliste + das man den [lexicon]Encoder[/lexicon] schön über eine [lexicon]GUI[/lexicon] einstellen kann sehr übersichtlich.


    Bei einer Batchdatei muss es für jeden User individual gestaltet werden, da jeder User anders kodieren möchte. Bedeutet aber auch das er sich mit den [lexicon]CLI[/lexicon] Einstellungen erst befassen muss. Und das wollen viele einfach nicht. Genausowenig wie viele oftmals kein [lexicon]AVISynth[/lexicon] Skript schreiben wollen.


    Daher... wenn du was machst, mach es so, das es zum einen Korrekt ist und zum anderen das jeder die Freiheiten hat selbst zu bestimmen.


    Seh es bitte als Tipps an um deine jetzige [lexicon]Batch[/lexicon] besser zu machen. Ansonsten sieht es ja so gut aus. Nur halt das du es weiter optimieren müsstest.

    Erstmal vorab:

    Zitat von Sagaras

    Seh es bitte als Tipps an um deine jetzige [lexicon]Batch[/lexicon] besser zu machen. Ansonsten sieht es ja so gut aus. Nur halt das du es weiter optimieren müsstest.

    ich habe mich nie angegriffen gefühlt und wollte auch nie jemanden angreifen. ;)


    Zitat von Sagaras

    RGB und YUY2 Material wie vom [lexicon]Frameserver[/lexicon] ausgegeben dauern länger beim Encode. Das wird immer so sein. Wenn der [lexicon]Encoder[/lexicon] bereits vom [lexicon]Frameserver[/lexicon] YV12 Material bekommen würde, wäre der [lexicon]Encoder[/lexicon] schneller.
    Was meinste warum [lexicon]MeGUI[/lexicon] es automatisch zuerst immer in den Skript schreiben möchte? ;D

    Gut zu wissen. Das wusste ich nicht. Aber macht es wirklich einen Unterschied ob der [lexicon]Frameserver[/lexicon] oder der [lexicon]Encoder[/lexicon] den Farbraum ändert?


    Zitat von Sagaras

    Und was meinst du mit mischen von Farbräumen? xD Was willst du da mischen jetzt? YUY2 ist ein 4:2:2 Planer, wärend YV12 ein 4:2:0 Planer ist und RGB sowie YV24 4:4:4 Planer sind.


    Ich will gar nichts mischen. In meinen Let's Plays hatte ich jedoch 2 Videos die mit unterschiedlichen Farbräumen kodiert waren. Es handelt sich dabei um ein [lexicon]Let's Play[/lexicon] "Together" wo wir das Video-Material meines Kumpels YV24 und mein eigenes RGB war. [lexicon]AviSynth[/lexicon] mochte das nicht und meinte, ich solle den Farbraum bitte anpassen.



    Ich glaub hier liegt ein Missverständnis vor. Ich liebe [lexicon]AviSynth[/lexicon] und ffmpeg. Da programmieren mein Hobby ist und [lexicon]AviSynth[/lexicon] ziemlich mächtig ist, ist es immer interessant mit AvinSyth zu hantieren. Leider hat [lexicon]AviSynth[/lexicon] auch Nachteile. Und diese Nachteile sind für mich der Hauptgrund, warum ich zu einem [lexicon]NLE[/lexicon] wie Sony Movie Studio wechseln möchte. Aber das geht eher in den "Basic Compositing" Bereich.


    Zitat von Sagaras

    Zudem verstehe ich auch nicht warum du von [lexicon]AVISynth[/lexicon] dich so distanzieren willst? Es gibt dort Resizer die zig mal besser sind als das Bicubische oder Bilineäre in NLEs wie [lexicon]Sony Vegas[/lexicon]. Gerade Spline16 in Kombination mit ResampleHQ ist ein Segen wegen dem kaum Sichtbaren Ringing und den neutralen Encode. Ist viel besser als das andere was NLEs oft verwenden.

    Ich stimme dir voll und ganz zu. Ich habe in einem anderen Forum die Aussage eines Film-Profis gelesen. Und was der schrieb, ist schon überzeugend genug. Ich brauche für gewöhnlich nur keine Resizes. Und wenn ich das doch brauche, wende ich mich an [lexicon]AviSynth[/lexicon].
    Der Vollständigkeit halber versuche ich den Author im anderem Forum zu zitieren:

    Zitat

    Wenn Qualität wichtiger ist als Geschwindigkeit, ist [lexicon]AviSynth[/lexicon] die richtige Wahl.


    Zitat von Sagaras

    Dafür das du deine LPs mit [lexicon]AVISynth[/lexicon] mal gemacht haben solltest, haste dich nicht sonderlich mit beschäftigt.

    Ich fürchte, hier kommt meine alte "Angewohnheit" zu Tage. :rolleyes:
    Sprich: "Ich kann schon mehrere Programmiersprachen. Ich muss es nicht richtig lernen, ich muss nur wissen was die Aufgabe erfüllt."
    Schlechte Angewohnheiten sind manchmal schwer abzulegen...


    Zitat von Sagaras

    Und die Idee mit der [lexicon]Batch[/lexicon] hatten schon viele vor dir gehabt. Auch mit FFMPEG. Nur waren da schon welche bei wo es auch gleich via [lexicon]Batch[/lexicon] auf [lexicon]Youtube[/lexicon] hochgeladen wird nach dem Encode. Auch das [lexicon]AVISynth[/lexicon] dort richtig angewandt wurde bereits.

    Klingt cool. Zumal ich nichtmal wusste das man per [lexicon]Batch[/lexicon] auch hochladen kann. So ein Skript würde ich echt gerne sehen.


    Zitat von Sagaras

    Zudem ist es einfach so das [lexicon]MeGUI[/lexicon] durch seine schon eingebaute Jobliste und dem AutoEncode viel besser ist als eine [lexicon]Batch[/lexicon]. Da kann man gleich mehrere Sachen nacheinander hinweg reinschmeißen und ohne dabei zu sein [lexicon]encodieren[/lexicon] lassen.
    In deiner [lexicon]Batch[/lexicon] müsste alles einzeln gemacht werden. Unpraktisch an sich.

    Ich denke, ich bin dann wohl der Einzige der immer nur ein Video encoden muss. ^^"


    Zitat von Sagaras

    Bei einer Batchdatei muss es für jeden User individual gestaltet werden, da jeder User anders kodieren möchte. Bedeutet aber auch das er sich mit den [lexicon]CLI[/lexicon] Einstellungen erst befassen muss. Und das wollen viele einfach nicht. Genausowenig wie viele oftmals kein [lexicon]AVISynth[/lexicon] Skript schreiben wollen.

    Stimmt. Mein Kumpel hasst es auch, die [lexicon]CLI[/lexicon] zu verwenden. Für unsere Let's Plays hatten wir daher [lexicon]Batch[/lexicon]-Dateien, die uns ermöglichten, die Videos per USB-Stick mitzunehmen. Später dann eine [lexicon]Batch[/lexicon]-Datei für ihn, damit er einen geringeren Upload hat (Sonys [lexicon]Encoder[/lexicon] ist echt nicht so toll...). Da er jetzt aber [lexicon]MeGUI[/lexicon] und den Debug [lexicon]Frameserver[/lexicon] verwendet, ist das überflüssig. Und die Ergebnisse, die er damit erzielt - wenn auch ein Preset von jemand anderem - sind wesentlich beeindruckender als das was ich so zusammen gebastelt habe.


    Ich habe mein Skript auch nur gepostet, weil es vielleicht jemandem nützen könnte.

    Zitat von anihex

    Ich poste hier mal das von mir verwendete Script. Vielleicht nützt es ja jemandem.


    Danke für euer Feedback und schöne Grüße. :)

    Zitat von anihex

    In meinen Let's Plays hatte ich jedoch 2 Videos die mit unterschiedlichen Farbräumen kodiert waren. Es handelt sich dabei um ein [lexicon]Let's Play[/lexicon] "Together" wo wir das Video-Material meines Kumpels YV24 und mein eigenes RGB war. [lexicon]AviSynth[/lexicon] mochte das nicht und meinte, ich solle den Farbraum bitte anpassen.


    Korrekt. RGB ist zwars YV24 sehr identisch von der Abtastrate des Farbraums. Jedoch ist das eine YUV und das andere nun mal RGB. Diese beiden Farbräume sind allein vom Aufbau schon unterschiedlich. Einige [lexicon]AVISynth[/lexicon] Filter können nur mit YUV Farbräumen etwas anfangen, wärend andere unbedingt RGB brauchen. Zu wissen wann man was braucht und wie man effizient einsetzt ist entscheident dabei.
    Ein Video im RGB Bereich kann den Filter Tweak z.B. nicht nutzen, da Tweak ausschließlich für YUV Farräume bestimmt ist.



    [lexicon]AVISynth[/lexicon] Videobearbeitung ist absolut Linear und daher bei vielen recht schwer nachzuvollziehen. Weil die meisten Leute kennen und wollen auch oft nur Nicht Lineare Videobearbeitung durchführen. Weil es halt einfacher für viele auch ist. Aber wer die Lineare Beareitung beherscht würde daraus die tollsten Sachen entwickeln können. ^^

    Zitat von anihex

    Und technisch ist [lexicon]WebM[/lexicon] ein klein wenig anders als [lexicon]MKV[/lexicon]. [lexicon]WebM[/lexicon] ist für [lexicon]MKV[/lexicon], was [lexicon]MP4[/lexicon] für MOV ist. Ein abgespeckter [lexicon]Container[/lexicon] mit weniger Features.


    [lexicon]webm[/lexicon] kann man die Endung einfach umbenennen in [lexicon]mkv[/lexicon]. Und sogar mkvmerge muxt in [lexicon]webm[/lexicon] wenn gewünscht. [lexicon]MP4[/lexicon] und MOV kann man nicht einfach in mov oder [lexicon]mp4[/lexicon] umbenennen, wenn mich mein Gehirn jetzt um halb 4 morgens nicht verlassen hat ^^
    Und darum schrieb ich ja auch:


    Zitat

    Das Video muss für [lexicon]webm[/lexicon] bloß ein paar Anforderungen erfüllen


    Zitat

    Ich lehne mich einfach mal aus dem Fenster indem ich behaupte, dass du nicht auf dem neusten Stand in Sachen HTML5 bist.
    Firefox unterstützt h264+[lexicon]aac[/lexicon] schon seit einigen Versionen. Vorraussetzung ist lediglich, dass der h264 [lexicon]CODEC[/lexicon] auf dem PC installiert ist. Das betrifft standard mäßig alle Windows 7 User. Aber eben nicht nur.


    hmm ich traue das meinem FF nach wie vor nicht zu und ich hab win7. Kanns ja nochmal prüfen, aber ich trau dem das immer noch nicht zu zu können. Aber Smartphones sind für mich auch kein Argument mich den Beschränkungen von HTML5 zu unterwerfen. Wer auf einem derart kleinen Display Videos gucken will, braucht auch meine externen Videos nicht, da reicht sogar der Schrottencode von [lexicon]youtube[/lexicon] dann aus.


    Zitat

    Sorry, aber das würde mein Download-Volumen sowas von sprengen. xD


    Naja die 1080/1200 sollte eig. laufen. Notfalls vorpuffern lassen :D

    Hallo. Mein Problem ist sicher hier irgendwo in diesem Thema schon gelöst worden habe es aber auf die schnelle nicht gefunden.
    Und zwar: Ich habe ab und zu Runtime Errors von x.264 [lexicon]Encoder[/lexicon] wenn [lexicon]MeGUI[/lexicon] encodiert (logisch ohne brauch man den [lexicon]encoder[/lexicon] ja nicht :-D)
    Aber halt nicht am Anfang des Encodierens sindern meisten so bei rund 60-70% was natürlich dann doppelt ärgerlich ist.


    Gibs da nen Anhaltspunkt woran das liegen kann?

    Die Sourcenmenge und die Zielauflösung, die verwendete Menge weiterer Filter etc.


    3200x1800 muss mit 2 Threads laufen. Wenn zu viele Sourcen kann aber auch das die 4GB RAM Grenze einer 32 Bit Anwendung sprengen ( avs4x264mod.exe )

    Also MT ist so eingestellt:
    Sourcen: Mode 3 Threads 2
    Tweak: Mode 3
    MemoryMax: 512


    Und als Filter habe ich BB, MB, RHQ und Chroma. Da sind die Einstellungen so wie bei dir im Video ausser dass ich bei MB nur 10 eingestellt habe statt 15, da es sonst zu lange [lexicon]rendern[/lexicon] bei mir.


    Ach ja Zielauflösung ist 1800p

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden