[FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

Michael Niedermayer michael at niedermayer.cc
Thu Sep 6 12:47:38 EEST 2018


On Thu, Sep 06, 2018 at 11:50:12AM +0530, Gagandeep Singh wrote:
> On Thu, Sep 6, 2018 at 11:34 AM Gagandeep Singh <deepgagan231197 at gmail.com>
> wrote:
> 
> >
> >
> > On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer <michael at niedermayer.cc>
> > wrote:
> >
> >> On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
> >> [...]
> >> >
> >> > > [...]
> >> > > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx,
> >> void
> >> > > *data, int *got_frame,
> >> > > >              }
> >> > > >          }
> >> > > >      }
> >> > > > -
> >> > > > -    if (!s->a_width || !s->a_height || s->a_format ==
> >> AV_PIX_FMT_NONE ||
> >> > > > -        s->coded_width || s->coded_height || s->coded_format !=
> >> > > AV_PIX_FMT_NONE) {
> >> > >
> >> > > > +    //disabled to run mountain sample file
> >> > > > +#if 0
> >> > > > +    if ((!s->a_width || !s->a_height || s->a_format ==
> >> AV_PIX_FMT_NONE
> >> > > ||
> >> > > > +        s->coded_width || s->coded_height || s->coded_format !=
> >> > > AV_PIX_FMT_NONE) && s->sample_type != 1) {
> >> > > >          av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
> >> > > >          ret = AVERROR(EINVAL);
> >> > > >          goto end;
> >> > > >      }
> >> > > > -
> >> > > > +#endif
> >> > >
> >> > > please elaborate why this needs to be disabled
> >> > > i presume this code was needed for something
> >> > >
> >> > I didn't need to disable this for any sample except one, where the image
> >> > height and width data wasn't transfered in accordance to how it was in
> >> the
> >> > rest of the sample so the flow of code was just causing the decoder to
> >> > crash. I can produce a more robust fix, though again will need to repost
> >> > other patches as well, please comment.
> >> >
> >> > > also this decoder with the patches should be tested with a fuzzer to
> >> > > reduce
> >> > > the chance of bugs
> >> > >
> >> > > I don't know how to use 'fuzzer', sorry, though i can look into that.
> >>
> >> had missed this reply as its not quoted correctly
> >> yes, please look into testing this with a fuzzer, we should make
> >> reasonable
> >> sure we dont add anomalies
> >>
> >> thx
> >>
> >> [...]
> >> --
> >> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >>
> >> Dictatorship naturally arises out of democracy, and the most aggravated
> >> form of tyranny and slavery out of the most extreme liberty. -- Plato
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel at ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> > Hi,
> > patch updated to add back the check.
> >
> 
> The work around for the check is just to not to check for the coded_width
> == 0 and coded_height == 0 as these are used to set a_width and a_height
> during buffer allocation (which are also being checked for non zero values.
> coded_width and coded_height  were later set to 0 for a loop exit (which
> has been taken care of in other way), and  since i needed to update
> coded_width and coded_height with some other data in case they were not
> available in the sample(we have a sample for the same), thus it
> necessitates that the unneeded check be removed.

tested with zzuf
it crashes:
make -j12 && zzuf -M -1 -r 0.00001 -s 0:1000 ./ffmpeg -i fate-suite/cfhd/cfhd_odd.mov -f null -

zzuf[s=297,r=1e-05]: signal 11 (SIGSEGV)



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20180906/b9782886/attachment.sig>


More information about the ffmpeg-devel mailing list