Use the limit range YUV to RGB conversion formula

[Charlie-Zheng]

• Changes the YUV to RGB to use the limit range YUV formula.
• Added a test to convert a white H264 to RGB

Closes #42

[Charlie-Zheng]

One of the tests (decodes_file_requiring_flush_frame) fails now, due to the more saturated colors produced. I extracted PNGs from the multi_1024x768.h264 file using the following command:

ffmpeg -i multi_1024x768.h264 out%d.png

And the resulting image does not match the "ground truth" multi_1024x768.bmp.

The output from ffmpeg extracting video frames:

I also tried extracting BMP instead of PNG and it still looks like this.

[Charlie-Zheng]

I can update the multi_1024x768.bmp file with the extracted image using ffmpeg if desired.

[ralfbiedert]

Thanks for the PR!

Could you make the BMP a LFS file and re-do the commit so it doesn't end up in Git history?

I can update the multi_1024x768.bmp file with the extracted image using ffmpeg if desired.

I haven't looked at exactly why this fails but yes, fixing the unit tests would be good.

[Charlie-Zheng]

Is there any specific reason why there isn't a SIMD write_rgba8?
I've added SIMD version of write_rgba8 (copying and modifying the SIMD version of write_rgb8) but I don't know if this is an appropriate PR to add it.

[ralfbiedert]

The write alpha is fine, but it looks like you still have the old bmp as non-lfs in a previous commit. It might be better to create a new branch and clean commit everything again with lfs right from the start

[Charlie-Zheng]

I've correctly added multi_1024x768.bmp to git-lfs now. When I ran cargo clippy --fix, it fixed a few things (build.rs, error.rs, encoder.rs, etc) that were not touched as part of my PR. Please let me know if I should remove those changes.

[jnnks]

Is there any specific reason why there isn't a SIMD write_rgba8?

Noone has done it yet :)

[ralfbiedert]

@Charlie-Zheng thanks for the PR and the follow ups!