zsh: killed ffmpeg

B

biro21

unregistriert
Thread Starter
Dabei seit
19.01.2021
Beiträge
1.807
Reaktionspunkte
1.015
Hi,

compiliere mir aktuell ffmpeg in einer sehr einfachen Version selber für mein MBP M1 und habe das Problem, dass wenn ich die neue Version nach /usr/local/bin kopiere ein Aufruf von ffmpeg im Terminal mit obiger Fehlermeldung endet.

Ein Schließen des Fensters (Beenden der Session) oder Neustart des Terminals hilft nicht, erst nach einem Neustart des MBP ist alles als wäre nichts gewesen. Das Quarantäne-Attribut ist nicht gesetzt. Ein Doppelklick auf die ffmpeg-Binary startet es im Terminal.

Da am Videotoolbox-Code ja nicht so viel geändert wird, wird ffmpeg nicht so oft neu compiliert, würde aber gerne wissen, was das Problem ist. Weiß jemand warum das Problem auftritt?
 
Bei 16GB? Wäre wirklich skurril. Werde es aber beim nächsten Auftreten mal anschauen.
 
Bei 16GB? Wäre wirklich skurril. Werde es aber beim nächsten Auftreten mal anschauen.
Es kann auch Phyton oder Home Brew sein, da gibt es viele Dinge. Schau doch mal bei Superuser im Netz bzw. Google hilft hier auch manchmal weiter.
 
ffmpeg wird von Hand compiliert, nicht via Homebrew.
 
Wie ist denn deine configure line?
Signiert hast es auch?

Mach doch parallel einen Tab mit top auf und guck ob es ein memory leak gibt.
 
Code:
./configure --disable-doc --enable-gpl --arch=arm64
dazu noch ein Patch um die Option "-q" für videotoolbox zu nutzen (funktioniert übrigens sehr gut auf dem M1). Da wird nichts signiert.

Vorhin mal den aktuellen Snapshot runtergeladen, compiliert und nach /usr/local/bin kopiert. Die neue Version wurde anstandslos genutzt. Hatte es aber wie schon geschrieben mehrmals dass es die Fehlermeldung gab.

Wenn es mal wieder auftritt, werde ich schauen ob es ein memory leak gibt. Habe ein memory leak bei intensiver ffmpeg-Nutzung schon auf Intel-Macs bemerkt, aber nicht mit diesen Konsequenzen.
 
Der Fehler kommt daher, dass das binary nicht signiert ist. Du musst entweder mit einem gültigen developer-Zertifkat signieren, oder das alte binary löschen und dann erst das neu kompilierte installieren. Geht nicht anders.
 
  • Gefällt mir
Reaktionen: Bozol
Ich habe nochmals nachgelesen. Es geht auch ohne kostenpflichtiges developer Cert, mit einem sog. ad-hoc Cert. Xcode würde das automatisch zufügen, bei builds im Terminal via Makefiles muss man es manuell anstoßen. Ein

Code:
codesign -s - ffmpeg

sollte funktionieren.
 
Werde es bei der nächsten Fehlermeldung mal probieren, aber aktuell kann ich nur sagen, dass ich die ffmpeg-Binary auf dem M1 noch nie signiert habe und sie läuft in der Regel ohne Probleme - außer gelegentlich wenn ich neu compiliere. In der Regel wird die alte auch nicht gelöscht sondern einfach überschrieben. Das MBP hat die Standardeinstellungen die es bei Auslieferung hatte.
 
Warum gibst du denn die arch an?
Du machst doch keinen cross compile.
 
Es geht nicht ums Laufen. Das geht auch ohne Signatur. Es geht darum, dass beim überschreiben eines bereist vorhandenen binarys die genannte Fehlermeldung kommt, die daran liegt, dass das neue binary keine ad-hoc signatur hat und Big Sur somit zwar das alte binary kennt und soweit ich weiß sogar selbst signiert hat, aber das neue binary halt nicht, da es einfach drüber kopiert uerde und aus Sicht des OS es eben nicht mehr valide ist, da es keine Signatur hat.
 
  • Gefällt mir
Reaktionen: Bozol
Warum gibst du denn die arch an?
Du machst doch keinen cross compile.
das habe ich vorgegeben, da ich bemerkt habe, dass die Makefiles von ffmpeg auf macOS x86_64 vorgeben, selbst auf Apple Silicon. Warum auch immer.
 
das habe ich vorgegeben, da ich bemerkt habe, dass die Makefiles von ffmpeg auf macOS x86_64 vorgeben, selbst auf Apple Silicon. Warum auch immer.
Das configure sollte das doch eigentlich erkennen.
Hab kein M1, deswegen noch nie selbst probiert.
 
Werde es einfach beobachten und etwas rumprobieren (u.a. rüberkopieren und schauen was passiert).

Sollte jemand interessiert sein, hier ist der Patch (nur für Apple Silicon) von @lisanet (git apply patch) mit dem man eine konstante Qualität via videotoolbox-Codec erzielt (ffmpeg-Option "-q" - Werte zwischen 1-100 - "-q:v 55" ist für FullHD schon ziemlich gut, persönlich nehme ich 60 oder gar 65).
Code:
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 400401550a..e8cbc9dd4d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -224,7 +224,7 @@ typedef struct VTEncContext {
int64_t require_sw;

bool flushing;
- bool has_b_frames;
+ int has_b_frames;
bool warned_color_range;

/* can't be bool type since AVOption will access it as int */
@@ -1014,6 +1014,12 @@ static int get_cv_ycbcr_matrix(AVCodecContext *avctx, CFStringRef *matrix) {
return 0;
}

+// constant quality only on Macs with Apple Silicon
+static bool vtenc_qscale_enabled(void)
+{
+ return TARGET_OS_OSX && TARGET_CPU_ARM64;
+}
+
static int vtenc_create_encoder(AVCodecContext *avctx,
CMVideoCodecType codec_type,
CFStringRef profile_level,
@@ -1025,7 +1031,9 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
VTEncContext *vtctx = avctx->priv_data;
SInt32 bit_rate = avctx->bit_rate;
SInt32 max_rate = avctx->rc_max_rate;
+ Float32 quality = avctx->global_quality / FF_QP2LAMBDA;
CFNumberRef bit_rate_num;
+ CFNumberRef quality_num;
CFNumberRef bytes_per_second;
CFNumberRef one_second;
CFArrayRef data_rate_limits;
@@ -1056,15 +1064,33 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
return AVERROR_EXTERNAL;
}

- bit_rate_num = CFNumberCreate(kCFAllocatorDefault,
- kCFNumberSInt32Type,
- &bit_rate);
- if (!bit_rate_num) return AVERROR(ENOMEM);
+ if (avctx->flags & AV_CODEC_FLAG_QSCALE && !vtenc_qscale_enabled()) {
+ av_log(avctx, AV_LOG_ERROR, "Error: -q:v qscale not available for encoder. Use -b:v bitrate instead.\n");
+ return AVERROR_EXTERNAL;
+ }
+
+ if (avctx->flags & AV_CODEC_FLAG_QSCALE) {
+ quality = quality >= 100 ? 1.0 : quality / 100;
+ quality_num = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberFloat32Type,
+ &quality);
+ if (!quality_num) return AVERROR(ENOMEM);

- status = VTSessionSetProperty(vtctx->session,
- kVTCompressionPropertyKey_AverageBitRate,
- bit_rate_num);
- CFRelease(bit_rate_num);
+ status = VTSessionSetProperty(vtctx->session,
+ kVTCompressionPropertyKey_Quality,
+ quality_num);
+ CFRelease(quality_num);
+ } else {
+ bit_rate_num = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberSInt32Type,
+ &bit_rate);
+ if (!bit_rate_num) return AVERROR(ENOMEM);
+
+ status = VTSessionSetProperty(vtctx->session,
+ kVTCompressionPropertyKey_AverageBitRate,
+ bit_rate_num);
+ CFRelease(bit_rate_num);
+ }

if (status) {
av_log(avctx, AV_LOG_ERROR, "Error setting bitrate property: %d\n", status);
@@ -1333,6 +1359,7 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
}

vtctx->codec_id = avctx->codec_id;
+ avctx->max_b_frames = 16;

if (vtctx->codec_id == AV_CODEC_ID_H264) {
vtctx->get_param_set_func = CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
@@ -1340,7 +1367,7 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
vtctx->has_b_frames = avctx->max_b_frames > 0;
if(vtctx->has_b_frames && vtctx->profile == H264_PROF_BASELINE){
av_log(avctx, AV_LOG_WARNING, "Cannot use B-frames with baseline profile. Output will not contain B-frames.\n");
- vtctx->has_b_frames = false;
+ vtctx->has_b_frames = 0;
}

if (vtctx->entropy == VT_CABAC && vtctx->profile == H264_PROF_BASELINE) {
@@ -1353,6 +1380,8 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
vtctx->get_param_set_func = compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex;
if (!vtctx->get_param_set_func) return AVERROR(EINVAL);
if (!get_vt_hevc_profile_level(avctx, &profile_level)) return AVERROR(EINVAL);
+ // HEVC has b-byramid
+ vtctx->has_b_frames = avctx->max_b_frames > 0 ? 2 : 0;
}

enc_info = CFDictionaryCreateMutable(
@@ -1448,7 +1477,8 @@ static av_cold int vtenc_init(AVCodecContext *avctx)

if (!status && has_b_frames_cfbool) {
//Some devices don't output B-frames for main profile, even if requested.
- vtctx->has_b_frames = CFBooleanGetValue(has_b_frames_cfbool);
+ // HEVC has b-pyramid
+ vtctx->has_b_frames = (CFBooleanGetValue(has_b_frames_cfbool) && avctx->codec_id == AV_CODEC_ID_HEVC) ? 2 : 1;
CFRelease(has_b_frames_cfbool);
}
avctx->has_b_frames = vtctx->has_b_frames;
@@ -2356,7 +2386,7 @@ static av_cold int vtenc_frame(

if (vtctx->frame_ct_in == 0) {
vtctx->first_pts = frame->pts;
- } else if(vtctx->frame_ct_in == 1 && vtctx->has_b_frames) {
+ } else if(vtctx->frame_ct_in == vtctx->has_b_frames) {
vtctx->dts_delta = frame->pts - vtctx->first_pts;
}

Diese Zeile nicht mehr...
Bis zu "Diese Zeile nicht mehr..." alles auswählen und in eine textdatei kopieren.
 
Hast denn mal mit und ohne Patch kompiliert?
Zum Vergleich, ob das nicht vom Patch kommt?
 
Ja. Wie gesagt, heute neu compiliert und die Binary ersetzt - kein Problem. Bis zum Auftreten des Problems wurde das MBP bestimmt 2 Wochen einfach nur zugeklappt. Nach dem Auftreten des Problems, einmal neu gestartet und das Problem war weg. Mal schauen ob es wiederkommt.
 
Codesigning verhindert doch nur das Starten und im Log kommt der entsprechende Fehler.
 
Ok, dann die Langversion, so wie ich das Thema verstanden habe.

Wenn du auf der Kommandozeile ein Makefile-Projekt kompilierst, wird das vorherige binary nicht gelöscht sondern durch das neue kompiliert binary überschrieben. Hier kommt es dann wohl (so habe ich einige postings in Apples Developer Foren verstanden) zu caching Problemen. Es wurde dort empfohlen, das neue Binary erst an einem anderen Ort neu zu generieren oder vorher das alte zu löschen, und dann erst in der Installation, das neue binary an den korrekten Ort zu kopieren.

Also entweder ffmpeg vorher löschen oder das neue neu code signen um dem OS die neue Signatur bekannt zu geben.

Das mit --arch schaue ich heute abend nochmals nach, woher das genau bei mir kam.

Edit: Link zum Apple Developer Forum

https://developer.apple.com/forums/thread/129977
 
  • Gefällt mir
Reaktionen: biro21 und ruerueka
Zurück
Oben Unten