Wo ist die Qualität von "DGDecodeNV.dll" anzusiedeln?

Äh was ? DGDecodeNV ist ein Indexer tool für AVC Material was zusätzlich die Nvidia GPU miteinbezieht um fixer zu decodieren.
Es ist mir absolut neu das das .dll auch Deinterlace Funktionen parat hat :hm: Kann sein das du da was durcheinander wirfst ?
Was die Qualität von DG's tools angeht die ist absolut super und den Preis auf jeden Fall wert.
Der Decoder ist sehr stabil - auch bei interlaced Material - und excellent für die Verarbeitung mit AviSynth geeignet.
Was die Bildqualität angeht, so müssen alle Normgerechten Decoder das selbe Bild liefern. Der MPEG-4 AVC Standart beschreibt nämlich "nur" wie das Bild zu decodieren ist (nicht wie man das vorher macht).

Zitat

Wie ist die Qualität bei diesen Funktionen? Besser als bei TDeint und Co, oder wie?

Nein.

Zur Qualität des Deinterlacers:
Wie gut das Deinterlacing ist, kannst Du einfach sehen, in dem Du einen normalen Decoder verwendest, der cuvid verwenden kann (z.B. LAV Filters).
An gute Software Deinterlacer wie (Q)TGMC und gute IVTC Filter wie TIVTC kommt er definitv nicht ran.

Zur Qualität des Resizers zitier ich mal neuron2:

Zitat

The resizer is a simple bilinear resize. Do resizing in your script if that does not meet your needs. I find it adequate for downsizing, especially when I want the result in a hurry.

Quelle: https://forum.doom9.org/showthread.php?p=1536043#post1536043

Gründe die ich sehe um DGDecodeNV zu verwenden:
1. wesentlich besserer MPEG-Container support wenn die Files in einzelnen Dateien rumliegen, also vob, mpg, ts,m2ts Dateien (das DG seine Tools kein ordentlich IFO parsing können finde sehr enttäuschend)
2. ordentliches dekodieren von interlactem H.264 und VC-1 Material (ffmpegsource, was die einzige alternative wäre, hat da so seine Probleme)
3. kommt auch mit mehr progressiven H.264 Streams klar als ffmpegsource
4. lagert eine Teil des Decodingaufwandes auf die GPU aus (lohnt i.d.R. nur bei älteren Rechnern und wenn man unter RealTime encoden muss/will,...)

Cu Selur

Ps: Angemerkt sei, dass ich selber DGDecodeNV nicht nutze, da ich so gut wie nie mit interlactem AVC oder VC-1 Material zu tun habe. (würde ich mir aktuell nur kaufen, wenn ich es auch ohne Avisynth in der Konsole nutzen kann, aber laut DG wird ein raw output an den STDOUT wohl nicht kommen, weil ihn wohl außer mir niemand will :))
PPs.: Kann DGDecodeNV nicht schon fast immer auch Deinterlacen?

Zitat von may24

Was die Bildqualität angeht, so müssen alle Normgerechten Decoder das selbe Bild liefern.

Nein. Das wäre nur der Fall, wenn beim Decodieren korrekte mathematische Verfahren angewendet würden. Das werden sie aber nicht. Erweiterungen wie SSE, MMX, 3DNow usw. sind zwar schneller als genormte Rechenvorschriften (IEEE 1188), aber auch ungenauer, so daß das Bild eben nicht identisch ist. Und hier stellt sich dann natürlich die Frage: ist CUDA zwar besonders schnell, aber auch besonders schlampig? Oder vielleicht sogar besonders gut?

Weiterhin sind Decoder zum Abspielen darauf ausgelegt, ein flüssiges Bild zu liefern. Wird es eng mit der Prozessorlast, dann schludert man eben etwas, und lässt beispielsweise das Deblocking weg. Und wenn das nicht reicht, dann lässt man lieber ein paar komplette Frames fallen.

Decoder zum Transcodieren sind da anders priorisiert. Lieber etwas zu langsam, als die Bildqualität zu verschlechtern oder gar Bilder wegzulassen.

Gruß

akapuma

Also, ich möchte mich hier nicht allzu weit aus dem Fenster lehnen, aber ich dachte eigentlich auch, dass bei AVC der Standard so ausgelegt ist, dass jeder (normgerechte) Dekoder ein absolut identisches Ergebnis liefern müsste? (War's nicht so, dass die Operationen mit Integer-Operationen durchgeführt werden, statt mit Float?) Gerade das war doch einiges der wichtigen Ziele/Neuerungen im AVC Standard. Beim Mpeg-2 und Mpeg-4/ASP Standard war das ja einer der ewigen & unvermeidlichen Problembereiche, weil da nix definitives festgelegt war, sondern quasi nur ein "Toleranzbereich". Aber AVC sollte beim Dekodieren doch schon deterministisch sein. Oder nicht?

Stimmte Didée zu, alle Standard konformen Decoder müssen erst mal das gleiche Bild ausgeben,...

Oh - tut mir leid. Da hab ich wohl Blödsinn geschrieben:

Zitat von Wikipedia

H.264 baut weitestgehend auf seinen Vorgängern MPEG-1, MPEG-2, MPEG-4 und der H.261-Familie auf, weist jedoch deutliche Veränderungen und Erweiterungen auf:

Anstelle einer Diskreten Kosinustransformation (DCT) mit 8×8 Pixel großen Blöcken wird eine Integertransformation auf 4×4 Pixel (im High-Profile zusätzlich wählbar bis 8×8 Pixel) großen Blöcken verwendet.

Also: keine Probleme mit verschiedenen iDCT-Implementierungen, wie ich dachte. Sorry.

Gruß

akapuma