kleines Problem gibt es noch mit der Version mp4box.exe -version zeigt: 0.5.2-DEV-revUNKNOWN-master
media-autobuild_suite
-
-
ich melde es mal
-> https://github.com/jb-alvarado/me…suite/issues/87 -
Hier ne MP4Box Version bei der die Revision wieder richtig angezeigt wird. Haben sie schnell gelöst.
-
Grummel, bei MP4Box geht '-hint' nicht bei den builds die mit dem media-autobuild_suite erstellt wurden,..
-> https://github.com/jb-alvarado/me…suite/issues/88
Scheint auch schon ne Weile nicht zu gehen, da der MP4Box - GPAC version 0.5.1-DEV-rev5619 den ich mit dem media-autobuild_suite erstellt hatte das Problem auch hat.
(die Mp4Box aus den nightly builds von gpac geht ohne Probleme) -
Danke nochmal für das zweite build.
-
Seit x265 das Multi-library Interface hat, wäre es sinnvoll, die DLLs gleich passend zu benennen:
- Die für 8 bit compilierte EXE kann bei Anforderung mit '-D 10' eine libx265_main10.dll für 10-bit-Encodierung laden.
- Die für 10 bit compilierte EXE kann bei Anforderung mit '-D 8' eine libx265_main.dll für 8-bit-Encodierung laden.
In meinen Release-Archiven aus GCC 4.8.2 benenne ich beide Varianten (Win32 / Win64) ab v1.7 entsprechend: libx265_main.dll / libx265_main10.dll + x265_main.exe / x265_main10.exe
-
Wir haben 8 bit zum Standard gemacht und 10 bit wird per dll verlinkt.
-
Nachdem ich die aktuelle suite hab laufen lassen, hab ich das dann auch festgestellt... :redface: Gut, für den praktischen Bedarf wird das auch ausreichen.
-
wobei mir persönlich separate statische builds lieber wären, kann ich aber mit leben
-
Hast du auch weiterhin, du hast nur zusätzlich die Option z.B. in ffmpeg zu wählen ob du in 10bit komprimieren möchtest. Die Standalone Tools sind immer noch statisch.
-
Für mich wäre es schon ein gewisser Unterschied, ob bloß ein alternativer Encoder bei Bedarf dynamisch gelinkt wird, oder in jedem Fall auch zusätzlich noch die Laufzeitbibliothek des Compilers, die dann im System installiert sein muss. Letzteres ist bei den statischen Builds ja nicht der Fall (bis auf den Kernel und die Basis-MSVC, die jedem Windows beiliegt, und auch von GCC-Binaries gelinkt wird).
__Beim doppelten Durchlauf (32 + 64 bit) beschwert sich der Paketmanager bei einigen Sachen (z.B. bei zbvi), dass da schon Patches angewendet worden seien, ob er "-R" annehmen soll [n]?
-
So wie ich das verstanden habe, hast du ja quasi ein statisches ffmpeg. Brauchst du kein 10bit x265, brauchst du auch die dll nicht. Wer es verwenden möchte tut neben bei sich noch die dll ins Verzeichnis. Es entsteht also kein Nachteil. Wer keine dlls zusätzlich haben möchte lässt sie einfach weg. Klar wäre es schöner wenn x265 beides zusammen in einer lib anbieten würde, aber das haben wir nicht in der Hand.
Das mit den Patches müssen wir uns mal anschauen - danke für den Hinweis!
-
Ist noch mal kräftig an dem Script gearbeitet worden, man kann jetzt recht einfach selbst bestimmen, welche libs in ffmpeg integriert werden sollen und welche nicht. Habe es selbst noch nicht getestet, möglich dass noch etwas nachgebessert werden muss.
-
Das klingt gut. Anscheinend ist z.B. xavs reichlich uninteressant...
-
Ja, da hast recht :). Im alltäglichen bräuchte man sicher die meisten nicht.
-
-
Gerade entdeckt: CDParanoia wird auch gebaut? Interessant. Bisher vertraue ich ja ausschließlich EAC, aber ein CLI-Grabber mit Smilie-Ausgabe ... macht mich neugierig. ;D
-
Vielen Dank für doc/forcing-recompilations.md :daumen:
-
Gerade entdeckt: CDParanoia wird auch gebaut? Interessant. Bisher vertraue ich ja ausschließlich EAC, aber ein CLI-Grabber mit Smilie-Ausgabe ... macht mich neugierig. ;D
Habe es selbst noch nicht getestet scheint aber zu funktionieren:
https://github.com/jb-alvarado/me…omment-11500622Bin gerade nicht so aktive, aber der Ricardo ist gerade sehr fleißig.
-
Du hast also Verstärkung. Das ist doch das beste Detail seit dem Wunsch nach Überlassung des Projektes.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!