On Wed, Jun 12, 2024 at 03:48:29PM +0200, Andreas Rheinhardt wrote: > There is no reason to use a temporary buffer as destination > for the new macroblock before copying it into its proper place. > > (History: 3994623df2efd2749631c3492184dd8d4ffa9d1b changed > the precursor of ff_mpv_reconstruct_mb() to always decode > to the first row of macroblocks for B pictures when > a draw_horiz_band callback is set (they are exported to the caller > via said callback and each row overwrites the previously decoded > row; this was probably intended as a cache-optimization). > Later b68ab2609c67d07b6f12ed65125d76bf9a054479 changed this > to the current form in which a scratchpad buffer is used when > decoding B-pictures without draw_horiz_band callback, followed > by copying the block from the scratchpad buffer to the actual > destination. I do not know what the aim of this was. When thinking > of it as a cache optimization, it makes sense to not use it > when the aforementioned draw_horiz_band optimization is in effect, > because then the destination row can be presumed to be hot > already. But then it makes no sense to restrict this optimization > to B-frames.)
IIRC The B frames where directly placed in GPU memory, which is slow to read from, so building up MC + IDCT (which could read depending on caches) was avoided by a a scratchpad but its really long ago so i might remember this only partly thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
_______________________________________________ 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".
