Encoder-Absturz auf Adreno-GPU beim Codieren von Surface

Lesezeit: 4 Minuten

Benutzer-Avatar
Benutzer1592546

Ich kämpfe seit mehr als einer Woche mit diesem Problem, und höchstwahrscheinlich handelt es sich um einen Fehler in der Qualcomm GPU/Hardware-Videoencoder. Da wir unter Druck stehen, die Anwendung zu veröffentlichen, und ihre Entwicklerforen kein Feedback gegeben haben, poste ich sie auch hier, in der Hoffnung, dass jemand einige Hinweise oder noch besser einen Workaround geben kann, damit der Fehler im Encoder ist nicht ausgelöst.

Die Anwendung codiert von einer Oberfläche. Wenn bestimmte Bilder auf die Oberfläche gerendert werden, schlägt der Encoder an der gleichen Stelle (100 %) fehl (wenn das aktuell codierte Bild ein Schlüsselbild ist). Die Logcat-Ausgabe des Encoders zum Zeitpunkt des Absturzes lautet (wobei die letzten Zeilen mit einer sehr hohen Rate wiederholt werden):

11-26 11:41:33.312: E/OMX-VENC-720p(25949): ERROR: async_msg_process() - Error statuscode = 1
11-26 11:41:33.312: E/ACodec(29317): [OMX.qcom.video.encoder.avc] ERROR(0x80001009)
11-26 11:41:33.312: E/MediaCodec(29317): Codec reported an error. (omx error 0x80001009, internalError -2147483648)
11-26 11:41:33.362: E/OMX-VENC-720p(25949): ERROR: venc_use_buf:set input buffer failed 
11-26 11:41:33.362: E/OMX-VENC-720p(25949): ERROR: in dev_use_buf
11-26 11:41:33.362: E/OMX-VENC-720p(25949): ERROR: empty_buffer_done() failed!
11-26 11:41:33.372: E/OMX-VENC-720p(25949): m_fbd_count at o/p flush = 306
11-26 11:41:33.372: E/OMX-VENC-720p(25949): m_etb_count at i/p flush = 313
11-26 11:41:33.372: E/OMX-VENC-720p(25949): ERROR: ioctl VEN_IOCTL_CMD_FILL_OUTPUT_BUFFER failed
11-26 11:41:33.372: E/OMX-VENC-720p(25949): ERROR: dev_fill_buf() Failed
11-26 11:41:33.372: E/OMX-VENC-720p(25949): ERROR: FTBProxy() failed!

Ich kann es auch auf replizieren Grafika durch einfaches Ersetzen in der GL-App aufzeichnen das Zeichnen von zwei geometrischen Formen mit dem Zeichnen eines der problematischen Bilder im Vollbildmodus im Querformat und Ändern der Bitrate auf einen höheren Wert (7 Mbit / s). Der Absturz des Encoders erfolgt früher für größere Bitraten.

Hier ist eine Bild das scheint es leicht zu brechen und hier ist RecordFBOActivity.java mit den erforderlichen Änderungen.

Mit Grafika habe ich getestet und der Encoder stürzt sowohl auf Samsung S4, internationale Version, als auch auf dem ursprünglichen Nexus 4 ab. Mit unserer Software, die etwas komplexer ist als das Rendern des einfachen Bildes, stürzt es immer noch auf beiden ab. Habe es nicht auf anderen Adreno-Geräten getestet. Auf Samsung S3 mit einer Mali 400-GPU funktioniert es einwandfrei.

Bei 4 Mbit/s stürzt der Encoder in unserer Anwendung immer noch sowohl auf S4 als auch auf N4 ab, aber später. Grafika stürzt auf N4 an derselben Stelle ab, aber nicht auf S4.

BEARBEITEN: Laut den folgenden Kommentaren kann es auch reproduziert werden, wenn dasselbe Bild aus dem Puffer codiert wird. Verschiedene Tests scheinen die Bedingungen für die Reproduktion einzuschränken: h264 hw-Encoder auf Qualcomm-Geräten, Codieren eines Standbilds für viele Frames (dies bestimmt sehr niedrige Bitraten im Encoder aufgrund ähnlicher Frames), Fehler beim Codieren eines Keyframes (der Fehler tritt nur beim Codieren bestimmter Bilder auf, die mehr Details zu haben scheinen, dh viele Bits für die Intracodierung benötigen).

  • Das omx Fehlercode von 0x80001009 ist OMX_ErrorHardware was bedeutet, dass die Komponente einen Fehler in Bezug auf die zugrunde liegende Hardware zurückgibt. Können Sie bei der Oberflächenaufzeichnung schnell das Farbformat des Frames überprüfen, der der zugrunde liegenden HW bereitgestellt wird? Kannst du mal versuchen durch Konvertieren von RGB- in YUV-Raum zu sagen YUV420 Planar oder YUV420 Interleaved und dann den Encoder aufrufen, um zu codieren?

    – Ganesh

    3. Dezember 2014 um 0:18 Uhr

  • Bitte versuchen Sie INDE Media for Mobile, GLCapture-Beispiel von: github.com/INDExOS/media-for-mobile . Stürzt es ab? Es wurde definitiv überprüft, ob es auf S4 funktioniert. Ich erinnere mich auch, dass es auf einigen Geräten Probleme mit hohen Bitraten gab, die auf zu kleine (optimalere) Speicherpufferzuweisungen für codierte Frames zurückzuführen waren, sodass wir die maximale Bitrate begrenzen mussten

    – Marlon

    3. Dezember 2014 um 5:53 Uhr

  • @Ganesh: mEncoder.getCodecInfo().getCapabilitiesForType(“video/avc”) gibt 0x7FA30C06 zurück (nicht gefunden in den Definitionen der statischen Klasse CodecCapabilities, nur COLOR_QCOM_FormatYUV420SemiPlanar gefunden, was eigentlich 0x7FA30C00 ist), 0x7F000789 (COLOR_FormatSurface), 21 (COLOR_FormatYUV420SemiPlanar), – 1320330260 (konnte es nicht identifizieren). Ich verwende COLOR_FormatSurface, wenn das Format des Encoders konfiguriert ist, was “angibt, dass die Daten eine GraphicBuffer-Metadatenreferenz sein werden”. Mit RGB-> YUV und dann Codierung meinen Sie, glReadPixels zu verwenden, eine Konvertierung durchzuführen und dann aus dem Puffer zu codieren? Oder?

    – Benutzer1592546

    3. Dezember 2014 um 12:09 Uhr

  • @Marlon: Muss ich Intel® INDE, die kostenlose Edition, herunterladen und installieren, um es auszuprobieren? Media-for-mobile funktioniert also nicht alleine. Ist Inde nicht als Glas erhältlich?

    – Benutzer1592546

    3. Dezember 2014 um 12:35 Uhr


  • Sie benötigen die kostenlose INDE-Edition, Sie erhalten dort .jar-Dateien. Entschuldigung, es gibt keine Möglichkeit, .jar-Dateien auf andere Weise zu erhalten

    – Marlon

    3. Dezember 2014 um 13:02 Uhr

Es scheint ein Fehler zu sein, wie oben bereits erwähnt.

1226490cookie-checkEncoder-Absturz auf Adreno-GPU beim Codieren von Surface

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy