Windows 64bit mencoder, ffmpeg, mplayer ?

Zitat von Selur

Ps.: gibt es eigentlich eine 64bit Windows version von smplayer?

Brauch man ja eigentlich nicht. Performance-Vorteile ergäben sich höchsten, wenn die MPlayer.exe als 64-Bit Programm läuft.
Aber ob die GUI nun als 32-Bit oder 64-Bit Programm läuft dürfte doch relativ egal sein...

(BTW: Sind die Qt Libs überhaupt als 64-Bit Version verfügbar?)

Bleibt die Frage welche Vorteile man davon hat, eine reine GUI Anwendung als 64-Bit Prozess laufen zu lassen...

/ironie
man kann mehr grafik schnick schnack auf die GUI legen...
high res... unkompremiert... so das man die 4GiB auch knackt
/ironie

Zitat von Selur

zumindest kein *32 im Taskmanager, sicher ist es teilweise eine Spielerei, aber trifft das nicht auf vieles zu

Teilweise? ;D

Also ich fände es sehr viel sinnvoller das GUI front-end als 32-Bit Prozess laufen zu lassen und dann zur Laufzeit die jeweils zum System passende Encoder/Player binary aufzurufen...

(BTW: Aus einem 32-Bit Prozess heraus lässt sich z.B. mit IsWow64Process() feststellen, ob das System 32- oder 64-Bit ist)

wenn man sich genau überlegt währe sogar 16bit oder weniger für simple GUI's sinnvoll
leder kann das betriebsystem & CPU das nicht linear skalieren
so das z.b. auch 18bit möglich währe...

daber das letzt bischen bit der speicherplatz gewinnung (hdd/ram) ist bei heutigen kapazitäten wohl egal...
da compelliert man doch "gern" 2 mal...
und wenn erst das nächste bit-update kommt (128bit),
dann geht der ganze spaß schonwieder von vorne los...

es währe doch vieles einfacher, wenn man diese bittigkeiten endlich duchbrechen könnte...

Zitat von HQ-LQ

wenn man sich genau überlegt währe sogar 16bit oder weniger für simple GUI's sinnvoll

Nein. 16-Bit Windows Systeme sind praktisch ausgestorben und daher heute irrelevant. Alles ab Windows 95 oder NT kann 32-Bit.
Aber selbst die meisten 32-Bit Binaries setzen heute mindestens Windows 2000 (oder neuer) voraus...

(Versuch z.B. mal ne MSVC 9.0 Binary unter Windows 98 zu starten: "Ein an das System angeschlossenes Gerät funktioniert nicht")

Mal ganz davon abgesehen, dass 64-Bit Windows ohnehin keine 16-Bit Anwendungen mehr ausführen kann

Zitat von Selur

Für ne GUI ist es Performance technisch i.d.R. recht uninteressant welche bit-Anzahl man nutzen würde, da ich aber wenn es möglich ist doch gerne die dem System native Anzahl vorziehe (warum Wrapper&VMs nutzen wenn es nicht nötig ist?

32-Bit Prozesse laufen unter 64-Bit Windows genau so "native" wie 64-Bit Prozesse. Die AMD64 Architektur konnte sich ja gerade deshalb gegenüber IA64 durchsetzten, weil sie über einen uneingeschränkten 32-Bit Modus verfügt. Und ja, 64-Bit Systeme können jederzeit in den 32-Bit Modus und wieder zurück schalten. 32-Bit Prozesse laufen also keines Wegs in einer VM oder etwas ähnlichem. Alles was WOW64 macht ist den 32-Bit Prozessen eine Win32-kompatible API zur Verfügung zu stellen...

Zitat von LoRd_MuldeR

32-Bit Prozesse laufen unter 64-Bit Windows genau so "native" wie 64-Bit Prozesse. 32-Bit Prozesse laufen also keines Wegs in einer VM oder etwas ähnlichem. Alles was WOW64 macht ist den 32-Bit Prozessen eine Win32-kompatible API zur Verfügung zu stellen...

Nun, sie laufen in WoW64 ... also einem Emulator, der in das 64-Bit System integriert ist. Das geht zwar, aber natürlich müssen dann alle Libraries bis runter zum Kernel auch nochmal in 32bit Form in den Speicher geladen werden. Was aber im Grunde gegen die Idee von Libraries ist.

Am sinnvollesten ist es schon, dass man alle Programme in 64 bit Fassung auf dem Rechner laufen hat, damit nicht alle Libraries doppelt im Speicher liegen.

mfg,
Monarc

Zitat von monarc99

Nun, sie laufen in WoW64 ... also einem Emulator, der in das 64-Bit System integriert ist.

Eben das ist nicht der Fall

Richtig ist, dass unter 64-Bit Windows grundsätzlich alle System DLL's zwei mal vorhanden sind, einmal als 64-Bit Variante und einmal als 32-Bit Variante.
WOW64 sorgt dafür, dass jeder Prozess die jeweils passenden DLL's und Registry Einträge "sieht". Das war's im Prizip aber auch schon.
Die 32-Bit Prozesse laufen genau so "nativ" auf der CPU, wie jeder 64-Bit Prozess. Wenn irgendwas "emuliert" wird, dann sind es bestimmte System Aufrufe.
Man darf sich das aber nicht so vorstellen, dass 32-Bit Prozesse in einer VM oder gar in einem Emulator (à la QEMU) laufen...

Zitat von monarc99

Das geht zwar, aber natürlich müssen dann alle Libraries bis runter zum Kernel auch nochmal in 32bit Form in den Speicher geladen werden. Was aber im Grunde gegen die Idee von Libraries ist.

Unter Windows lädt eh jeder Prozess seine eigene Instanz der benötigten DLL's in seinen eigene Adressraum. Zumindest bei den aller DLL's.
Soweit ich weiß, werden nur einige System-DLL's wirklich systemweit "geshared". Ansonsten bezieht sich das "shared" eher auf den Code auf der Festplatte.
Das Argument zieht so also nicht! Und eine WOW64 Umgebung ist eh auf jedem 64-Bit System vorhanden. Bei mir sind etwa 2/3 der Prozesse 32-Bit.

Tatsächlich sind 64-Bit Binaries sogar größer (jedes "Instruction Word" ist 64-Bit groß, anstatt 32-Bit) und belegen dementsprechend mehr Arbeitsspeicher ;D

64-Bit Programm haben zwei große Vorteile:
* Es kann mehr Arbeitsspeicher direkt adressiert werden (derzeit etwa 256 TB)
* Es stehen mehr "general purpose" Register zur Verfügung und die Register sind größer

Für Anwendungen, die daraus keinen Vorteil ziehen können, bringt der 64-Bit Modus keinerlei Gewinn.

Übrigens muss nur das Betriebssystem 64-Bit sein, damit mehr als ~3 GB physikalischer Arbeitsspeicher genutzt werden können.
32-Bit Prozesse sind halt weiterhin auf 2 GB virtuellen Speicher pro Prozess beschränkt. Aber für die aller meisten Anwendungen ist das mehr als ausreichend.
Wenn eine GUI Anwendung so viel Speicher verbraucht, dann ist da irgendwas grundsätzlich falsch