Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecenc: Probe supported pixel formats

From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecenc: Probe supported pixel formats
Date: Mon, 09 Jan 2023 13:27:55 +0100
Message-ID: <f642215a76a0cc4a65bab157a7adc45d31565ad3.camel@haerdin.se> (raw)
In-Reply-To: <tencent_4FD0B5A6CAA7C72AA11318DC5F4B8FE62706@qq.com>

> > > 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".