#11563: Implement better jpeg compression now that patents on those two algorithms expired -------------------------------------+------------------------------------- Reporter: Balling | Owner: (none) Type: enhancement | Status: new Priority: normal | Component: | undetermined Version: git-master | Resolution: Keywords: mjpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Bug Image specific quantization tables https://github.com/mozilla/mozjpeg/issues/182 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11563#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#11563: Improve JPEG compression based on now-expired patents -------------------------------------+----------------------------------- Reporter: Balling | Owner: (none) Type: enhancement | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: mjpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Description changed by Balling: Old description:

Summary of the bug: bigger bug is here "Image specific quantization tables" which can source code that should compile just fine, https://pages.cs.wisc.edu/~ratnakar/rdopt.html and there is even a better algorithm that doubles average size savings: Joint Optimization of Run-Length Coding, Huffman Coding, and Quantization Table With Complete Baseline JPEG Decoder Compatibility.

Unfortunately, it is patent encumbered probably until 2024 (2025 now, btw): https://www.google.com/patents/US7570827

There are also images comparison https://cloud.githubusercontent.com/assets/72159/8814942/99255002-300a- 11e5-8fcd-4f810b0aa78b.jpg

vs

https://cloud.githubusercontent.com/assets/72159/8814943/992ee824-300a- 11e5-99fe-0f56e3229c84.jpg

New description: Summary of the bug: bigger bug is here "Image specific quantization tables", source code that will compile just fine (if you insert some std headers), https://pages.cs.wisc.edu/~ratnakar/rdopt.html and there is even a better algorithm that doubles average size savings: Joint Optimization of Run-Length Coding, Huffman Coding, and Quantization Table With Complete Baseline JPEG Decoder Compatibility. Unfortunately, it is patent encumbered probably until 2024 (2025 now, btw): https://www.google.com/patents/US7570827 There are also images comparison https://cloud.githubusercontent.com/assets/72159/8814942/99255002-300a- 11e5-8fcd-4f810b0aa78b.jpg vs https://cloud.githubusercontent.com/assets/72159/8814943/992ee824-300a- 11e5-99fe-0f56e3229c84.jpg -- -- Ticket URL: <https://trac.ffmpeg.org/ticket/11563#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#11563: Improve JPEG compression based on now-expired patents -------------------------------------+----------------------------------- Reporter: Balling | Owner: (none) Type: enhancement | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: mjpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by MasterQuestionable): ͏    Even so, still of so many inefficiencies; however optimized. ͏    Demonstrable by that some images may nevertheless compress better in PNG. [ !^ ͏ https://github.com/orgs/community/discussions/141322#discussioncomment-11754... ͏    Images that of large contiguous color region. ͏    Ideally in WebP Lossless, for whose overall superiority: ͏ https://github.com/lvandeve/lodepng/issues/187#issuecomment-2561596363 ͏    Also note JPEG compression is simply block-based: ͏    Cannot properly merge certain duplicates disregard. ] ͏    Somewhat like the still prevalence of PNG? ͏    https://github.com/MasterInQuestion/talk/discussions/27 ͏    . ͏    Being ubiquitous doesn't change that, it's still a poor codec in fact. \\ ͏    Video is essentially a sequence of motion pictures. ͏    That could be just GOP (Group of Pictures). ͏    The image codecs could as well handle. ͏    (Inter-frame compression is fundamentally no different from Intra- frame) ͏    What's needed is just some extension of the basic container scheme: ͏ https://github.com/MasterInQuestion/talk/discussions/3#discussioncomment-958... ͏    (MPX Simple) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11563#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker