libjpeg-turbo
rav1e
libjpeg-turbo | rav1e | |
---|---|---|
15 | 70 | |
3,594 | 3,579 | |
1.1% | 0.7% | |
8.2 | 9.1 | |
23 days ago | 11 days ago | |
C | Assembly | |
GNU General Public License v3.0 or later | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libjpeg-turbo
-
Jpegli: A New JPEG Coding Library
> all decoders will render the same pixels
Not true. Even just within libjpeg, there are three different IDCT implementations (jidctflt.c, jidctfst.c, jidctint.c) and they produce different pixels (it's a classic speed vs quality trade-off). It's spec-compliant to choose any of those.
A few years ago, in libjpeg-turbo, they changed the smoothing kernel used for decoding (incomplete) progressive JPEGs, from a 3x3 window to 5x5. This meant the decoder produced different pixels, but again, that's still valid:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/6d91e9...
-
My personal C coding style as of late 2023
Last vestiges of this fact AFAIK were libjpeg, which had a macro NEED_SHORT_EXTERNAL_NAMES that shortens all public identifiers to have unique 6-letter-long prefixes. Libjpeg-turbo nowadays has removed them though [1].
[1] https://github.com/libjpeg-turbo/libjpeg-turbo/commit/52ded8...
- Libjpeg-Turbo 3.0.0
-
Why there may never be a libjpeg-turbo 3.1
While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do.
There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.
-
Learn x86-64 assembly by writing a GUI from scratch
Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86
Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.
Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...
-
Announcing zune-jpeg: Rust's fastest JPEG decoder
zune-jpeg is 1.5x to 2x faster than jpeg-decoder and is on par with libjpeg-turbo.
-
JDK 21 - Image Performance Improvements
This is interesting from the standpoint of how new JVM features can be used to improve performance (what I presume the article's main purpose to have been), but the image processing improvement itself isn't head-turning. Also, we've found that libjpeg-turbo (https://libjpeg-turbo.org/) is ~5x (IIRC, can re-run my JMH benchmark if anyone wants me to) as fast for decoding JPEGs as ImageIO, so we wouldn't even benefit from this change in 21 much.
-
Convenient CPU feature detection and dispatch in the Magnum Engine
libjpeg-turbo: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/simd/x86_64/jsimdcpu.asm
-
Implementing SVE2 for Open Source Project
libjpeg-turbo
-
How to go about implementing file encoding [Question]
For all but the simplest formats (basically BMP), the difficulty of implementing encoding/decoding from scratch is significant - well beyond a beginner's ability, and challenging/time-consuming even for senior developers. So, libraries are used in practice - e.g. libpng and libjpeg-turbo.
rav1e
-
Learn x86-64 assembly by writing a GUI from scratch
Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86
Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.
Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...
-
SISVEL VP9/AV1 patent declared invalid in China
Again, if anything AOM would be the one restricting licenses to AV1 (if they chose to) except AOM has stated and also published AV1 in a way to allow license free access to development (which allows people to make forks of the official build like it's open source) and usage. (1)(2) I don't see why they would suddenly change this.
- Any new Opensource projects in (rust) looking for contributors. I want to start my journey as an OSS contributor.
- assembly from dav1d 1.1.0 now integrated into rav1e
-
A little script to parse large libraries to AV1, if you're interested
You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.
-
rav1d: a Rust port of dav1d (currently experimental)
That remember me of https://github.com/xiph/rav1e which is an AV1 encoder
- A Safer High Performance AV1 Decoder
-
rav1e wrong mastering-display output?
I put in the request for ffmpeg passthrough mastering-display data a few years ago and haven't heard of any support yet.
-
HDR10, HDR10+, Dolby Vision with AV1?
It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000
-
Release Notes: Safari 16.4 Beta adds AV1 codec + hardware decode for WebRTC
It's entirely possible to re-use bits of other HW encoders for the first pass (motion estimation, etc).
What are some alternatives?
ImageMagick - 🧙♂️ ImageMagick 7
SVT-AV1
libwebp - Mirror only. Please do not send pull requests. See https://chromium.googlesource.com/webm/libwebp/+/HEAD/CONTRIBUTING.md.
dav1d - A read-only mirror of dav1d source code repository. The origin is at https://code.videolan.org/videolan/dav1d/
orion - Usable, easy and safe pure-Rust crypto
SVT-AV1 - Welcome to the GitHub repo for the SVT-AV1! This repo is set to read-only for archiving purposes. Please join us at https://gitlab.com/AOMediaCodec/SVT-AV1. We look forward to seeing you there
bloom - The simplest way to de-Google your life and business: Inbox, Calendar, Files, Contacts & much more
ffmpeg-build-script - The FFmpeg build script provides an easy way to build a static FFmpeg on OSX and Linux with non-free codecs included.
virtualgl - Main VirtualGL repository
obs-amd-encoder - AMD Advanced Media Framework Encoder Plugin for Open Broadcaster Studio
Rustup - The Rust toolchain installer
libavif - libavif - Library for encoding and decoding .avif files