Beiträge von De-M-oN

Zitat

Ich bezweifle allerdings stark, dass Decoder-Unterstützung für das Profil High422 weit verbreitet ist, insbesondere unter Consumer-Playern. Die typischen Blu-ray-und-mehr-Player-kompatiblen Profile Main und High verwenden intern jedenfalls YUV 4:2:0.

Da es sowieso kein Hardware Player jemals zu Gesicht bekommen wird, ist mir das reichlich egal, was die unterstützen

avs4x264mod.exe kommt scheinbar tatsächlich mit einem angefügten

ConvertToYV16 zurecht.

YUY2 konvertier zu YV16 dürfte ja eig. auch kein Einfluss auf die Qualität haben? Da gibt x264 nicht mal mehr eine resize warning aus (yuyv422 -> yuv422p) hatte der vorher immer als warning ausgegeben.
YUV422p scheint dann ja YV16 zu sein?^^
Dann wäre das ja bereits die Lösung.

avs4x264mod.exe -L x264-10b_64.exe --preset slow --crf 20.0 --aq-strength 1.25 --output-csp i422 --sar 1:1 --output "d:\XVideos\Lets Play DooM\ZDW-Tournament-Swordgrunt-vs-Savant-blur3.264" "d:\XVideos\Lets Play DooM\ZDW-Tournament-Swordgrunt-vs-Savant-blur.avs"

Ohje.. Sagaras hat mir erstmal gesagt das - | x264-10b_64.exe .........
die pipe baut, argh..

http://paste2.org/b4fhfFU8

Das Problem hab ich aber nun

Ich hab hier yuyv422 als pix_fmt genommen, da die Quelle in diesem Farbformat vorliegt und es mir logischer erscheint das dann so anzugeben, da ja letztendlich x264 10bit encoder es erst in 10bit codiert.

http://paste2.org/HUWD2vvk

Noch 'ne kleine Anpassung wegen einlesen, aber ändert nix dran.

Ok hab gehofft, ich habs nun gefunden, weil ich deine Parameter -an -sn -vsync 0 nicht drin hatte, aber das hat immer noch nichts geändert am Problem.

ffmpeg -y -loglevel fatal -i "PFAD ZUR QUELLE" -an -sn -vsync 0 -r 25 -pix_fmt yuv422p -f rawvideo -

diese zeile muss aber noch ergänzt werden oder? Denn codiert wird ja hier nix denk ich?^^ Irgendwie muss das ja an x264 gehen.

Kann man externen x264 nehmen? MeGUI benutzt die komisar mod x264.
Weil sonst muss ich wohl gucken wie man bei ffmpegs internen x264 den 10bit x264 encoder anspricht. Der wählt den Encoder dann je nach pix_fmt? Weil eig. hat 10bit x264 mitm chroma sampling ja nicht viel zu tun

hmm irgendwie find ich den nur im Zusammenhang mit mplayer..

Einen Pipe dafür gibts nicht? Wäre glaub ich am einfachsten, statt ein neues programm mit neuen CLI Parametern zu lernen.

Kann es ffmpeg vllt sogar schon irgendwie? Mit dessen Parametern kenn ich mich allerdings auch nicht aus.

Die bei MeGUI enthaltene avs4x264mod.exe scheint rein nur YV12 zu unterstützen.

Ich will ein 4:2:2 Video mit dem 10bit Encoder codieren und avs4x264mod.exe konvertiert das dann immer zu YV12 um.. Da man das dem scheinbar auch nicht austreiben kann und für 3200x2000er Auflösung vermutlich die 4 GB RAM Grenze des 32bit geknackt wird, müsste ich das wohl irgendwie über 64bit kriegen. Und das wäre ja auch schneller..
Die 3200x2000 brauch ich für youtube, das hilft immens gegen ihre Kompression. (bzw wenn man einen 16:9 Monitor hat, 3200x1800)

Daher die Frage:

Gibt es irgendeinen Pipe der YUY2 (4:2:2) unterstützt??

Youtube kann sogar .bik Videos lesen (Bink Videos was einige Spiele verwenden).

Youtube scheint für die Decodierung ffmpeg zu verwenden. Denn all was ffmpeg bisher decodieren konnte, kann auch youtube. Wobei x265 und VP9 ja eig. auch ffmpeg schon hinkriegen dürfte? Naja vllt verwendet yt nicht immer die aktuellste ffmpeg version.

Tools - AVS Script Creator - Video Input öffnen - File Indexer Button drücken, den idx job machen lassen, freuen wie das Video auftaucht
Dürfte zumindest dann gehen.

Aber hat es überhaupt 'nen Sinn 8Bit eingangsvideo in 10bit zu codieren?

Ich würde sagen, der möchte dir damit sagen, das dein Eingangsvideo nur 8 bit Farbe hat.

edit: Anscheinend lag ich mit der Vermutung ja richtig ;D

Zitat

Na ja, wahrscheinlich hat so ein Screenrecording eh die merkwürdigsten Durchschnitts-Frameraten.

Naja das stellt man ja ein, mit wieviel FPS man aufnehmen will.

Wenn du zb 30 FPS einstellst, dann produziert das Programm auch ein 30,000 fps Video.
Die Programme arbeiten nicht mit VFR. Wär ja furchtbar wenn dem so wär.

Wenn MeGUI das erste Mal gestartet wurde, bevor Avisynth installiert war, wird MeGUI aber sein portable Ding nutzen. Guck bei MeGUI unter dem Tab "Log" und dort unter Versions. Wenn dort an dem Avisynth, Portable, dran steht und das aktiv ist, dann nutzt er das, statt dein externes.

Immer drauf achten das du das externe Avisynth nutzt. Falls also MeGUI sich schon das Portable reingezogen hat, entweder MeGUI neu runterladen oder alle avisynth.dll Vorkommnisse im MeGUI Ordner löschen. Kann das nur empfehlen. Egal ob es deinem Problem nun hilft oder diesma nicht hilft.

Alle avisynth.dll Vorkommnisse ausm MeGUI Ordner löschen, und avisynth extern installieren http://sourceforge.net/projects/avisynth2/files/

Das behebt meist schon einiges ;D

Die portable Integration ist nämlich ziemlich fürn Hintern.

--aq-strength 1.5 und --qcomp 0.7

sorgte dafür das Dunkelheit nun sehr sehr niedrige quantizerwerte bekam, also ein Erfolg

'nen Standbild bekam nun aber 'nen Quantizer von 30, statt 29. Sehr wahrscheinlich wegen --qcomp 0.7

Ich werds morgen mal mit --aq-strength 1.5 alleine probieren, vllt bleibts dann ja 29 und nur Dunkelheit wird besser. Das wäre super.

In einem anderen Thread stand auch was, das wohl ne höhere aq-strength helfen soll? Macht die nur inkomplexität besser, oder reduziert sie gleichzeitig auch komplexität?
Wie sehr bringt eig. no-fast-pskip?

Hallo

CRF 19 gefällt mir eig. super, aber bei extremer Dunkelheit sieht man durchaus minimalst!! Blockbildung. Wirklich absolut kleinkariert extrem minimalst, aber entspricht halt nicht mehr für mich visuell gleiche Qualität, wenn auf hellerer Ebene es visuell aussieht wie das Lossless Material.
Lokal jetzt nicht so schlimm, aber bei Youtube hab ich den Eindruck (youtube komprimiert Dunkelheit vom Ding her eh weit runter, Quantizerkompressionproblematik eben) das es immerhin ein bisschen besser ausfällt, wenn Dunkelheit vom hochladematerial mehr Qualität aufweist.
Jemand macht ein Amnesia LP und ja das Spiel ist halt sehr dunkel und dieser jemand schrieb mich an, das es ungewöhnlich schlecht aussieht und beim Sarazar viel sauberer aussieht und musste dem zustimmen. Er benutzt auch CRF19.

CRF19 machte eine Schnittbitrate von 39xx kbit bei seinem Amnesia Part.

Hab ihm dann mal gesagt, mach ma (für das Spiel) übertriebene 25 Mbit Bitratenencode - dann wird dem Encoder ja aufgezwungen auch bei Dunkelheit eine dezente Bitrate abzuliefern, zumal das Spiel ja durchweg dunkel ist und x264 ja irgendwo die 25000 einhalten muss. Auch mal dann bei einem Part von mir in 25000 probiert und hatte natürlich dann auch auf Dunkelheit perfekte Qualität abgeliefert, da x264 ja auf Dunkelheit dann auch hohe Bitrate verteilte.

Als er das dann hochgeladen hatte, sah es tatsächlich besser aus und mit Sarazar vergleichbar.

Da ich das aber ziemlich blöde find mit Bitrate zu arbeiten, weils einfach unwirtschaftlich ist und Bauchgefühl oft ist ob es auch reicht - Arma 2 ohne Motion Blur reichen 25mbit auf 2048x1152 nämlich beispielsweise nicht wirklich aus. Da gibt selbst youtube auf "original" über 40mbit teilweise aus.
Youtubes Quantizer @ Original ist bei ca. 25.

Was ich mich nun frage:

Kann man x264 nicht irgendwie ermutigen beim CRF bei Dunkelheit den Quantizer noch weiter niedriger zu ziehen, damit der Quantizer die Dunkelheit nicht ganz so dolle komprimiert?

So das hellere Stellen wie gewohnt encodiert werden mit der CRF19 Qualität, aber Dunkelheit 'nen Push kriegt in Qualität?

Hab da zb an --qpstep gedacht, aber das wird dann sicher auch bei Helligkeit entsprechend dann noch höhere Quantizerwerte nehmen, er soll ja aber nur Dunkelheit niedrigerere Quantizer benutzen

Vllt gibts da ja eine Möglichkeit

Wenn es beispielsweise mit Constant Quantizer lösbar wäre, wäres ja auch in Ordnung, würde nur gerne von Bitrate weg ;D

Ist es denn überhaupt was gleiches wie Blockbuster?

Das Ziel von Blockbuster isses ja die Komprimierbarkeit auf Dunkelheit zu verschlechtern durch einfügen von Schärfe, Noise etc (je nachdem was man dafür nutzen will).

Das klang für mich recht praktisch, würde der YT Encoder ja ebenfalls dann den höheren Detail bemerken und die dunklen Stellen dann entsprechend nicht so krass komprimieren. Aber bisher brachte mir das noch recht wenig. Nur minimal.

Genesis: Bitte verwechsel jetzt nicht Synchronous Surface Lock und Synchronize FPS.

Zitat

Bei Skyrim gibts auf meiner Maschine ohne Sync-Surface heftig Ruckler beim abspielen

Du scheinst nämlich hier SyncFPS zu meinen oder?

Weil SyncLock ist ja gerade das, was ich dir empfehle an zu haben.^^

Hier auch mal eine Erklärung zu SyncLock:

http://www.letsplayforum.de/index.php?page=LexiconItem&id=196

Zitat

Bezüglich der Helligkeit hab ich alles mögliche probiert ... auf meinem Monitor ist das wesentlich heller als in der Aufnahme ... unabhängig von VLC, MPC und nVidia -Einstellungen. Wenn ich die Helligkeit oder Kontrast im Spiel höher drehe, sieht es in der Aufnahme übersteuert aus.

Das dürfte aber wie gesagt echt nicht so sein. Da muss der Wurm bei dir liegen

Sorry falscher Link.

http://avisynth.org/warpenterprise…ll_20030204.zip

Ist die gleiche Version.

GradFun3 werd ich mir dann auch mal anschauen.

Es ging mir mehr um die SyncFPS Option.

Die ist total unnötig.

Zitat

b) um 30fps Ruckelfrei rendern zu können, brauchst du eine permanente Mindestframerate von 60fps ... bricht diese während des Spiels ein, gibts ruckler in der Aufnahme ... spiel mal Skyrim auf Hoch oder Ultra bei permanent >=60fps ... ich spiel/capture lieber mit hoher Detailstufe, als das ich den Luxus von 30fps haben muss.

Das stimmt so nicht.

Synchronous Surface Lock anhaken, schon klappts auch mit zb 40 ingame FPS und 30 AufnahmeFPS. SyncFPS ist absolut unnötig. Damit zerstörste dir nur das Spielerlebnis mit den wenigen FPS.

Zitat

Eigentlich gibt es sowas wie "korrektes Gamma" garnicht ... in dem Moment, wo du an deinem Monitor die für dich "korrekten" Helligkeits- und Kontrasteinstellungen wählst, hast du schon andere Werte.

Es geht aber nicht um meinen Monitor, sondern darum das DXTory exakt so das Spiel mit seiner Helligkeit aufnimmt, wie es auch aktuell war. Das ist 1:1. Wenn da bei dir Differenzen auftreten haste entweder 16-235 chroma range auf 0-255 gezwungen (stichwort VLC oder schlechte Ausgaberenderer wie zb VMR) oder youtube kommt dir bloß nur dunkler vor, wegen dem Detailverlust der Blockbildung - Blockbildung erschwert natürlich die Sicht auf Dunkelheit, eben wegen dem Detailverlust. Und youtube komprimiert dunkelheit ja massiv runter. Auf helligkeit macht yt ja auf orig eig. sehr gute Ergebnisse. Aber Dunkelheit - da sackts echt tierisch ein..

Und bezüglich dazu werf ich auch mal diesen Filter in den Raum:

http://kvcd.net/sansgrip/avisynth/Blockbuster-0.7.zip

http://killerinstinct.ath.cx:2000/files/blockbuster.html

Damit wird durch verschiedene Methodikauswahlmöglichkeiten den dunklen Bereichen die Komprimierbarkeit entzogen. Vllt bringts ja was

Sorry für die späte Rückmeldung, aber irgendwie bekam ich keinerlei Mail das neue Antwort gekommen ist

Zitat

a) ich bekomme mehr Bitrate pro Frame und die ist in YT sowieso schon mehr als knapp

Youtube encodiert 25fps nicht besser als 30. Das wär mir neu. Auch youtube benutzt keine festen Bitraten, auch die benutzen quantizer. nur eben leider festen quantizer, kein CRF. Darum ja auch der massive Abfall auf Dunkelheit

Aber wird da nicht dann auch auf 320 kbit limitiert? nur so aus interesse.

Hab die .dll noch nicht runtergeladen, weil ich noch nicht so überzeugt von bin, daher kann ich nicht selber testen gerad.

Aber ich vermute mal das TVBR so ähnlich ist wie Neros Adaptive Bitrate.

Bei Q-AAC find ichs aber unschön das der nicht mehr als 256 kbit erlaubt.
Ich find da Nero AAC etwas flexibler, auch wenn Q-AAC ein Tick effizienter ist. Das kann ich bei Nero AAC mit bisschen mehr Bitrate notfalls ausgleichen.

MeGUI hätte q-aac drin, megui benötigt lediglich die CoreAudioToolbox.dll dafür.

edit: Sehe gerade das nun 320 kbit gehen. Vllt durch 'nem Update. Keine Ahnung. Hätte schwören können es war 256 limitiert und nicht 320. hm.

Trotzdem sagt mir Nero AAC mehr zu mit seiner Adaptive Bitrate und dem großen Freiraum der Bitrate.