Exception on Voukoder startup

Zu allem Überfluß habe ich ziemlich oft auch eine richtig hammerharte Exception, wenn ich im AME den Voukoder konfigurieren will:

Danach kann ich den AME nur noch mit dem ProcessExplorer "abschießen", normal beenden geht nicht.

Na ich habe ein Projekt im AME geöffnet und auf den Voukoder-Knopf gedrückt, wo normalerweise das Fenster aufgehen sollte. Und statt des Voukoder-Fensters kam eben die Exception. Ich hatte den Fehler jetzt aber auch schon eine ganze Zeit lang nicht mehr... Melde mich, wenn ich das noch mal habe.

Mach mal lieber was an mehr Outputformaten. FFMPEG kann doch wirklich jedes Format und der Voukoder sollte wenigstens noch RAW (ohne Multiplexer), TS und M2TS (wegen BluRay) beherrschen. Klar, man kann MKV auch hinterher in M2TS umdröseln, aber das ist ja ein zusätzlicher Schritt.

LG aus der Rhön!

Ich hatte es bis jetzt nicht wieder...

Das war bis jetzt mur aufm Laptop und das ist der einzige Rechner, wo Win X läuft, alle anderen haben Win 7. Ich probiere es heute Abend mal dort aus.

Da steht ja was zu der GUI-Bibliothek "wxWidgets" und eine genaue Pfadangabe drin und auch 'n Hinweis, daß der Fehler durch irgend einen call auftritt. Den call vielleicht mit einem Exception-Handler aufrufen?

Tja, was mir noch einfällt: Der Schlepptop mit Win X hat auch ein UHD-Display und da ist ja auch ein Problem mit der Dialoggröße... Die Skalierung von Win X für High-DPI-Displays kann auch 'ne Quelle sein...

Und nix direkt aus einer Bibliothek nutzen... dann kommt der Fehler womöglich aus der Bibo selbst: Seit den Anfängen der objektorientierten Programmierung sind da fast immer Funktionen/Prozeduren, die beim Anlegen/Löschen eines Objekts ausgeführt werden (constructor/destructor).

Was macht überhaupt "setlocale(0,0)"? Der sollte einen String liefern, weil doch "strcmp" die vergleichen soll (also einfach "rep cmpsb").

Kann man die 2.1.1Beta nur wegen der DPI-Geschichte schon mal runterzerren? Wenn ich das mit der Exception in der 2.1.0 nachher teste, kann ich's gleich mit der 2.1.1b gegenchecken.

Zu dem Profilfehler bei x264 ("high10") habe ich übrigens am Wochenende herausbekommen, daß x264 automatisch "high10" wählt, wenn man den Parameter ganz wegläßt, es reicht, 4:2:0/10Bit und L5.1.

Ma 'ne Frage:

Ich habe das "Performance"-Kapitel gelesen.

Wie funktioniert eigentlich die Farbraumkonvertierung in Premiere? Ist das also so, daß Premiere das Video dekodiert und in einen internen Farbraum umwandelt und danach bearbeitet/filtert/etc. ? Wie ist das "interne Format", RGB 32 Bit ("single") Fließkomma oder so? Und wie kommt's aus Premiere raus? Man muß das ja irgendwie in das Format des Videocodecs (z.B. YV planar 8 Bit 4:2:0 mit dem richtigen Farbprofil) umfräsen... und wer macht das (Premiere oder Voukoder)?

Zitat von Vouk

Ich schau mal ob ich schon ne beta rausgeben kann.

Es reicht intern die Daten im entsprechenden pixelformat yuva444p10 anzuliefern, daran erkennt er es schon.

Ja, interner Farbraum. Voukoder muss ein entsprechendes Pixelformat anfordern und bekommt die Daten dann in diesem Format. Leider sind diese Formate nicht identisch mit denen in FFmpeg/libav so das u.U. noch eine Konvertierung erfolgen muss.

YUV420 (planar) geht direkt durch

YUV422 und YUV444 müssen von packed nach planar umgewandelt werden

Alles mit mehr als 8 bit wird als YUVA4444 32 bit float geholt und aufwändig nach yuva444416p konvertiert und dann nochmalsvon FFmpeg/libav ins entsprechende Zielformat gewandelt. Deswegen sind 10 und 12 Bit auch relativ langsam.

Alles anzeigen

Ja, das wird mir jetzt auch klar... Habe mal selbst vor nicht allzu langer Zeit überlegt (AVISynth), um 'ne >8Bit-Unterstützung irgendwie in die verbreitete v2.58 reinzubekommen, also wie man die in RGB angeforderten Bilder vom Dekoder irgendwie in 4:2:0 10Bit kommt. Also 'ne DLL selber schreiben. Ich dachte, das geht mit SSE und AVX fix, so der Plan:

1. Mit "pmovsxbd" in 32Bit wandeln,

2. mit "cvtqd2ps" nach single wandeln,

3. Farben von RGB nach YV12-32Bit umfräsen (mulps/addps, die Umrechnungskonstanten für BT601/709/... stehen sogar in de Wikipedia),

4. Skalieren mit 1024 und in Integer zurückwandeln,

5. Ja, genau danach kommt das Problem: Jetzt muß man die wichtigen Bits zusammenschieben und es gibt zwar shifts für 8/16/32/64 Bit, aber trotz 256Bit Recheneinheiten nichts für das gesamte Register. Der Plan, die nicht benötigten Bits rauszushiften und das mit Bitmaske in ein Auffangregister zu schießen, geht leider nicht. Da hat Intel leider bei den mittlerweile 256 Bit breiten Recheneinheiten Befehle für die Bearbeitung von 128/256 Bit in einem ganze Stück vergessen. (Genau so, wie 'ne Integerdivision fehlt!)

Ich hab's dann entnervt gelassen. Konvertierung mit FFMPEG und eine 2 Kilometer lange Kommandozeile war nämlich erheblich schneller.

Ma zurück: Von YUVA float nach YUVA word kann man mit SSE/AVX aber schon ziemlich fix erledigen? Mit mulps skalieren, nach 32 Bit Int konvertieren und in 16 Bit umpacken. 3-4 Befehle??? (Und den Loop natürlich wenigstens 2fach entrollt!)

P.S.: Demnächst mach ich Dir ma ne Spende.... Auch wenn's im Forum noch viel Gemecker gibt, der Voukoder ist bis jetzt das mit Abstand beste Enkoderplugin für Premiere/AME. Was meinst Du, was ich schon für graue Haare bekommen habe, weil der AFS (bekannter Frameserver...) manchmal zerfetzte Bilder seit CC2015 geliefert hat und die Pipe über Avisynth zu x264 nicht so besonders schnell ist (alter Code, teilweise nur MMX und dann nur 1 Thread). Und damit habe ich Urlaubsfilme in UHD kodiert: 4 1/2 Wochen USA. Da kommt was zusammen....

Keep on working!

So, da isse wieder. Der "Einstellen"-Knopf leuchtet noch.

Witzig: Wenn man "Don't Show..." und "Continue" anklickt geht's normal weiter und das Fenster poppt auch später nie wieder auf. Vielleicht ist das 'n Hinweis. Und wie gesagt: Bisher nur unter Win X und die Installation ist noch nicht sehr alt.