Beiträge von Der_Lurchi

    Echt mehrere GB an Downloads, wieso soviel so ne ffmpeg.exe ist doch nur 90mb groß ???

    Der Win 7 PC (den ich fürs konvertieren benutze) hängt nicht mehr am Internet , was sich natürlich wieder ändern läßt, nur mach ich das eher ungern das irgendwelch Tools was auch immer so aus dem Internet sich "selbstständig" runterladen, ohne zu wissen das nachher alles so auf einen PC mitbefördert.

    Gibt es da keine andere "Offline-Install" Möglichkeit?

    Läßt sich eine vorhandene ffmpeg.exe ev. mittels eines Toos libnpp "enabled" patchen?

    Hmmm okay was bräuchte ich denn dafür alles, wäre das der richtige Download?

    https://developer.nvidia.com/cuda-downloads

    https://sourceforge.net/projects/mingw-w64/

    http://msystem.waw.pl/x265/ --> da wähl ich dann das GCC 10.2 none x265 Pack.

    https://ffmpeg.org/download.html#releases ---> was für einen FFMPEG Download brauch ich da zum selbst "compilieren"?

    https://github.com/m-ab-s/media-autobuild_suite ---> davon nehm ich die batch datei

    und mache mit dem ganzen anschliessend was genau ???

    Ich hab bislang noch nix runtergeladen/installiert (weiß ja nichtmals was ich alles brauche)

    D.h. bislang nur deinen Link d.h. dieses "issue ticket" gelesen, und der Fehler war das du bei der Cuda version 10.0 statt V10.0 eingetragen hattest, oder wie???

    nur wo hast du was eingetragen, ohne das jemals gemacht zu haben, wüßte ich nichtmals worauf sich Passagen in diesem Issue Ticket beziehen wie der non free flag, das "custom profile" & so:

    # adapt these to your environment

    _cuda_basepath="C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA"

    _cuda_version=10.0

    Ich formuliere die Eingangsfrage mal neu;
    Geht die -method option zum auswählen eines Sinc (oder anderen Scalingmedthode) per GPU nur per cli mit x.264.exe?

    Das es keine fertige FFMPEG Builds mit scale_npp gibt hat ja, offensichtlich lizenzechtliche Gründe wg der libnpp.dll aus dem CUDA SDK PAck.
    Gibt es den ein FFMPEG Build was als scale_npp "enabled" bzw. --enable-libnpp und --enable-cuda compilliert wurde, wo jedoch lediglich die libnpp.dll fehlen würde? (wäre doch vermutllich nicht illegal wenn die dll nicht dabei wäre)

    Kann man so pauschal nicht sagen: Thuban + GTX 950

    Obiges HEVC nvenc Beispiel mit verschiedenen bicubic Resizern:

    Nvcuvid Scaler = 250FPS mit ca. 30% CPU Auslastung

    FFMPEG Scaler = 130FPS mit ca. 50% CPU Auslastung ***

    FFMPEG Zscaler = 120FPS mit ca. 55% CPU Auslastung
    ***(Anm. mit sinc+accurate_rnd+full_chroma_int+full_chroma_inp gar nur noch 70FPS)

    130FPS mit FFMPEG Scaling schon aufgrund der CPU Limitierung ein Trugschluß;

    die max Anzahl an parallelen nvenc Encodes ist Nvidia hardwareseitig auf 3 limitiert doch schon bei nur 2 (!) paralellen Encodes der Thuban schlicht zu 100% gnadenlos überlastet.

    Da werden bei 3 parallen Encodes aus 130FPS ganz schnell nur noch 35FPS pro encode.

    Läuft hingegen auch das Rezise komplett über die GPU halt über nvcuvid,

    bleibt die CPU Auslastung selbst bei 3 parallelen nvenc encodes knapp unter 100%

    3 encodes parallel flitzen dann meist mit so 140FPS daher was klar ein Unterschied zu 35FPS ist.

    Das bei moderneren CPUs div. nicht ins Gewicht fällt schon klar,

    nur mit so oller Hardware bleibt nur das beste draus machen. Hab zwar noch ne GTX 1050 rumliegen die im Gegensatz zur GTX 950 zwar 10bit YUV444 nvenc kann (auch weight_prediction)

    nur das macht nicht wirklich einen nennenswerten Qualitäts Unterschied.
    Neuen PC anschaffen zu teuer würde wenn nur lohnen mit Rizen + Nvidia Turingkarte. (mit Turing soll das HEVC enc doch was besser aussehn)
    Rein per CPU alles encoded mit eigenen (brauchbaren) Settings die schon einen guten Kompromiß Speed vs. Quality darstellen encoded der Thuban mit lumpigen 7FPS, ein (bezahlbares) Rizenmodell mag um den Faktor 2-3x schneller sein nur auch damit wär ich per CPU bei max. 25-30FPS, was immer zu lang wäre um mal eben bei nem Encode daneben zu sitzen, ergo kann ich auch gleich den ollen Thuban behalten, abends mit CPU encoded Material "füttern" und über nacht die encodes laufen lassen, damits am nächsten Tag fertig ist.


    Selur

    ja, das mit dem FFMPEG selbst compilieren steht auch im Nvidia paper,

    nur was man dafür alles braucht, irgendwas mit MinWing und Cuda SDK was auch immer so,

    ich geb zu - ich versteh da nur Bahnhof &, folglich bleibt nur das was es da auf der FFMPEG Seite zum download gibt,
    womit eben "nur" Nvcuvid als GPU Scaler geht.

    bergh

    Doch Sinn macht es 20GB große H.264 Videoaufnahmen anzusammeln,

    wenn es auch 1GB als HEVC tuen würde. Und ja du hast das schon richtig erkannt, das sind nicht 0,9% sondern über 90% Platzersparniss. ;)

    Selur

    Zitat

    Mit scale_npp erlaubt NVIDIA unterstütztes resizing.

    Was per GPU Resize funtkionert ist obiges Nvcuvid zumindest mit den FFMPEG builds hier von Gyan.dev / Btbn:

    https://ffmpeg.org/download.html#build-windows

    Was jedoch nicht funktioniert scale_npp
    der scale_npp Resizer ist in diesen FFMPEG builds nicht drin. (kommt nur so ne Meldung no such filter/Feature not implemented)

    Keine Ahnung woher man ein FFMPEG Windows Build mit scale_npp herkriegt. :(

    Hab mir auchmal das Nvidia NVENC pdf* zu H264 runtergeladen (* Using_FFmpeg_with_NVIDIA_GPU_Hardware_Acceleration)

    und ja, da ist obiger nvcuvid -resize wie aus meinem Beispielcode zwar auch beschrieben,

    nur eigenartigerweise steht selbst in dem Nvidia PDF bzgl. nvcuvid -resize rein gar nix von einer "-method" option mit lanczos sinc & so,

    wie auf der Brother John seite. (daher vermute ich mal das nvcuvid wohl auch nur bicubic & sonst nix anderes kann, wenn selbst im Nvidia pdf nix von ner -method option steht)

    Hi,
    Ausgangsmaterial H264 -> H265 nvenc

    hiernach unterstützt H.264 resize ja auch lanzcos, sinc resize etc.: https://encodingwissen.de/codecs/x264/referenz/#skalieren
    nur irgendwie scheint das alles unter FFMPEG anders, als da steht um z.b. beim croppen oben unten die Balken entfernen:

    -crop 145x145x0x0
    -resize 1920x788 -----> macht ja dann nur bicubic
    nur wie sieht der Synthax für z.b. sinc aus?
    (per , wie : dranhängen schon probiert)
    Den FFMPEG Scaler möchte ich nicht benutzen, da im direkten Vergleich der FFMEP bicubic zu scharf zeichnet,
    davon ab der FFMPEG sinc sehr langsam ist.

    ffmpeg -y -hwaccel_output_format cuda -c:v h264_cuvid -crop 145x145x0x0 -resize 1920x788 -threads 1^

    -i "e:\tv\movie.mkv" -c:a copy -c:v hevc_nvenc -preset slow -rc vbr -cq 28 -qmin 27 -qmax 30 -b:v 0 -b-pyramid 2 -mbtree 1^

    -2pass 1 -spatial-aq 1 -aq-strength 3 -rc-lookahead 50 -me_range 32 -fast-pskip 0 -psy 1 -psy-rd 23.00:1.00 -b_adapt 2 -weightb 1 -weightp 2^

    "e:\newest movuie\\movie.mkv"

    Hmm nein, das stimmt so nicht - denn es ist eher so das ich ein Idiot bin :rolleyes_: , denn da lief wie ich eben erst sah doch noch ein interner vdub Filter im hintergrund mit und deswegen war da kaum ein Unterschied. :D

    So ist es korrekt:
    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: 70Minuten
    100 Minuten Clip über DGindexnv+avisnyth+ +vdub 64bit: 72Minuten

    Joa, das de/encoding mit DGindexNV spart ca. 16Minuten Zeit bei 720->720p. Gehe davon aus das es von 1050i->720p noch was besser ausfällt, weil man ja u.a. das resize über die GPU laufen lassen kann, sowie wohl auch das deinterlace - muss ich mir aber noch ansehen, wie das so von der Qualität ist.

    Bin soweit zufrieden wie es mit der GTX660 nun läuft. :ja:
    Nur die Sache wieso, das mit kleineren Karten der 7xx Serie abstürzt, werde ich dennoch mal nachfragen (Treiber war dergleiche).

    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

    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.

    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)

    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.

    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.

    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)

    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)

    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.

    Zitat

    Da bleibt dir aber nur die Box zu tauschen, weil andere Geräte nehmen DVB-T2 problemlos auf.


    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.


    Zitat

    Da du keine Hardware hast, die H265 in HW dekodieren kann, wird dir das nix bringen.


    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.


    may24
    Das setzt voraus, das man sich in dem Bereich auskennt und selbst dann, dürfte es ziemlich kostspielig + komplex werden.
    Habe nun erstmal folgendes gemacht: Eine kleine GT mit HDMI Ausgang gekauft, weil dann könnte man über einen EzRecoder vermutlich auch Zattoo o.ä. über den PC aufnehmen, ..... man könnte gar seine alte VHS Band Sammlung damit überspielen.. und man hätte leicht zu verarbeitendes H.264.
    Nur ist die Sache die aus 1050p wird 1050i, was man wieder deinterlacen müsste oder einfach die FPS auf 25 setzen, wenn man es auf 720p runterrechnet was (beides) mit Qualitätsverlust einhergeht.
    Variante 2 wäre den Videoausgang direkt auf 720p setzen, dann hätte man auch 720p als Aufnahme, was auch mit Qualitätsverlust einhergeht.
    Die Frage ist letzlich was das bessere Resultat bringt?

    hi,
    sieht gut aus und klar würde mir das reichen. :)
    Der Haken an der Sache ist ja nur, das 720p mkv ganz offensichtlich nicht so aus deiner Box kam.
    Und ich hatte die tage mal in Handbrake mit dem Thuban "The Call" umkonvertiert und das war richtig lahm,
    egal ob H.265->H.265 oder von H.265->H.264.

    H.264 1080p nach H.264 720p (über dgvindex/avisynth/vdub x.264.vfw) mit guten Qualisettings= ca. 45FPS.
    H.265 1080p nach H.264 720p (über Handbrake) bei gleichen QualiSettings = nur 9-11 FPS. :rolleyes_:
    (selbst mit schnelleren/schlechteren Qualisettings, wärens gradmal 18FPS)

    Das liegt aber nicht allein an dem Sechskerner, sondern dieses H.265 dekodieren zieht einfach unnötig CPU Leistung weg
    - daher auch meine Frage, welche KonvertierungsSoftware H.265 mittels LAV + Cuvid dekodieren würde.

    Hab mir das mal durchgelesen, SAT ist dann auch keine Option, wenn die SD Sender in paar Jahren abgestellt werden.
    HD+ macht keinen Sinn, steh nicht um 4h morgens für ein Formel1 Rennen auf - nur, weil man das nachher bei RTL nicht aufzeichnen kann.
    Zum Glück gibts für F1 aber auch ORF und bleiben nur die Serien von Sixxx,
    Hatte btw. bei Freenet wg. den Sixx Aufnahmen extra nachgefragt, die sagten bis auf die RTL-Gruppe wären die Aufnahmen unverschlüsselt.
    Ändert aber nicht, das sich manch Aufnahmen der Box trotz Abo dennoch nicht öffnen lassen.
    (hier konnte ja anscheinend auch keiner beide MPGs öffnen u./o. am PC abspielen)