DGDecNV Joke oder nicht?

    Hi ich beschäftige mich gerade etwas mit DGDecNV und FFAudioSource.

    Dabei finde ich aber DGDecNV irgendwie extrem schwach.

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\DGDecNV\DGDecodeNV.dll")
    DGSource("F:\daddy.dgi")
    BicubicResize(688,544,0,0.6,6,0,1268,688)
    AddBorders(16,16,16,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CCE Speed 4.01

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
    Audio=FFAudioSource("F:\720.mkv")
    Video=FFVideoSource("F:\720.mkv")

    AudioDub(Video, Audio).AssumeFPS(25, true)
    BicubicResize(688,544,0,0.6,6,0,1268,688)
    AddBorders(16,16,16,16)
    ConvertToYUY2()

    CCE Speed 4.75

    Intel QuadCore 6600 auf 3000 mhz übertaktet.
    8 Gig Ram DDR 800
    GF 9600 GT
    Testfile MKV 720

    Das bringt irgendwie gar nix im gegenteil?. Wir kann das sein?. Treiber sind die neuesten.

    Einmal editiert, zuletzt von trecordings (2. Oktober 2010 um 20:59)

    Sind sie doch?

    Auch wenn ich AudioDub wegmache also nur VIDEO nehme ist FFSource schneller. Normal dürfe das nicht sein egal ob mit oder ohne Audio.

    Und willst Du damit sagen das die GF 9600 nicht schnell genug Decodiert und das meine CPU solo schneller ist wenn sie Decodiert, Resize, und Enkodiert?!!!!!!!!!

    Hier mal ein 1080 MKV

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\DGDecNV\DGDecodeNV.dll")
    DGSource("F:\daddy.dgi")
    BicubicResize(656,544,0,0.6,2,0,1916,1088)
    AddBorders(32,16,32,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CCE 1.94

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
    FFVideoSource("F:\1080p.mkv")
    BicubicResize(656,544,0,0.6,2,0,1916,1088)
    AddBorders(32,16,32,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CCE 2.80

    DirectShowSource("1080p.mkv")
    BicubicResize(656,544,0,0.6,2,0,1916,1088)
    AddBorders(32,16,32,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CCE 1.68

    Einmal editiert, zuletzt von trecordings (2. Oktober 2010 um 22:12)

    Ruhig bleiben. Hinsetzen. Tee trinken. Und mal die Taste mit 1 und ! putzen, die klemmt bei dir. (Recht hat nicht, wer am lautesten schreit, sondern wer die Ursache versteht.)
    __

    Und dann nennst du uns mal deine kompletten technischen Daten.

    Ja, es ist nicht ausgeschlossen, dass extrem schnelle CPUs mit mehreren Kernen mit ffmpeg-mt-Decoder schneller sein können als ein eher langsamer Decoder in einer GPU. Und die 9600 ist durchaus nicht die schnellste aller Nvidia-Grafikkarten. Möglicherweise auch bei der PureVideo-Decodierung. Immerhin geht es ja nicht nur um die bloße Verarbeitung -- das Video muss ja nach der Decodierung auch wieder unkomprimiert aus der Grafikkarte über den Bus zurück in den RAM.

    Zitat

    Und dann nennst du uns mal deine kompletten technischen Daten.

    Welche?
    Gelesen haste aber oder nur die Ausrufungszeichen?
    Was soll das bringen?

    Intel QuadCore 6600 auf 3000 mhz übertaktet.
    8 Gig Ram DDR 800 Geil Value., 4x2 Gig
    Gigabyte GeForce 9600 GT Passiv, 1024MB GDDR3, VGA, DVI/ HDMI
    MSI P45 Neo3-FR, P45 (dual PC2-6400U DDR2) (7514-040R)
    4x320 WD Blue im Raid 0

    Allgemein
    Vollständiger Name : F:\1080p.mkv
    Format : Matroska
    Dateigröße : 5,62 GiB
    Dauer : 57min
    Gesamte Bitrate : 13,9 Mbps
    Kodierungs-Datum : UTC 2009-11-24 16:47:33
    Kodierendes Programm : mkvmerge v2.9.8 ('C'est le bon') built on Aug 13 2009 12:49:06
    verwendete Encoder-Bibliothek : libebml v0.7.7 + libmatroska v0.8.1

    Video
    ID : 1
    Format : AVC
    Format/Info : Advanced Video Codec
    Format-Profil : High@L4.1
    Format-Einstellungen für CABAC : Ja
    Format-Einstellungen für ReFrame : 4 frames
    Format_Settings_GOP : M=2, N=19
    Muxing-Modus : Container profile=Unknown@4.1
    Codec-ID : V_MPEG4/ISO/AVC
    Dauer : 57min
    Bitrate : 12,4 Mbps
    Breite : 1 920 Pixel
    Höhe : 1 080 Pixel
    Bildseitenverhältnis : 16:9
    Bildwiederholungsrate : 23,976 FPS
    ColorSpace : YUV
    ChromaSubsampling : 4:2:0
    BitDepth/String : 8 bits
    Scantyp : progressiv
    Bits/(Pixel*Frame) : 0.249
    Stream-Größe : 4,90 GiB (87%)
    verwendete Encoder-Bibliothek : x264 core 78 r1301M bcba15d
    Kodierungseinstellungen : cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.5:0.0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=4 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=12400 / ratetol=1.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:0.80
    Sprache : Englisch

    Audio
    ID : 2
    Format : DTS
    Format/Info : Digital Theater Systems
    Codec-ID : A_DTS
    Dauer : 57min
    Bitraten-Modus : konstant
    Bitrate : 1 510 Kbps
    Kanäle : 6 Kanäle
    Kanal-Positionen : Front: L C R, Side: L R, LFE
    Samplingrate : 48,0 KHz
    BitDepth/String : 24 bits
    Stream-Größe : 625 MiB (11%)
    Sprache : Deutsch

    Wobei ich jede wette, wette das hilft nicht die bohne weiter.

    Zitat

    Ja, es ist nicht ausgeschlossen,


    Sprich Du hast auch keine ahnung und spekulierst nur. :)

    Nun weiß ich auch warum es von dem Tool keine Demo gibt. Dann würde man feststellen das es nur unter Labor Bedingungen was bringt.

    Falls noch jemand eine wirklich Idee hat nur herraus damit. :)
    Ansonsten kismet tool ist für mich Schrott.

    Kurz:

    Resize mal auf 720p (oder gar nicht), mach' das Encoding mit x264.exe --preset slower, und dann vergleiche die beiden Dekoder nochmal.


    Lang:

    Man muss den Gesamtkomplex betrachten.

    Niemand hat jemals behauptet, dass Dekodieren per Grafikkarte den Rekodierungsprozess zwangsweise beschleunigt. Der Punkt ist schlicht und einfach, dass die benötigte CPU-Zeit für das Dekodieren der Quelle von soundso-viel Prozent auf Null Prozent fällt. Die somit freigewordene CPU-Zeit kann für andere Zwecke genutzt werden, vorzugsweise Avisynth-Filterung.

    Wenn das Material eher aufwändig mit Avisynth gefiltert wird, dann steht durch DGDecodeNV dafür einfach mehr CPU-Kapazität zur Verfügung.

    Wenn die Anforderungen kleiner sind (betreffs Zielauflösung/Encoderkomplexität), dann kann es durchaus passieren, dass der Leistungsbedarf der gesamten Kette so "gering" ist, dass die CPU alleine damit schneller fertig wird, weil die Dekodierung per GraKa zum Flaschenhals würde.

    Außerdem nicht vergessen, dass das Dekodieren auf der GraKa (zumindest bei Nvidia) gar nicht über die eigentliche GPU erfolgt, sondern über einen separaten Dekoderchip. Und der ist nicht unbedingt dafür gedacht, um ultimative Geschwindigkeitsrekorde zu erzielen ... wenn der genug Power hat, um 1080p schneller als Echtzeit zu Dekodieren, dann hat er seinen Zweck (aus Herstellersicht) ja bereits erfüllt.

    Bei den modernen Karten kann eine GT240 (das unterste Low-End vom Mid-Range) 1080p-Video mit ca. 100fps dekodieren, je nach Quelle 90-120 fps. Und das ohne CPU-Belastung. Damit stehen einem "100%" Cpu-Leistung zur Verfügung, um Full-HD mit maximal dieser FPS-Geschwindigkeit zu enkodieren.

    Ich hab' vor einiger Zeit auf Doom9 (English) einen DGDecNV Benchmark-Thread gestartet: http://forum.doom9.org/showthread.php?t=155911

    Wenn man sich alle Ergebnisse mal genau anschaut wird es klar, dass die Decoder-Geschwinigkeit fast nur vom verwendeten Chip abhängt (VP2, VP3, VP4). Eine billige G210 ist da schneller als eine GTX275 weil sie einen VP4 chip hat. Also, die Decoder-Geschwindigkeit hat nichts mit dem Tool zu tun.

    Wenn Du mal nur die Decoder-Geschwindigkeit messen willst, kannst Du dieses Tool versuchen (CLI): AVSInfo.

    Zitat

    Der Punkt ist schlicht und einfach, dass die benötigte CPU-Zeit für das
    Dekodieren der Quelle von soundso-viel Prozent auf Null Prozent fällt. Die somit
    freigewordene CPU-Zeit kann für andere Zwecke genutzt werden, vorzugsweise
    Avisynth-Filterung.

    Wenn das Material eher aufwändig mit Avisynth gefiltert wird, dann steht durch
    DGDecodeNV dafür einfach mehr CPU-Kapazität zur Verfügung.

    Das ist gut. :cheers:
    Das ist eine absolut Logische erklärung. Da ja Avisynth kein QuadCore kann
    kann es auch die freigewordene CPU Power nicht nutzen. Das klingt absolut einleuchtend.
    Und da die Grafikkarte nicht die stärkste ist geht die CPU Last auch nur wenig zurück. Das teste ich gleich noch in wie weit die CPU Last sich unterscheidet in beiden Scripten.

    Demnach ist das auch ein klassicher Denkfehler das es schneller wird, wenn Avisynth limitiert.

    Nicht zu vergessen, dass man mit DGDecNV auch den PureVideo Deinterlacer (der IMHO garnicht mal so schlecht ist!) benutzen kann,
    als auch schon den Resizer der Grafikkarte nutzen kann.

    D.h. man könnte 1080i60 mit dgdecnv in 720p60 umwandeln. Komplett ohne CPU-last!
    Das kann man dann an einen Encoder der Wahl schicken, der sich dann genüsslich über die CPU hermachen kann.

    Zitat

    Resizer der Grafikkarte

    Wie geht das?. Gibt doch nur Crop als Option in DGDecNV?

    So hier die ergebnisse CPU

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\DGDecNV\DGDecodeNV.dll")
    DGSource("F:\daddy.dgi")
    BicubicResize(656,544,0,0.6,2,0,1916,1088)
    AddBorders(32,16,32,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CPU last 25-30% wobei CCE 20-25% last hat und der CUVIDServer 2-5% last

    LoadPlugin("D:\Eigene Dateien\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
    FFVideoSource("F:\1080p.mkv")
    BicubicResize(656,544,0,0.6,2,0,1916,1088)
    AddBorders(32,16,32,16)
    AssumeFPS(25.000, true)
    ConvertToYUY2()

    CPU Last 80-90% wobei der CCE diese last alleine veruracht.

    Damit ist das eigentlich klar. Avisynth also das Resize wird den CCE auf 25% bremsen. Weil 25% sind genau ein Core was Avisynth nutzt.

    Zitat

    Avisynth gibt es auch mit Unterstützung für MultiThreading. Funktioniert gut.


    Aber nicht das Resize. Meine Tests mit Avisynth MT und Resize sind alle negaitv verlaufen. Das Resize ist ja die Haupt last der Sache.

    Zitat von trecordings

    Aber nicht das Resize. Meine Tests mit Avisynth MT und Resize sind alle negaitv verlaufen. Das Resize ist ja die Haupt last der Sache.


    Dann ist irgendwas nicht richtig. Wie im anderen Thread beschrieben: Mit einem nur-Resize-sonst-nichts Script erziele ich durch MT locker eine Verdoppelung der Geschwindigkeit.

    Welches ist die genaue Avisynth-Version die Du dafür genommen hast, und wie hat das Script genau ausgesehen?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden