[FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[wm4]

On Fri, 27 Apr 2018 22:27:47 -0300
James Almer <jamrial at gmail.com> wrote:

> On 4/27/2018 4:37 PM, wm4 wrote:
> > From: wm4 <nfxjfg at googlemail.com>
> > 


> > require_pkg_config libvapoursynth "vapoursynth-script >= 42" VSScript.h vsscript_init || die "ERROR: vapoursynth or vsscript not found";  
> 
> die() is needed only with test_pkg_config and check_pkg_config, not
> require_pkg_config.

OK, will remove.

> And seeing that vapoursynth-script.pc depends on vapoursynth.pc, you can
> simplify all this by only checking for vapoursynth-script.

I'm not sure if I should rely on this. But considering VSScript.h
includes VapourSynth.h anyway, and we don't use any VapourSynth
functions directly, the risk is low, so I'll remove it.

> > +    st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> > +    st->codecpar->codec_id = AV_CODEC_ID_WRAPPED_AVFRAME;  
> 
> What exactly is the use case for this?

You mean using wrapped avframe? It means you don't have to mess with
raw encoding/decoding.

Unless we have some fancy way to make rawdec.c accept frames packed by
av_image_copy_to_buffer() without having to map pixfmts to raw codecs?
(rawdec.c is a lot of code, I might have missed a simple way to make it
accept that.)

> > +    pkt->buf = av_buffer_create((uint8_t*)frame, sizeof(*frame),  
> 
> So, the whole wrapped avframe is pretty much fucked up since conception.
> Did nobody notice that lavc/wrapped_avframe.c is using sizeof(AVFrame)?
> 
> Much like in here, it's wrong and Bad Things(tm) will happen as soon as
> we add a new field.

Ah, that is true. In theory it's in conflict with out policy that
libavutil can append fields to AVFrame, without rebuilding libavcodec.
I've copied this AVFrame packing code from kmsgrab.c though (which is
also new code, and which I've noticed leaks memory when handling malloc
failure).

I think it'd be best if we had updated "non-dumb" side data which can
manage AVFrames in a correct way. But it'll be a long way until this
happens, apparently. If you really want to solve this, we could
introduce an av_frame_get_struct_size() call, which would be dumb, but
correct. (Or maybe make it avpriv_?)