On 19/03/2026 21:49, Michael Niedermayer via ffmpeg-devel wrote:
Hi Lynne
On Thu, Mar 19, 2026 at 02:48:04PM +0100, Lynne via ffmpeg-devel wrote:
On 19/03/2026 13:32, Michael Niedermayer via ffmpeg-devel wrote:
Hi Jerome
On Thu, Mar 19, 2026 at 10:08:19AM +0100, Jerome Martinez via ffmpeg-devel
wrote:
Le 18/03/2026 à 06:06, Lynne via ffmpeg-devel a écrit :
[...]
This would not change the amount of memory we would need to allocate, we
would simply be buffering the entire slice in memory before inverting it
in the decoder. While it would be faster than doing it for an entire
image at a time, the memory requirement makes this suboptimal.
I second that, currently it is possible to just keep in fast memory 2 lines,
and it is an advantage, especially when we need to process 8K content.
Also, here we talk about an update of FFV1, not FFV2 or any new format,
keeping the process simple and based on what already exists is IMO more
important that getting the "best" (speed? compression ratio? or less
complexity).
Have you checked that the suggested 45° rotated plane cannot be encoded
with a small line buffer ?
Consider this:
FFV1 uses the following past samples to predict the x sample
P
P P P
P P x
rotate by 45°
P P P
P P
x P
Now lets flip it
P P P
P P
P x
This is the exact same pattern and it only touches lines above and samples
in the same line to the left
-> Thus you can encode the green samples as a single plane
with the exact same FFv1 predictor and context models
Its just that instead of rotating the plane you rotate the context and predicto
That's not entirely accurate. The pixel data is predicted only via
L, TL and T. In the context == 0 case, these same pixels are used for
prediction. With context == 1, LL and TT are added, but are only used for
predicting the context.
In an earlier message, I did propose extending the pixel prediction, but
since it would benefit multiple codecs, I would prefer to leave that for a
future extension since it's a very low level change that should benefit
everything, rather than inventing a new one for Bayer coding.
Its neccesary that we test and compare alternatives.
Thats the foundation of finding a good solution.
This specific proposal
* does one operation less (the haar TX) -> should be faster
* it can be argued that not doing the haar TX should compress better
This specifically is absolutely a thing that I will include in my
benchmarks.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
