Intel Arc A 380 - AV1 QSVEnc - Wer hat noch Probleme ?

[swirtgen]

Hallo,
ich habe mir letzte Woche die Karte von Asrock gekauft, primär sollte sie dazu dienen, meine Filmesammlung von x264 auf AV1 zu Transcoden (Emby)
Bisher mit sehr mäßigem Erfolg.

In Staxrip werden die Filme zwar vollständig encodiert, beim muxen allerdings fehlt dann ein Teil,
Soll heißen, es wird ein Film mit 5GB erstellt, die Fertig gemuxte Datei ist dann aber nur 3,7GB groß z.b.
Der Film hört dann halt irgendwo auf, der Ton läuft weiter....

Auch ein manuelles muxen mit MKVToolnix kommt zum selben Ziel, kann zwar die encodierte Datei in das Fenster ziehen, beim Muxen wird aber nur ein Teil davon übernommen.

Hatte den Fehler in der QSVenc gesucht, weil ich davor auch teilweise mal Probleme mit meinem J3455 hatte, der das selbe verhalten bei H.264 zeigte. Aber Der Entwickler selbst meinte auf Github, dass er mit der Kommandozeile --vbr 5000 encodiere, und bei ihm alles OK wäre.

Hab´s dann auch mit der Kommandozeile versucht, hat auch funktioniert, nur leider läuft bei mir nun der Ton und das Bild auseinander.

Sprich, am Anfang passt es, in der Mitte sind es ca. 2 Sekunden Versatz und zum Ende hin dann gegen 5 Sekunden.


Ich enkodiere nun schon seit zig jahren - So ein Fehler ist mir bisher noch nicht unter gekommen.

BTW: Es geht dabei nicht um einen Film, sondern um mehrere. Lustigerweiße können die aber z.b. mit VCEEnc oder NVEnc Encodiert werden OHNE Probleme.

Hat jemand von euch zufällig die selben Symptome, oder muss ich mir mit dem Fehler irgendwie doof vorkommen?
Ahso, System ist ein i3-10100 mit 16GB DDR4 - Windows 11 22H2 Heute extr neu aufgesetzt mit allen Treibern.
Läuft auf einer NVME SSD von Patriot und die Filme die ich bearbeite liegen auf einer Samsung Sata SSD 870

 

[mkl1]

Ich habe das gleiche Problem. Das Problem liegt an Staxrip bzw. der Staxrip Umgebung. Wenn ich nur QSVEnc nehme ohne Aufsatz und mp4/mkv wähle geht es. Wobei Staxrip nur ein Problem mit AV1 hat. Eine Sache könntest du versuchen in Staxrip, du musst bei other und custom "--output-format mp4" eintragen.

 

[swirtgen]

Hatte ich auch schon versucht, also mit MP4 und auch mit output ffmpeg>>mp4 das Muxing Problem bleibt leider das gleiche.
Aber soeben zumindest für das auseinanderlaufen vom Ton eine Lösung gefunden.
hab den Film vorher mit Mediainfo ausgelesen und gesehen das der 24Fps hat, QSVEnc gibt den aber in 23,96Fps aus hab jetzt beim Input --fps 24 gesetzt. schon läuft es richtig.

Ergänzung (30. Oktober 2022)

Ahso, Habe auch Handbrake versucht, aber da kann ich eingeben was ich möchte (bei der Input Framerate) das Ausgabevideo stottert wie verrückt....

 

[mkl1]

Also geht es jetzt mit QSVEnc? Heute gab es eine neue Version, die habe ich mir gleich installiert. Das Problem in Handbrake ist ein bekanntes timestamp Problem. Übrigens ruckelt es auch in FFmpeg wenn man bf 1 oder höher verwendet, das ist auch ein timestamp Problem. Die Software muss noch reifen.

 

[swirtgen]

Also die Filme die ich heute Nacht noch versucht hatte, funktionierten nun alle über die cmd.

Ist zwar etwas doof wenn man jetzt vorher noch erst die FPS checken muss.
Daran merkt man aber, das man von staxrip zu verwöhnt war ☺️

Ab und an kommt aber ein mfxd.... Error oder ein Error das der Decoder das Input file nicht lesen kann. Mach dann nen Neustart, dann geht's wieder 🤔

Werde die neue Version später Mal testen.

Aber was mich noch interessieren würde,
Kann man eine batch schreiben
Die da in einem Rutsch ein paar Filme aus dem Ordner macht ?

Hatte eins für ffmpeg,
Alle MKV im Ordner >>> MKV im Output Ordner

Aber die qsvenc gibt mir wegen dem Output einen Fehler aus.

Und qsv kann ja nur den Film encodieren aber z.b. kein audio kopieren
Oder sehe ich das falsch?

Weil muxe die Filme dann immer im Nachgang.


Und wegen Handbrake, da hatte ich auf GitHub nen Threads verfolgt, da hatte jemand das selbe Problem, dort wurde es aber behoben,
Dachte ich zumindest. Hatte dann extra die neueste nightly getestet. Und immer noch.

Jetzt steht der Thread wieder als bug drin für Milestone 1.6.0

 

[mkl1]

Müsste es dann nicht auch über Staxrip funktionieren mit --fps 24 --output-format mp4? Den mfxd.... Error hatte ich auch ab und an, jetzt nicht mehr. Ich glaube das konnte passieren wenn ein anderes Programm die GPU oder den Decoder verwendet hat, irgendwie hat sich das nicht vertragen. Wenn ich alles geschlossen habe ging es meistens. Ich habe das Problem jetzt nicht mehr, ich bin mir nicht sicher warum. Die iGPU habe ich deaktiviert, neuesten Treiber installiert, neuestes Bios installiert und im Firefox die Hardwarebeschleunigung deaktiviert. Das GPU Bios hat sich mit einer Treiberinstallation aktualisiert. Der timestamp Bug von Handbrake wurde noch nicht behoben.

 

[swirtgen]

Den mfdx Fehler habe ich überwiegend bekommen wenn das Arc Control Center gelaufen ist, hab das bei mir aus dem Systemstart raus, seither keine Fehler mehr.

Habe jetzt die neue qsv in staxrip und teste gerade
Hoffe das es funktioniert 🫣

Wegen den fps Einstellungen, müsste das auch Mal testen. Hab's bei staxrip ja nie gebraucht, weil staxrip eigentlich immer beim hinzufügen der Datei alles gecheckt hatte, und bisher noch nie ein Fehler bei mir dabei war.

Selbst mit dem nvenc 25fps Bug den einige beschreiben hatte ich bisher nie Probleme.

Wie gesagt, teste gerade die 7.22 qsv in staxrip und berichte ob's funktioniert.

Auch wegen dem muxen

Ergänzung (30. Oktober 2022)

Also muxen mit staxrip klappt leider immer noch nicht

Einer von drei wurde jetzt komplett fertig.

Immerhin 33% Erfolg....

Und das waren jetzt 23.96fps Filme
Also hängt es damit auch nicht zusammen

Dann werde ich wohl oder übel abwarten müssen bis staxrip ein Update für den Fehler rausbringt.
Und so lange mit der cmd Version arbeiten....

 

[mkl1]

This is the same root cause. Fix for the timestamp issue is expected in next Arc driver release.

https://github.com/HandBrake/HandBrake/issues/4570

Möglicherweise ein Treiberproblem, jedenfalls sind die timestamp Ruckelprobleme anscheinend vom Treiber versursacht. Der nächste Treiber soll das fixen, mal abwarten. Ob und wie sich das in QSVEnc bemerkbar macht, muss man dann nochmal testen wenn der Treiber draußen ist.

 

[swirtgen]

Na dann bin ich mal gespannt, wäre jedenfalls etwas besser wenn man wieder eine Batch Alternative hätte, ohne hinterher immer alles muxen zu müssen.

Hoffe auch, das staxrip das wieder in den Griff bekommt.
War halt einfach, Dateien rein, Tagesablauf erledigen, Abends alles fertig und nichtmal mehr kontrollieren müssen, weil hat ja alles geklappt

 

[mkl1]

Das ist wirklich ein Treiberproblem. In QSVEnc wurde ein workaround eingebaut, um das Problem zu umgehen.

Anyway QSVEnc 7.20 or later has a workaround for this, overwriting and correcting the timestamp to avoid stuttering, to make it work even with the current driver.

 

[swirtgen]

Dann kann es vlt. Daran liegen
Das sich staxrip und mkvmerge daran verschlucken.🤔

Würde es so jedenfalls erklären.

Dann bin ich ja Mal gespannt, wann das dann treiberseitig gefixt wird.

Aber ich glaube
Die Prioritäten liegen bei Intel gerade woanders.🙄

 

[mkl1]

Die OneVPL library im Treiber wird ständig aktualisiert, das ist ja auch unabhängig von den ganzen 3D Sachen. Das wäre nicht das Problem.

 

[swirtgen]

Ich denke Mal das Intel sich da kein Bein rausreißen wird
Weil von der OBS Fraktion hört man bisher wenig bis gar nichts dazu - entweder läuft es dort prima, oder die Karte hat dort einfach zu wenig Akzeptanz - also werden die sich jetzt erstmal um die Stabilität bei den Spielen kümmern.

Da können dann erstmal die Entwickler der encoding Anwendungen mit Patches gegen den Fehler gegensteuern und warten bis der Treiber richtig funktioniert, bzw. Die fehlerhafte Bibliothek gegen eine Fehlervereinigte ausgetauscht wurde.

Finde ich auch schade
Das Intel die Karte rausgehauen hat
Ohne vorher zu prüfen
Ob da zumindest das funktioniert was das Zugpferd sein sollte

Av1 encodieren.

Wobei das Streamen ja geht

 

[mkl1]

Es ist doch schon gefixt intern, die Arbeit ist erledigt. Die Änderung muss nur noch in einem nächsten Treiber release mit integriert werden, da muss sich Intel doch kein Bein rausreißen.

Dass Intel für OBS weniger relevant ist, hat natürlich stark mit der Verbreitung zu tun. Die Anzahl an Arc Besitzern ist im Vergleich zu Nvidia verschwindend gering. Würde ich als Developer für eine game streaming software auch nicht anders machen, da würde ich mich auch erstmal auf das konzentrieren, was mehr Relevanz hat.

Außerdem hat Nvidia auch einen sehr guten Encoder (ok den AV1 Encoder kann ich nicht beurteilen, h264 und h265 sind aber sehr gut). Falls es irgendwann günstige RTX 4000 Karten mit AV1 encoding gibt, hole ich mir eventuell eine und kann vergleichen. AMD ist zwar verbreitet, hat aber einen vergleichsweise schlechten Encoder mit deutlich schlechterer Bildqualität. Vielleicht überrascht AMD mit der RX 7000 und haut einen raus. Das muss man sehen.

 

[swirtgen]

Kommt ja auch auf den Preis drauf an.

Das war bei mir der Punkt, weswegen ich mich für die 380 entschieden habe.

Entweder die, oder auf eine 4050 warten.

Bin ja aus dem Hardcore gaming Zeitalter raus gewachsen 😁

Der AMD Encoder ist, Nuja
Sagen wir mal funktional.

Wer damit emby oder Plex Transcodes machen möchte, jenseits der 5mbit's sieht es dann gut aus für 1080p

Da finde ich das Bild von der RTX 30er Serie definitiv besser.
Wobei ich auch schon sehr zufrieden mit den Transcodes von der alten Apollo Lake Serie bin.

Da sieht das h264 Bild bei 4 Mbit's besser aus als das von AMD bei 5 Mbit's

Und bei AMD habe ich die Befürchtung,
Das sie wieder bei der Einstiegsserie den Encoder weg lassen (siehe rx6400/6500)

Lassen wir uns beim nächsten Intel Treiber Mal überraschen.
Wäre jedenfalls echt Happy
Wenn ich meine encodes einfach wieder nebenbei als batch machen könnte, statt jeden einzelnen Film danach wieder zu muxen
Und zu kontrollieren ob auch alles passt.🙄

 

[mkl1]

Der Treiber ist mittlerweile online mit dem timestamp fix, Handbrake nightly und ffmpeg sind jetzt möglich. Bei Handbrake sollte man die gop Größe abändern. Die setzen das auf 1s, was deutlich Qualität kostet. 4s oder 5s ist da der deutlich bessere Kompromiss, also fps*5.

 

[swirtgen]

Danke für den Hinweis, werde allerdings erst nächste Woche zum testen kommen.

Ist nun endlich auch der Bug behoben, das nach einer gewissen Zeit die Grafikkarte nicht mehr gefunden wird?

Hatte bei den letzten beiden Treibern das Problem das ich ein Paar Filme machen konnte (mit QSVEnc) danach hat QSVenc mir einfach nen Fehler ausgespuckt wonach er kein Direct3D9 bzw. Direct3D11 Device mehr gefunden hatte.
Auch Spiele konnten keine mehr gestartet werden.
Einzig ein neustart hat abhilfe verschafft. bzw. den Treiber nochmal drüberbügeln.
Danach hat es wieder für ein Paar Filme funktioniert.

Und ja, die komischen MFXEncode Fails... - meist bei 4K Filmen.
hoffe das das nun endlich der Vergangenheit angehört...

Irgendwie bin ich froh, die Karte gekauft zu haben, andererseits bereue ich den Kauf schon etwas.
Glaub ich hätte warten sollen, bis es von Nvidia eine 4050 gibt oder ob es von AMD eine Einsteigerkate der 7xxx Generation geben wird, die auch encoden kann.

Beste Grüße

 

[mkl1]

Also ich hatte den Bug nicht mehr, aber schon seit 3802 oder 3793. Allerdings habe ich meine CPU und Mainboard erneuert, keine Ahnung ob es daran liegt.

 

[swirtgen]

Also ich habe den Fehler leider immer noch. (Auch mit dem 3975er Beta Treiber)
So langsam tippe ich auf einen Defekt der Karte
Ich kann 1 oder 2 Filme mit Handbrake machen, beim 3ten Film kommt dann meistens einfach nur ein Fehler, installiere ich den Treiber neu, kann ich gleich weitermachen (Oder eben das System neu starten)

Hab die Karte in einem OEM System von HP (W11 Pro mit 16GB Ram) - Kann von daher RBAR im BIOS (Oder soll das ein UEFI darstellen, ich weiß es nicht) nicht aktivieren, weiß nicht, ob´s damit besser laufen würde.

Was mir noch aufgefallen ist, wenn der PC mal so 5-6 Stunden an ist, und ich ein AVC oder AV1 Video abspiele, kommen immer Microruckler, dachte am Anfang das die Videos wieder schlecht encodiert wurden, spiele ich die aber an meinem anderen PC ab, laufen die total flüssig.

Hab mich nun dafür entschieden, 1080p Videos vorerst weiter mit x264 zu encoden, der AV1 Encoder hat gerade in schnellen Szenen (Und auch Szenen mit Wasseroberflächen) noch Probleme mit Artefakten....

The Kings Daughter als Beispiel eine Szene in der die Dame aus dem Wasser raus geholt wird,
mit AV1 in 5Mbit totale Blockbildung.
Gleiche Szene bei Amazon Prime mit gerade mal 2,5 Mbit in AVC - glasklar...

Wüsste allerdings nicht, wo ich noch ansetzen könnte, das die Qualität noch besser werden könnte,

--gop-ref-dist 3 --input-buf 16 --bframes 5 --gop-len 4 --open-gop --vbr 5000 --i-adapt --b-adapt --b-pyramyd --max-bitrate 5000

Trotzdem werden die Filme Qualitativ mit x264 slow und Bitraten unter 4Mbit in 1080p besser.

Hätte glaub warten sollen, bis es AV2 so in ein Paar Jahren gibt...

Ein Frohes Fest wünschend 🎅

 

[mkl1]

--gop-ref-dist 3 -->sollte auf 8 stehen oder meinetwegen auf 4
--bframes 5= bframes rausnehmen bei AV1, das beißt sich mit gop-ref-dist

Du kannst noch --la-depth 100 nehmen für CBR/VBR, das wirkt sich ein wenig positiv auf die Qualität aus. Und das preset sollte natürlich auf --quality best stehen, das fehlt bei dir. Ansonsten wird es wohl im balanced preset laufen.

Achso du nimmst Handbrake. In Handbrake musst du die gop-pic-size anpassen, ansonsten gibt es schlechte Qualität. Das ist je nach fps im Video unterschiedlich. Empfehlen würde ich fps*5. Bei einem 24 fps Video ergibt sich gop-pic-size=120.

AVC ist deutlich schlechter als AV1. Wenn das bei dir andersrum ist, stimmt irgendwas nicht.