[FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[wm4]

On Fri, 13 Oct 2017 20:03:12 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> I dont really know and as a maintainer of some of this code, i dont
> really want to have to keep track of how exactly AVFrames can pass
> through the code.

You have to do that anyway.

> And as the one taking care of a lot of security i totally have to
> reject this. It turns a robust system into something thats really
> fragile. This is only secure if every way a AVFrame can pass through
> the code has each interface point carefully convert the opaque_ref type.
> Thats a large source of bugs and exploits.

The security argument is bullshit. It's very clearly defined how the
field behaves. If you pass it to libavcodec you have to wrap it, if you
return it you have to unwrap it.

> Just look at how hard it is to get this patch work initially.

The only hard thing was "discussing" this with you. I even gave up my
resistance to release ffmpeg 3.4 without it, and took care of your
considerations (see updated patches I've sent before).

Normally you're quick to apply whatever fragile and complicated BS
there is, only here you're making an exception. Why the special
treatment.

> How many future commits will change the way AVFrames move and incorrectly
> update all the wraping. developers are not machines this suprising
> requirement of (un)wraping on interfaces will not be done correctly
> in a few years from now even if you get it all correct now.

Again, this is not complicated. Even if it is, it's less complicated
than all the tricky things you insist on and defend.

> Now add libavformat, libavdevice, libavfilter specific opaque_ref
> wraping
> 
> you really consider this to be good design by any definition of "good"?

It's probably better than whatever you could come up with. But you
didn't even make a suggestion.