On 19/03/2026 22:52, Michael Niedermayer via ffmpeg-devel wrote:
Hi Lynne
On Thu, Mar 19, 2026 at 03:08:45PM +0100, Lynne via ffmpeg-devel wrote:
On 19/03/2026 14:13, Michael Niedermayer via ffmpeg-devel wrote:
Hi
On Wed, Mar 18, 2026 at 02:44:34PM +0100, Lynne via ffmpeg-devel wrote:
[...]
When i asked chatgpt a few days ago (yes, please forgive me)
... "Please list all algorithms that we should consider. " ...
It gave me a long blob of academic stuff, here just 2 of it
The one reminding me of what you implemeted is this:
https://sci-hub.box/10.1109/ICIP.2019.8803376 (short and simple paper)
And heres a comparission of this against 5 other methods
https://www.mdpi.com/1424-8220/22/21/8362
Noticably, its never the best compressing nor the fastest
The issue I see with those is they are not lossless.
I much more would liek to see "heres the compression my PR achieves, heres the
compression it achieves when this and that is changed, heres the compression
the best state of the art alternatives achieve"
What I was hoping for is feedback about whether this path - e.g. modelling
Bayer coding from the RGB path, including a decorrelation filter like RCT -
is agreeable.
I cannot awnser this in a vaccuum
I think you can at least agree that writing a fundamentally different codec
is not what we would like to end up with, right? At least not on this stage
yes
though if you submit a PR to FFv1 that gives us 20% better compression with a
totally
different algorithm. I would be overjoyed
And if that is true, what can we do to make Bayer coding fit into FFv1's
architecture?
I think given those constraints, we can put a limit on what we could do.
Given this, would you agree that needing a linecache larger than what we
currently use is not acceptable?
"larger than what we currently use" is a bit too strict
I think
we want all memory needs to be minimal (but its not the most important goal)
Addditional memory needs would require proportional gains elsewhere
I think I understand memory limits a bit more clearly, since I had to
work with the limitations that Vulkan exposed.
Requiring extra memory implies more copies, which means more bandwidth.
FFv1 is already very bandwidth-starved, as decoding each sample means
needing to do 6 loads from a potentially massive backing buffer.
Seeing as I need to also create a Vulkan version of the algorithm, I
would very much prefer to avoid needing to increase the buffer size.
I expect that we will end with a O(slice_width) and not O(slice_width *
slice_height)
but i dont want to discard anything without knowing what iam discarding
We need to see how alternatives perform
But what is clear is that this will not be resolved in 2 weeks
I can certainly make comparisons between other coding method alternatives,
as long as they are a reasonable fit for the codec.
great
[...]
I will prepare performance and compression figures too, of course.
that would be very good
You are mainly focusing on the use of Haar to decompose Bayer into median +
difference for the green samples. Would you prefer a more general
interpolation or predictor instead? Like I mentioned, I wouldn't mind this,
though it would be better if it benefitted RGB coding as well.
My concern is not about a specific part of this, rather that we dont
know how the surroundings of the algorithm landscape perform.
We dont even know if this choice is a local minimum in the landscape
of algorithms. Maybe we can make a small change and it will perform better.
Maybe we can make a larger change and we would be in a much deeper local
minimum.
What iam asking for is that the landscape of choices / algorithms is
investigated more before we settle on what choice FFv1 would use for decades
That's good, but you should keep in mind that this is an unstable feature
that can be changed in the future, rather than the final design.
I have to push back on this
the STF project says
"Completing this milestone will expand FFv1's archival capabilities to handle not
just produced video, but also direct camera footage, as well as film scanners and
scientific applications."
I dont think "an unstable feature" can be used for archival.
archival requires features to be long term supported and stable
All new features need to be introduced as unstable features until
version 4 of the codec is released. It is implied that this extension to
the codec will also go through the same procedure.
I think that merging support for it (or approving the PR) is enough to
satisfy the requirement of the milestone, rather than standardization.
The feature would be in the next version of the codec whenever it is
frozen and specified.
I think starting with a simple but proven design, and improving it, is the
most optimal path. It's how all other codecs were developed, including AV1.
sure but when we have bayer support behind "-strict -2" and change the algorithm
over time then it cant really be used by users. Its more for developers
colaborating
That's my point. I found some ways that floatmap can be optimized, and
we can collaborate to improve it. I don't want to be the single person
who can touch Bayer coding.
Right now, users who want to encode floating-point images losslessly via
FFv1 also have to use -strict -2 -level 4, and that's okay.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
