From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/3] tools: Add target_sws_fuzzer.c
Date: Wed, 21 Feb 2024 02:17:30 +0100
Message-ID: <20240221011730.GX6420@pb2> (raw)
In-Reply-To: <c85475ad-71bd-4213-be70-3fd8c7e23e30@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2715 bytes --]
On Tue, Feb 20, 2024 at 12:41:57AM -0300, James Almer wrote:
> On 2/19/2024 11:49 PM, Michael Niedermayer wrote:
> > +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
> > + int srcW= 48, srcH = 48;
> > + int dstW= 48, dstH = 48;
> > + int srcHShift, srcVShift;
> > + int dstHShift, dstVShift;
> > + unsigned flags = 1;
> > + int srcStride[AV_VIDEO_MAX_PLANES] = {0};
> > + int dstStride[AV_VIDEO_MAX_PLANES] = {0};
> > + int ret;
> > + const uint8_t *end = data + size;
> > + enum AVPixelFormat srcFormat = AV_PIX_FMT_YUV420P;
> > + enum AVPixelFormat dstFormat = AV_PIX_FMT_YUV420P;
> > + uint8_t *src[AV_VIDEO_MAX_PLANES] = { 0 };
> > + uint8_t *dst[AV_VIDEO_MAX_PLANES] = { 0 };
> > + struct SwsContext *sws = NULL;
> > + const AVPixFmtDescriptor *desc_src, *desc_dst;
> > +
> > + if (size > 128) {
> > + GetByteContext gbc;
> > + int64_t flags64;
> > +
> > + size -= 128;
> > + bytestream2_init(&gbc, data + size, 128);
> > + srcW = bytestream2_get_le32(&gbc) % 16384;
> > + srcH = bytestream2_get_le32(&gbc) % 16384;
> > + dstW = bytestream2_get_le32(&gbc) % 16384;
> > + dstH = bytestream2_get_le32(&gbc) % 16384;
>
> Might as well use bytestream2_get_le16 to save bytes from the input buffer.
>
> > +
> > + if (srcW * (uint64_t)srcH > 16384 || dstW * (uint64_t)dstH > 16384)
> > + return 0; // we avoid high res as its very slow
>
> This will abort in a lot of cases. Would reading only xW then setting xH to
> 16384 / xW make sense? You can remove these checks if so.
no that would reduce the number of tested resolutions to one for each width
What we are trying to do here, is to map some flat random data into
a resolution constraint to
X > 0
Y > 0
X*Y <= 16484
and at the same time have each pair occur approximately as frequent as any other
that can be achieved in a few ways, ill use the following
static void mapres(unsigned *r0, unsigned *r1) {
double d = (double)(*r0*10ll - 9ll*UINT32_MAX) / UINT32_MAX;
double a = exp(d) * 16384 / exp(1) ;
int ai = (int)round(a);
uint64_t maxb = 16384 / ai;
*r0 = ai;
*r1 = 1 + (*r1 * maxb) / UINT32_MAX;
}
this avoids all the aborts and is flat enough statically for this purpose
will apply with that, but if you prefer the previous simpler code, dont hesitate
to replace it. Iam not sure this helps the fuzzer at all
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-21 1:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 2:49 Michael Niedermayer
2024-02-20 2:49 ` [FFmpeg-devel] [PATCH 2/3] Revert "swscale: fix sws_setColorspaceDetails after sws_init_context" Michael Niedermayer
2024-02-21 17:30 ` Michael Niedermayer
2024-02-20 2:49 ` [FFmpeg-devel] [PATCH 3/3] libswscale/utils: Fix bayer to yuvj Michael Niedermayer
2024-02-21 17:30 ` Michael Niedermayer
2024-02-20 3:41 ` [FFmpeg-devel] [PATCH 1/3] tools: Add target_sws_fuzzer.c James Almer
2024-02-21 1:17 ` Michael Niedermayer [this message]
2024-02-21 2:33 ` James Almer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240221011730.GX6420@pb2 \
--to=michael@niedermayer.cc \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git