On Fri, Jun 26, 2020 at 12:22:22AM +0530, Gautam Ramakrishnan wrote: > On Tue, Jun 23, 2020 at 8:04 AM Gautam Ramakrishnan > <gautamr...@gmail.com> wrote: > > > > On Tue, Jun 23, 2020 at 2:55 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > > > > > Am Mo., 22. Juni 2020 um 04:57 Uhr schrieb Gautam Ramakrishnan > > > <gautamr...@gmail.com>: > > > > > > > > On Mon, Jun 22, 2020 at 1:54 AM Carl Eugen Hoyos <ceffm...@gmail.com> > > > > wrote: > > > > > > > > > > Am So., 21. Juni 2020 um 21:11 Uhr schrieb <gautamr...@gmail.com>: > > > > > > > > > > > > From: Gautam Ramakrishnan <gautamr...@gmail.com> > > > > > > > > > > > > The log2_chroma_wh is derived from the sample separations of the > > > > > > codestream if the file is a j2k codestream. Not sure if sample > > > > > > separation is same is subsampling and whether using sample > > > > > > separation values from the codestream to determine pixel format. > > > > > > > > > > What would get fixed by this change? > > > > > > > > > The p1_01.j2k image was not getting recognized by the native > > > > decoder due to this condition. > > > > > > In any case, this was missing from the commit message. > > > > > > > It would now get recognized. If this patch is fine, > > > > > > I wanted to suggest to add the following two lines after > > > the calls to pix_fmt_guess(): > > > if (s->avctx->pix_fmt == AV_PIX_FMT_NONE && ncomponents == 1) > > > s->avctx->pix_fmt = AV_PIX_FMT_GRAY8; > > > > > I had tried this for testing initially. I placed this inside the > > if (i == possible_fmts_nb) check. It seemed to work correctly. > > I could possibly resend with this also, but I did not know this would > > be a good solution. > > > But p1_01.j2k does not get decoded with the change either here. > > > > > > > I would preferably remove this check at all places. > > > > > > I thought the check is needed but if fuzzing does not produce > > > invalid memory access for you, it may be ok. > > > > > I'll run the fuzzer again carefully. > I ran the fuzzer (zzuf) where I ran ffmpeg with input files p1_01.j2k > and p1_07.j2k. > I tried with seeds from 0 to 10000. > I tried error rates of 0.01, 0.1 and 0.5. There was no segfault. I > used the -c option as > I only wanted it to fuzz the .j2k files. I hope my configuration while > using zzuf was correct.
from my command line history, i tested zzuf -C9 -s 0:100 ./ffmpeg -v -99 -i p1_07.j2k zzuf[s=8,r=0.004]: signal 11 (SIGSEGV) zzuf[s=12,r=0.004]: signal 11 (SIGSEGV) zzuf[s=52,r=0.004]: signal 11 (SIGSEGV) zzuf[s=81,r=0.004]: signal 11 (SIGSEGV) zzuf[s=93,r=0.004]: signal 11 (SIGSEGV) zzuf[s=97,r=0.004]: signal 11 (SIGSEGV) i didnt investigate these at all yet so they may be unrelated to the j2k decoder, but there where segfaults ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
