Beiträge von AlexF

  • Some more filters

    Good idea! In case you have a Project in 60fps with Clips of exact the 0,5-framerate you will have a better result by exporting the Project in 60fps and then drop every second Frame before Encoding to 30fps. Exactly that's what I'm doing when i would like to preserve a tv recording for future: Cinema stuff on TV will be in Europe converted to 50fps (NTSC-to-PAL-speedup + doubling Frames) and usually it Looks better converted back to native 25fps (1:1 Frame Transfer).

    (Sorry! Die saublöde teutonische Rechtschreibkontrolle kann leider kein Englisch!)

  • Encoder Settings lost when editing a created preset

    Bei der 2.3b4 werden jetzt zwar die erweiterten Einstellungen bei x264/265 korrekt angezeigt, aber nur die vom letzten Aufruf des Codecdialogs! Wenn man ein zuvor abgespeichertes Preset (bzw. eine "Voreinstellung") lädt, stehen die alten Einstellungen noch im Fenster drin und nicht die des Presets. Das Problem besteht jetzt übrigens auch beim nV-Encoder.

    Daß das Laden der Voreinstellungen endlich mal richtig klappt, wäre schon 'ne richtig gute Sache!

  • HEVC-Nachfolger VVC/H.266

    Und: Was ich noch vergessen habe. Bin jetzt schon gespannt, was für halbausgegorene Dinger uns die Medienindustrie da vorsetzen wird. Ich erinnere mal an die Bluray:

    Kein 1080p25, kein 1080p30, also die 1080er Auflösung in PAL & NTSC nur mit Zeilensprung und das in einer Zeit, wo schon klar war, daß es keine HD-Röhrenfernseher geben wird! Genau so kein 720p50 & 720p60, dafür aber die DVD-Auflösungen in allen Systemen mit und ohne Zeilensprung. Im Endeffekt hat man z.B. 25p-Filme mit "fake interlaced" kodiert, die eine Hälfte der Hardware fiel darauf hinein, die andere nicht bzw. man wußte nicht, wird jetzt deinterlaced und wie oder aber auch nicht? Auf jeden Fall hat es der Zwischenbildberechnung der Fernseher sehr schwer zugesetzt: Ein z.B. vom ZDF in 720p50 aufgenommener Kinofilm (der ja von 24p auf 25p "beschleunigt" wurde, danach werden noch die Bilder verdoppelt) sieht nämlich auch besser aus, wenn man ihn in 720p25 (Verfahren: jedes 2. Bild entfernen) kodiert.

    Bei der UHD-BD kam die nächste Gurke: Man darf bei Verwendung des 10 Bit-Profils zwar H264 (Profil H10@L5.1) zur Kodierung einsetzen, HDR geht aber nur mit H265. Wo doch jeder weiß, daß die Farbübertragung (BT709 vs. SMPT2084) überhaupt nix mit dem Videocodec zu tun hat!

    Und für beide Systeme: PAL, NTSC und Kino (23,976p & 24p) kann man blöderweise auf einer Scheibe auch nicht mischen, was mich auch sehr wundert, weil doch die Frametime in jedem Videostream explizit mitgeführt wird.

    Man hätte einen Standard auch so definieren können: Ein Bluray-Player muß H264-Filme bis Profil H4.1 ohne Einschränkungen wiedergeben können. Punkt.

  • HEVC-Nachfolger VVC/H.266

    Ich lach mich kaputt... Da gibt's noch genügend Baustellen bei HEVC, die größte ist, daß es keine Authoringsoftware für H265 gibt. Ist quasi wie beim Flughafen Berlin. Da faseln die schon vom Nachfolger. Abgesehen davon hat sich die UHD-BD noch nicht durchgesetzt - noch zäher, als bei der BD. Erstens mangelte es an Abspielgeräten, zweitens mangels Rohlingen (BD-XL und UHD-BD sind leider nicht kompatibel), drittens wegen fehlender Authoring-Software für privat übliche Zwecke. Ich habe zum Glück für mich mit unglaublich viel Ausprobieren 'ne "Krücke" gefunden, wie man UHD-Scheiben herstellt, die wie gewohnt mit Menü, Kapiteln usw. im Player laufen (aber nicht 100%ig UHD-BD-kompatibel sind, was heißt, daß sie möglicherweise nicht in jedem Gerät laufen).

    Das nächste Thema ist die Geschwindigkeit:

    Mein i9-9900K schafft ein HD-Filmchen bei H264 mit ~40fps mit Einstellungen, die für extrem gute Qualität bei mittleren VBR-Bitraten 10-15MBit/s (TV sendet auch nicht mit viel mehr!) optimiert sind, da ist die CPU noch nicht mal zu 100% ausgelastet. Bei UHD sind es noch so ~10fps. Nehme ich dafür H265 mit gar nicht mal so aggressiven Einstellungen, komme ich noch auf ~5fps. Schuld daran ist auch das 10 Bit-Encoding, aktuelle CPUs sind dafür nicht ausgelegt (alle Datentypen sind 8, 16, 32 und 64 Bit), es fehlen schlicht und einfach Befehle dazu bei SSE/AVX. BMI1 & 2 enthalten zwar passende Befehle (pdep, pext, pextr, ...) die funktionieren aber nur mit den allgemeinen Registern - nix mit Parallelverarbeitung. Die Pixelformatumwandlung in Einheiten, die die CPU beackern kann (und zurück) ist also ein Flaschenhals.

    Angesichts dessen frage ich mich, wie lange es dauert, einen 2h-Film in 8K mit H266 zu kodieren und ob ich das Ende der Kodiersession mit heute aktueller Hardware überhaupt noch erlebe...

  • AMD Threadripper Encoding Guide

    Disabling CUDA IS an bad idea! Filtering etc. in Premiere/AME is done by the GPU, encoding is done by the video engine. Since both are parts of the graphics card they use different resources on it. You can use "GPU-Z" to verify this.

  • color shift

    Tip: You should not use the hardware encoders for quality reasons. They're fast but that's all about it. Especially the h264 encoder has low coding quality. I use it only for quick testing, for final outputs better use x264! HD encoding isn't really demanding in case of todays CPU power. (If you own a newer CPU like the i9s or the Ryzens/Treadrippers... An additional CPU core can only replaced by a CPU core.)

    Actually I had to encode a very short:/ (6h22min) UHD Video to UHD-BD, used x264 High10@L5.1 and settings for best quality. It tooks me 34 hours to encode on a 9900K@5,0GHz! (Using the nV-HEVC-Encoder ist 2x realtime even on a slow GF1050!)

  • Redesign the User Interface

    Yes, something like this would taste good...

    Especially the filters are a good idea: FFMPEG can do a lot of filtering, especially the resize is important. AME can resize the Picture (ex.: from 2160p to 720p) but the result is always looking quite soft because of the (bicubic?) resize algorithm. If there would be an option to let FFMPEG do the resize, ther would be more Option (bicubic, blackman, ...).

    But the filter-tab should be presented as the 2nd from top: General (codecs, multiplexer, external files to multiplex), filters, video, audio.

  • Exception on Voukoder startup

    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.

  • Exception on Voukoder startup

    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!:thumbup:

  • Exception on Voukoder startup

    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!)