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

["Zhao Zhili" <quinkblack@foxmail.com>]

> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Tomas Härdin
> Sent: 2023年1月7日 2:22
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecenc: Probe supported pixel formats
> 
> lör 2023-01-07 klockan 02:03 +0800 skrev Zhao Zhili:
> > On Fri, 2023-01-06 at 16:42 +0100, Tomas Härdin wrote:
> >
> > > +            if (!(format = ff_AMediaFormat_new(use_ndk_codec))) {
> > > +                av_log(NULL, AV_LOG_ERROR, "Failed to create media
> > > format\n");
> > > +                ff_AMediaCodec_delete(codec);
> > > +                continue;
> >
> > Here is a use-after-free (codec) issue.
> 
> Oops. I had the call to ff_AMediaCodec_createEncoderByType() inside the
> loop earlier. Will fix.
> 
> 
> > init_static_data should be determinate, no matter when it was called,
> > it should
> > give the same result.
> 
> You mean across devices? That obviously won't work. On the same device?
> I would assume it always returns the same results, modulo what you
> wrote below.

I mean on the same device.

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

The JNI probe can tell which pixel format is supported after encoder configure
failed at runtime. That's a safe and valid usecase. And it can be implemented
out side of FFmpeg, so it can be called earlier and multiple times, without the
limitation of init_static_data() being called only once.

> 
> > 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().

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

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