Ich habe die ältere kostenlose Version verwendet und festgestellt, dass alle 1080i-TS-Aufnahmen aus Plex nach der Konvertierung in mp4 oder MKV sehr ruckelig/zitterig waren (alle paar Frames stocken). Ich habe versucht, die Ausgabe auf 720p zu reduzieren, aber ich erhalte dieselben Ergebnisse. Ich habe nun die neueste MCEBuddy-Version gekauft und habe immer noch dieses Problem. Gibt es eine Einstellung oder ein Profil, das ich verwenden muss, um zu verhindern, dass dies passiert? Alle 720p-Quellen werden von .ts in mp4 konvertiert, ohne Probleme.
Das war standardmäßig aktiviert und ich habe es so belassen… wenn ich die 1080i-Quelle .ts mit Handbrake encodiere, sehe ich das Zittern/Zögern in der resultierenden Datei nicht.
Versuchen Sie, die Option Skip remuxing auf der Experteneinstellungsseite der Konvertierungsaufgabe zu aktivieren. Dadurch sollte die Datei direkt an Handbrake weitergegeben werden, wenn Sie das MP4-Profil verwenden.
Überprüfe dein Profil und schau, ob Handbrake verwendet wird und welche Parameter eingestellt sind. Versuche es mit der Option Detect and optimize video quality und den Skip cropping-Optionen.
Ich habe nicht, aber was ich festgestellt habe, ist, dass die Quelldateien, die Plex vom HDHomerun speichert, nicht korrekt sind. Wenn ich die frisch aufgenommenen Dateien (nicht transkodiert) für 1080i-Sendungen (CBS oder NBC) ansehe, sind sie ruckelig, als würde der Deinterlacer nicht richtig funktionieren. Ich habe gelernt, damit für den Moment zu leben.
Danke für deine schnelle Antwort. Es scheint, dass Geräte wie oder ähnlich dem 4K Fire TV Stick (selbst mein Nvidia Shield Cube) mit interlaced Video nicht gut umgehen können, in manchen Fällen gar nicht. Ich werde versuchen, die Decomb-Einstellung in MCE Buddy Handbrake zu ändern und schauen, ob das hilft. Wenn es funktioniert, lasse ich es dich wissen.
Sie möchten die Option Detect and optimize video quality im Konvertierungsauftrag ausprobieren. Sie ist dafür gedacht zu prüfen, ob die Quelle interlaced ist, und die Deinterlace-Einstellungen dann automatisch anzupassen.
Hi, danke für deinen Vorschlag. Ich bin mir sicher, dass ich das schon einmal umgeschaltet habe, und es hat keinen spürbaren Unterschied gemacht. Ich werde aber vielleicht einen richtigen Test aufsetzen und sehen, ob es einen Unterschied macht.
Okay, ich glaube, ich habe möglicherweise eine Lösung gefunden. Man kann die konvertierten Dateien jedoch nicht erneut konvertieren. Die Problemdateien in meiner Bibliothek konnte ich daher nicht für den Test verwenden – die Originalaufnahmen wurden nach der Konvertierung gelöscht. Ich musste eine Problemdatei suchen und neu aufnehmen, was eine Weile gedauert hat. Ich stellte fest, dass das Problem bei bestimmten Landschafts-Panoramaaufnahmen sehr deutlich ist.
Das Profil, das ich bisher verwendet habe, ist „HDHomeRun H.264“. Dieses wählt zunächst HandBrake für die Konvertierung. Ich bin sicher, wenn ihr ein anderes Profil verwendet, könnt ihr dasselbe tun. (Schließt McBuddy zuerst, bevor ihr Änderungen vornehmt.)
Ich habe die profiles.config mit WordPad geöffnet, decomb=bob eingestellt und gespeichert
(C:\Program Files\MCEBuddy2x\config)
Es ist allerdings sehr CPU-intensiv: meine vorherige Konvertierung nutzte 99 % GPU und kaum CPU; BOB verwendet 99 % GPU und 75 % CPU. Die Dateigröße verdoppelt sich fast. Sie ist jedoch vergleichbar mit der einer nativen progressiven Aufnahme, die über MCEBuddy mit demselben Profil ohne BOB konvertiert wurde.
Die Zeit wird es zeigen …………………….. Wenn ihr die Änderung vornehmen wollt, lasst mich wissen, wie es läuft.
Ich kann bestätigen, dass das Setzen von Deinterlace auf BOB das Problem bei mir gelöst hat (habe gerade mit einer kürzlichen/neuen regelmäßig auftretenden Sendung herumgespielt)
Hoffe, es funktioniert auch bei dir
*Hmm, bei näherer Überlegung erzielen verschiedene Geräte und Player unterschiedliche Ergebnisse. (Es funktionierte für die Player- und Geräte-Kombination, die mich ursprünglich hierher geführt hat)
(habe gerade mit einer kürzlichen/neuen regelmäßig auftretenden Sendung herumgespielt)
