[libyuv] MJPEG codec fuzzer

[DavidKorczynski]

MJPEG codec fuzzer for Libyuv.

Notice this conflicts with the initial integration work over here: #4363 and am not interested in jumping in on other peoples work, so am happy to have this merged following the merge of #4363

[ToSeven]

I think we should fuzz the official API of the libyuv rather than some internal functions.....

[ToSeven]

I guess you are not a maintainer of the libyuv, right? If yes, don't add your email address under the ccs.

[DavidKorczynski]

I guess you are not a maintainer of the libyuv, right? If yes, don't add your email address under the ccs.

The way you phrase it makes it sound like the only possible deduction, but that's not the logic I followed. The reasoning to add my email is that if something goes wrong in the set up then I will receive the notifications and can help. Nonetheless, am naturally happy to remove it if the maintainers prefer to do things themselves.

I did not see you had another PR doing an integration (#4363) and - naturally - I think you should get the initial integration bounty for your work, so am happy to have this merged following the merge of your work.

I think we should fuzz the official API of the libyuv rather than some internal functions.....

Could we have a view from the maintainers here? I am pretty sure going for codecs is desirable.

[inferno-chromium]

@fbarchard @dalecurtis - are you ok with this additional fuzzer for libyuv integration to OSS-Fuzz, can you please take a review pass on fuzzer code.

[ToSeven]

I guess you are not a maintainer of the libyuv, right? If yes, don't add your email address under the ccs.

The way you phrase it makes it sound like the only possible deduction, but that's not the logic I followed. The reasoning to add my email is that if something goes wrong in the set up then I will receive the notifications and can help. Nonetheless, am naturally happy to remove it if the maintainers prefer to do things themselves.

I did not see you had another PR doing an integration (#4363) and - naturally - I think you should get the initial integration bounty for your work, so am happy to have this merged following the merge of your work.

I think we should fuzz the official API of the libyuv rather than some internal functions.....

Could we have a view from the maintainers here? I am pretty sure going for codecs is desirable.

MJPEG codec fuzzer for Libyuv.

Notice this conflicts with the initial integration work over here: #4363 and am not interested in jumping in on other peoples work, so am happy to have this merged following the merge of #4363

Thank you! you are very kind! last week, I was busy with writing the experiment code for my paper. so I have not enough time to modify my code.

[ToSeven]

I guess you are not a maintainer of the libyuv, right? If yes, don't add your email address under the ccs.

The way you phrase it makes it sound like the only possible deduction, but that's not the logic I followed. The reasoning to add my email is that if something goes wrong in the set up then I will receive the notifications and can help. Nonetheless, am naturally happy to remove it if the maintainers prefer to do things themselves.

I did not see you had another PR doing an integration (#4363) and - naturally - I think you should get the initial integration bounty for your work, so am happy to have this merged following the merge of your work.

I think we should fuzz the official API of the libyuv rather than some internal functions.....

Could we have a view from the maintainers here? I am pretty sure going for codecs is desirable.l

MJPEG codec fuzzer for Libyuv.

Notice this conflicts with the initial integration work over here: #4363 and am not interested in jumping in on other peoples work, so am happy to have this merged following the merge of #4363

I guess you are not a maintainer of the libyuv, right? If yes, don't add your email address under the ccs.

The way you phrase it makes it sound like the only possible deduction, but that's not the logic I followed. The reasoning to add my email is that if something goes wrong in the set up then I will receive the notifications and can help. Nonetheless, am naturally happy to remove it if the maintainers prefer to do things themselves.

I did not see you had another PR doing an integration (#4363) and - naturally - I think you should get the initial integration bounty for your work, so am happy to have this merged following the merge of your work.

I think we should fuzz the official API of the libyuv rather than some internal functions.....

Could we have a view from the maintainers here? I am pretty sure going for codecs is desirable.

libyuv is an open-source project that includes YUV scaling and conversion functionality and offers some API to users to call. Because we fuzz an API every time, we fuzz some internal functions. this is just my thought.
@fbarchard please comment here, thank you!

[dalecurtis]

Defer to @fbarchard, I didn't even know libyuv had an mjpeg decoder. Overall lgtm though.

[DavidKorczynski]

For reference, I went for creating something similar to the convert_test.cc unit test (https://chromium.googlesource.com/libyuv/libyuv/+/refs/heads/master/unit_test/convert_test.cc#1955)

It may be that I should apply more logic on the decoded JPEG though, to get more coverage of libyuv. However, it would be trivial to add the remaining logic, e.g.

static int ShowJPegInfo(const uint8_t* sample, size_t sample_size) {

   MJpegDecoder mjpeg_decoder;
   LIBYUV_BOOL ret = mjpeg_decoder.LoadFrame(sample, sample_size);
    
   int width = mjpeg_decoder.GetWidth();
   int height = mjpeg_decoder.GetHeight();
    
   // YUV420
   if (mjpeg_decoder.GetColorSpace() == MJpegDecoder::kColorSpaceYCbCr &&
   mjpeg_decoder.GetNumComponents() == 3 &&
   mjpeg_decoder.GetVertSampFactor(0) == 2 &&
   mjpeg_decoder.GetHorizSampFactor(0) == 2 &&
   mjpeg_decoder.GetVertSampFactor(1) == 1 &&
   mjpeg_decoder.GetHorizSampFactor(1) == 1 &&
   mjpeg_decoder.GetVertSampFactor(2) == 1 &&
   mjpeg_decoder.GetHorizSampFactor(2) == 1) {

I can add that, but I did this one for a starter.

[fbarchard]

The jpeg decoder is there because webcam's on Windows/Linux can return raw jpeg and rely on a static motion jpeg header. Webcam support is a primary use case. Mainly for webrtc - video chat, but also for machine learning these days. Someone that maintains the OSS libyuv should review this. I dont maintain this branch or the fuzz targets.

…

On Tue, Sep 8, 2020 at 11:21 AM Dale Curtis ***@***.***> wrote: Defer to @fbarchard <https://github.com/fbarchard>, I didn't even know libyuv had an mjpeg decoder. Overall lgtm though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRZQDLJ3KROY2NWZOVWPBTSEZYY3ANCNFSM4Q2YZJUA> .

[DavidKorczynski]

The jpeg decoder is there because webcam's on Windows/Linux can return raw jpeg and rely on a static motion jpeg header. Webcam support is a primary use case. Mainly for webrtc - video chat, but also for machine learning these days. Someone that maintains the OSS libyuv should review this. I dont maintain this branch or the fuzz targets.

I see - thanks! Okay, I am not aware if such a person exists, i.e. who maintains the OSS libyuv.

I can see multiple people assisting with Libyuv so I will leave this in the hands of @ToSeven to avoid unnecessary confusion (or @JohnathanNorman who is also working on it now it seems #4424). The fuzzer remains in this PR so you can always use it or reopen this PR once you are ready.