> > > 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-requ...@ffmpeg.org with subject "unsubscribe".
