DVBT2 Aufnahmen, HEVC-Stream - wie öffnen, womit weiterverarbeiten?

  • Hardware-beschleunigte Decodierung hat aber nichts direkt mit CUDA zu tun. Da geht es um einen speziellen Video-Decoder-Bereich auf dem Chipsatz der Grafikkarte. Und wenn der Videodecoder deiner Grafikkarte kein HEVC decodieren hilft, kann der noch so viele CUDA-GPGPU-Einheiten haben, die für die eigentliche Decodierung des Videos gar nicht verwendet werden. CUVID verwendet lediglich die CUDA-API zum Ansteuern des Videodecoders. Man kann dafür aber auch andere APIs verwenden. Gegenüber der DirectX-API gibt es bei CUVID sogar Nachteile. Darüber diskutiert man im doom9-Forum immer und immer wieder.

  • Und wieso konvertiert H.264 über vdub dann soviel schneller wenn man DGIndexNV als Cuda Framerserver nimmt?
    Man sieht schon an der steigenden Temperatur sowie mittels GPUz das die Grafikkarte da sehr wohl irgendwas berechnet (was die CPU dann nicht mehr berechnen braucht).
    Hatte früher dafür nur eine GTS250 genommen (später eine GT460) und diese uralten Nvidia unterstützten hardwareseitig nichtmals H.264:
    https://forums.geforce.com/default/topic/…c-a-k-a-h-265-/

    Dasgleiche mit H.265 + GTX660, ohne Cuvid als Hardwarebeschleunigung = mind. 70% CPU Auslastung
    Mit Cuvid+MadVr = max. 10% CPU Auslastung
    Das ist aber schon ein Unterschied und nein, die GTX660 unterstützt auch kein H.265 wie aus der Liste oben zu entnehmen
    - trotzem entlastet das Ding massiv die CPU. (in Pod/Kmplayer)
    Alte Phenoms sind bekanntlich nicht die schnellsten: 1050p HEVC/H.265 lassen sich dennoch mit nur 1,4GHZ CPU Takt flüssig in Verbindung mit der GTX660 abspielen - schalte ich auf die AMD/ATI IGP um, braucht dergleiche PC aber dann schon 2,5-3GHZ an CPU Takt fürs abspielen des gleichen H.265 videoclips.

    Kann also irgendwie so nicht ganz sein, das das über eine GPU angeblich nichts bringt wenn eine Karte diesen oder jenen Codec hardwareseitig nicht per intregrierten Decoder unterstüzt.

    17 Mal editiert, zuletzt von Der_Lurchi (1. Mai 2017 um 00:48)

  • Welche Box von welcher Firma hast du?
    Hab das mit unserer Box mir nochmal angesehen, das Knacken ist doch nicht nur in den Aufnahmen, sondern auch am TV. Ist mir nur nicht aufgefallen, weil es aussschliesslich bei Spielfilmen auftritt (die ich aber nicht live gesehen, sondern aufgenommen hatte). Bei Sendern wie ZDF Neo ists ganz schlimm, aber auch bei den anderen ÖR.
    Hier mal eine "Hörprobe": https://www.file-upload.net/download-12472…-ger_1.mp4.html
    Geräteempfangsqualität und Stärke lt Gerät angeblich 100%
    Antenne ist eine aktive mit Verstärker.


    Ja, die 100% geben die gerne an, auch wenn es nicht stimmt. Ich hab zwar kein DVB-T2, sondern DVB-C und hatte da anfangs auch Probleme.


    Wenn das in videoplayern mittels CUDA geht eine CPU beim Playback drastisch zu entlasten, wieso sollte das in anderer Software nicht gehen?? :huh:
    Da zumindest steht auch was anderes als du sagst: https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode
    Demnach unterstützt FFMPEG wohl CUDA und dieses Cuvid ist doch genau dasgleiche wie in den videplayern per LAV.

    Ja, und da steht

    Zitat


    CUVID offers decoders for H264, HEVC, MJPEG, mpeg1/2/4, vp8/9, vc1. Codec support varies by hardware.

    Du hast oben angeben, dass du ne GTX 660 besitzt. Mit Kepler GK 106 Chip ... der kann nur H264.
    https://developer.nvidia.com/video-encode-d…-support-matrix

    Was es (nur unter Windows) gibt, sind diese Hybrid Decoder (so halb Software, halb auf Hardware beschleunigt). Die unterstützt ffmpeg aber nicht.

  • Genau so sieht es beim Playback von H.265/HEVC mit der GTX660 aus:

    [Blockierte Grafik: http://img5.fotos-hochladen.net/thumbnail/madvr1b8dwu9j3ydzgnlb7wf4_thumb.jpg]

    Oben mind. 70% CPU Auslastung ohne cuvid/Madvr
    und das ganz egal, ob DXVA native oder copy back ausgewählt oder gar nix, das senkt alles die CPU Last nicht dermassen wie eben die Kombination von cuvid+MadVR.
    Wieso das so ist, weiss ich nicht - ich sehe nur , das eine Grafikkarte sehr wohl die CPU entlasten kann und auch dann wenn sie überhaupt kein H.265 unterstützt.
    Und ok, dann geht das nicht über FFMPG, aber es wird doch gewiss irgendeine Convertierungsoftware geben die es dann kann, wenn sowas sogar schon in Freeware Playern geht. (ein Teil der Rechenarbeit auf die GPU zu schieben)

    5 Mal editiert, zuletzt von Der_Lurchi (1. Mai 2017 um 01:18)

  • Genau so sieht es beim Playback von H.265/HEVC mit der GTX660 aus:


    Nur aus Interesse (damit ich es mit meinem i5 vergleichen kann):
    Was für ne CPU hast du denn und wie sieht die Auslastung aus, wenn du es mit vlc abspielst?

  • Ist das alte AM2+ System mit dem AMD Thuban.
    Bzgl. VLC der kann die H.265 TV Aufnahmen nicht richtig abspielen, produziert nur Bildfehler und das Bild bleibt da einfach stehen.
    Problemlos abspielbar sind die H.265 hingegen in (fast) allen anderen Playern wie KM Player, Podplayer, MPC HC - in allen 3Playern funktioniert o.g. Combi (NVcuvid+MadVr).

    Und wie schon gesagt, da das ja in videoplayern ganz offensichtlich funktioniert, such ich halt adhoc auch nach einer Software, wo H.265 -auf welche Art technisch auch immer- zumindest teilweise über die Grafikkarte dekodiert wird und das eigentliche H.264 Encoding dann über die CPU. (Encoding über die GPU braucht das Program nicht haben, das war schon über dieses Badaboom nicht sooo toll von der Quali)

    16 Mal editiert, zuletzt von Der_Lurchi (1. Mai 2017 um 09:38)

  • Das bereits genannte DGIndexNV/DGDecNV arbeitet doch über die selbe CUVID API wie LAV Video, oder? Wenn LAV Video darüber mit Deiner GTX660 also tatsächlich HEVC dekodieren kann, wenn auch nur hybrid, dann könnte es damit auch funktionieren. Im LAV Video-Fenster kann man beim Abspielen nachschauen, ob wirklich "cuvid" oder doch der "avcodec"-Fallback genutzt wird ("Active Decoder").

    Als Notnagel kann man auch LAV Video über dss2()/DirectShowSource() oder äquivalente Funktionen über AviSynth oder ffmpeg und Co. nutzen.

    2 Mal editiert, zuletzt von sneaker2 (1. Mai 2017 um 12:25)

  • Ich weiss nicht über welche Schnittstelle DGIndexNV/DGDecNV arbeitet.
    Das Program selbst funktionierte immer wunderbar mit meiner alten GTS, verweigert aber unter der GTX660 den Dienst (cuModuleLoad NV12toRGB24_sm_20.cubin failed (300)
    Dürfte aber schlicht daran liegen, das meine Version einfach zu alt ist - denn gekauft hatte ich die Software vor rund 6Jahren (32Bit XP Version). Das Ärgerniss mit DGIndexNV war allerdings, das die Software quasi auf den den ollen VIA Mini PC mit Internetverbindung "gedongelt" war, bin aber offensichtlich nicht der einzigste gewesen, der damals nicht kapierte wie die Software von PC A nach PC B zu aktivieren geht.
    (gab ja auch hier im Forum dbzgl. Tread, obgleich sich das aufs DGDecNV bezog): http://forum.gleitz.info/showthread.php…NV-Lizenz/page2

    Und ok, irgendwie hatte es nachher doch funktioniert.
    Nur, jetzt zum zweiten mal DGIndexNV bezahlen, um wieder irgendwelch "exotische" Aktivierungs-Abenteuer zu haben, also ich weiss nicht, dann vergess ich das lieber mit dem H.265 umconvertieren und kauf mir einen EZRecorder.
    Das muss zwar auch umkonvertiert werden, dürfte aber nicht so lange dauern wie H.265 Sachen.

    4 Mal editiert, zuletzt von Der_Lurchi (1. Mai 2017 um 20:08)

  • Die Lizenzen sind meines Wissens lebenslang gültig für sämtliche Software des Autors. Falls Du Probleme mit Fehlermeldungen und/oder Lizenzen-Transfers hast, würde ich direkt im Forum des Autors fragen. Mag aber sein, daß Nvidia mit neueren Treibern teilweise alte Karten nicht mehr voll unterstützt. Je nach Betriebssystem könnte vielleicht ein älterer/neuerer Treiber das Problem lösen.


  • (Encoding über die GPU braucht das Program nicht haben, das war schon über dieses Badaboom nicht sooo toll von der Quali)


    Meine 1060 hat H264&H265 Encoding über HW. Kommt nicht an einen Software Encoder ran, aber nicht mehr so schlimm wie früher.
    Per GPU dekodiert, skaliert und encodiert - ffmpeg zeigt fps=382 - also langsam ist es nicht und lastet die CPU praktisch nicht aus ;)

  • Hab mich final fürs aufnehmen via. H.264 entschieden, da ich zuviel Probleme mit den H.265 Files sehe. Was DGIndexNVbetrifft, hab die Software seit Umstieg auf die GTX nicht mehr installiert gehabt (lief ja auch nicht damit)
    Finde adhoc zudem nicht in welchem alten Backup es mitsamt der Lizensdaten rumliegt.

    Wie bindet man FFMPEG cuvid zum dekodieren von H.264 in ein avs Script ein?

  • Dass DGDecNV in einer früheren Version mit früheren Treibern nicht auf aktuellen Chips lief, muss nicht heißen, dass es das heute mit aktuellen Versionen von Software auch nicht tut (ich glaube, das erforderte u.a. ein Update der Dateien NV12ToRGB24_sm_*.cubin). Außerdem sollte Donald Graft in der Lage sein, den Nutzer-Lizenzschlüssel noch mal nachzusenden; der berechtigt ja auch zum Einsatz seiner Software auf mehreren Systemen, ist also nicht weiter schlimm, wenn mal noch ein zusätzlicher Maschinen-Lizenzcode generiert wird.

    Eine ffmpeg.exe wird man wohl nicht als Videoquelle für AviSynth-Skripte verwenden können, höchstens asynchron (zwischendurch Y4M ausgeben lassen) – das würde aber gerade keinen Geschwindigkeitsvorteil bringen. Wenn FFMS2 und L-SMASH Works keinen hardwarebeschleunigten Decoder verwenden, kannst du nur hoffen, dass LAV Filters nativ (DSS2Mod) oder via DirectShow das tun.

  • Hab mal in mein gmx Postfach geschaut, in der Hoffnung vielleicht da die alte Aktivierungsmail noch zu finden, sind nur keine Mails mehr von 2011 drin gespeichert und im Paypal kann ich auch nicht soviel Jahre zurückgehen. :rolleyes_:
    Um das Elend abzukürzen - bin ich jetzt hierhin und das ganze halt nochmals bezahlt. : http://rationalqm.us/dgdecnv/dgdecnv.html
    Nur, wieso steht da eigentlich DGDecnV - ist doch dasselbe wie DGIndexNV oder? :huh:

    Zitat

    Therefore, at this time series-500 and earlier cards are not supported on Windows 10 for DGDecNV. It is not known at this time if nVidia will extend full support to these older cards on Windows 10. These older cards may still be used successfully on Windows 7/8/8.1.


    Demnach sind Modelle der 5xx und davor nicht mehr supportet, sollte ja dann mit der GTX660 laufen.

    4 Mal editiert, zuletzt von Der_Lurchi (2. Mai 2017 um 17:04)

  • "DGDecNV" bezeichnet glaube ich das gesamte Softwarepaket, "DGIndexNV" speziell das ausführbare Programm mit der grafischen Oberfläche aus diesem Paket, das u.a. die Index-Datei erzeugt.

  • Genau. DGDecNV ist das ganze Paket, bestehend aus der DGIndexNV.exe zum Generieren der *.dgi-Indexdatei und der DGDecodeNV.dll zum Decodieren in AviSynth.

    Einschränkungen der Kombination aus Hardware und Software sind natürlich ärgerlich; aber so puschen sich die Hersteller gegenseitig, und das halt auf Kosten der Benutzer.

    Ich habe bisher nur höchstens eine GT 450, ansonsten noch GeForce 9K. Da hab ich schon mal einen weiteren Grund, den Umstieg auf Windows 10 herauszuzögern, "bis es mir mal zu gut geht" ...

  • Hehe, jenach PC Forum wird sowas aber gar nicht gerne gehört, einen Umstieg auf Win 10 rauszuzögern.:D
    Komm als Nicht-bis-wenig Zocker gar noch mit XP hin und was da nicht mehr drin läuft, halt im Win7.
    Win 10 ist zwar auch installiert, habs aber bis heut nie genutzt. Hoffe die neuere DgindexNV Version läuft noch im XP, denn hab binnen kürzester Zeit 2TB an Writes im Win7 auf die SSD wg. der H.265 files (meist wg. "rumtesten":rolleyes_:) verbraten. Nicht das ich die SSds schonen würde, fand das aber schon was viel.
    Im XP kann ich das meiste hingegen übers 12GB Ramdrive laufen lassen. (was zudem auch schneller geht)

  • So Program ist da und wie sollte es bei meinem Glück anders sein, es klemmt hinten und vorne. :D
    Ja, das encoding läuft im XP nun schnell, die neue DGvindex Version crasht nur dummerweise vdub nach spätestens 1Minute.

    OK also ins Win7, avisynth 2.6 habe ich aber nur als 32bit gefunden - gibts das nicht in 64bit?
    Ja keine Ahnung, sehe nur das Vdub 64Bit das avs File nicht öffnen kann.
    Vdub 32Bit + Dgvindex im Win7 hingegen funktioniert, ist nur dummerweise langsamer, als wenn man vdub 64bit direkt mit dem mp4 füttert.
    Hinzukommt das das indizieren seitens DGvindex von H.264 wenn es als mp4 vorliegt, warum auch immer sehr lang dauert. Als mkv geht das indizieren zwar wesentlich schneller, macht aber keinen tieferen Sinn extra umkontainern, da sowas genauso wie die Tonspur demuxen auf HDDs einfach viel zu lang dauert. (hab im win7 kein ramdrive)


    Also, ich werd jetzt erstmal in dieses Forum gehen
    und fragen ob die nicht einfach eine andere cubin für die alte XP Version schicken können, denn so macht das keinen Sinn.

    3 Mal editiert, zuletzt von Der_Lurchi (3. Mai 2017 um 12:55)

  • Um AviSynth-Skripte in einem 64-bit-Programm verwenden zu können, braucht man ein 64-bit-AviSynth. Inklusive aller sonstigen Plugins in 64-bit-Code. Mit 32-bit-Code mischen geht nicht.

    Die Entwicklung des ursprünglichen AviSynth 2.x in 64-bit-Code kann man vergessen; bleibt also nur der Umstieg auf AviSynth+, wenn man beides abwechselnd verwenden wollte. Dabei immer auf die aktuelle MT-Version updaten und nicht mit den beiden Systemverzeichnissen durcheinander kommen.

    Die Antwort, wenn bei Donald Graft jemand jetzt noch um Unterstützung für Windows XP bittet, kann ich mir schon lebhaft vorstellen ... :nein:

    Dass das Remultiplexen und Indexieren "sehr" lange dauern soll (im Verhältnis zu einer Konvertierung mit kompletter Neuberechnung des Videos), überrascht ein wenig; sind deine Festplatten so alt (kein SATA II, wenig Cache), dass es länger als 2 Minuten braucht?

  • Habs auf dem Thuban mal ausprobiert und lag nicht am XP. (will nur nicht mit 7xxer Nvidias laufen, mit der 6xxer Serie aber schon). Ist im Grunde aber egal mit dem XP, da es darüber langsamer ist wie ich eben feststellen mußte.

    Womit nur Win7 interessant ist und danke für den Link ;) ,
    und unter Win7 ist Sache nun letzlich die (anhand eines 5inuten clips hochgerechnet):

    100 Minuten Clip über vdub 64bit (FFMPEG Plugin): 86Minuten
    100Minuten Clip über vdub 32bit (FFMPEG Plugin): 100 Minuten
    100 Minuten Clip über DGindexnv+avisnyth 2.6+vdub 32bit: 84Minuten
    100 Minuten Clip über DGindexnv+avisnyth+ +vdub 64bit: 85Minuten
    Indizieren --> + 4Minuten
    Demuxen der Audiospur --> + 1.30Minuten
    = 5.30Minuten > 89-90Minuten

    13 Mal editiert, zuletzt von Der_Lurchi (3. Mai 2017 um 20:50)

  • Das Decodieren war noch nie der Flaschenhals, wenn der Encoder über 90% der gesamten Rechenzeit während der Konvertierung benötigt. Und je komplexer die Encodierung (darin auch: je größer die Bildfläche), umso höher der Anteil der Video-Encodierung am gesamten Zeitbedarf.

Jetzt mitmachen!

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