x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

  • GAT explained it somewhere in this thread - after some point x264 can't use more threads without sacrificing image quality. So you can't alter how it uses your ressources.

    But it would be nice if you would post your result with the complete system for reference anyways :)

  • Actually, the developers DID find ways to make it scale better in the meantime (without washing output quality down the drain), so new versions of x264 are considerably better at loading more cores even at "low" resolutions such as 1080p.

    However, using that would make red results of course. So I'd always advise to run both the stock version AND the new version and report both results if you'd like to do that.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (1. März 2016 um 10:56)

  • GAT explained it somewhere in this thread - after some point x264 can't use more threads without sacrificing image quality. So you can't alter how it uses your ressources.

    But it would be nice if you would post your result with the complete system for reference anyways :)

    that's kinda useless I mean more cores should just make the process finish faster I dunno man, kinda seems an inaccurate test then, ya know what I mean right.
    This also means every run I would do with it would result an entirely different time as well.

    The score is bad since 48% of all my cores was used...

    TimeThis : Elapsed Time : 01:17:04.351

    2 CPU's 12 Cores per CPU 24 Cores total @ 2.5Ghz

    Old Build:

    Elapsed Time : 01:17:04.351 | 2/12/12 | 12 Core AMD OpteronMP 6180 SE D1 @ 2.5Ghz | 48GB DDR-III/1600@ 1333Mhz | Supermicro H8DG6-F | 2x AMD SR5690 | Win7 Pro x64 UK + SP1


    (Official r2665 x64 Build):

    Elapsed Time : 00:31:34.145 | 2/12/12 | 12 Core AMD OpteronMP 6180 SE D1 @ 2.5Ghz | 48GB DDR-III/1600@ 1333Mhz | Supermicro H8DG6-F | 2x AMD SR5690 | Win7 Pro x64 UK + SP1

    CAS# Latency 9.0 clocks
    RAS# to #CAS Delay 9.0 clocks
    RAS Precharge 9.0 clocks
    Cycle Time 24.0 clocks
    Command Rate 1T

    2 Mal editiert, zuletzt von Gold Leader (1. März 2016 um 12:08)

  • that's kinda useless I mean more cores should just make the process finish faster I dunno man, kinda seems an inaccurate test then, ya know what I mean right.
    This also means every run I would do with it would result an entirely different time as well.

    It's actually very accurate. Let me explain this in greater detail:

    At the time, the algorithms were as good as they could make it. I said this before, but I'll state this again: For the x264 developers, output quality is paramount above all else. Their pride lies within the fact that the x264 encoder delivers the highest video quality amongst all existing H.264/AVC encoders in the entire world for any given bitrate. Speed and scalability comes second, always. x264 will never sacrifice quality for speed or scalability. This is, what makes this a "real world" application, not a synthetic benchmark. Not every real world application can easily scale up to n cores. In 2010, this was just how good they managed to make it.

    So a given x264 version in this benchmark measures one thing and one thing exactly: How fast your machine can run that version of x264. That's it. If it's not that fast because you have a ton of cores at lower clock speeds, than that's how it is.

    Also, x264 is a highly active project, and constantly evolving and improving. That is how the developers managed to make it scale better without sacrificing video quality in the last 5 years.

    However, when comparing machines, they have to be compared apples to apples, not apples to oranges. The benchmarks' x264.exe cannot stay up-to-date all the time, as the code is evolving at insane speeds. We'd need to throw away all results every other week or so, because there's a newer, better and/or faster version once again.

    The benchmark had to be frozen at a certain version (for comparable reference results), otherwise this would've been nothing but a mess.

    When comparing apples to apples, the benchmark is highly deterministic, so you don't get a high runtime variance. This has been tested by a lot of users pushing the stock version through multiple runs on the same hardware. Variance tends to stay well below 1%, which I consider a sufficient result in that department.

    Of course, as you dive into the reds, you need to check build numbers (like your r2665) when comparing machines. Newer builds always tend to be better somehow, often in terms of speed. It's not just scalability; They also added more assembly optimizations for SSE4.2 as well as AVX and recently AVX2, which also give more speed.

    Remember, there are even algorithms that are completely serial and not parallelizable, so some things can't even use more than a single core. Some practical applications are limited to that for very real and valid reasons. The same holds true for the scalability of x264.

    Video encoding - contrary to common beliefs - is not that easily spread across many cores, at least not if you want to deliver the best output quality in the entire world.

    I hope this helps in understanding why the x264 benchmark is how it is, and why it has to be that way.

    When starting anew, I'd rather leave the x264 benchmark project up and running as it is now, and start with a new (again: frozen at a certain version) project using x265 for H.265/HEVC content instead.

    Edit: Actually, it wasn't even meant as a benchmark in the beginning. Back when this project was started up, it was more of a stability test than a benchmark, as originally envisioned primarily by S2 Sedan and then myself. The benchmarking component was added to give users some extra motivation, because competitive things always push people to try reach the maximum or compare things with each other. ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (1. März 2016 um 14:24)

  • Und hier ein neues Notebook / Elitebook auf der Arbeit im Belastungstest:

    0003:33:25.201 | GAT | 1/2/4 | Intel Core i5-6200U 2.30GHz | 8GB DDR-IV/2133 9-9-9-28-1T | HP EliteBook 820 G3 | Windows 10 Pro x64

    Ist fein mit 2.7GHz Boostclock durchgefegt.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Der kleine Opteron nochmal mit Standardtakt:
    11:11:54.021 | 666psycho | 1/2/2 | AMD Opteron 1212HE 2.0GHz | 4GB DDR-II/800 | Gigabyte M57SLI-S4 rev 2.0 | nforce 570 SLI | Win10
    08:05:00.017 | 666psycho | 1/2/2 | AMD Opteron 1212HE 2.0GHz | 4GB DDR-II/800 | Gigabyte M57SLI-S4 rev 2.0 | nforce 570 SLI | Win10 (official r2334 x64)

    Übrigens, sehr schöne Erklärung in deinem Beitrag zuvor @GAT :thumbup:

  • Ist drin!

    Es ist halt "schade", daß sich x264 in der Benchmarkversion nicht mehr so perfekt eignet heutzutage, also für die richtig stark parallelen Maschinen. Und der AVX/AVX2 Code is auch noch ned drin. Vor über 5 Jahren, als es damit losgegangen ist, sind halt auch noch nicht so viele Leute mit dual 12-Kerner Haswells und Magny-Cours herumgelaufen. :topmodel:

    Auf lange Sicht kann man sich evtl. überlegen, den Bench durch eine parallele Schiene mit neuerer Software zu ergänzen (getrennte Webseiten usw.). Aber dafür ist die Zeit auch noch nicht reif; Ich würde dann gerne x265 einsetzen. Aber das ist noch nicht hinreichend massiv parallel. Soll heißen: Das lastet im aktuellen Zustand auch keine 48 Threads einfach Mal so easy aus, zumindest soweit ich es bisher geschafft habe.

    Aber noch skaliert das alte x264 ja, wenn auch nicht mehr ganz so perfekt. Sieht man z.B. auch [hier] (beides Haswells).

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Naja, ne parallele Schiene halte ich jetzt nicht unbedingt für nötig, solange x264 immer weiterentwickelt wird. Ich finde es sogar einen sehr interessanten Aspekt des Ganzen hier, dass man neben der hardwareseitigen Skalierung über die Zeit auch die softwareseitige Weiterentwicklung betrachten kann. Deswegen hab ich für mich so einen kleinen Freeze bei der x264 Version 2334 gemacht und lass meine Probanten immer durch diese zwei Versionen rennen, um die softwareseitige Performanceverbesserung auf den verschiedenen Systemen zu sehen. Vielleicht kommt da irgendwann mal noch eine dritte Version dazu, die 2334 ist ja auch schon wieder 2 Jahre alt (glaub ich).

  • Ist drin!

    Es ist halt "schade", daß sich x264 in der Benchmarkversion nicht mehr so perfekt eignet heutzutage, also für die richtig stark parallelen Maschinen. Und der AVX/AVX2 Code is auch noch ned drin. Vor über 5 Jahren, als es damit losgegangen ist, sind halt auch noch nicht so viele Leute mit dual 12-Kerner Haswells und Magny-Cours herumgelaufen. :topmodel:

    Auf lange Sicht kann man sich evtl. überlegen, den Bench durch eine parallele Schiene mit neuerer Software zu ergänzen (getrennte Webseiten usw.). Aber dafür ist die Zeit auch noch nicht reif; Ich würde dann gerne x265 einsetzen. Aber das ist noch nicht hinreichend massiv parallel. Soll heißen: Das lastet im aktuellen Zustand auch keine 48 Threads einfach Mal so easy aus, zumindest soweit ich es bisher geschafft habe.

    Aber noch skaliert das alte x264 ja, wenn auch nicht mehr ganz so perfekt. Sieht man z.B. auch [hier] (beides Haswells).


    Script:
    Anzahl der Cores auslesen
    Mehrere Filme parallel transcoden?
    Done.
    ... oder so ;)

    Raspi A+, 3, Zero

  • Najo sicher, sowas kann man machen, nur muß das auch 1.) deterministisch und 2.) vergleichbar ablaufen. Jetzt kann man natürlich vordefinieren, daß ab einer gewissen logischen CPU Anzahl sliced oder dupliziert wird, so habe ich ja die Clusterversion von x264 auch gelöst. Slicen, und parallelisieren.

    Nur eines ist ganz klar: Ich werde den bestehenden Test aus Vergleichbarkeitsgründen nicht mehr abändern. Also nicht so, daß es bestehende Ergebnisse invalidieren würde.

    d.h., wenn man da etwas macht, dann from scratch! Und eher mit H.265. Man kann die Parallelisierung (is ja Blocklevel) auch boosten, indem man die Auflösung steigert. 4K ist da weit besser geeignet, 8K erst Recht. Durch Auswahl des Testvideos läßt sich das also auch noch positiv beeinflussen.

    Bräuchte nur Mal eine Many-Core Maschine (also so 100-200 Kerne wären nice), um das ein bissl zu testen.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Many Cores:
    GPU... ;)


    Jo, aber ned mit x264/x265. ;)

    Und klar. Der aktuelle Test ist in Stein.

    x265 ist ein Idee, jop. Nach diesem Motto: Linki


    Auch wenn das Interesse hier bisher eher.. sagen wir "minimal" ist, werde ich mir trotzdem vorab Mal ein bissl was zusammenstoppeln und mir das anschauen. Dieses Mal kann ich auch gleich von Anfang an die Binaries selber bauen und den Quellcode gleich dazulegen. Auch wenn es zwischen Compilern natürlich auch Unterschiede gibt (schon klar) würde ich dann dazu tendieren, die Quellcodeversion als "Referenz" zu bezeichnen, und nicht irgendein bestimmtes Binary. So könnte man plattformübergreifende (Windows, BSD, Linux, OSX, usw.) "Referenzergebnisse" bekommen. Compiler muß man halt dazuposten, wie jetzt auch.

    Sinn: Weniger Rainbow Parade in der Ergebnisliste. :topmodel:

    Für normale Windows User sollte es natürlich so simpel bleiben wie es jetzt auch ist. Ist eh schon "obskur" genug für den Standarduser, wenn man da ein Batch File ausführen muß, und es geht in einem Konsolenfenster ein Bench auf usw. :rolleyes:

    Nachteile des Ansatzes: Höhere potentielle Ergebnisvarianz bei Standardergebnissen, aber weit weniger hoch als jetzt mit weiß+rot.
    Nachteile von x265: Wahrscheinlich kein Windows Support für Systeme vor WinXP möglich. Gehörte aber noch getestet.
    Zukunftssicherheit: Wahrscheinlich um die 5 Jahre gröbstens geschätzt, wie es halt beim alten auch war. Würde wohl auf 8K setzen, wenn es Mal Content unter freier Lizenz gibt.

    Aber wie gesagt, das werd ich derweilen eh noch nicht machen. Man muß sich auch die Akzeptanzfrage stellen, also ob das überhaupt wen interessiert? ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (11. März 2016 um 10:29)

  • Musst es halt größer aufziehen! Oder ganz bleiben lassen. Muss dich auch selber interessieren!

    Wenn es einfach zu "installieren"/"nutzen" ist, kommt das sicher besser bei den "Usern" an.
    Ein platformunabhängiges Script oder binary (java, .net... whatever)
    Alles was den Aufwand gering hält.

    Interesse. Das kannst ja in div. Foren oder Hardware Seiten prüfen.

    Raspi A+, 3, Zero

  • Jo, is halt ned so leicht, weil am Ende is der Encoder (und der benötigte Decoder) C/C++ und Assembly, das muß bei *nix Maschinen halt kompiliert werden, speziell wenns ned mehr auf x86 is. Da is die Fragmentierung einfach zu groß um alle "einfach" mit einem Binary bedienen zu können. Windows is easy, kein Thema..

    Aber is ja noch Zeit.. Der Hut brennt ja ned wirklich. ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Jo, eh..

    So, hier meine neue mobile Maschine.. Ein Convertible Tablet. Über die Unis läuft bei uns grade wieder die sogenannte "u:book" Aktion, da gibt's einiges verbilligt, und ich wollte schaun, ob ich nicht doch Mal einen Hybriden versuche. Eigentlich hätte es das kleinste Surface 4 Pro werden sollen (weil passiver Core m3), aber das ebenfalls angebotene Elite X2 1012 G1 von HP sah dann einfach in allen Aspekten überlegen aus:

    • Core m5-6Y54 mit HD Graphics 515, alles passiv gekühlt
    • Mit neuesten Treibern GPU-Beschleunigung für 10-Bit H.265/HEVC Playback in MPC-HC => Argl, scratch it. Geht erst ab HD Graphics 520 schauts aus, so also nur 8-Bit. Meh. Also doch mehr Arbeit für die CPU. :(
    • MILSPECs für Staub- und Spritzwasserschutz
    • 4G/3.5G/3G/2G Modem
    • Zerlegbar, man kann SSD (M.2 SATA & NVMe PCIe) und Akku tauschen
    • Niedrigere Auflösung von 1920x1280 für 100% native Scaling in Win10
    • 256GB SSD und 8GB RAM, beides das doppelte vom Surface Pro 4 Angebot innerhalb der Aktion
    • Besseres Keyboard als beim Surface, inkl. Beleuchtung
    • Kaum schwerer als das MS Convertible, 820g ohne Tastatur
    • Gefühlt sehr hohe Verarbeitungsqualität

    Besonders interessant fand ich die Taktstabilität bei thermischer Belastung, getestet bei 27°C Umgebungstemperatur. Die CPU schafft es nicht, ihren 2.4GHz all-core Turbo durchzubringen, aber unter 1.7GHz ist er nie gefallen, sondern eher bei ~1.8-1.9GHz geblieben, tlw. 2GHz. Schon nicht schlecht die kleinen Dualcores mit nur 4.5W TDP. Für ein passiv gekühltes x86 Tablet ist das denke ich eine ordentliche Menge an Power:


    04:37:33.724 | GAT | 1/2/4 | Intel Core m5-6Y54 1.10GHz | 8GB LP-DDR-III/1866 14-17-17-40-1T | HP Elite X2 1012 G1 | Windows 10 Pro x64

    Nur mit'm Betriebssystem werde ich noch lange nicht warm werden, die Nutzung von Win10 fühlt sich an wie KRIEG, vor allem wenn man's sowohl als Notebookverschnitt wie auch alternativ als Tablet nutzen will.. Ein Haufen Applikationen haben halt eben KEINE "App" Version auf Metro.. Mein geschätzter Vivaldi Browser (noch) nicht, MPC-HC auch nicht usw.. Najo, Zur Not läßt sich ein unskalierter Desktop auch noch nutzen, wenn man den Wacom Stylus hernimmt. Ist nur etwas strange. ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    3 Mal editiert, zuletzt von GrandAdmiralThrawn (12. März 2016 um 15:53)

  • Sehr feines Gerät, könntest das evtl. mal durch den Unigine Valley jagen? Interessiert mich immer, wie gut oder schlecht aktuelle IGPs sich da schlagen.

    Ich hab übrigens letztens festgestellt, dass man sich unter Debian 8.3 ein fertiges x264 Paket holen kann:

    Code
    :~/x264$ sudo apt-get x264Paketlisten werden gelesen... 0%Paketlisten werden gelesen... 100%Paketlisten werden gelesen... FertigAbhängigkeitsbaum wird aufgebaut.... 0%Abhängigkeitsbaum wird aufgebaut.... 0%Abhängigkeitsbaum wird aufgebaut.... 50%Abhängigkeitsbaum wird aufgebaut.... 50%Abhängigkeitsbaum wird aufgebaut.... 84%Abhängigkeitsbaum wird aufgebaut.       Statusinformationen werden eingelesen.... 0%Statusinformationen werden eingelesen.... 0%Statusinformationen werden eingelesen.... FertigDie folgenden zusätzlichen Pakete werden installiert:  libavcodec56 libavformat56 libavresample2 libavutil54 libdrm-nouveau2 libdrm-radeon1 libdrm2 libffms2-3 libgl1-mesa-dri  libgl1-mesa-glx libglapi-mesa libglu1-mesa libgpac3 libgsm1 libmp3lame0 libogg0 libopenjpeg5 libopus0 liborc-0.4-0  libschroedinger-1.0-0 libspeex1 libswscale3 libtheora0 libtxc-dxtn-s2tc0 libva1 libvdpau1 libvorbis0a libvorbisenc2 libvpx1  libx11-xcb1 libx264-142 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxshmfence1 libxvidcore4  libxxf86vm1 va-driver-all vdpau-va-driverVorgeschlagene Pakete:  opus-tools speex vdpau-driverDie folgenden NEUEN Pakete werden installiert:  libavcodec56 libavformat56 libavresample2 libavutil54 libdrm-nouveau2 libdrm-radeon1 libdrm2 libffms2-3 libgl1-mesa-dri  libgl1-mesa-glx libglapi-mesa libglu1-mesa libgpac3 libgsm1 libmp3lame0 libogg0 libopenjpeg5 libopus0 liborc-0.4-0  libschroedinger-1.0-0 libspeex1 libswscale3 libtheora0 libtxc-dxtn-s2tc0 libva1 libvdpau1 libvorbis0a libvorbisenc2 libvpx1  libx11-xcb1 libx264-142 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxshmfence1 libxvidcore4  libxxf86vm1 va-driver-all vdpau-va-driver x2640 aktualisiert, 42 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.Es müssen 14,0 MB an Archiven heruntergeladen werden.Nach dieser Operation werden 52,0 MB Plattenplatz zusätzlich benutzt.Möchten Sie fortfahren? [J/n] J

    Fertig installiert siehts dann so aus:

    Code
    x264 --version
    x264 0.142.2431 a5831aa
    (libswscale 3.0.0)
    (libavformat 56.1.0)
    (ffmpegsource 2.20.0.0)
    built on Nov 27 2014, gcc: 4.9.2
    configuration: --bit-depth=8 --chroma-format=all
    x264 license: GPL version 2 or later
    libswscale/libavformat/ffmpegsource license: GPL version 2 or later

    Ist da alles soweit korrekt gelinkt, dass ich den Banchmark laufen lassen kann?

  • Unigine Valley, kann man machen, jo.

    @Debian Paket: Zu 100% kann man's nie sagen (falls einzelne Decoder deaktiviert wurden oder so, die Debian Leute sind da etwas vorsichtig bei Software die nicht zu 100% GPL-konform ist), aber da es gegen libav gelinkt wurde, müßte es eigentlich funktionieren, solange man beim Bau alles auf Standard belassen hat! Und das macht Sinn, weil wenn man x264 schon anbietet, dann wohl auch inkl. H.264 Decoder. ;)

    Einfach ausprobieren würde ich sagen!

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Er startet auf jeden Fall schon mal:

    Hab manuell abgebrochen, die Kiste wird so ca. 10-12 Tage brauchen schätze ich :D

  • Was hast denn da ausgegraben, Pentium II oder so? ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"