Beiträge von Mr. Brown

sasuke9999
der weissliche rand is schon in der orginal source drin und bedeutet das hier digital nachgeschärft wurde

die digitale nachschärfung (auch halos oder egde enhancement genannt) verursacht diese weissen ränder und linien an den kanten ! Allerdings finde ich diese in deinem fall nicht so schlimm da sie nur ganz schwach sind und kaum auffallen

Fast alle DVD's die ich kenne haben halos mal mehr mal weniger !

Denn die studios gehen nun mal davon aus dass diese am fernseher angesehen werden hier fallen rauschen und halos weit wengier auf als am pc-monitor

ich persöhnlich würde hier nicht filtern :so-nicht: da die source recht sauber und scharf ist

@ sasuke9999
poste mal bitte ein kurzes sample (10-20sek) von der original source

Zitat von Deinorius

Bei welcher Einstellung bringt das nochmal Vorteile? Oder ist das nur allgemein.

Bei eingeschalteter Intra Search also eigentlich fast immer!

Zitat von Deinorius

Ich kann die Intra Search grad nicht wirklich zuordnen. Ist das bei Hexagonal, Multi-hex, Exhaustive?

Hier
[Blockierte Grafik: http://img137.imageshack.us/img137/6441/pic2hi.jpg]

ffdshow-rev2546 von celtic_druid

Download
http://ffdshow.faireal.net/mirror/ffdshow/

Changelog
http://cia.navi.cx/stats/project/ffdshow

DGMPGDec 1.4.7 beta 7

Zitat

* Improved the misleading error message a user gets if he erroneously loads a file with MPEG2Source() that is not a D2V project file. Previously it complained about a version mismatch; now it says the file is not a project file.

* Fixed the display of the running time in the Parse D2V output.

http://forum.doom9.org/showpost.php?p=823081&postcount=112

r517: typo in expand_border_mod16
r518: --sps-id, to allow concatenating streams with different settings.
r519: faster intra search: some prediction modes don't have to compute a full hadamard transform.
x86 and amd64 asm.
r520: faster intra search: filter i8x8 edges only once, and reuse for multiple predictions.
r521: allow sar=1/1.
patch by Loic Le Loarer.
r522: msvc doesn't like C99 named array initializers
r523: set the SPS constraint_set[01]_flag based on the profile in use, just in case some decoder cares

Update

Zitat

What's New in Firefox 1.5.0.3

Firefox 1.5.0.3 is a security update that is part of our ongoing program to provide a safe Internet experience for our customers. We recommend that all users upgrade to this latest version.

* Security fix for denial of service vulnerability.

Release Date: May 2, 2006

http://www.mozilla-europe.org/de/products/firefox/

So weil die changelogs von divx 6.1 - 6.2.2 nicht gepostet wurden trag ich sie mal der vollständigkeit halber nach !

6.0.3 --> 6.1

Zitat

* The encoder now includes full support for single CPU, HyperThreaded (HT), dual CPU (SMP) and dual core processors. Encoding performance is vastly improved on systems with multiple logical processors and even on those with only a single CPU. We benchmarked the encoder on everything from stock P4 processors to those with HyperThreading(HT), Dual AMD systems, AMD's new dual core X2 chips and Intel's flagship dual core + HT Pentium D Extreme Edition. Scroll down to see some of the results!
* The decoder now supports multithreading for improved playback performance on all HT, SMP and dual core processors. To enable it you need to use the Decoder Configuration Utility (which you'll find in the 'DivX' group on your Start menu) to ensure "Reduce CPU spikes using one frame delay" is enabled and some level of post-processing is set (we recommend the default, "Automatic Deblocking"). Multithreading will then be applied to any video with B-frames, including most Home Theater and High Definition media.
* The performance of Extreme quality and Insane quality modes has been improved - you can now get production quality video in even less time! Our testing shows that these modes are between 70% and 80% faster, even on regular single CPU machines.
* A new High-performance mode has been created which benches anywhere from 90% to 160% faster than Balanced mode in the 6.0 codec depending on CPU type. This mode yields slightly lower compression but has good quality and is perfectly suited to live-capture applications and other rapid encoding applications. When we used a D1 MPEG-2 source video using AVISynth and VirtualDubMod on our Pentium D Extreme Edition we averaged 150fps, encoding a clip that was 5.3 minutes long in just 51 seconds! Best of all, the output from this mode will play on DivX Certified devices!
* We have significantly enhanced Fastest mode, with virtually zero performance impact. In the DivX 5.x and DivX 6.0 codecs Fastest mode used no motion estimation and was therefore capable of producing very high quality video but with very low compression. That meant that it was possible to use this mode for live capture on slower computers but with two major drawbacks: file sizes were huge and the output could not be played immediately on DivX Certified devices - you had to re-encode it in one of the other encoding modes first. In the 6.1 codec, compression for this mode has improved so much that it's possible to encode directly into DivX Certified profiles with small, good quality files.
* You can now specify a target quantizer instead of an average bitrate during encoding, enabling you to avoid multipass encoding altogether in certain circumstances, reducing encoding time by half! This new method even works with DivX encoding profiles!
* We've added more optimizations for processors supporting SSE2 extensions. English translation: If you have a newer CPU things will go slightly faster for you.
* DivX High Definition profile now allows up to 6Mbps average bitrate for crystal clear HD video, even with your nose pressed against your 60" HD plasma TV.
* A new Lanczos resize filter is included in the encoder, enabling very sharp resizing during export from any video suite.
* Quarter-pixel motion estimation has been enhanced for performance, and is now available in all modes from Balanced through Insane when Unconstrained Profile is selected. Please remember that using quarter-pixel motion estimation (or simply switching to Unconstrained Profile) means that your videos are highly unlikely to play well, if at all, in your DivX Certified device.
* The Feedback Window now displays VBV level and has variable axis for PSNR plots, making it easy to monitor encodes with very high PSNR metric results.
* The Feedback Window now contains controls for changing VBV bitrate, performance mode, and psychovisual enhancement in real time during encoding.
* MPEG quantization has been improved
* Brightness, Contrast, and Saturations controls now operate correctly in the DivX Decoder for DirectShow

Alles anzeigen

6.1 --> 6.1.1

Zitat

* Fixed a problem where some systems would crash as the Psychovisual Enhancement method was modified in the encoder configuration window.
* Improved B-frame decision.
* Improved rate control for very high bitrates.
* Fixed a problem that caused cropping to reduce performance.
* Fixed an issue where adjusting the VBV_bitrate slider in the Feedback Window would reset the VBV buffer occupancy.
* Improved Japanese encoder translations.
* Fixed a problem where the decoder may fail if both smooth playback and YUV output are enabled in the Decoder Configuration Utility.
* Fixed a post-processing issue in the decoder for multi-threading systems.
* Fixed a handle leak in the decoder.

Alles anzeigen

6.1.1 --> 6.2

Zitat

New:

* A new encoder preset option allows you to quickly configure the encoder based upon your preference for encoding speed and video quality
* The DivX community codec replaces the current free version of DivX, offering a wider range of performance and quality options for free through encoder presets
* Multithreaded resize filters have been added for improved performance on all HyperThreaded (HT), dual CPU (SMP) and dual core processors
* A new "Enhanced multithreading" option capable of increasing encoding rate depending on system configuration and encoding environment
* A new "Enhance texture" psychovisual enhancement method that improves picture details around keyframes and reduces the appearance of stray blocks under fast motion when encoding at lower bitrates
* MMX optimizations for the MPEG quantization method
* The DivX decoder can anonymously check for updates to the DivX codec, ensuring you are always notified of newer versions. For more information, and to enable notifications for future beta releases, click here.

Fixed:

* Fixed a problem where multiple instances of the feedback window would cause the encoder to fail
* Fixed a problem where very old DivX 5.0 content might not be decoded correctly
* The encoder GUI now adapts to screen resolutions of 800x600 or lower

Changed:

* Bitrate modulation for multipass nth pass encoding is now preset at an optimal value for quality, and this option removed from the user interface.
* The DivX Pro 6 month trial has been replaced by a 15 day trial, which can be started from the DivX encoder GUI, rather than during installation. This is because a much wider range of features are now available for free in the community codec. Previously installed 6 month trials will be honored.

Alles anzeigen

6.2 --> 6.2.1

Zitat

* Fixed reduced performance when resizing is enabled
* Fixed an error when exporting from TMPGEnc
* Fixed a problem where the "Configure" button would sometimes become disabled

6.2.1 --> 6.2.2

Zitat

* Fix an issue where parts of the picture could turn green when resizing
* Fixed truncation of the term "Psychovisual Enhancement" in the German encoder configuration interface
* Fixed a problem where only two consecutive B-frames were allowed in Unconstrained mode instead of three
* Fixed the decoder failing for bitstreams created by applications that do not correctly handle packed B-frames
* Added an option to toggle checking for updates during playback to the installer component selection dialog

r514: More vector types fixes for gcc 3.3
r515: Let the user choose the compiler with "CC=xxx ./configure"
r516: typo impaired 2pass bitrate prediction.

Zitat von Redfox

Woltest du nicht anfangs garkeine externen Skripte aufnemen, weil das angeblich zu kompliziert für den Nutzer wähe? Aber OK, wir werden sehen.

Ja aber Crestore und vorallem Restore24 sind da schon etwas andere Kaliber

Zitat von Naito

Hab das Script (leider) noch nie ausprobieren können, mein Rechner gibt sowas einfach nicht her. Versuche trotzdem etwas dazu beizutragen und dank an alle, die so hart mitarbeiten. :daumen:

Gute Quali dauert nunmal etwas länger

aber ich versuche immer einen kompromiss zwischen quali und encodingspeed zu finden

Zitat von Redfox

Crestore ist etwas schneller als Tdeint und ergibt doch ein besseres Ergebniss (meiner Meinung nach).

Nicht wenn du es mit Tdeint benutzt

Tdeint ist nur im skript für DVB und falls mal irgendein spinner ne europäische zeichentrickserie als 25i auf dvd rausbringt

Crestore und Restore24 bringen ja auch bessere ergebnisse bei Animes die nach PAL gewandelt wurden aber sowas kommt mir nicht ins Haus!
Ich besorg mir NTSC DVD's die sind bei weitem besser

Zitat von sade

Die meisten sse2 Routinen sind aber nur auf Intel CPUs schneller, auf AMDs sind sie langsamer.

trotzdem profitieren sie von sse2

Zitat von sade

sse3 bringt nicht wirklich viel. Die einzige, wichtige Instruktion ist lddqu, die unaligned loads schneller machen soll. Jedoch verwendet x264 nur bei motione estimation unaligned loads und auch da bringt es nicht viel. Bei einem Test auf meinem P4 habe ich keinen Geschwindigkeitsunterschied gemerkt.

soweit ich den changelog verfolgt habe benutzt x264 gar kein sse3

auch muss man beachten dass AMD's sse3 anders ist als Intel's sse3 weil die
Instruktionen (monitor, mwait) Hyper-Threading Funktionen sind die halt nur auf einem p4 ht laufen!

@ Redfox

Letterbox(2,2,2,2)

hatte ich sowieso vor zu entfernen weil ich gelesen hab das die meisten codecs für den übergang von schwarzen rand --> bild sehr viel bitrate benötigen und

Letterbox(16,16,16,16)

ist einfach zu breit

mit den irreführenden standartwerten bei dem resize/crop zeug's hast du recht da werde ich mal etwas sicherere werte hernehmen

und nun zu eedi2
wenn ich ins skript einbaue und er dir nicht gefällt dann reicht ein "#"
und schon bist du ihn los also wieso die aufregung ?

so nun etwas an alle v9.50 ist gerade bei mir kurz vor der fertigstellung
hauptsächliche verbesserungen werden sein:
-besseres Dehalo
-Dot-Crawl entfernung nun auch bei high motion

EDIT:
Dass mit Letterbox und Ringing hab ich jetzt verstanden wie ihr dass meint

Zitat von Deinorius

Das ist wohl wahr, kommt aber nur vom Compiler her. Direkt von der Source wird SSE2/3 doch gar nicht unterstützt. Oder red ich was falsch?

Nein auch intern also im sourcecode von x264 gibt es diverse sse2 routinen

Zitat von Deinorius

Die Leistungssteigerung bei -m 6 und 7 ist bemerkenswert, aber warum gibts keine Steigerung bei -m 5?

gibt's schon nur hat pengvado die nicht gemessen (keine zeit, keine lust)

Zitat von Deinorius

Gibts eigentlich große Leistungsunterschiede zwischen Athlon XP, P4 und Athlon 64 CPUs hinsichtlich der prozentualen Leistungssteigerung?

um wieviel prozent genau neuere prozzis schneller sind als alte weiss ich nicht aber sse2 bringt sicher nochmal ein paar % mehr speed beim encoden

Zitat von Deinorius

Ich nehme an, dass diese Leistungssteigerungen allgemein gelten

nein!
der speedgewinn bezieht sich nur auf die Bewegungsanalyse von x264

und schon wieder hat pengvado am encodingspeed geschraubt

r510: * common/ppc/pixel.c: fixed illegal implicit casts of vector types.
r511: Before evaluating the RD score of any mode, check satd and abort if it's much worse than some other mode.
Also apply more early termination to intra search.
speed at -m1:+1%, -m4:+3%, -m6:+8%, -m7:+20%
r512: Use sa8d instead of satd for i8x8 search.
+.01 dB, -.5% speed

r507: mmx implementation of x264_pixel_sa8d
r508: When evaluating predictors to start fullpel motion search, use subpel positions instead of rounding to fullpel.
about +.02 dB, -1.6% speed at subme>=3
patch by Alex Wright.

Zitat von Naito

Hab einen Deinterlacer-Test auf Doom9 gefunden. Das was ich interessant fand ist, dass dort u.a. TDeint mit EEDI2 (maxd=20, nt=150) benutz wurde und noch bessere Ergebnisse lieferte als ohne. Weiß leider nicht was das genau macht (scharfis_brain fragen, der hat mitdiskutiert), aber möglicher weise wäre es eine überlegung wert es ins Script mit auf zu nehmen.

EEDI2 für cartoon/anime ist der filter doch recht brauchbar (bei realvideo sieht die sache jedoch anders aber egal darum geht's hier nicht).

Zitat von Redfox

Mr. Brown

Hattest du eigentlich schon mal Dup von neuron2 getestet?

Ja hab ich aber selbst mit vorsichtigen settings tauchten hin und wieder ruckler auf die es in der source nicht gab!

Zitat von Deinorius

Was ist eigentlich mit dem DCTFilter? Der konnte doch Anime-Quellen recht gut komprimierbar machen.

Also bei meinen test's hat der DCTFilter keine guten ergebnisse geliefert

Zitat von MOmonster

Mr. Brown
Da du schon vier komplexe Funktionen in deinem Skript nutzt und simpel deinterlacte Normwandlungen schlechte Motion und höheren Bitratenbedarf zu Folge haben, solltest du vielleicht doch darüber nachdenken restore24 oder Crestore mit ins Skript einzubauen. Beide Version (restore24 rc + Crestore 1.0) arbeiten sehr schnell und sind auch nicht schwierig anzuwenden.

wenn jemand r24 oder crestore in seinen script braucht soll er es bitte selbst einbinden denn ich will dieses skript kompakt halten

Zitat von sade

Entschuldigung wenn das schon mal angesprochen wurde, aber ich bin noch nicht dazu gekommen mir den ganzen Thread durchzulesen.

Das wird starkes Ringes hervorufen(Gibbs Phänomen). Mit Letterbox(4,4,4,4) kann man das verhindern und verschwendet "nur" mvs, allerdings nur mit AVC Codecs.

meinst du damit das letterbox() halo's verursacht ? :nein:

Zitat von Redfox

Dafür ist NERV... äh Redfox da. :cool:
Allerdings: Das war alles 'As far as I know'! Ich wollte dich nur daruf hinweisen das die Standart-Deinterlancer bei Animes contraproduktiv sind, auch wenn man bei Mr. Browns Skript den Tdeint findet.
Wenn ich mit meinen Recherchen bisher richtig liege, ereicht man die bessten Ergebnisse wenn man das Material erst per IVTC wieder auf 24 Bilder pro Sekunde bringt und danach einen PAL-Seep-Up durchführt(Punkt 2.1.1).
Wenn ich das richtig sehe, verringert man damit auch die resultierende Datei den dadurch wird der Anime 4% kürzer(bzw. bessere Quali bei gleicher File-Größe).

also wer seine animes am pc ansieht (sowie ich) für den reicht ein IVTC auf 24p und fertig der speedup auf 25p ist nur sinnvoll wenn es auf'm fernseher laufen soll

und die bessere quali weil's kürzer ist funzt nur auf'm PC den auf'm Fernseher erzeugen PAL und NTSC genau das selbe datenvolumen!

Zitat von Redfox

Das bringt mich wieder auf ne Sache die mich schon seit einiger Zeit stört. Schauen wir uns diesen ganzen Crop, AdBorders, Letterbox, Resizekramm mal an:

# Werte für die Zielaufloesung & das Zuschneiden
Breite = 640 # mod 16 werte empfehlenswert aber nicht unbedingt notwendig
Hoehe = 480 # mod 16 werte empfehlenswert aber nicht unbedingt notwendig
Links = 4
Oben = 4
Rechts = -4
Unten = -4

### Crop ###
Crop(Links,Oben,Rechts,Unten)

### Saubere Ränder ###
LetterBox(2,2,2,2)

### RESIZE ###
LanczosResize(Breite,Hoehe) # Scharfer Resizer für hohe bitrate
#BicubicResize(Breite,Hoehe,0,0.5) # Neutraler Resizer
#BilinearResize(Breite,Hoehe) # Weicher Resizer für niedrige bitrate

Erstmal Crop:
Warum oben und unten 4 Pixelreihen weg? Das Bild ist zu diesem Zeitpunkt schon Progresiv. Ob 'Matsch'-Progressiv(Tdeint) oder echt IVTC-Progressiv ist dabei doch egal. Und warum die 4 Pixelreihen an der Seite? Der Overscan, den man enfernen sollte, ist doch nach Standart jeweils 8 Pixel breit.
Und warum dann Letterbox? Dass entfernt doch noch mehr vom Bild (durch überscheiben mit Schwartzen Balken) damit werden jetzt schon 12 Horizontale Pixelreihen entfernt und der der Overscan ist immer noch da! Auserdem ist die Aussage ### Saubere Ränder ### doch falsch, weil durch die anschlisende interpolation des Resizeing doch am rand zwischen der Letterbox'(ihr versteht hoffendlich wie ich das meine) und dem verbleibenden Bild Rundungsfehler entstehen, oder?

Und wegen dem Resizeing generel:
Da hat man das Glück das man als im PAL-Gebiet lebender ne höhere Horizontale Auflösung hat und dann soll man diese für das menschliche Auge wichtigere Horizontale Auflösung quasi kaputtmachen? No Way!
Währe es nicht besser wenn man nur in der Breite verkleinert (anamorbes enkoding ala SVCD)? Das Auge sollte diesen Detailverlust doch weniger stark warnehmen.

Ich weiss, Stand-Alone-Player's spielen MPEG4 anscheinent nur mit Statischen Pixeln(1:1) ab, aber selbstwenn ich so ein Ding hätte, würde ich den kram eher per Lanczos4Resize auf 768 × 576 bringen als wertvolle horizontale Auflösung zu killen.

Oder liege ich da mal wieder total daneben?

Alles anzeigen

das sind doch nur beispielwerte kann doch jeder kinderleicht so einstellen wie er will!

overscan kann man mit
crop(8,0,-8,0)
entfernen richtig

und mpeg4 in Sap's dass mach ich nicht !
da encode ich lieber ne saubere dvd die überall läuft

Zitat von Gothmog

Nächste Frage (sorry): Auf dem Bild mit dem Boot sieht man die Kontur des Bootes doppelt (rechte Seite vor dem Wasser). Wie lautet der Fachbegriff für so etwas und wie kriege ich das weg?

man nennt dies Egde Enhancement, Halo, Überschärfung usw.
hiermit geht's (fast) immer weg

### Vernünftiges Dehalo ala Didee 	###den   = dein_denoiser()dh    = Dehalo_Alpha(rx=3.0,ry=3.0)#.BlindDehalo3(PPmode=-3,PPlimit=4)	# <- evtl. bdh3 für starke helle halosedges = dh.removegrain(12,-1).prewitt(multiplier=2.5) \         .mt_expand().mt_inflate().mt_inflate().removegrain(12,-1).mt_expand()mt_merge(den,dh,edges)

falls noch etwas EE übrig bleibt würd ich

FastGaussBlur(2.0,2.0)

http://forum.doom9.org/showpost.php?p=632648&postcount=12

drüberjagen

dass hinterher geschärft werden sollte versteht sich woll von selbst !

Zitat von DJ oSSi

Statt der kompletten Bilder packt das Verfahren Objekte aus dem Video separat - Gesichter beispielsweise - und kann sie beim Wiedererscheinen im Film aus bereits vorhandenen Daten abbilden.

Dabei werden dann aber auch 4mal soviel Fehler wie bei motion compensation entstehen

Update

Es fällt auf das in den letzten rev's an der geschwindigkeit von x264 gefeilt wurde.

r489: Added support for ppc64. I'm really fucking tired of having to do this.
r490: interleave multiple calls to SAD. 15% faster fullpel motion estimation.
r491: more interleaved SAD. 1% faster umh, 6% faster esa.
r492: more interleaved SAD. 25% faster halfpel.
r493: yasm noexec stack
r494: fix a yasm-incompatible syntax in x86 asm
r495: store quoted configure options. needed e.g. for multiple args under --extra-cflags.
r496: cosmetics in sad/ssd/satd mmx
r497: 3% faster satd_mmx
r498: slightly faster loopfilter