Beiträge von Dispatcher7007

    Hey Selur, vielen Dank für die Idee!

    hab mplayer bisher nie über die commandline angesprochen.

    Auch wenn ich deine flags nicht ganz verstehe (was bedeuten die "+" zeichen? ; -noskip gab nen fehler ; aus einer Befehlssammlung hab ich -vo null...) hast du mich auf die richtige Idee gebracht.

    mplayer test.avs -nosound -vo null -speed 20
    funktioniert, und erzeugt etwa 10x Tempo mit ~240fps... damit kann ich arbeiten, schneller wirds wohl nicht mehr, denn die cpu ist fast ausgelastet^^

    Grüße, und nochmals Danke!

    Die Auswertung der Zahlenreihen aus der Logdatei funktioniert nun zuverlässig.

    Was nicht klappt, ist das Erstellen der Logdatei in mehr als Echtzeit. Nur wenn ich das Skript per player abspiele, ergibt sich eine saubere Logdatei, die bei Frame 0 anfängt, und ohne unterbrechung bis zum letzten Frame durchgeht, wie es sein soll.

    Wenn ich aber z.B. per VDub die Video Analysis laufen lasse, wie selur vorschlug, dann ist die Logdatei seltsam zerstückelt. So werden z.B, die Frames 2, 12, 162, 197, 226, ... überprüft, was ja für mein Anliegen völlig ungeeignet ist.
    Das gleiche Phänomen, wenn auch anders zerstückelt, tritt auf, wenn ich einen x264 --pass 1 laufen lasse. von xvid hab ich keine Ahnung, aber es sollte ähnlich sein.

    Kann sich da jemand einen reim drauf machen, und hat ne Idee?

    Hallo zusammen,

    ich hab jetzt LigHs Vorschlag aus dem 2. Beitrag dieses Threads einmal ausprobiert, und der funktioniert so wie er soll. Danach werden die einzelbilder mit ihrem Nachfolger per compare(a,b, "logfile.log") verglichen, und die Abweichung in einem Wert gemessen.

    Kann man diese Analyse auch laufen lassen, ohne den Videostream durchlaufen zu lassen? (damit es halt schneller läuft)

    Die auftretenden Bildfehler treten deutlich als 2 aufeinanderfolgende peaks (Wert ca 50) aus dem Grundrauschen (zwischen 1 und 12) zu Tage, ebenso wie jeder Filmschnitt mit nur einem Peak. Damit ist das Entscheidungskriterium gefunden, um das automatisch auswerten zu lassen, da es jetzt ziemlich nervig ist, eine txt mit 250.000 Zeilen durchzusuchen, ob da irgendwo 2 "hohe" Werte hintereinander auftauchen.

    Kennt jemand eine einfache Methode, das automatisch auszuwerten?

    Mir schwebt jetzt grob ein Weg vor, der über Matlab läuft, und den gleitenden Durchschnitt über 2 Elemente mit dem Durchschnitt der z.B. 100 benachbarten Frames vergleicht, und bei einer abweichung von mehr als einem Schwellenwert (noch zu entscheiden), die entsprechende laufende Nummer ausspuckt... In Matlab würde ich das wohl hinbekommen. Das ist einer der Momente, indem ich mir wünschte, ich hätte mal etwas mehr programmiert... vllt. grabe ich nochmal meine rudimentären c++-kenntnisse aus^^ Damit wär es wahrscheinlich viel simpler.

    Vorschläge willkommen!

    Grüße, Dis

    @ ffmpeg "-strict experimental"
    Das Ergebnis ist wirklich objektiv und offensichtlich schlecht. So wie ich das verstanden hab, wurde das als "low anchor" für die Interpretation der Wertungen genutzt. Wer den low anchor nicht deutlich abgewertet hat, disqualifiziert damit die gesamte Bewertung, weil er hat offensichtlich die Ohren nicht aufgemacht.

    @Stereo und Mono:
    Ich hörte, das es Probleme beim Channel-Mapping gibt, sobald es mehr als 2 Kanäle gibt. Ich hab testweise eine 5.1-dts per foobar2k recodiert, und dort waren die Kanäle nachher in Ordnung. (--ignorelength als Zusatz notwendig, sonst gabs abstürze)

    Ab hier
    hab ich das mal beschrieben, aber auf das dort (wie hier) gepostete fb2k Spektrogramm hat noch niemand geantwortet.

    Links ist der Teil von der original dts, ab dem Bruch in der Mitte ists der gleiche ausschnitte als qtaac-Ergebnis. So wie ich das sehe, ist alles da, wo es sein soll.
    [Blockierte Grafik: http://img193.imageshack.us/img193/6370/dtsvsqtaaspectrogram.png]

    Es gibt auch noch ein alternativprodukt (was im Wesentlichen das gleiche macht wie qtaacenc.exe), das nennt sich qaac.exe. Das erlaubt in der brandaktuellen Version eine manuelle Reihenfolgen-Vorgabe der Kanäle. Im Moment sehe ich die Notwendigkeit davon aber nicht... etwas verwirrend.

    naja, "mies" ist halt relativ. Ich war damit immer zufrieden, weil er eben nicht objektiv "mies" ist, auch wenn ich ihm mit 150kbps doch etwas mehr bitrate zugestehe. Allerdings ist auch die aktuelle Version 1.5.4.0 auch schon 1,5Jahre alt, und die Entwicklungen laufen ja weiter, und anscheinend gibts mittlerweile besseres, was Qualität/Bitrate angeht.

    Solche Doppelblindtests mit 280 Proben sind schon ziemlich verlässliche Aussagen, vor allem, weil die Ergebnisse auch nach Plausibilität gefiltert werden. Wer z.B. 3x die Referenz abgewertet hat, dessen Ergebnisse werden komplett ignoriert. Mit sowas werden "geratene" Ergebnisse schon recht effektiv unterdrückt, also scheint es ja objektiv auch einen Unterschied zu geben (96kbps ist ja auch eine Herausforderung für die Codecs)

    Ich hab eine Aufnahme von Bachs "Toccata und Fuge in d-moll", als 96kHz/24bit lossless Aufzeichnung, die auch in dieser Qualität aufgezeichnet wurde. Das ist einer meiner persönlicher Referenzpunkte, woran sich schnell die Spreu vom Weizen trennt. Hier in diesem Vergleich fand ich es besonders schwer, weil die meisten dieser 20 Testsequenzen schon synthetisch erzeugte Musik war. Das fand ich extrem schwierig. Orgel- oder Orchestermusik ist klanglich wesentlich komplexer, und daher finde ichs dabei einfacher schlechte Encodes zu entlarven.

    http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/index.htm

    Ich denke, es wird den einen oder anderen interessieren, denn es sind recht interessante Ergebnisse herausgekommen (z.B. Neroaacenc.exe als der schlechteste im Test)

    Ich hab daran teilgenommen, und war verblüfft, wie gut sich diese Codecs bei diesen niedrigen Bitraten (96kbps waren angepeilt) dargestellt haben. Ich konnte oft keinen Unterschied zwischen den ernsthaften Teilnehmern des Vergleichs feststellen, und meistens nur minimale, in keiner Weise störende Einflüsse.

    Vor allem überrascht mich das, weil ich vor über 10 Jahren schonmal bei so einem Vergleichstest mitgemacht habe, wo es um verschiedene mp3-Bitraten ging, und ich die damals bis VBR~160kbps ziemlich zuverlässig (>80%, fast 100% bei 128kbps) gefunden habe, und jetzt bei 96kbps nur ziemlich wenig dran auszusetzen hatte, wenn auch damals mit besserem Equipment. Entweder sind die Codecs außerordentlich gut geworden, oder meine Ohren dümmer^^ Wahrscheinlich beides ;)

    Ich hab noch was gefunden:
    MVTools2 in der ST64bit-Fassung ist zwar schneller als in der ST32bit-Fassung, aber in der jeweiligen MT-Variante ist die 32bit bei mir wiederum 30% SCHNELLER als die 64bit-Variante. Das MT in der 64bit-Fassung von Avisynth scheint noch nicht rund zu laufen.

    /edit: vergesst den Rest, den ich einst schrieb... ich hab was übersehen!

    Hi,

    Ich teste grade avisynth64 mit der MVTools2 64bit-fassung. Vom Tempo her bin ich begeistert! Ca. 30% Geschwindigkeitsgewinn, wenn ich nur MDegrain3 verwende und Abstürze hatte ich bisher auch noch (toitoitoi) keine.

    Jetzt kommt ein Wermutstropfen. Wenn ich nach der Rauschfilterung leicht nachschärfen möchte (fft3dgpu(... , bt=-1 = sharpen only)), dann kommt folgende Fehlermeldung, auch wenn ich jegliches SetMTMode aus dem Script lasse (also singlethreaded arbeite, oder?):

    Code
    E:\Datendrehscheibe\Verarbeiten>x264-64.exe --preset slow --tune film --crf 18.0
     --ref 8 --bframes 8 --output "output.mkv" "source.avs"
    avs [info]: 1920x800p 0:0 @ 2997/125 fps (cfr)
    x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
    x264 [info]: profile High, level 5.0
    x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
    x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
    x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
    x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
    x264 [warning]: 996 suppressed nonmonotonic pts warnings0:00

    Woran liegt das? Was kann man dagegen tun? Das Ergebnis sieht auf den ersten Blick in Ordnung aus!

    /edit: Wenn ich NUR fft3dgpu benutze, passiert das nicht, sondern nur, wenn vorher MDegrain läuft... Wie gesagt, alles Singlethreaded (da ohne SetMTMode(irgendwas))

    mysteriös... ist das normal, das es unter 32bit MT so klappt, aber unter 64bit nicht? Würde doch sagen, wenn diese Probleme auftauchen, dann bei beiden varianten, oder?

    @fft3dfilter: Ich möchte so viel cpu wie möglich für den encode nutzen, und fft3dfilter ist nunmal cpuintensiv, daher entfällt das. Hier wird das ding auch nur zum nachschärfen nach der aufwändigen Rauschfilterung genommen.

    Wie siehts bei 64bit mit piping aus? Notwendig?

    Klar, der fehler ist nicht groß, aber ich ärgere mich über sowas... sonst wahrscheinlich keiner... aber ohne eine latente Grund-Unzufriedenheit wird man ja auch nicht permanent besser^^

    Zitat

    Und wenn Du dann weißt, dass im fertigen Encode der Frame Nr. 124678 fehlerhaft ist, dann machst Du ... was ?

    Ich mach nur avc(x264) in mkv.
    Dann schneide ich mit mkvmerge das betroffene stück raus, füge in die source.avs ein passendes "trim(x,y)" an, mache den Teil neu, und setze die Soße am Ende wieder zusammen. Funktioniert prima, wenn mkvmerge halt syst*****ingt auch nicht beliebig schneiden kann, sondern nur an IDR-Frames. Das macht es aber offensichtlich richtig, denn es gibt keine Bildfehler.

    @piping:
    mach ich im moment notgedrungen wei ich das avisynth64 noch nicht ans Laufen brachte, mit Lord Mulders x64-gui. Das ist zwar etwas off-topic, aber wenn ich das gleiche Script von avisynth32 mit avisynth64 bearbeite, dann messe ich Geschwindigkeit in sekunden pro frame ;) Grund noch nicht rausgefunden. Ich hab aber 8gig ram, muss ich da immer noch pipen?

    Das Skript sieht so aus: (mit trim beispiel)

    Code
    SetMTMode(5)FFVideoSource("video.mkv")AssumeFPS(23.976)ConvertToYV12()Crop(0,138,0,-142)SetMTMode(2)super = MSuper(pel=1, sharp=1)  backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4, blksize=16, truemotion=false)  backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4, blksize=16, truemotion=false)  backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4, blksize=16, truemotion=false)  forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4, blksize=16, truemotion=false)  forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4, blksize=16, truemotion=false)  forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4, blksize=16, truemotion=false)  MDegrain3(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD = 400)fft3dgpu(beta=1, sigma=0, plane=4, bt=-1, mode=1, sharpen=0.5, precision=2, bw=64, bh=64, degrid=1, wintype=1)#trim(114463,-1076)


    x264 aufruf ist:

    Code
    x264-x64.exe --preset slow --tune film --crf 18.0 --ref 8 --bframes 8 --output "output.mkv" "source.avs"

    LigH:
    Danke! Wird demächst getestet, Update kommt!

    Hin und wieder schleichen sich bei mir Bildfehler während des encodes ein. Die sind nicht reproduzierbar, und rühren meist daher, das der Rechner grade irgendwo mal für ein paar Sekunden "hängenbleibt". An der Stelle, wo der encode grade dran ist, ist dann oft (gefühlt 50%) ein Bildfehler, der mich natürlich stört.

    Mit nur 2gig Ram passierte das quasi immer, wenn der physische ram zu klein wurde, das problem hat sich jetzt mit 8gig erledigt, aber es ist immer noch nicht ganz weg.

    2 Fehlerarten sind konnte ich ausmachen:
    1) Es schleicht sich ein Frame (oder auch nur Teile eines Frames) ein, der da gar nicht hingehört. Wenn es nur ein Teil eines Frames ist, ist der seltsam mit dem original überlagert.
    2) Manchmal ist zwar alles in der richtigen Reihenfolge, aber Teile eines frames (oder auch ganze Frames) haben einen seltsamen Grün- oder Rotstich.

    Ich benutze jeweils aktuelle versionen von
    ffvideosource
    Mdegrain
    fft3dgpu
    removegrain

    Der Fehler trat bei diversen avisynth-versionen auf, auch den offiziellen Builds, dennoch vermute ich den Fehler bei der Avisynth-bearbeitung, denn wenn ich mal einfach eine .mkv an x264 verfüttert hab, habe ich den fehler noch nicht gesehen. Jedoch hab ich das nicht sooo oft gemacht, um da wirklich sicher zu sein. Der Fehler ist ja leider nicht provozierbar, sondern tritt auf, oder eben nicht...

    Bisher schreib ich mir immer die Framenummer auf, wo der grade ungefähr dran war, und schau es mir nachher aufmerksam an, und wenn da was nicht stimmt, wird der Teil repariert. Dabei kann einem aber mal was durch die lappen gehen, was mich dann bei einem Videoabend ziemlich fuchsen würde...

    Gibt es eine Möglichkeit diese Suche nach Bildfehlern zu automatisieren? Irgendein tool, was nach "ungereimtheiten" im Stream sucht? Es geht immer nur um 1 Frame, was sich DEUTLICH von allen anderen Unterscheidet, daher sollte das THEORETISCH algorithmisch auffindbar sein. Hat jemand schonmal sowas gesehen?

    Ja das Ergebnis find ich auch gut, aber es lohnt sich durchaus mal ein etwas dranzusetzen, das ding auf der gpu auszuführen. danach kannst du nämlich immer noch ein paar kleinigkeiten in avisynth packen, ohne das dich das single-threaded-dasein ausbremsen könnte. Vor allem kannst du dann Einstellung fahren, wo man sonst die frames mitzählen konnte.

    fft3dgpu.dll und fft3dgpu.hlsl ins avisynth-plugin-verzeichnis kopieren und directx installieren, oder, wie Goldwingfahrer das schon schrieb, das manuell machen.

    Hier stehts nochmal: Link Achtung: letzte version ist glaub ich V0.8.2

    Ich hab da ja schon oft Probleme mit, Zeug ans laufen zu bekommen, aber das hab selbst ich Dussel hinbekommen :)

    PS: Wenn du auf Qualität stehst, und dir Zeit nicht so wichtig ist (hey, du benutzt fft3dfilter^^), schau mal nach der MDegrainX (X=1,2 oder 3) aus der MVTools2-Bibliothek. Das kann noch ein bischen mehr, als fft3dfilter, auch wenn das noch recht neu für mich ist. Spätestens bei MDegrain3 wirst du aber wieder dasselbe Singlethreaded Problem haben...

    Diskordier:

    Die schrubst was von "fftw3.dll" - daraus schließe ich, das du fft3dfilter verwenden willst, was bekanntlich ziemlich langsam ist, und damit als ST-Version den Encode ausbremsen kann.

    Hast du mal über fft3dgpu nachgedacht? Ist einer meiner Lieblingsfilter, besonders, wenns mal schnell gehen soll. Wenn deine Graka für deine gewünschten Einstellungen genug Ram hat, wirst du damit die Engstelle ohne das Glücksspiel mit MT los... Ich hab am WE mal ein paar 32bit vs 64bit tests gemacht, und die Unterschiede waren marginal, manchmal war 32bit sogar schneller. Wenn Plugins besonders auf die neuen Möglichkeiten mit 64bit optimiert wurden, dann soll das was bringen. Ich hörte MVTools2 soll als optimierte 64bit-version existieren.

    Das werde ich demnächst mal testen!

    grüße!

    Vielen Dank an alle Beteiligten, das klappt!

    Sorry, wenn es einige genervt zu haben scheint. Die boardeigene Sufu sowie google hab ich ausgiebig genutzt, allerdings konnte ich den richtigen Hinweis ) nicht finden!

    Zitat

    Als Mausschubser entsprechend die Fenster- (GUI-) Version im Debug-Menü in den "erweiterten Modus" stellen.

    Schuldig im Sinne der Anklage^^

    Grüße!

    jaja.. selbst der Tod kostet das Leben^^

    Also mit blksize=16 sind sowohl overlap=4 als auch overlap=8 ohne dieses Artefakt! Hier würde ich overlap4 wählen, aus Tempogründen, oder? /edit: overlap=0 macht auch keine Probleme. Der Unterschied ist selbst bei standbildern winzig!

    Bei blksize=32 bringt auch overlap=16 nix. bei Overlap=24 kommt totaler Käse raus. Dazu ist das laaaaaangsam und produziert enorm hohe bitraten... Okay, wenn jedes Pixel 3x bearbeitet wird, und sich die einzelnen Bearbeitungen intern vielleicht noch gegenseitig vors Knie treten, kann das wohl nix bringen. for educational purposes...

    Ebenso:

    Zitat

    da braucht man "bessere" Bewegungssuche um's besser einfangen zu können


    würde es etwas bringen, die Bewegungssuche auf (sagen wir mal) umh laufen zu lassen, statt der standardmäßigen Hex-suche? /edit: habs getestet: Nope! blksize=32 ist anscheinend verbugt.

    Würde vllt, die von dir in einem anderen Thread angesprochene Bewegungssuche mit einem vorgefilterten Bild etwas bringen?

    Übrigens:
    Dir und noch einigen Anderen möchte ich hier mal ganz laut DANKE! sagen... Ohne dich und euch wäre ich schon öfters aufgeschmissen gewesen, und hätte ganz viel nicht gelernt auf diesem Gebiet, auch wenn ich noch immer weit am Anfang stehe.

    Hallo zusammen,

    Das sollte mein erster großer Einsatz von MDegrainX (nochmal vielen Dank an Didée für diesen Tip!) werden, und ich war auch zunächst ziemlich begeistert, bis ich beim sichten des Materials folgende Artefakte fand:
    Link (1MB @Mediafire)
    Achtet auf die Lanzenspitze des Reiters in der Bildmitte.

    Bei der benutzung von MDegrain3 gibts halt 3 Echos in beide Richtungen, und bei MDegrain1 halt nur eins.

    Das erzeugende Script sieht so aus...

    Ist was an meinen Einstellungen falsch oder passiert sowas halt mit Mdegrain? (wäre schade, das denoisen ist phantastisch!)

    /edit: Der Fehler kommt nicht von der Quelle!
    Grüße,
    Dis

    /edit2 Link korrigiert

    Hallo,

    ich bin zwar sicherlich kein Avisynth-Spezialist, aber ich will auf diesem Gebiet auch noch was lernen, daher versuch ichs einfach mal!

    Ich bin mir nicht sicher, was du willst... bist du sicher das du 25i = 25 Halbbilder pro sekunde = 12,5 ganze bilder pro Sekunde haben willst?

    Könnte so aussehen (keine Gewähr!):

    Code
    LoadPlugin("Path\to\ffms2.dll") #soll ein besserer quellfilter sein, als Directshowsource... wirklich verstanden hab ich das nicht...FFVideoSource("video") # hier: 50pAssumeFrameBased()SeparateFields() #hier: 100iSelectEvery(4,0) #jetzt: 25i - für 50i: (2,0)Weave()


    wird aber arg holprig aussehen...


    Jetzt werden aber immer nur die oberen Felder genommen. Es wäre sicherlich im Output schöner, wenn man das obere Feld des ersten Bilds mit dem unteren Feld des (über)nächsten Frames verweben würde. Ich weiß aber nicht, wie das geht.

    /edit: das müsste es leisten!

    Code
    AssumeFrameBased()
    SeparateFields()
    SelectEvery(8,0,5)
    Weave()

    Wofür möchtest du das denn verwenden? Ist ziemliche Datenvernichtung!

    Grüße
    Dis

    Hallo!

    Und noch ne Frage: Gibts ne einfache Möglichkeit, die Anzahl der Frames in einer mkv auszulesen?

    Der Encoderprozess ist bei mir etwas instabil (vermute thermische Probleme wegen Übertaktung). Daher wird die entstandene Datei nach einem Absturz hinten sauber zu beschnitten (mit mmg), und der encoding-prozess mit einem angehängten "trim(xxx,0)" in der .avs fortgesetzt.

    Dafür muss ich aber diese Frameanzahl auch genau kennen, und dafür habe ich bisher nur 2 umständliche Methoden.
    1) import.avs für VirtualDubMod erstellen (was mich danach für eine Minute in die Warteschleife schick fürs indizieren, NERVIG!), und mir anschließend per "File >> Save Image Sequence" anzeigen zu lassen, wie viele Bilder er mir erstellen würde.
    2) Das ganze in Matlab importieren, und dort anzeigen lassen. Matlab mit unzähligen zusatzpaketen zu starten geht auch nicht schneller...

    Beides irgendwie "von hinten durch den Rücken ins Auge"... Das muss doch leichter gehen... Media Info tut mir leider nicht den gefallen...

    Womit würdet ihr das machen?
    Grüße! Dis