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 * it applies the same context and prediction as other FFv1 cases, just rotated Maybe we have to think a bit about how to neatly implement it. But in fact that only matters if we select it in the final design for FFv1 bayer thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB For a strong democracy, genuine criticism is necessary, allegations benefit noone, they just cause unnecessary conflicts. - Narendra Modi
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
