VideoLAN hat ein neues Update für den VLC zum Download und Testen bereitgestellt. Der VLC 3.0.18 ist als RC erschienen und wenn keine größeren Probleme enthalten sein sollten, dürfte diese Version dann auch als finale erscheinen.
Es wurden wieder so einige Korrekturen und Verbesserungen gegenüber der derzeitigen Version 3.0.17.4 vorgenommen. Hier einmal ein Auszug:
- Demux:
- Großes adaptives Streaming-Update, insbesondere für mehrere Timelies und Webvtt
- Korrektur der Suche mit einigen fragmentierten MP4-Dateien
- Unterstützung für DVBSub innerhalb von MKV hinzugefügt
- Korrektur einiger Flac-Dateien, die nicht abgespielt werden konnten
- Verbessertes Suchen in Ogg-Dateien
- Dekodierer:
- Korrektur von DxVA/D3D11-Abstürzen bei HEVC-Dateien mit falschen Referenzen
- Korrektur der libass-Speichergröße und der Abstürze
- Korrektur von Dekodierungsfehlern bei der macOS hw-Dekodierung bei einigen HEVC-Dateien
- Video-Ausgabe:
- Korrektur der farblichen Abweichungen bei der VAAPI/iOS- und OpenGL-Ausgabe
- Korrektur einiger Größenänderungsprobleme mit OpenGL unter GLX/EGL/X11/XV
- Korrektur der 10-bit beschleunigten Videofilter unter macOS
- Wiedergabeliste: Vermeidet den Live-Loop der Playlist bei fehlgeschlagenen/kleinen Elementen (temporäre EOS-Bursts)
- Verschiedenes:
- Verbessertes SMBv1- und SMBv2-Verhalten
- Verbesserte FTP-Kompatibilität
- Unterstützung von RISC-V
- Korrektur des AVI-Muxing für Windows Media Player-Kompatibilität
[Update]: Die finale Version ist jetzt erschienen. Mehr dazu unter:
Info und Download:
VLC 3.0.18 mit einem großen adaptiven Streaming-Update als RC erschienen
Bekommen wir auch noch mal eine Info, wenn die finale Version da ist?
Lass dich überraschen.
früher oder später schon
Ich habe es mal versucht. Es gab ein Problem mit dem Windows Installer Package. Die Installation konnte nicht ausgeführt werden. Dann warte ich eben bis zum offiziellen final release und installiere es über die Funktion im Player.
Problem hatte ich auch mit dem Windows Installer Package – aber die „normale“ exe funktioniert (einwandfrei)
Danke, dann werde ich es noch mal damit versuchen.
Das Problem ist, dass das .msi Paket die bereits installierte Version nicht deinstallieren kann, weil die „uninstall.exe“ nicht ausgeführt werden kann, obwohl sie da ist. Das hatte ich aber auch schon mit der Version 3.0.17.4, weswegen das Update über winget nicht geklappt hat.
Okay, ich habe die exe-Datei genommen und es lief.
„…weswegen das Update über winget nicht geklappt hat.“
Das mit Winget ist (momentan) auch nicht das Wahre vom Ei, momentan wird mir darüber
( mit –upgrade all) auch versucht IMMER ein älterer AIMP zu installieren ( was natürlich schief geht) , obwohl schon eine neuere Version raus ( und auch installiert) ist
Ja, winget und Versionen, das ist auch so ein Fall für sich.
Nö, kannst Du winget nicht anlasten, sind schon die Trolle, die unfähig sind ihre Installer und Programme korrekt auszuliefern und Mist auf das Repository hochladen.
Da gibt es dann Einsichtige, die Dir am Tag, nachdem Du ihnen das Problem gemailt hast, eine korrigierte Version zum Testen mailen und die, die dir irgendwelchen Blödsinn zurückmailen, dass das ein Problem von Microsoft wäre und sie nix damit zu tun haben. – Nö, werter Herr Präsident, es waren schon die …, Deiner Projekt-Entwicklungsabteilung, die falsche Versionsnummern reingeschrieben und den Blödsinn hochgeladen hatten – das ist statistisch R-wiesen. Da sollte man dann auch dazu stehen und den Verantwortlichen in der eigenen Organisation direkt darauf hinweisen, statt blöd rumzulabern. Und wenn man in Deutsch angeschrieben wird, sollte man auch nicht in Englisch antworten, vor allem dann nicht, wenn man laut Lebenslauf mal in Bayern gejobbt hat, das Projekt in Österreich gehostet ist und man selbst schon in Deutsch publiziert hat.
So einfach ist das aber nicht. winget hat da durchaus Probleme mit den Versionen. Im Falle von AIMP war bzw. ist es so, dass in winget aktuell es die Version 5.03.2397 ist. Installiert man aber manuell die aktuell die 5.03.2398, dann erkennt winget zwar, dass die 5.03.2398 installiert ist, da aber für winget die 5.03.2397 aktuell ist, wird beim Upgrade die 5.03.2397 installiert. Den AIMP Installer interessiert das auch nicht weiter. Der aktualisiert die aktuell installierte Version auch mit einer älteren Version. An der Stelle müsste winget das Upgrade einfach abbrechen, macht es aber nicht.
Einigen wir uns darauf, da haben sich zwei 80:20 Trolle gefunden.
Ich gebe Dir recht, korrekterweise müsste winget das abfangen, die paar Zeilen Source Code, die dafür nötig sind, einzufügen kann sich die Klitsche, die dahinter steckt, aber vermutlich personell und finanziell nicht leisten. Da wären sie vermutlich völlig überfordert – dauert garantiert Jahre und hunderttausend Zeilen, um das zu realisieren. Mit dem einen Systemanalytiker und zwei Tippäffchen zum Auscodieren, die der Laden beschäftigt, wird das vermutlich in diesem Jahrhundert nix mehr. Dieses komische Ding mit ‚if‘, ‚else‘ und ein paar Klammern samt Inhalt ist ja sooooo kompliziert. Vermutlich aber einfach zu neu, als dass das jeder schon kennt.
Vielleicht steht dem aber auch nur diese Kotz-80:20-Mentalität im Weg, wenn alle anderen alles richtig machen, brauchen wir die letzten 20 % nicht zu leisten. Warum 100 % abliefern, wenn weniger vielleicht auch reicht.
Motto, wenn alle ihre Versionsnummern mit jedem Installer korrekt überall reinschreiben und die neueste Version zuerst in das Repository von winget hochladen, bevor sie es auf der eigenen Website einstellen, kann ja gar nix passieren.
Wie zumindest wir zwei wissen, funktioniert das prächtig, muss keine Seite was ändern.
Mozilla schreibt weiterhin 105.0 ins System und liefert dann aber 105.0b2, … aus ohne das zu ändern oder irgendein Troll vergisst die Versionsnummer vor dem Kompilieren an allen Stellen im Source zu ändern (wieso eigentlich, steht normalerweise in einer Variablen – aber zumindest die muss man anpassen – wenn im System was anderes, als bei ‚Über/Info‘ steht, hat’s jemand nicht begriffen, wie das geht und arbeitet falsch) und produziert munter neue Versionen, die sich mit der alten Versionsnummer eintragen.
Videolan schreibt bei VLC mit dem einen Installer 3.0.17.0 und mit dem anderen 3.0.17.4 ins System, obwohl beide 3.0.17.4 installieren und man das unter ‚Über‘ auch so nachzulesen ist. Machen sie mit 3.0.18 übrigens auch wieder, der .msi-Installer schreibt 3.0.18.0 und der .exe-installer 3.0.18-rc ins System, so wie man es auch unter ‚Über‘ nachlesen kann. Da weiß die linke Hand nicht, was die Rechte tut.
Und das alle das zeitgleiche Hochladen auf alle ihre Downloadoptionen beherrschen ist wohl auch eher Wunschdenken, das klappt schon nicht, wenn nicht möglicherweise noch eine Prüfinstanz, die das ganze auf böse Inhalte prüft, zwischengeschaltet ist. Da will keiner warten bis Microgoofy, Google oder wer auch immer geprüft hat, auf der eigenen Seite landet das Teil im Zweifel sofort.
Den Bug schleift man auch schon ewig in der Version 4.x mit.
Dinge wo man sich nur an den Kopf fassen kann. täglich neue Versione raus hauen und über Monate oder fast Jahre ist kein Hansel in der Lage mal den Installer richtig zu machen.
Stellt sich die Frage, ob sie den fehlerhaften .msi-Installer diesmal korrigiert haben.
Bei 3.0.17.4 hat der nämlich 3.0.17.0 ins System geschrieben, was in einer Endlos-Update-Schleife von winget geführt hat.
die .exe hat es richtig gemacht und wenn man mit der installierte, stand 3.0.17.4 im System und winget hat Ruhe gegeben.
Meldung vom 13. Januar 2019:
„In der kommenden Version 4.0 wird der VLC Media Player mit Airplay-Unterstützung erweitert werden.“
Also wenn wir uns in diesen Schritten fortbewegen, dann kann es bis Version 4.0 ja noch ein wenig dauern.
Ist ja schon fast so wie bei ReactOS.
Mit 3.0.18 wird die upnp Bibliothek gegen eine neuere Version ausgetauscht. Die Neue findet keinerlei DLNA Server mehr im lokalen Netzwerk. Tauscht man die libupnp.dll im Unterordner gegen die Version von 3.0.17.4, funktioniert wieder alles.
VLC Media Player 3.0.18
Download:
https://download.videolan.org/videolan/vlc/3.0.18/