From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E662D44F2C for ; Mon, 9 Jan 2023 12:28:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CCC8F68BCC0; Mon, 9 Jan 2023 14:28:03 +0200 (EET) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8234368BC1B for ; Mon, 9 Jan 2023 14:27:57 +0200 (EET) Received: from laptop.lan (h-79-136-39-105.A258.priv.bahnhof.se [79.136.39.105]) by mail.frobbit.se (Postfix) with ESMTPSA id 52C3421B0C for ; Mon, 9 Jan 2023 13:27:56 +0100 (CET) Message-ID: From: Tomas =?ISO-8859-1?Q?H=E4rdin?= To: FFmpeg development discussions and patches Date: Mon, 09 Jan 2023 13:27:55 +0100 In-Reply-To: References: <1a215429e2ac714005e4bc2ccb08c0c3d0bf9356.camel@haerdin.se> <19df94a9b138b93727530f3cb64f8e13bde60b09.camel@haerdin.se> User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecenc: Probe supported pixel formats X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > > > In addition to the 'different MediaCodec backends support > > > different pixel format' issue, another concern of this method is > > > that > > > it's not > > > determinate, it can give different results at different > > > time/condition. > > > > > > MediaCodec can fail for all kinds of reasons, and it can fail > > > dynamically. For > > > example, the supported instance is limited > > > (getMaxSupportedInstances()). Some > > > low end/legacy chip only support one instance. So it can fail > > > when > > > another app > > > or another SDK in the same app has already created a codec > > > instance. > > > > Won't the encoder fail anyway in that case? Also will the JNI probe > > still fail in that case? > > Create encoder can fail, and recover after a while. If JNI probe > depends on > a codec instance, it has the same issue. Use the codeclist API should > be fine, > but then we don't know which omx codec is the default one. I did see the codeclist API but using a codec instance seemed simpler than replicating much of ff_AMediaCodecList_getCodecNameByType(). Is omx used only for software decoders or does it also handle hardware ones? I feel it bears pointing out again that for users in the US having the software codecs is also sometimes desirable. > > > It can > > > fail when out of other resouce (like GPU memory) temporarily. > > > Since > > > init_static_data() only being called once, there is no way to > > > recover > > > from a > > > temporary failure. > > > > Well, the code can try to probe the color formats more than once > > inside > > the function. But that feels very wrong. > > That's the problem, init_static_data() can't do retry by design. > Probe multiple > times inside init_static_data() doesn't work, unless there is a sleep > after each > loop, and we can't put sleep inside init_static_data(). Indeed that would be very wrong. Is there some sort of mutex we can instruct users to lock before running ffmpeg? /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".