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 <jamr...@gmail.com> wrote: > >>> > >>>> On 5/4/2018 12:58 PM, wm4 wrote: > >>>>> On Sat, 28 Apr 2018 19:05:29 +0200 > >>>>> wm4 <nfx...@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@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
