Ich habe die neueste 64-Bit-Version von MCEBuddy heruntergeladen und verwendet, und beim Konvertieren einer 1,6 GB großen Datei stieg der Speicherverbrauch von handbrakecli.exe auf 100 % (von 32 GB), bis mein Computer blockiert war. Ich bin auf die Website von HandBrake gegangen und habe die stabile 64-Bit-CLI-Version 1.0.7 heruntergeladen, und das Problem war bei derselben Datei verschwunden.
Danke, dass Sie uns darauf aufmerksam gemacht haben. Können Sie das Originalvideo hochladen, durch das Sie das Problem festgestellt haben, damit wir es in unser Test-Suite aufnehmen können? Keines unserer aktuellen Testvideos hat bisher das Problem verursacht, daher wäre das eine gute Ergänzung.
Die Details zum Upload-FTP-Server finden Sie im ReadMe-Beitrag
Leider habe ich die Datei bereits erfolgreich konvertiert und daher das Original gelöscht. Ich hänge meine Profile und Konfiguration an, falls es hilft. mcebuddy.conf (5,9 KB)
profiles.conf (17,1 KB)
Das verwendete Profil war das erste. (MP4 Matthew’s Custom 16:9 Rip 23.976)
1 „Gefällt mir“
Danke. 1.0.7 wird derzeit getestet und bei keinen Problemen im nächsten Release enthalten sein.
Update dazu: Die neueste stabile Handbrake-Version 1.0.7 hängt sich bei der Verwendung von Intel QuickSync-Encoding mit einigen Testdateien auf. Wir können Handbrake daher noch nicht aktualisieren, bis das Problem behoben ist. Ich lasse dies vorerst offen. Falls du auf eine weitere Dateie mit dem Speicherleck-Problem stößt, lade sie bitte auf den Server hoch.
Ich habe das neueste HandBrake-Paket vom Git-Master-Branch kompiliert. Die Nightly Builds liegen noch ein paar Tage zurück und enthalten nicht den Sound- und QSV-Fix, den dieser Build hat. handbrakeCLI_20170716_b77f66d.zip
1 „Gefällt mir“
In der nächsten Hauptversion 2.4.8 planen wir, die H/W-Kodierung zu überarbeiten, um die Leistung zu verbessern. Wir werden die Handbrake-Version im Release 2.4.8 aktualisieren.
Ich bin auf diesen Fehler erneut gestoßen. Ich habe mein Profil, die Konfiguration und die Videodatei in den FTP-Ordner mit einer kurzen Beschreibungsdatei hochgeladen.
1 „Gefällt mir“
Wir können das Problem reproduzieren. Aktualisieren Sie zuerst auf die neueste Nightly-Build von Handbrake, dies löst das 100%-Speicherproblem.
Zweitens ist Ihre Datei beschädigt: Sie enthält EOFs (End of File) mitten im Stream
hb_ts_stream_decode - eof
Wenn Sie dies OTA aufzeichnen, haben Sie einen fehlerhaften TV-Tuner-Treiber/Firmware, der EOFs mitten in die Datei einfügt.
Ich habe auch bemerkt, dass du das -ss 5 aus dem Remux-Profil und deinem benutzerdefinierten Profil entfernt hast; diese sind für solche Situationen gedacht, wenn Dateianfänge beschädigt sind. Versuche, es wieder hinzuzufügen, dann sollte es funktionieren.
Diesmal war es kein OTA, sondern ein Web-Rip. (Daher habe ich das -ss 5 entfernt, ich wollte die ersten 5 Sekunden des Videos behalten.) Könntest du mir vielleicht helfen, mein HandBrake-Profil in ein FFmpeg-Profil mit dem -ss 5 zu konvertieren? Meine Überlegung ist, dass ich sie in der Reihenfolge HandBrake, FFmpeg einstelle und dabei HandBrake ohne das -ss 5 und FFmpeg mit. So dass, wenn HandBrake bei so einem Fall versagt, automatisch zu -ss 5 gewechselt wird und ich nur diese 5 Sekunden verliere, wenn es wirklich sein muss. Ich habe schon versucht, auf FFmpeg umzusteigen, aber ich kenne mich damit bei Weitem nicht so gut aus wie mit HandBrake.
Dies wurde im heutigen 2.4.8 BETA-Build behoben. Wir haben außerdem Unterstützung für QuickSync-Hardware-Decoding in diesem Build hinzugefügt sowie verschiedene andere Hardware-Performance-Optimierungen.
Ja… das habe ich vor einiger Zeit auch bemerkt. Ich habe einfach die neueste CLI-Version heruntergeladen und im MCEBuddy-Installationsverzeichnis ersetzt. Damit wurde auch mein Hardware-Encoding-Problem mit QuickSync und Intel HD Graphics 530 behoben.