ZitatAlles anzeigenVersion 1.0.6
1. Added support for double rate deinterlacing.2. Released shared memory properly on termination.
3. Fix memory issue causing crash with latest Nvidia drivers.
4. Fix for streams with cropping on the right.
5. Server opens in the system tray.
6. Fix problem with transport streams that have a PES header split between transport packets.
DGAVCDec + DGAVCDecDI: MPEG4-AVC-Quellfilter für AviSynth
-
-
Du solltest immer mit erwähnen, dass es sich hierbei eher um die CUDA-Version für nvidia-Grafikkarten handelt, denn Deinterlacing beherrscht die libavcodec Version nicht.
-
Bevor einer schneller ist als ich!!
Version 1.0.8http://forum.doom9.org/showthread.php?p=1219571#post1219571
Grüße
-
Dann hat aber jemand die 1.0.7 übersehen... also hole ich die Changelogs noch mal nach:
Version 1.0.7:
- Fixed a bug in the handling of open GOPs that caused problems if the first GOP in the stream is open.
Version 1.0.8:
- Fix bug in demuxing of DTS audio tracks.
- Fix problem with random access.
So weit scheint das alles unabhängig von GPU-Beschleunigung zu sein.
-
Ihr mischt hier ganz schön durch
DGAVCIndex ist bei Version 1.0.7
DGAVCIndexNV ist bei Version 1.0.8
Ist allerdings nur für Nvidia-GPUs ab 8xxx und ist kostenpflichtig (15$). -
-> Wäre schön wenn derjenige der das nächste DGAVCIndexNV - Update postet, einen eigenen Thread dafür aufmachen würde.
Danke
Cu Selur
-
Warum?
-
Weil es verwirrt, wenn die News nicht zum Threadtitel passen.
Die GPU-Variante ist ein eigenständiges Programm und sollte dann auch einen eigenen Thread bekommen.greets
LTJ -
DGAVCDec 1.09
1. Fix a bug in backward GOP stepping.
2. Fixed a problem with Load Project.
3. Added option "Display HD Full Sized".
4. Fixed a problem in M2TS file parsing.
greets
LTJ -
Das Projekt wurde eingestellt:
http://85.230.118.136/showthread.php?p=1347769#post1347769Man wird wohl auf die (kostenpflichtigen) DGNV Tools oder auf FFmpegSource2 ausweichen müssen.
Schade :nein:
-
Na wieso?
DGAVCDec funktioniert weiterhin. Zukünftige Streams könnten da vielleicht eher ein Hinderniss sein, aber die waren es schon immer, weil FFMPEG da immer einen Fehler für diverse Streams hatte.
neuron2 hatte aber auch geschrieben, dass er ein DGAVCDec mit CoreAVC plane. Ist doch gerade für die Besitzer von Intel/ATI Karten essentiell.
-
Zitat
Na wieso?
Weil Neuron2 offensichtlich sein kostenpflichtiges DGAVCIndexNV vorantreiben will...
ZitatZukünftige Streams könnten da vielleicht eher ein Hinderniss sein, aber die waren es schon immer, weil FFMPEG da immer einen Fehler für diverse Streams hatte.
Naja, Probleme mit dem H.264 Dekoder von FFmpeg/libavcodec wurden doch von den Entwicklern immer recht zeitnah behoben. Und die Multi-Threding Unterstützung kann sich mittlerweile auch sehen lassen. Last but not least: Im Gegensatz zu CoreAVC werden Weighted P-Frames unterstützt. Ja, CoreAVC wird auch Weighted P-Frames unterstützen, aber erst nach dem kostenpflichtigen Update auf Version 2.0.
Zitatneuron2 hatte aber auch geschrieben, dass er ein DGAVCDec mit CoreAVC plane.
Wird's nich geben. Laut den Entwicklern wird CoreAVC wird seine API nicht offen legen:
Will 2.0 have an api allowing DGAVCDecode to use it?
Die "other options" werden wohl darin bestehen, dass kommerzielle Entwickler CoreAVC als Bibliothek für ihre Produkte lizenzieren können.
Leider schließt das kostenlose OpenSource Software auf Basis von CoreAVC aus...
-
Mist! Ich hätte ja nix dagegen, wenn es sein DGNV Tool wenigstens auch für ATI Karten gäbe, aber ich sehe kein Licht am Horizont. :mad:
-
Mist! Ich hätte ja nix dagegen, wenn es sein DGNV Tool wenigstens auch für ATI Karten gäbe, aber ich sehe kein Licht am Horizont. :mad:
ATI hat meines Wissens nach nichts vergleichbares zur CUDA Video API im Angebot.
Bleibt somit nur DXVA, um die Hardware Decoder von ATI Karten zu benutzen. Aber DXVA ist nun mal eine reine Wiedergabe Schnittstelle und somit nicht für Avisynth als Quelle geeignet.
Es bleibt ja immer noch FFmpegSource2. Und das Projekt wird sehr aktiv weiterentwickelt:
http://85.230.118.136/showpost.php?p=1347813&postcount=691 -
Ich dachte, die DGNV Tools nutzen doch den Decoder, der auch für DXVA benutzt wird?
-
Ich dachte, die DGNV Tools nutzen doch den Decoder, der auch für DXVA benutzt wird?
Naja, der Decoder ist der Decoder-Chip auf der Grafikkarte, bei NVidia "Pure Video" genannt. Natürlich ist die Hardware die selbe, egal ob man sie über DXVA oder über die CUDA Video API anspricht. Aber DXVA ist nun mal für die Wiedergabe konzipiert. Nachdem die Anwendung die Daten an den DXVA Renderer schickt, landen das Ergebnis auf dem Bildschirm und das war's. Für einen Avisynth Quellenfilter muss man aber die dekodierten Daten wieder von der Grafikkarten holen können. Das ist bei NVidia Karten über die CUDA Video API (nvcuvid.dll) möglich. ATI bietet meines Wissens nach derzeit nichts vergleichbares...
(BTW: Wird wohl mal wieder Zeit, die sich entwickelnde Diskussion aus dem News Thread abzutrennen ^^)
-
Ach so, jetzt versteh ichs den Unterschied. Ich wünschte, AMD würde sich in gewissen Gebieten mehr engagieren. Sie können es mit nvidia in der Rechenleistung aufnehmen (laut Schätzungen von 3dcenter.org sogar übertreffen) und dort Geld scheffeln. Ich wünschte, nvidia würde was Vernünftiges zu den jetzigen HD5000 Karten bieten.
-
ATI hat einfach den Einstieg in den GPGPU bzw. HPC Mark total verschlafen.
ATI mag mit Stream mittlerweile leistungsmäßig sogar vor Nvidia's CUDA liegen, aber bei wissenschaftlichen Anwendungen ist Stream quasi nicht existent. NVidia versorgt Universitäten sogar kostenlos mit dicken Tesla Karten. Da ist CUDA derzeit in aller Munde. Von Stream hört man dagegen höchstens in der Kategorie "gibt's auch noch, aber wird hier nich besprochen". Und mit der kommenden "Fermi" Generation hat NVidia ein ganz heißes Eisen im Ofen! Man darf hier nicht nur auf die reinen theoretischen(!) Leistungswerte schauen, sondern vor allem auf die Änderungen an der Architektur. NVidia hat da wirklich einiges verbessert, was für GPGPU Anwendungen von großer Bedeutung ist. Tolle Benchmark Werte bringen halt herzlich wenig, wenn die eigene Anwendung nich auf die Architektur passt...
-
Ich bin für den Untergang von CUDA. Ich will DirectCompute und OpenCL vorwärtskommen sehen.
-
Ich bin für den Untergang von CUDA. Ich will DirectCompute und OpenCL vorwärtskommen sehen.
Erzähl das mal einer Arbeitsgruppe, die die letzten 2 Jahre damit verbracht hat, ihre Anwendung auf CUDA zu portieren :zunge:
Auf lange Sicht wird sich wohl OpenCL durchsetzen, aber viele haben eben mit CUDA ihre ersten Schritte mit GPGPU gemacht und mittlerweile viel Kosten und Mühe in die CUDA Entwicklung gesteckt. Da wird man nich mal eben auf eine neue Schnittstelle umstellen. Vor allem wenn man mal gemerkt hat, wie entscheidend häufig winzige Implementierungsdetails sind! Teilweise laufen selbst CUDA Programme auf verschiedenen NVidia Grafikkarten völlig anders. Welchen Ärger wird man da erst haben, wenn man auf NVidia und ATI Hardware testen muss, dazu mit einer neuen Schnittstelle, die man noch nich so gut im Griff hat ???
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!