Youtube Videos ... bitte mal 'ne Meinung abgeben

TheGenesis

Hi leuz,

ich glaub ich bin jetzt fasst am maximal möglichen angekommen.

Könntet ihr euch das Erbebnis bitte mal anschauen und sagen, ob ich da vielleicht noch wo dran drehen sollte?

Das erste Video ist hier:

http://youtu.be/MfUWSonoy68

Und ich hab noch ein zweites (nativ YV12 ohne Level-Korrektur):

http://youtu.be/P-7e77d6EqU

Bitte nur die maximalen Auflösungen begutachten ... die 360er würde ich am liebsten löschen, da kriegt man Augenkrebs

Achso ... wenn das zweite oben ist, sagt mir doch bitte mal, ob man einen Unterschied erkennen kann.

Danke und Gruß
Thom

TheGenesis

Niemand ne Meinung?

Ich seh nämlich keinen Unterschied ... gibts da eigentlich keine Programme, die sowas digital "bewerten"?

LigH

Doch.

Aber das Ergebnis hat höchstens ansatzweise Ähnlichkeit mit dem menschlichen Empfinden. Und sie können immer nur zu einem Original sinnvoll vergleichen, nicht zwei Kopien miteinander oder ein einzelnes Video für sich.

Und ohne das Original zu kennen, erkenne ich wirklich kaum Unterschiede; so für sich sehen beide erst mal sehr gut für ein YouTube-Video aus. Na ja, im kleinen YouTube-Ausschnitt. Zum ernsthaften Vergleich müsste ich es herunterladen und in voller Größe anschauen. Hab aber im Moment nicht so viel Zeit dafür...

Goldwingfahrer

Zitat

Ich seh nämlich keinen Unterschied

wirklich nicht ??
der native YV12 hat einen leichten Grauschleier,siehst Du sofort im Beispiel-PNG
Mehr habe ich noch nicht geschaut.Werds aber Morgen direkt ab TL per HDMI an den Plasma senden.
http://www.ww-consulting.ch/DL/EDIUS.zip

TheGenesis

Hast recht!

Ich hab aber gerade doch noch was gesehn ... der Himmel ist beim 220er-White-Input-Level komplett ausgewaschen ... is auch logisch ... außerdem ist mir gerade aufgefallen, das mein Uploadfile bei vollem spektrum kleiner wird ... der YouTube re-encode bei voller Auflösung lustigerweise größer ... bei den downscalings macht das größenmäßig nichts aus.

Das ist doch eigentlich unlogisch ... mehr Farbe müsste eigentlich mehr Bitrate bedeuten.

Aber ich möchte die Details (z.B. am Himmel) nicht verliehren, wenn ich dadurch keinen Vorteil in anderen Bereichen habe ... die Texturen in den dunkleren (nicht so "hellen") Frames sind rein subjektiv nämlich gleichermaßen ok.

Neuer Ansatz (rendered gerade):

Nativ YV12 wird genommen
Gamma von 1.2 auf 1.3

Und ich lass gleich noch 'nen Faktor mit reinlaufen ... das ist mir alles noch zu weichgespült ... mir ist aufgefallen, das die Gesichter mehr wie ein convolution3d() aussehen, als das man die Hautpigmentierungen noch erkennen könnte ... ich nehm den FFT3DFilter() nochmal komplett raus ... auch auf die Gefahr hin, das es im Hintergrund wieder anfängt zu wabern bzw. mir das höhere Graining den re-encode bei Youtube versaut ... mit etwas Glück gibts bei 1152p trotz höherem Detailgrad noch keine Artefakte.

Die Renderingzeit beschleunigt das Manöver auf jedenfall schonmal um den Faktor 3 ... mal sehen wie groß die Uploaddatei wird ... grusel

Übrigens nettes Prog das du da hast ... was kann man damit machen, außer Frames zu vergleichen?

TheGenesis

Nääähhh ... pfui ... bah ... spuck ...

Wurde gerade wieder schmerzlichst daran erinnert, warum ich den FFT3D eingebaut habe ... das reinste rumgeflackere an allen Ecken und enden ... und der Gewinn an Details ist kaum sichtbar (wahrscheinlich nur durch das erhöhte Rauschen) ... den Gamma anheben bringts auch nicht ... das hebt die mittleren Lumas zu weit an ... da gibts dann keine vernünftigen Schatten mehr und heller wirds dadurch auch nicht.

Ich schraub jetzt den Sigma beim FFT3D auf 1.0 runter und lass den Gamma auf 1.2 (ohne Levelerhöhung).

So'n Käse ... das sieht zwar gut aus, ist aber immernoch zu Dunkel ... in der Szene sind es 13:00 Uhr und die Sonne steht voll am Himmel ... muss eigentlich so hell sein, wie in dem Beispiel mit Levels 220 ... aber dann verliehr ich die Details in den hellen Bereichen ...

Jemand noch 'ne Idee, wie ich das Heller kriege ohne den Himmel in eine Weisse Fläche zu verwandeln?

Bitte keine Kommentare wie "Brightness und/oder Contrast" ... das kann ich dann auch gleich mit 'nem ACDSee drüberbügeln :hm:

TheGenesis

So ... das wird voerst die Endfassung sein:

http://youtu.be/P8HNw5NGO_I

(lädt noch hoch ... 815MB ... ca. 320min ... bis ca. 08:15)

Achso ... das wäre dann das folgende Script:

Code

loadplugin("c:\Program Files\AviSynth\plugins.manual\FFT3DFilter.dll")AVIsource("d:\Storage\Work\Dxtory\TESV 2013-03-13 22-22-30-998.avi")Levels(0,1.2,255,20,255)FFT3DFilter(sigma=1, bt=5, bw=32, bh=32, ow=16, oh=16, ncpu=8)Lanczos4Resize(2048,1152)Sharpen(0.79)

getreu dem Motto ... weniger ist oft mehr

... und der Vollständigkeit halber noch die x264 Parms:

Code

x264.exe --crf 18 --no-fast-pskip --ref 4 --bframes 16 --b-pyramid --weightb --analyse all --subme 7 --trellis 1 --mixed-refs --no-psnr --no-ssim --direct temporal --partitions all --me hex --deblock -3:-3 --aq-strength 0.5 --deadzone-inter 2 --deadzone-intra 4 --threads auto --progress --output OUTFILE.mp4 INFILE.avs

Achtung ... die sind für die Version "x264 core:66 r1093M 1df50b9" (irgendwann Anfang 2009) ... die neueren x264's nehmen die so nicht mehr ... da sind einige obsolete ... ich hatte die demletzt mal an eine aktuelle Version angepasst, aber Dateigröße und Encodingdauer hatten sich damit drastisch erhöht, ohne das ich optisch irgendeinen Nährwert erkennen konnte und deshalb bleib ich für meinen Teil erstmal bei des "Schusters Rappen" ;D

LigH

Vergiss bitte nicht die alte Bauernregel:

"Schärfe" ist schlecht komprimierbar, und bei begrenzter Bitrate sorgt das für sichtbare Artefakte.

Erst das überschärfende Skalieren mit Lanczos4 (Gibbssches Phänomen), und dann noch mal nachschärfen mit dem "blinden" Anti-Blur, halte ich persönlich nicht vorteilhaft für die vollautomatische Recodierung bei YouTube.

Getreu dem Motto "Weniger ist oft mehr", gibt ein neutraleres Skalieren und "LimitedSharpen" dem Recoder vielleicht etwas mehr Spielraum, in der vorgegebenen Bitratengrenze (die Optimierung könnte ja theoretisch mit Netzwerk-Bandbreiten zu tun haben) noch ein paar Bits für Texturdetails übrig zu haben.

Deine x264-Parameterliste ist von der Länge her beeindruckend, aber vielleicht reichen dafür – bei aktuellem x264 – auch eine Handvoll Basisparameter (preset, tune). Ich persönlich halte ein paar der Parameter in der vorliegenden Kombination für übertrieben. Sind bis zu 16 aufeinander folgende B-Frames nötig und sinnvoll? Deblocking extrem reduziert? Warum Bewegungsvorhersage speziell nur "temporal" statt "auto"? (Vielleicht wegen der x264-Version.)

Und ja ... gibt es Gründe für das Verbleiben bei einer so "veralteten" x264-Version, außer dass neue Versionen veraltete Parameter nicht mehr akzeptieren? Dann wär's mal Zeit zum Umlernen und neu Optimieren; wäre es nicht sinnvoll gewesen, hätte man sich die Weiterentwicklung sparen können. In den aktuellen Versionen sollte man sich vorwiegend auf "--preset" und "--tune" verlassen und darüber hinaus nur anpassen, wovon man genau weiß, warum das nötig ist (z.B. Profile@Level und VBV-Parameter für Geräte-Kompatibilität). Welches Tuning für PC-Spiele-Aufzeichnung sinnvoll ist, bin ich mir nicht sicher; aber für das Preset wird sicherlich kaum ein langsameres als "slow" oder "slower" notwendig sein.

Lassen wir das mal gemeinsam bedenken...

TheGenesis

Zitat

Vergiss bitte nicht die alte Bauernregel:

"Schärfe" ist schlecht komprimierbar, und bei begrenzter Bitrate sorgt das für sichtbare Artefakte.

Als alter Hase mach ich das normalerweise auch nicht ... aber 264 reagiert darauf nicht so böse, wie MPG2 oder DivX aka MP4.

Bei meinen ersten Encoding-Versuchen für die "Lets Plays" waren die Details, die ich mit meinen mühsam zusammengesuchten optischen Mods zur Geltung bringen wollte, so dermassen ausgewaschen, das ich zu drastischeren Maßnahmen greifen musste.

Zitat

Erst das überschärfende Skalieren mit Lanczos4 (Gibbssches Phänomen), und dann noch mal nachschärfen mit dem "blinden" Anti-Blur, halte ich persönlich nicht vorteilhaft für die vollautomatische Recodierung bei YouTube.

Das 50% schärfen ist bei den "Lets Plays" komischerweise die einzige Holzhammermethode, die gewirkt hat, um die feinen Details (wie z.B. die Maserung an den überall rumstehenden Holzbalken) zu erhalten, ohne das mein Upload (oder später das YT-re-encode) die wieder herauswaschen.

Ich könnte das schärfen ein bischen runterziehen (auf 45%), aber durch den zwingenden upscale geht eh schon zuviel bei drauf, als das ich die wahl hätte.

Zitat

Getreu dem Motto "Weniger ist oft mehr", gibt ein neutraleres Skalieren und "LimitedSharpen" dem Recoder vielleicht etwas mehr Spielraum, in der vorgegebenen Bitratengrenze (die Optimierung könnte ja theoretisch mit Netzwerk-Bandbreiten zu tun haben) noch ein paar Bits für Texturdetails übrig zu haben.

Hatte ich ganz am Anfang schonmal probiert ... sah echt übel aus ... gibt große weiche Flächen in der mittleren Entfernung, in trotzdem anfangen zu wabern.

Welche kombi würdest du denn vorschlagen?

Zitat

Deine x264-Parameterliste ist von der Länge her beeindruckend, aber vielleicht reichen dafür – bei aktuellem x264 – auch eine Handvoll Basisparameter (preset, tune). Ich persönlich halte ein paar der Parameter in der vorliegenden Kombination für übertrieben.

Wenn ich ehrlich bin, hatte ich bei dem halbherzigen Versucht letzte Woche keine Lust, wieder soviel Zeit für die Tests zu verballern. So hab ich an einem abend gerade mal die Dokus verglichen und die meisten Parameter in der tat durch preset und tune zusammengefasst.
Das Ergebnis war dann von der Qualität vergleichbar, hat aber doppelt so lange kodiert und über 50% mehr Bitrate gefressen. Und dann hab ich aufgehört, weil ich in die Einstellungen da oben in 2009 ungefährt 2 Wochen arbeit reingesteckt habe.
Da hatte ich "im zuge der Umstellung von MPG43 auf x264" alle Kombinationen an Filmmaterial in den unterschiedlichsten CRF/VBR Varianten kodiert und auf alle mir und meinen Bekannten zur Verfügung stehenden Geräte auf Kompatibilität und subjektivem Empfinden getestet.
Die "beeindruckende Parameterliste" ist "Rock-Stable" will meinen, funktioniert mit allen mir bisher untergekokmmenen Quellen hervorragend, was Endgröße und Qualität angeht ... bisher hatte ich 0-Artefakte und die Dateigrößen entsprechen i.d.R. der doppelten Größe von MP43.
Ich hab auch schon mehrere Blue-Rays auf 720p runterkodiert und dabei gigantische "Platzeinsparungen" erreicht, ohne das jemand in meinem Bekanntenkreis (die mit den riesengroßen, neumodischen HD Fernsehern ) was gemerkt hätten.

Zitat

Sind bis zu 16 aufeinander folgende B-Frames nötig und sinnvoll? Deblocking extrem reduziert? Warum Bewegungsvorhersage speziell nur "temporal" statt "auto"? (Vielleicht wegen der x264-Version.)

Grins ... du fragst mich gerade sachen, die schon 4 Jahre her sind ... lol.

Zitat

Und ja ... gibt es Gründe für das Verbleiben bei einer so "veralteten" x264-Version, außer dass neue Versionen veraltete Parameter nicht mehr akzeptieren?

Nein, eigentlich nur der Zeitaufwand zum testen, aber Zeit ist bei mir immer sehr knapp und da weiche ich ungerne vom "bewährten" ab.
Aber du hast recht ... ich tu's mir nochmal an ... arrgghhh ... hab gerade gesucht und kann die angepasste Parameterliste nicht mehr finden (hab ich warhscheinlich aus Frust gelöscht) ... gibst du mir mal 'nen Ansatz? ... vielleicht kann ich mir dann das rumvergleichen der einzelnen Parameter sparen.

Zitat

Dann wär's mal Zeit zum Umlernen und neu Optimieren; wäre es nicht sinnvoll gewesen, hätte man sich die Weiterentwicklung sparen können. In den aktuellen Versionen sollte man sich vorwiegend auf "--preset" und "--tune" verlassen und darüber hinaus nur anpassen, wovon man genau weiß, warum das nötig ist (z.B. Profile@Level und VBV-Parameter für Geräte-Kompatibilität). Welches Tuning für PC-Spiele-Aufzeichnung sinnvoll ist, bin ich mir nicht sicher; aber für das Preset wird sicherlich kaum ein langsameres als "slow" oder "slower" notwendig sein.

Ich glaube nicht, das für Spiele besondere x264-Parameter notwendig sind ... weisst du, was mich an dem Preset-Gedöns stört? ... ich gebe die Kontrolle von "meinem persönlichem Empfinden von Qualität" an die Allgemeintheit bzw. an die Leute ab, welche festlegen, was in den Presets enthalten ist ... da hab ich ein bischen Angst davor, das in ein paar Jahren jeder so ein Preset für das Maß aller Dinge hält und die folgeversionen auf diesem (evtl. degradierenden) Qualitätsempfinden aufbauen.

Gruß
Thom

TheGenesis

Ich hab mir gerade das Ergebnis in YT angeschaut ... bin recht zufrieden ... ich hatte die Erhöhung des White-Level-Inputs (um 35) rausgenommen und dafür das Output-Level um 20 erhöht ... ist jetzt von der Helligkeit akzeptabel und es wäscht den Himmel nicht mehr so stark aus.

Werd das wohl nochmal mit dunklen Szenen testen müssen ... will nicht plötzlich mit banding überrascht werden.

Wenn sonst niemandem mehr eine Aufhellung ohne Kontrastverlust einfällt, würde ich mich auf die neuen x264-Versionen stürzen, denn ein Upload-File von 800MB ist bei meiner ollen 4Mbit-Leitung (480KB upstream) "nicht so wirklich prickelnd"

LigH

Nun gut - "die Praxis ist das Kriterium der Wahrheit"; wenn es nur mit Nachschärfung möglich ist, YouTube vom Wegfiltern von Details abzuhalten, dann ist das wohl notwendig.

Du sagst, du hättest wenig Zeit zum Testen und wenig Ahnung von der Bedeutung einzelner Parameter und ihrer Wirkung, insbesondere im Zusammenhang zu anderen Parametern. Nun ... die Entwickler haben das Wissen, und sie hatten sich auch die Zeit genommen, mit vielen Beispielen zu testen, welche Standardwerte im Allgemeinen sinnvoll sind, insbesondere welche Balance zwischen mehreren Einzelparametern. Und das gilt noch einmal in Kombination von Preset und Tuning. Du kannst ja die Vorgaben in "x264 --fullhelp" nachlesen, und dabei wirst du auch Parameter entdecken, die in den letzten tausend Revisionen heute ganz andere Werte annehmen können (z.B. Trellis: nicht nur 0=aus oder 1=an, sondern auch noch Modus 1=einmal und 2=mehrfach pro Makroblock):

Code

[size=8]      --preset <string>       Use a preset to select encoding settings [medium]
                                  Overridden by user settings.
                                  - ultrafast:
                                    --no-8x8dct --aq-mode 0 --b-adapt 0
                                    --bframes 0 --no-cabac --no-deblock
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions none --rc-lookahead 0 --ref 1
                                    --scenecut 0 --subme 0 --trellis 0
                                    --no-weightb --weightp 0
                                  - superfast:
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions i8x8,i4x4 --rc-lookahead 0
                                    --ref 1 --subme 1 --trellis 0 --weightp 1
                                  - veryfast:
                                    --no-mixed-refs --rc-lookahead 10
                                    --ref 1 --subme 2 --trellis 0 --weightp 1
                                  - faster:
                                    --no-mixed-refs --rc-lookahead 20
                                    --ref 2 --subme 4 --weightp 1
                                  - fast:
                                    --rc-lookahead 30 --ref 2 --subme 6
                                    --weightp 1
                                  - medium:
                                    Default settings apply.
                                  - slow:
                                    --b-adapt 2 --direct auto --me umh
                                    --rc-lookahead 50 --ref 5 --subme 8
                                  - slower:
                                    --b-adapt 2 --direct auto --me umh
                                    --partitions all --rc-lookahead 60
                                    --ref 8 --subme 9 --trellis 2
                                  - veryslow:
                                    --b-adapt 2 --bframes 8 --direct auto
                                    --me umh --merange 24 --partitions all
                                    --ref 16 --subme 10 --trellis 2
                                    --rc-lookahead 60
                                  - placebo:
                                    --bframes 16 --b-adapt 2 --direct auto
                                    --slow-firstpass --no-fast-pskip
                                    --me tesa --merange 24 --partitions all
                                    --rc-lookahead 60 --ref 16 --subme 11
                                    --trellis 2
      --tune <string>         Tune the settings for a particular type of source
                              or situation
                                  Overridden by user settings.
                                  Multiple tunings are separated by commas.
                                  Only one psy tuning can be used at a time.
                                  - film (psy tuning):
                                    --deblock -1:-1 --psy-rd <unset>:0.15
                                  - animation (psy tuning):
                                    --bframes {+2} --deblock 1:1
                                    --psy-rd 0.4:<unset> --aq-strength 0.6
                                    --ref {Double if >1 else 1}
                                  - grain (psy tuning):
                                    --aq-strength 0.5 --no-dct-decimate
                                    --deadzone-inter 6 --deadzone-intra 6
                                    --deblock -2:-2 --ipratio 1.1 
                                    --pbratio 1.1 --psy-rd <unset>:0.25
                                    --qcomp 0.8
                                  - stillimage (psy tuning):
                                    --aq-strength 1.2 --deblock -3:-3
                                    --psy-rd 2.0:0.7
                                  - psnr (psy tuning):
                                    --aq-mode 0 --no-psy
                                  - ssim (psy tuning):
                                    --aq-mode 2 --no-psy
                                  - fastdecode:
                                    --no-cabac --no-deblock --no-weightb
                                    --weightp 0
                                  - zerolatency:
                                    --bframes 0 --force-cfr --no-mbtree
                                    --sync-lookahead 0 --sliced-threads
                                    --rc-lookahead 0
[/size]

Alles anzeigen

Ich erinnere mich, dass es mal ein Tuning "touhou" gab. Das bezieht sich auf die japanischen Spiele, in denen man ständig gefühlten Millionen von Geschossen ausweichen muss, während man den Endgegner des Levels angreift. Das fordert natürlich die Bewegungsvorhersage aufs Extremste. Anscheinend ist das nun nicht mehr enthalten, aber es wäre vielleicht interessant, die darin verwendeten Parameter-Änderungen als Basis für weitere Überlegungen zu verwenden.

Aber ich maße mir nicht an, dir ein Optimum für deine Anforderungen zu empfehlen. Ich bin hier nicht der einzige, der Erfahrung mit x264 hat — und die meiste schon gar nicht.

Selur

LigH: 'touhou' gibt's immer:

Code

else if( !strncasecmp( s, "touhou", 6 ) )
        {
            if( psy_tuning_used++ ) goto psy_failure;
            param->i_frame_reference = param->i_frame_reference > 1 ? param->i_frame_reference*2 : 1;
            param->i_deblocking_filter_alphac0 = -1;
            param->i_deblocking_filter_beta = -1;
            param->analyse.f_psy_trellis = 0.2;
            param->rc.f_aq_strength = 1.3;
            if( param->analyse.inter & X264_ANALYSE_PSUB16x16 )
                param->analyse.inter |= X264_ANALYSE_PSUB8x8;
        }

Alles anzeigen

Quelle: x264-snapshot-20130315-2245
wird nur schon ewig nicht mehr in der Hilfe ausgegeben.

TheGenesis

Zitat von LigH

Sind bis zu 16 aufeinander folgende B-Frames nötig und sinnvoll?

Ich bin nochmal ein bischen in mich gegangen und meine, ich hätte damit (damals) Speed gegen Bitrate getauscht.

Zitat

Deblocking extrem reduziert?

Ich glaube, ich hab den reduziert, damit das Video bei der Ausgabe nicht verfälscht wird ... ich möchte keine Blöcke im encode, das ist (oder war früher) ein Zeichen dafür, das für das aktuelle Quellmaterial zu wenig Bitrate zur Verfügung steht.
Vielleicht habe ich das auch nur gemacht, um zusätzlich Bandbreite zu schonen ... nach dem Motto: "enkodiert eh satt, also brauch ich auch keine widerherstellungsdaten".

Zitat

Warum Bewegungsvorhersage speziell nur "temporal" statt "auto"? (Vielleicht wegen der x264-Version.)

Ja, mag der Verion geschuldet sein ... ich glaube ich hatte auf 'ner PS3 mal Artefakte ... könnte aber auch Trellis gewesen sein.

Ich experimentiere übrigens gerade mit 'ner frischen Version vom Holländer
Und es ist nicht besonders emutigend die Bitrate ist bei den gängigen presets (zumindest mit CRF 18/19) viel zu hoch.

Didée

Das ist keine große Überraschung bzw. hat nicht viel zu sagen. Das was "CRF=xy" liefert, das hat sich im Verlauf von ca. 1000 (!) Revisionen seit Deiner uralt-Version definitiv mehrmals geändert. Ziemlich sicher ist aber: bei am Ende gleicher Bitrate wird das Egebnis eines aktuellen Builds sicherlich besser sein als das vom 1000 Revisionen älteren Build. Und wenn der neuere Build +1 oder +2 höheres CRF braucht um auf die gleiche Bitrate zu kommen, dann ist es halt so. CRF ist immer nur ein relatives Maß. Niemals ein absolutes.

Nebenbei: ohne jetzt allzu tief in die x264 Settings einsteigen zu wollen, aber ein einziger Punkt: Wenn Du dermaßen niedrige Deadzone-Werte verwendest, dann ist das MÖRDERISCH betreffs Bitrate, wenn man NICHT Trellis=2 verwendet. (Ich nehme auch gerne die deadzone-Werte vom Grain-Preset: deadzone_intra und _inter beide = 6 -- aber NUR mit Trellis=2 und SubME=10. Wenn das zu langsam ist, kann man sich die Deadzone-Geschichte auch gleich komplett sparen, zumindest mMn.)

TheGenesis

Ok ... ist doch mal ein Ansatz ... werd ich morgen/übermorgen mal ausprobieren ... muss vorher leider noch 'nen blöden Auftrag erledigen.

Achso ... hätte mir ja mal jemand sagen können, das es von dem FFT3DFilter() auch 'ne GPU-Version gibt ... jauchz ... mal locker die rendering zeit um über die hälfte verkürzt ... voll geil ... das lässt sich damit fasst in Echtzeit angucken

Ich nehm den White-Level-Input übrigens wieder hoch, allerdings "nur" auf 230 ... da entsteht durch den erhöhten Kontrast mehr (subjektive) Tiefenschärfe ... und den Sigma schraub ich auch wieder auf 1.5 hoch ... das weniger glätten bringt keine zusätzlichen Details (im Upload-File) zutage, aber kostet mich 20% zusätzliche Bitrate.

TheGenesis

Urgs ... hab mal (mit dem alten Encoder) mit Trellis=2, *_intra=6 und subme=10 kodiert ... aua ... das macht dann Encodingdauer x2,5 (bei meinem kleinen i7) ... bei dem alten Encoder bringt das Bildmäßig überhaupt nix und die Bitrate steigt ein klein wenig an. Vielleicht liegts auch am Lets-Play-Material.

Werds dann die Tage auch nochmal mit dem neuen x264 und anderem Quellmaterial probieren.

Ich hatte gerade wieder so einen Aha-Effekt ... bei crf runter auf 24 baut x264 scheinbar mehr "error-distortion" mit rein ... das führt dazu, das mein blödes Gehirn einen "höheren Detailgrad" wahrnimmt... uaaahhh ... das ist sooo blöde ... würd ich glatt nehmen, aber bei den closeups geht dann der detailgrad teilweise wieder runter ... außerdem befürchte ich, das der re-encode bei YT das komplett zusammenmatscht ... ich lads aber trotzdem mal hoch ... 1/2 Bitrate sollte einen Versuch wert sein

Achso ... ich kann euch übrigens wärmstens so ein Kleinod nahelegen ... nennt sich VideoCheck ... sucht einfach mal in Google nach SetupVideoCheck0.4.exe
Das teil ist super simple aber prima geeignet, um unterschiede zwischen unterschiedlichen encodings zu vergleichen ... da öffnet man einfach das "referenz-video" und dann das "test-video" und beide werden synchron abgespielt ... mit einem Mausklick auf das Video schaltet er zwischen referenz-video (Blauer Indikator) und test-video (Roter Indikator) hin und her ... mit Space kann man das ganze pausieren. Das läuft bei mir zwar nicht mit der vollen FPS, aber nahe dran ... super simpel ... einfach mal ausprobieren.

Goldwingfahrer

Zitat

das der re-encode bei YT das komplett zusammenmatscht

das befürchte ich allerdings auch.
Dann ists eigentlich schade um den Aufwand den Du treibst.

Zitat

Ich nehm den White-Level-Input übrigens wieder hoch, allerdings "nur" auf 230 ..

hast Du eigentlich den Screen mit der YUV-Kurve angeschaut den ich hier gezeigt hatte,da kannst den Level anpassen ohne den ganzen Stream im unteren & mittleren Bereich zu ändern.

LigH

Wir haben da auch den Fritz Framalyzer, der tut auch so was. Aber ... weder PSNR noch SSIM sind wirklich Zahlenwerte, die eine direkte Verbindung zum gefühlten Qualitätsverlust haben. Beide haben ihre Grenzen, denn jeder Betrachter empfindet etwas anders.

TheGenesis

Zitat von Goldwingfahrer

hast Du eigentlich den Screen mit der YUV-Kurve angeschaut den ich hier gezeigt hatte,da kannst den Level anpassen ohne den ganzen Stream im unteren & mittleren Bereich zu ändern.

Huch ... hab ich was übersehen? Wo?

Zitat von LigH

Wir haben da auch den Fritz Framalyzer, der tut auch so was. Aber ...

Bei dem Test ist mir gerade aufgefallen, das meine erstellten MP4-Videos via DirectShowSource() nur graue Frames zurückliefern. Jemand ´ne Ahnung warum?

Der DGIndexNV kann leider noch keine MP4-Container ... geht das mit irgendeinem anderen Parser?

Goldwingfahrer

Zitat

Huch ... hab ich was übersehen? Wo?

Upps...war ja gar nicht auf Dich bezogen...aber trotzdem,schau mal den YUV Verlauf rechts im Bild an.
Dann weisst Du was ich meine.
Beitrag 33 von
http://forum.gleitz.info/showthread.php…MiniDV%29/page4

Jetzt mitmachen!