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

[Michael Niedermayer]

On Fri, May 04, 2018 at 09:51:38PM -0300, James Almer wrote:
> On 5/4/2018 9:19 PM, Michael Niedermayer wrote:
> > On Fri, May 04, 2018 at 02:02:02PM -0300, James Almer wrote:
> >> On 5/4/2018 1:51 PM, wm4 wrote:
> >>> On Fri, 4 May 2018 13:30:38 -0300
> >>> James Almer <jamrial at gmail.com> wrote:
> >>>
> >>>> On 5/4/2018 12:58 PM, wm4 wrote:
> >>>>> On Sat, 28 Apr 2018 19:05:29 +0200
> >>>>> wm4 <nfxjfg at googlemail.com> wrote:
> >>>>>   
> >>>>>> This can "demux" .vpy files.
> >>>>>>
> >>>>>> Some minor code copied from other LGPL parts of FFmpeg.
> >>>>>>
> >>>>>> I did not found a good way to test a few of the more obscure features,
> >>>>>> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
> >>>>>> changes. These can be easily implemented on demand.
> >>>>>> ---
> >>>>>>  configure                 |   5 +
> >>>>>>  libavformat/Makefile      |   1 +
> >>>>>>  libavformat/allformats.c  |   1 +
> >>>>>>  libavformat/vapoursynth.c | 421 ++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>  4 files changed, 428 insertions(+)
> >>>>>>  create mode 100644 libavformat/vapoursynth.c
> >>>>>>  
> >>>>>
> >>>>> Pushed, with some minor changes, and zero-copy frame passing.  
> >>>>
> >>>> The first step to fix something (in this case, usage sizeof(AVFrame)
> >>>> outside libavutil) is not adding even more cases of the issue in question.
> >>>> You still can replace this with rawvideo. Someone even already wrote it
> >>>> for you.
> >>>>
> >>>> Lets try to abide our own ABI rules...
> >>>
> >>> That's requires a frame copy and is not what I went through all the
> >>> effort for.
> >>>
> >>> Why didn't you say anything when the kmsgrab code did the same thing?
> >>> Or when the unwrapped frame stuff was added in the first place?
> >>
> >> I did the other day on IRC when you asked me why i was against this, if
> >> you recall, because it was then when i found out this has been the case
> >> for a long while, and why I'm now saying adding even more cases is going
> >> in the opposite direction of an actual solution.
> >>
> >> In any case, i explicitly didn't block this, and no one else seems to
> >> care, so whatever.
> > 
> > I just now realized this, no, use of sizeof(AVFrame) outside libavutil is not ok,
> > thats a ABI/API breakage.
> > 
> > This must be removed/reverted. In all cases that are relevant.
> 
> Fixed/adapted, not reverted. For vapoursynth and kmsgrab it should be a
> matter of making them output rawvideo packets.

I think we meant the same thing

the use of sizeof(AVFrame) outside libavutil must be removed/reverted.
That can be of course through adapting/fixing the code in some form.



> 
> > (there can be exceptions if they are irrelevant to API/ABI compatibility)
> > 
> > For example the "if (pkt->size < sizeof(AVFrame))" in libavcodec/wrapped_avframe.c
> > should be ok
> 
> How is that one ok? Is it because sizeof(AVFrame) can grow but never
> shrink without a soname bump so the check is safe?

yes


> 
> Still, that's only the wrapped_avframe decoder. What about the encoder?

that one doesnt look so good unless iam missing something


> It's used by the null and yuv4mpeg muxers, plus decklink and
> libndi_newtek outdevs.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180505/62b13573/attachment.sig>