[FFmpeg-devel] [RFC] How to fix DR+lavfi+vflip crash

Michael Niedermayer michaelni
Sat Dec 11 14:49:54 CET 2010


On Sat, Dec 11, 2010 at 02:12:10PM +0100, Stefano Sabatini wrote:
> On date Thursday 2010-12-09 04:35:58 +0100, Michael Niedermayer encoded:
> > On Mon, Dec 06, 2010 at 03:30:28PM +0100, Stefano Sabatini wrote:
> > > On date Sunday 2010-12-05 12:12:58 +0100, Stefano Sabatini encoded:
> > > > On date Friday 2010-12-03 00:03:15 +0100, Michael Niedermayer encoded:
> > > > > On Sat, Nov 27, 2010 at 04:53:51PM +0100, Stefano Sabatini wrote:
> > > > [...]
> > > > > isnt it easier to handle (lack) of neg linesize support by using the premission
> > > > > system?
> > > > > like "i need a readable buffer" vs. "i need a buffer with positive linesize"
> > > > 
> > > > New attempt. Note the addition of a flag in start_frame(), I added a
> > > > flag since it seemed more flexible.
> > > 
> > > Simpler.
> > [...]
> > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > > index 5d34bee..194a614 100644
> > > --- a/libavfilter/avfilter.h
> > > +++ b/libavfilter/avfilter.h
> > > @@ -86,6 +86,7 @@ typedef struct AVFilterBuffer {
> > >  #define AV_PERM_PRESERVE 0x04   ///< nobody else can overwrite the buffer
> > >  #define AV_PERM_REUSE    0x08   ///< can output the buffer multiple times, with the same contents each time
> > >  #define AV_PERM_REUSE2   0x10   ///< can output the buffer multiple times, modified each time
> > > +#define AV_PERM_POS_LINESIZES  0x20  ///< the buffer requested cannot have negative linesizes
> > 
> > i think POS is a bad term because it hints to position primarely before positive
> > or anything else
> 
> I propose AV_PERM_POSITIVE_LINESIZES or AV_PERM_NONNEG_LINESIZES (the
> latter is consistent with CODEC_CAP_NEG_LINESIZES), or we could invert

> the logic and request AV_PERM_NEG_LINESIZES.

probably safest


> 
> > >  /**
> > >   * Audio specific properties in a reference to an AVFilterBuffer. Since
> > > diff --git a/libavfilter/vf_vflip.c b/libavfilter/vf_vflip.c
> > > index 95d90d3..84c92bd 100644
> > > --- a/libavfilter/vf_vflip.c
> > > +++ b/libavfilter/vf_vflip.c
> > 
> > a solution in vflip is not ideal as this would require each filter that
> > could produce negative linesizes to duplicate that solution.
> 
> yes we currently have one filter with that feature and is called
> vflip, I don't think we're going to have so many filters of that kind.

vfw & dshow sources and sinks possibly will need it as windows stored (at least
in the past) rgb bitmaps upside down
raw rgb avi also has its negative linesize cases, and there are possibly
other cases i dont remember now (binary codecs likely are amongth them too)

so i dont think vflip is the only relevant case


> 
> > a fix should be in the filter core, there already is code to copy a frame
> > when permissions are not compatible and using that should be simpler than your
> > patch
> 
> I thought about this and after some attempts I don't think it is worth
> to follow this path, as it is complicating the core for a marginal
> feature.
> 
> If you can show a detailed solution which is simpler than this then I
> can try to implement it, otherwise I'll stick with this one.

in avfilter_start_frame()
the linesize case can be added here:
 /* prepare to copy the picture if it has insufficient permissions */
    if ((dst->min_perms & picref->perms) != dst->min_perms ||
         dst->rej_perms & picref->perms) {

in vflips
get_video_buffer()
check if negative linesizes are permitted and if not return a buffer from
default allocation or just skip the buffer flip

if this fails you likely have unrelated bugs elsewhere

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101211/664dae52/attachment.pgp>



More information about the ffmpeg-devel mailing list