On Thu, Sep 06, 2018 at 11:50:12AM +0530, Gagandeep Singh wrote:
> On Thu, Sep 6, 2018 at 11:34 AM Gagandeep Singh <deepgagan231...@gmail.com>
> wrote:
>
> >
> >
> > On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer <mich...@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@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
