Konvertierung fehlgeschlagen

General Support / Questions
1

Ich habe leider nicht so viel Glück, bin mir aber nicht sicher, ob es am Untertitel-Grund liegt.

Log ist angehängt. Völlig unqualifiziert, diese Entscheidung zu treffen, aber ich denke, es gab Probleme mit Folgendem:

2018-02-11T21:47:17 MCEBuddy.AppWrapper.FFmpeg → Please use -b:a or -b:v, -b is ambiguous

Hier ist das detaillierte Log:
NFL Football (2002) - 2018-02-04 - Philadelphia Eagles vs. New England Patriots.ts-Profile Test-2018-02-11T18-19-59.9641097-05-00.log.zip (4,3 MB)

Irgendwelche Ideen?

Danke
BrianGGG

2

Völlig unabhängig von Untertiteln.

Sie haben einen fehlerhaften Videoaufnahmestream

2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] start time for stream 0 is not set in estimate_timings_from_pts
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size

Deshalb stolpert ffmpeg und schlägt fehl.

2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:0 → #0:0 (h264 (native) → h264 (libx264))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:1 → #0:1 (ac3 (native) → aac (libfdk_aac))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Press [q] to stop, [?] for help
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Too many packets buffered for output stream 0:1.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → [libfdk_aac @ 00000215284102e0] 2 frames left in the queue on closing
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!

Ich habe auch bemerkt, dass Sie Handbrake aus Ihrer Encoder-Reihenfolge entfernt haben, damit es nicht versucht, auf Handbrake zurückzugreifen:

order=ffmpeg,mencoder

Versuchen Sie, Handbrake nach ffmpeg hinzuzufügen.

Die Hauptursache ist jedoch ein fehlerhaftes Aufnahmegerät, das eine nicht konforme Videodatei erstellt. Es könnte an schlechter Geräte-Firmware oder fehlerhaften Treibern liegen.

3

Danke, dass du dir das ansiehst. Ich habe seit der Aufnahme des Videos so viele Änderungen an Treibern, Profilen usw. vorgenommen (um Hardware-Encoding erfolgreich zu ermöglichen), dass ich nicht sicher bin, ob ich dieses Rätsel lösen kann.

Das ist aber in Ordnung, denn ich habe in späteren Aufnahmen nichts Vergleichbares mehr gesehen…

Ein paar Fragen dazu:

  1. Hat die Fehlermeldung in meinem ursprünglichen Beitrag („Please use -b:a or -b:v, -b is ambiguous“) eine brauchbare Aussage oder handelt es sich dabei um eine Nebensache?

  2. Ich habe Handbrake entfernt, weil das der einzige Weg war, sicherzustellen, dass FFMPEG Hardware-Encoding auf NVIDIA durchführt. Da ich eine NVIDIA-Karte mit CUDA und eine Intel-Karte mit QuickSync habe … führte die aktuelle Reihenfolge zu einem Software-Encoding durch Handbrake.

Ich werde Handbrake wohl meine CPU für eine Weile voll auslasten lassen, um diese Konvertierung zu schaffen…

Danke
BrianGGG

4

Keine Auswirkungen, ffmpeg unterstützt verschiedene Eingabestile; wir verwenden einen älteren, kompatibleren.

Verstanden; im nächsten Release patchen wir auch das, sodass die Kodierer nicht mehr umgeordnet werden, wenn beide Hardware-Kodierung unterstützen.

5

Okay, das habe ich im heutigen 2.4.9-Beta-Build gepatcht. Probiert es aus.

6

Es ist durchaus möglich, dass ich nicht verstanden habe, was dieser Patch bewirken soll, aber ich halte ihn nicht für erfolgreich. Zwei Beispiel-Logs finden Sie unten.

Ich habe die Standardprofile beim Installieren der Beta 2-12 unverändert gelassen, in der Annahme, dass das Algorithmus irgendwann FFMPEG wählen würde, da der Idealfall die Hardware-Kodierung mit meiner NVIDIA ist.

Offenbar war das nicht der Fall, denn die Logs zeigen, dass beide Aufträge HandBrake verwendet haben … ohne Hardware-Beschleunigung.

Bitte lassen Sie mich wissen, ob meine Annahmen über die Funktionsweise falsch waren.

log.zip (230,2 KB)

Danke
BrianGGG

7

Dieser Patch sollte die vom Benutzer ausgewählte Reihenfolge des Encoders beibehalten, falls mehr als ein Encoder Hardware-Encoding unterstützt. In deinem Fall unterstützen sowohl Handbrake als auch FFmpeg Hardware-Encoding-Funktionen, daher wurde sichergestellt, dass deine bevorzugte Reihenfolge nicht geändert wird.

Dein Profil sah wie folgt aus:

order=handbrake,ffmpeg,mencoder

Du hast MCEBuddy gebeten, zuerst Handbrake und dann FFmpeg zu verwenden, und genau das hat es getan.

Ich denke, du wolltest Folgendes schreiben:

order=ffmpeg,handbrake,mencoder

Verwende zuerst den FFmpeg-(Hardware-)Encoder, und falls dieser fehlschlägt, wechsle zu Handbrake.

8

Danke, Goose. Das hat das akute Problem gelöst. Ich habe die Reihenfolge geändert und kann bestätigen, dass FFMPEG nun die Hardware-Kodierung auf meiner NVIDIA-Karte nutzt (was in 2.4.8 nicht der Fall war).

Daraus ergeben sich ein paar Fragen/Anmerkungen:

Erstens … ich glaube, ich habe missverstanden, was eigentlich passiert. Die Reihenfolge zu erhalten erlaubt mir, ffmpeg zu erzwingen, doch eine noch flexiblere Lösung wäre, wenn MCEBuddy basierend auf der Konfiguration selbst entscheiden könnte, welchen Weg es einschlägt.

Ich schlage vor, dass es ideal wäre, wenn MCEBuddy zuerst alle Hardware-Kodierungswege ausprobiert und danach auf Software zurückgreift. Das ursprüngliche Problem in 2.4.8 war, dass MCEB Handbrake-Hardware-Kodierung versuchte, scheiterte und dann auf Handbrake-Software zurückfiel. Das war für meine Konfiguration nicht optimal.

Möglicherweise ein Wunschdenken, aber im Idealfall wäre Handbrake-Hardware, Fehler, dann Fallback auf ffmpeg-Hardware. Sollte auch das scheitern, würde man die Liste erneut mit Software-Kodierung durchlaufen.

Außerdem: Würdet ihr ein Feature-Request für die aktuelle Profile.Conf akzeptieren? Es ist nicht ideal, dass ich bei jeder Beta und jedem Release, das ich installiere, die Reihenfolge in jedem Profil ändern muss, das Handbrake nutzt.

Eine mögliche Alternative wäre das Konzept einer „Benutzer-Profil-Datei“ in einem Benutzerordner (statt im Programmordner). Diese Datei bliebe während Upgrades erhalten und könnte zwei Zwecke erfüllen:

  1. Individuelle Benutzer-Profile könnten erstellt und gepflegt werden und würden im Menü neben den System-Profilen angezeigt.

  2. Werte in bestehenden Profilen könnten überschrieben werden. Das erlaubt, dass sich änderbare Elemente (wie Parameter für ffmpeg) mit neuen Releases aktualisieren, während Benutzereinstellungen wie die Konverter-Reihenfolge erhalten bleiben.

Nur ein paar Gedanken – ich habe den Vorteil, keine Ahnung von der Komplexität zu haben.

Mit freundlichen Grüßen
BrianGGG

9

Ja, das steht auf unserer nächsten To-do-Liste; das ist etwas komplexer, daher wird es etwas Zeit brauchen, bis wir es ausgearbeitet haben.

Schon vorhanden → Systemeinstellungen

image

10

Danke für die Antworten.

Es ist großartig zu wissen, dass die „Hardware zuerst“-Reihenfolge auf der Roadmap steht.

Was die obige Diskussion zum Benutzerdefinierten Profil betrifft, werde ich eine Feature-Anfrage stellen, da ich denke, dass das Benutzerprofil eine „anstelle von“-Datei ist und nicht eine „zusätzlich zu“. Mein Vorschlag ist, dass wenn Sie 10 Profile in der Standard-Profil-Konfiguration und zwei im Benutzerprofil haben, MCEbuddy alle 12 anzeigt, nicht nur die zwei im Benutzerprofil. Ich denke, das wäre wesentlich wertvoller und flexibler…

Danke
BrianGGG

11

Um einen Feature-Request zu erstellen, ist das hier aus einem einzigen Grund knifflig: Manchmal benennen Leute das Profil nicht um, und dann haben sie zwei Profile – eines vom Master und eines vom Custom. Wir müssen herausfinden, welches Vorrang hat.

12

Ich werde eine separate Anfrage stellen. Mein Vorschlag für das Duplikat-Problem ist, dass man alles in der Benutzerdatei mit „USER_“ präfixt. Auf diese Weise bleibt „MP4 Normal“ in der offiziellen Profildatei von „USER MP4 Normal“ in der Benutzerdatei getrennt.