Posts by slart

    Keine Ahnung was du mit den Batch-Dateien fabrizierst.
    Für mich bleibt das ein No Go, dass mehrer nebeneinander "installierbare" Versionen auf ein und die selbe ini zugreifen. Bei Updates mag das OK sein, aber wenn man schon standalone Versionen anbietet, von denen man mehrere nebeneinander laufen lassen kann, dann absolut nicht. Allein schon deshalb nicht, weil sie auf USB-Sticks genutzt auf endlos vielen Rechnern, die vlc inis der User ungefragt verändern. Das freut User. Das begeistert User. Diese Problematik hast du noch nicht erkannt.


    Ich habe jetzt einfach den Ordner C:\Users\[UserName]\AppData\Roaming\vlc gesperrt. Da kann VLC da auch nichts reinschreiben. Was es zum Recording braucht, wird in der Kommandozeile mitgeliefert.
    Jetzt ploppt jedes Mal das "Privatsphären- und Netzwerkzugriff-Regeln" Popup auf. Mit einem klick ist es weg.


    Warum ich mehrere Versionen nebeneinander laufen haben will, ist absolut nebensächlich. Kann mir keiner verbieten. Zudem wird die Möglichkeit explizit angeboten (7z-, Zip-Versionen).


    Dass gerade du, der wohl am meisten damit zu tun hat, sich damit abgibt, kann ich absolut nicht nachvollziehen. Da hät ich schon längst einen Terz gemacht, dass die das gefälligst abstellen sollen. Füße küssen is nich.

    ach, na da fühle ich mich jetzt aber sehr veräppelt, wenn die ZIP Versionen nur Fake-Portable sind. Kann man mal sehen wohin das führt, wenn sich jemand sowas ausdenkt. Immer schön ins Betriebssystem einnisten, so tief es nur geht. Ach, und natürlich, wenn per USB Stick genutzt alle Rechner der anderen mit "infizieren". Da kann ich nur drüber meckern, so gut wie es geht, weil das wirklich Mist ist, und nur hoffen, dass VLC das sein lässt. Ich hab den Ärger. Du ja auch, mit deinen Batch-Dateien.


    Bei deinen Batch-Dateien blick ich nicht ganz durch. Wenn du eh rename machst, dann mach doch für jede Version ein anderes rename, oder gleich einen eigenen Ordner.


    Der Logscreen, der eben auch bei mir erscheint, erscheint mit der Kommandozeile, die du hier gepostet hast.


    Code
    1. START "" F:\VIDEOLAN\VLC215\vlc.exe --extraintf=logger --verbose=2 --logfile=F:\VIDEOLAN\vlc.log --logmode=text --file-logging screen:// :screen-fps=25 :screen-left=0 :screen-top=0 :screen-width=960 :screen-height=540 :sout=#transcode{vcodec=h264,vb=1600}:file{dst=F:\\VIDEOLAN\\Test_01.mp4}

    Jetzt hab ich auch den korrekten Namen dafür: "logger interface".


    Sorry, wenn ich unangenehm bin, aber solche Sachen stören mich.

    Dann sind wir an dem Punkt, an dem ich mehr Ahnung habe als du.
    VLC bietet selbst die Portablen Versionen an, von allen Versionen.
    Man muss sich nur durchklicken auf videolan.org.
    Hier ist das Verzeichnis aller Versionen, mit *.exe und *.7z sowie *.zip.
    Die *.zip Datei entpacken, oder die *.7z Datei mit dem Programm 7Zip entpacken, und man hat die Portable Version.
    http://download.videolan.org/pub/videolan/vlc/


    "Logscreen" ist das (schwarze) Fenster, dass neben dem VLC Fenster aufploppt.
    So sieht das aus (Beispiel): https://trac.videolan.org/vlc/…/ticket/13968/vlc-log.png


    Habe das irgendwo gelesen, dass man so die Fehlermeldungen sieht und bei dem installierten VLC 2.2.4 so eingestellt. Komischerweise wurde es vom Portablen VLC 2.1.5 übernommen. VLC bereitet sich da wohl selbst Probleme, da die Portablen Versionen auf die Verzeichnisse der installierten Versionen zugreifen. Und dann chrasht es eben. Kein Wunder! Welcher Spezialist an Programmierer hat denn diese Meisterleistung fabriziert?


    Hier eine selbe Fehlermeldung ohne Antwort:
    https://forum.videolan.org/viewtopic.php?t=122762


    Vor kurzem habe ich für Audacity den FFmpeg Codec installiert. Allerdings habe ich Audacity nur als Portable Version und den FFmpeg Codec in den Ordner von Audacity gespeichert, also nicht global installiert.
    Da bekannt ist, dass selbst Portable Progs in Windows rumpfuschen, ist es möglich, dass VLC sich da selbst Probleme bereitet. Oder soll das heißen, dass VLC diesen Codec vermisst?

    Hey kodela, nicht dass das falsch rüber kommt.
    Also erstmal DANKE! dafür, dass es jetzt funktioniert! :)


    Ich habe jetzt die Version 2.2.4 deinstalliert.
    Habe den PC danach neu gestartet.
    Natürlich, wie zu erwarten, bleiben jede Menge Registry-Einträge als Erinnerung zurück...


    Vor einer neuen Testaufnahme habe ich den Ordner:
    C:\Users\xxx\AppData\Roaming\vlc gelöscht.
    Er wird bei einem erneuten Aufnehmen neu angelegt, mit entsprechenden Dateien.
    Wieso Portable auf C:\ zugreift, ist nicht die feine Art. Andere Protable Progs fragen, wo sie ihre Dateien ablegen sollen. Im selben Verzeichnis wäre angebracht.


    Das Aufnehmen funktionierte wie gehabt.
    Aber auch jetzt werden die beiden Fehlermeldungen beim Abspielen im Logscreen angezeigt:

    Code
    1. [h264 @ 076e5820] A non-intra slice in an IDR NAL unit.
    2. [h264 @ 076e5820] decode_slice_header error

    OK, halb so schlimm, da das aufgenommene Desktopvideo dennoch abgespielt wird. Aber vorsorglich frage ich lieber nach, nicht dass es beim späteren bearbeiten Probleme macht.


    Ich versuche nochmal das Logfile als txt File anzuhängen. Ein frisches nur von dieser Aufnahme/Abspielen.

    Files

    • vlc.txt

      (20.17 kB, downloaded 461 times, last: )

    Wieso? Es hat doch funktioniert. hab ich doch geschrieben. Nur gab es beim Abspielen die Fehlermeldungen, die ich hier notiert habe. Die gibt es weiterhin, auch mit deiner Kommandozeile.

    • [h264 @ 076e5820] A non-intra slice in an IDR NAL unit.
    • [h264 @ 076e5820] decode_slice_header error

    Wieso greift die Portable Version in F:\ auf C:\ zu?
    Wieso machen Programme sowas immer? Das finde ich so schlimm. Es gibt wohl kein einziges Programm mehr, dass wirklich sauber funktioniert, alle machen noch irgendeinen anderen Kram dazu. Selbst bei Linux...


    Hier das Logfile einer neuen Aufnahme mit deiner Kommandozeile. ~.log als Anhang geht nicht. Wie du das mit "Protokoll anzeigen" hab ich nicht gefunden.
    EDIT: Als Spoiler ist der Text zu lang. Jetzt probier ich das log als txt im Anhang.
    Ach, das ist schlimm hier... zum Glück speicher ich immer meinen geschriebenen Text zwischen, sonst wäre er jetzt mit klicken auf "In Text einfügen" bei Dateianhänge weg. Wer WYSIWYG Editoren erfunden hat gehört gestraft.


    vlc.txt


    Und irgendwie geht das auch nicht... is mir jetzt zu blöde.vlc.txt

    Das würde voraussetzen, dass ich einen Fehler mache. Ich habe an den Werks-Einstellungen nichts geändert, also kann ich auch nichts falsch gemacht haben. Das mit dem Kommandozeilenstring hatte ich probiert und wohl Fehler gemacht. Also war das fehleranfälliger.


    Habe jetzt den Ordner vom VLC 2.1.5 (Portable) in einen extra neuen Ordner:
    F:/VIDEOLAN/VLC215/


    Test mit Kommandozeile liefert folgende Ergebnisse:

    Code
    1. START "" "F:/VIDEOLAN/VLC215/vlc.exe" screen:// :screen-fps=25 :screen-left=0 :screen-top=0 :screen-width=960 :screen-height=540 :sout=#transcode{vcodec=h264,vb=1600}:file{dst=F:/VIDEOLAN/vlc01.mp4}

    Die GUI und das Log-Fenster von VLC öffnen sich. Der Timer läuft. Im VLC Fenster ist nur schwarz.
    Es wird ein File "vlc01.mp4" in F:/VIDEOLAN/ angelegt, das stetig größer wird.
    Stopp gedrückt in VLC GUI. Der Timer stoppt. VLC mit Log-Fenster bleibt geöffnet.
    Abspielen des Files mit VLC 2.2.4 und VLC 2.1.5 funktioniert. Das Log-Fenster zeigt in beiden VLC-Versionen folgendes:

    Code
    1. [h264 @ 076e5820] A non-intra slice in an IDR NAL unit.
    2. [h264 @ 076e5820] decode_slice_header error

    ------------------------------------------------------------------------
    Weitere Details mit VLC 2.2.4:


    Dieser String funktioniert nicht:

    Code
    1. START "" "C:/Program Files(x86)/VideoLAN/VLC/vlc.exe" screen:// :screen-fps=25 :screen-left=0 :screen-top=0 :screen-width=960 :screen-height=540 :sout=#transcode{vcodec=h264,vb=1600}:file{dst=F:/VIDEOLAN/vlc0224.mp4}

    "Die Datei "C:/Program Files(x86)/VideoLAN/VLC/vlc.exe" kann nicht gefunden werden."


    Dieser String crasht VLC 2.2.4:

    Code
    1. START "" "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" screen:// :screen-fps=25 :screen-left=0 :screen-top=0 :screen-width=960 :screen-height=540 :sout=#transcode{vcodec=h264,vb=1600}:file{dst=F:/VIDEOLAN/vlc0224.mp4}

    Backslash \ statt / im Filepath zu vlc.exe.
    VLC crasht (ploppt nur auf und zu). Es wird eine vlc0224.mp4 angelegt (1kb). Eintrag im vlclog.txt:

    Dieser String crasht VLC 2.2.4 ebenfalls:

    Code
    1. START "" "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" screen:// :screen-fps=25 :screen-left=0 :screen-top=0 :screen-width=960 :screen-height=540 :sout=#transcode{vcodec=h264,vb=1600}:file{dst=F:\VIDEOLAN\vlc0224.mp4}

    Backslash \ statt / im Filepath zu vlc.exe. und zum File vlc0224.mp4
    VLC crasht (ploppt nur auf und zu). Es wird wieder eine vlc0224.mp4 angelegt (1kb, die vorherige wurder vorher gelöscht). Eintrag im vlclog.txt:

    Habe jetzt die Version 2.1.5 / 32bit als ZIP (Portable) gedownloaded.
    Version 2.2.4 habe ich nicht deinstalliert.


    Ein Versuch einer Aufnahme mit Version 2.1.5 / 32bit Rincewind (Portable) scheiterte, allerdings ohne Crash. Der Timer lief. Nach ~30 Sekunden habe ich erst Pause und dann Stopp gedrückt.
    Es wurden keine Änderungen an den Einstellungen vorgenommen (1f/s, 5kB/s).


    Es wurde wieder ein 1kb File angelegt mit folgendem Inhalt:

    Quote

    ftypisom mp41avc1qt ¡moov lmvhd ÔÃë‡ÔÃë‡ _ @ trak \tkhd ÔÃë‡ÔÃë‡ @ $edts elst zmdia mdhd ÔÃë‡ÔÃë‡ B@ -hdlr vide VideoHandler %minf vmhd $dinf dref url åstbl ™stsd ‰avc1 H H ÿÿ 3avcCd (ÿá gd (¬Ù@iäÀD Ê<`ÆX hëì², stts stsc stsz stco +udta #©enc vlc 2.1.5 stream output wide mdat

    Beim Abspielen des Files mit Version 2.2.4 und Version 2.1.5 / 32bit (Portable) wird im Log-Interface folgendes angezeigt:

    Code
    1. TagLib: MP4: No audio tracks.
    2. TagLib: MP4: No audio tracks.

    Mehr passiert nicht.


    Welcher Bereich aufgenommen werden soll und mit welcher Qualität ist solange nebensächlich, bis überhaupt erstmal eine Aufnahme funktioniert. Die 5000kB/s hatte ich irgendwo gelesen und eingetragen, weil da "Nicht benutzt" stand.


    Bei beiden Versionen steht folgendes bei Videocodec "H-264":
    Quality: Nicht benutzt
    Frame Rate: Gleich, wie die Quelle

    VLC 2.2.4 Weatherwax
    Win 7 (Dienst Windows Media Player deaktiviert)
    CPU AMD


    Hallo, seit vielen Jahren versuche ich ab und an den Desktop aufzunehmen und bin bisher immer gescheitert. Jetzt frage ich hier einmal nach, warum.


    Es gibt jede Menge Anleitungen im Internet, mit dem VLC den Desktop aufzunehmen, die voll easy aussehen, aber bei mir nicht funktionieren.
    Mein vorgehen:
    - VLC frisch downloaden (nach Win 7 Neuinstallation)
    - VLC öffnen
    - Medien → Aufnahmegerät öffnen
    - Aufnahmemodus → Desktop
    - Bildwiederholrate → 25,00 f/s
    - Konvertieren
    - Quelle → screen://
    - Profil → Video - H.264 + MP3 (MP4) → Einstellungen → Videocodec → Codec → Bitrate → 5000kB/s → Speichern
    - Zieldatei → C:\Users\xxx\Desktop\screen.mp4
    - Start
    - VLC stürzt ab!


    - screen.mp4 → 1kb → "VLC kann das Eingabeformat nicht erkennen."
    Inhalt über notepad++: " ftypisom mp41avc1 mdat "


    Inhalt vom Logfile:
    "
    -- logger module started --
    core: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
    dshow error: no video capture device was detected
    x264: using cpu capabilities: MMX2 SSE2Fast LZCNT
    x264: profile High, level 4.0
    x264: final ratefactor: 17.26"


    Für den Error "dshow error: no video capture device was detected" gibt es hier eine ungelöste Anfrage:
    https://forum.videolan.org/viewtopic.php?t=20476


    Bei Neustart von VLC → crash Report senden? → Ja → Fehler beim Senden → VLC geöffnet.

    Danke kadela und thweiss für die Informationen.
    Allen Anschein nach liegt es an dem MP3-Encoder, bzw. an seiner variable-Bitraten-Codierung, mit dem die Stream-Audio-Files codiert wurden. MediaInfo liefert bei Audio-Files, die mit dem Lame-MP3 Encoder in variabler Bitrate codiert wurden ordentlich Infos auch über eben diesen Encoder, mit dem die Audio-Files codiert wurden, sowie die Gesamtzeit.


    Player haben mit Lame-MP3 codierten langen Audio-Files in variabler Bitrate keine Probleme. Bei den Stream-Files mit variabler Bitrate ist hingegen gähnende Leere bei den File-internen-Infos in MediaInfo. Also liegt es weniger an der Länge, sondern am Encoder und da wiederum nur an seiner variable-Bitraten-Codierung.
    Durch eine größere Länge solcher (nicht Lame-MP3) Audio-Files mit variabler Bitrate wird das Risiko erhöht, dass Player ein Problem mit der Gesamtzeit-Berechnung bekommen, da sie diese berechnen müssen und nicht aus den File-internen-Infos einfach auslesen können. So gesehen ist es dann doch eine "Schwäche" der Player, nicht genügend mit solchen encodierten Audio-Files umgehen zu können. Vielleicht sogar beabsichtigt, da Stream-Files. Allerdings wäre es wegen Dateigröße reduzieren wohl etwas übertrieben, die Gesamtzeit-Anagbe einzusparen. Oder?

    Hallo kadela, danke fürs entgegenkommen. Nur mal nicht zu voreilig alles vom heiligen VLC abweisen. Schließlich gibt es keine Probleme im Chrome Browser.


    Ich habe ein wenig rumprobiert. Aber vorneweg erstmal zu deinem verlinkten File. Wenn ich diesen Link nicht downloade, sondern direkt als Netzwerkstream öffne und kurz nach dem Öffnen in der Zeit vorspringe, dann bricht VLC den Stream ab, Ende. Aber nicht immer!
    OK, das ist dann wohl ein anderes Problem, als das mit der Gesamtzeit/Restzeit, das da nicht besteht. Das Abbrechen beim Vorspringen liegt wohl an einem Kommunikationsfehler zwischen PC und Streamserver. Also weiter zum ursprünglichen Problem mit der Gesamtzeit/Restzeit.


    Die von mir erwähnten MP3-Files mit den Problemen sind ebenfalls solche "Streams". Eine Kuriosität, und hier vermute ich das Problem, besteht, wenn ich aufgenommene, also nicht downgeloadete, sondern am eigenen PC mit einem viel verwendeten Profi-Mediendesigner-Audioeditor aufgezeichnete Streams, die ich mit diesem Tool in *.wav abgespeichert habe und anschließend in *.mp3, eben diese selben Probleme machen, wie die downgeloadeten MP3-Stream-Files. In WAV-Format gibts übrigens keine Probleme. Es liegt nahe, dass es an diesem Tool liegt, bzw. dessen MP3-Encoder. Denn...


    Wenn ich die downgeloadeten MP3-Stream-Files in Audacity neu in MP3 codiere, besteht das Problem nicht mehr.

    Hallo,
    Es gibt ein Problem mit sehr langen (lokalen) MP3s, die über 1 Stunde lang sind. VLC (2.2.1) hat da ein Problem mit der Anzeige der Gesamtzeit/Restzeit.
    Beispiel: Ein MP3-File mit 2:00:00 zeigt beim Öffnen diese Länge an und fängt sofort an bei der Anzeige der Gesamtzeit rückwärts zu zählen. Die Gesamtzeit springt dann iwann wieder vor und verhält sich allgemein sehr nervös, kann sich nicht festlegen. Selbes umgekehrt bei der Restzeit. Beim Springen per Maus zu einer beliebigen Zeit nach circa 1:45:00 bricht das File ab. Als wenn das File ab einer bestimmten Länge kaputt wäre. Ist es aber nicht.
    Das MP3 File wird in Audacity in der kompletten Länge angezeigt und kann da auch in der kompletten Länge abgespielt werden. Ein neues Konvertieren bringt keine Änderung.
    Läuft das MP3-File eine Weile (5-10 min) im VLC, dann kann auch bis fast zur regulären Endzeit gesprungen werden.


    Ähnliche Probleme beim Abspielen und dem Anzeigen der Gesamtzeit gibt es zudem mit dem SMPlayer und sogar Winamp.


    Keine Probleme beim Abspielen gibt es in Browsern, wie Firefox oder Chrome. Wobei Firefox eine falsche (zu lange) Gesamtzeit anzeigt und zur Endzeit hin nervös wird. Chrome zeigt hingegen keine Gesamtzeit, aber im Abzählen der Zeit liegt er bei der Endzeit richtig und wird auch nicht nervös. In den Browsern kann sofort problemlos zu einer beliebigen Zeit gesprungen werden.


    Anfangs dachte ich an ein Problem mit den MP3s. Ist es aber nicht. Ist sehr wohl ein Player-Problem.