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

Tomas Härdin git at haerdin.se
Mon Jan 9 14:27:55 EET 2023


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



More information about the ffmpeg-devel mailing list