Schreibfehler: ich meinte "/dev/dri/renderD128" und "/dev/dri/renderD129".
GENAU DAS IST DAS PROBLEM !
vaapi, vdpau usw. sind einfach be***issen dokumentiert. Das ist einfach so und muß auch so deutlich ausgesprochen werden.
Die Infos überholen sich ständig selber, die Optionen ändern sich usw, weil ffmpeg auch ständig weiterentwicklet wird. Deswegen traut sich scheinbar auch keiner an die Unterstützung von vaapi ran.
Darauf bezog sich eigentlich auch der Vorschlag mit den "custom-encoder".
Eigentlich mach ich momentan nix anderes mit meinem ffmpeg-script. Und DAS funktioniert auch. Mir fehlen leider die Kenntnisse das so umzusetzen wie ich es gerne hätte. Der Kalk rieselt halt im Alter
Ich hab seit kurzem eine GTX1070 im Rechner und teste gerade "Nvidia Decoding" via "-hwaccel cuvid" mit "Intel vaapi Encoding. Das ist noch mal schneller mit maximalen Quality-settings. Ich schau mir das Resultat immer aus kurzer Entfernung auf meinem Flachbild-TV ... und das sieht gut aus. Und das bei einer Bitrate von 8M VBR.
Es ist einfach ein Jammer das vaapi so bescheiden unterstützt wird. Immer nur Windows ...
Ok, lassen wir das Thema ruhen.
Vielleicht kannst du mir bei meinem bash Script helfen.
Ich demuxe mit mkvextract nur die subtitel. Audio/Videoencoding laufen direkt über ffmpeg. Gemuxt wird dann wieder mit mkvmerge. Ohne das du jetzt mein Script kennst, hast du eine Idee wie das Audio-Delay, automatisch wenn vorhanden, mit berücksichtigt wird ?
War das nicht mal so, wenn das Delay im Dateinamen steht (Audio), wird es beim muxen berücksichtigt ? Ich muß halt selber einen Weg finden vaapi zu nutzen.
Quote:denn dann kommt wieder User XY der aus einem YouTube Video oder sonst wo ne Command line hat und rumstänkert warum es denn nicht geht.
Nee, eben nicht. Dieses Feature wird ja dann offiziell gar nicht unterstützt, erscheint dann auch nur in Hybrid wenn es z.B. in der misc.ini oder sonst wo eingeschaltet wird. So war das von mir eigentlich gedacht. Aber egal ...