Quoting Michael Niedermayer (2024-07-23 22:14:19) > On Tue, Jul 23, 2024 at 08:52:58AM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-07-22 23:14:04) > > > On Mon, Jul 22, 2024 at 11:43:21AM +0200, Anton Khirnov wrote: > > > > There is no reason to delay it and this is a more natural place for > > > > this code. > > > > > > There is a reason. > > > By doing it later the surrounding pixels are available and one could > > > compute motion vectors from these surroundings and use all kinds of stuff > > > from motion compensation and optical flow and all that. > > > > > > someone, i dont remember exactly who, (maybe you remember?) > > > said something about premature optimization is the root of all evil. > > > Here that actually applies. Moving the code up thwarts write better > > > error concealment. (and frankly we already have most of that EC code > > > it would just need a cleanup to free it from the 16x16 limitation) > > > > This is not an optimization though. > > > > But okay, I am dropping both original patch 28 and these 3 new patches. > > Are you ok with the rest of the series? > > The series looked mostly ok, is there somewhere i can take a quick look > at the current set ?
I just pushed it to branch 'receive_frame' in my tree. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
