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 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 > > 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 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
