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

Gagandeep Singh deepgagan231197 at gmail.com
Thu Sep 6 09:20:12 EEST 2018


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.

Thanks
Gagandeep Singh


More information about the ffmpeg-devel mailing list