| Message ID | 20220426210834.314078-1-leo.izen@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] doc/encoders: document libjxl encoder options | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
| andriy/make_armv7_RPi4 | success | Make finished |
| andriy/make_fate_armv7_RPi4 | success | Make fate finished |
On 2022-04-27 02:38 am, Leo Izen wrote: > Add more detailed documenation for the libjxl encoder > wrapper than is present currently inside libavcodec. > --- > doc/encoders.texi | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/doc/encoders.texi b/doc/encoders.texi > index aac9f25e55..99399d4674 100644 > --- a/doc/encoders.texi > +++ b/doc/encoders.texi > @@ -1809,6 +1809,40 @@ by ":". See the SVT-AV1 encoder user guide for a list of accepted parameters. > > @end table > > +@section libjxl > + > +libjxl JPEG XL encoder wrapper. > + > +Requires the presence of the libjxl headers and library during > +configuration. You need to explicitly configure the build with > +@code{--enable-libjxl}. > + > +@subsection Options > + > +The libjxl wrapper supports the following options: > + > +@table @option > + > +@item distance > +Set the target Butteraugli distance. This is a quality setting: lower > +distance yields higher quality, with distance=1.0 roughly comparable to > +libjpeg Quality 90 for photographic content. Setting distance=0.0 yields > +true lossless encoding. Valid values range between 0.0 and 15.0, and sane > +values rarely exceed 5.0. Setting distance=0.1 is usually attains > +transparency for most input. The default is 1.0. > + > +@item effort > +Set the encoding effort used. Higher effort values produce more consistent > +quality and usually produces a better quality/bpp curve, at the cost of > +more CPU time required. Valid values range from 1 to 9, and the default is 7. > + > +@item modular > +Force the encoder to use Modular mode. The default is to let the encoder pick > +between VarDCT and Modular encoding modes based on encoding settings and the > +type of input content. What happens in these two modes? Why would the user want to force modular? Is there a way and reason to force VarDCT? Regards, Gyan
On 4/27/22 04:39, Gyan Doshi wrote: > > > On 2022-04-27 02:38 am, Leo Izen wrote: >> >> + >> +@item modular >> +Force the encoder to use Modular mode. The default is to let the >> encoder pick >> +between VarDCT and Modular encoding modes based on encoding settings >> and the >> +type of input content. > > What happens in these two modes? Why would the user want to force > modular? Is there a way and reason to force VarDCT? > > VarDCT uses a fourier-DCT-based transform in essence. Modular uses a variety of transforms that can be combined like Lego bricks into patches, including a modified Haar transform. In general, VarDCT will be superior to Modular for lossy encoding, but VarDCT doesn't support lossless, so Modular is required for lossless encoding. Currently, the library always chooses VarDCT for lossy and Modular for lossless, although this could potentially be subject to change. A user will have very little reason to force modular unless they're testing the two modes against each other. The library API does not provide a way to force VarDCT. Or rather, it does, but if you force VarDCT and tell it to encode losslessly it will silently use modular rather than fail. You generally won't have a reason to force VarDCT anyway, since it's chosen by default if you pick lossy, so this isn't an issue. Leo Izen (thebombzen)
On 2022-04-27 05:58 pm, Leo Izen wrote: > On 4/27/22 04:39, Gyan Doshi wrote: >> >> >> On 2022-04-27 02:38 am, Leo Izen wrote: >>> >>> + >>> +@item modular >>> +Force the encoder to use Modular mode. The default is to let the >>> encoder pick >>> +between VarDCT and Modular encoding modes based on encoding >>> settings and the >>> +type of input content. >> >> What happens in these two modes? Why would the user want to force >> modular? Is there a way and reason to force VarDCT? >> >> > VarDCT uses a fourier-DCT-based transform in essence. Modular uses a > variety of transforms that can be combined like Lego bricks into > patches, including a modified Haar transform. > > In general, VarDCT will be superior to Modular for lossy encoding, but > VarDCT doesn't support lossless, so Modular is required for lossless > encoding. Currently, the library always chooses VarDCT for lossy and > Modular for lossless, although this could potentially be subject to > change. > > A user will have very little reason to force modular unless they're > testing the two modes against each other. The library API does not > provide a way to force VarDCT. Or rather, it does, but if you force > VarDCT and tell it to encode losslessly it will silently use modular > rather than fail. > > You generally won't have a reason to force VarDCT anyway, since it's > chosen by default if you pick lossy, so this isn't an issue. Ok, maybe qualify the option description to state lossless is always modular and lossy is VarDCT unless forced otherwise. LGTM with those changes. Regards, Gyan
diff --git a/doc/encoders.texi b/doc/encoders.texi index aac9f25e55..99399d4674 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -1809,6 +1809,40 @@ by ":". See the SVT-AV1 encoder user guide for a list of accepted parameters. @end table +@section libjxl + +libjxl JPEG XL encoder wrapper. + +Requires the presence of the libjxl headers and library during +configuration. You need to explicitly configure the build with +@code{--enable-libjxl}. + +@subsection Options + +The libjxl wrapper supports the following options: + +@table @option + +@item distance +Set the target Butteraugli distance. This is a quality setting: lower +distance yields higher quality, with distance=1.0 roughly comparable to +libjpeg Quality 90 for photographic content. Setting distance=0.0 yields +true lossless encoding. Valid values range between 0.0 and 15.0, and sane +values rarely exceed 5.0. Setting distance=0.1 is usually attains +transparency for most input. The default is 1.0. + +@item effort +Set the encoding effort used. Higher effort values produce more consistent +quality and usually produces a better quality/bpp curve, at the cost of +more CPU time required. Valid values range from 1 to 9, and the default is 7. + +@item modular +Force the encoder to use Modular mode. The default is to let the encoder pick +between VarDCT and Modular encoding modes based on encoding settings and the +type of input content. + +@end table + @section libkvazaar Kvazaar H.265/HEVC encoder.