I forgot to mention it is possible to go even further with ||izing the decoder by separating VLC decode from IDCT. This would affect serial performance however, since all coefficients would likely not fit in the innermost cache. For 4k yuv444p this is 51 MiB. Even 1080p yuv420p is still 6 MiB. For comparison, at the moment only a single DCT block is kept, which is just 128 bytes
Another possibility could be to have two threads per slice, interleaving VLC decode and IDCT, using double buffering on more modestly sized buffers. Two 16-line buffers per pair of threads or 768 KiB for 4k, 3 MiB across all four thread pairs. But, this would require mutexes between pairs of threads, which execute2() isn't designed for A final possibility is to do just enough upfront work to find the bit boundary between 16-line blocks within each slice. That is, doing VLC decode but not writing coefficients anywhere. Then each group of 16 lines could be made into its own job since we know the exact start and end bit for all of them. This would degrade serial performance and performance with 4/8 threads but probably a win for 4k and up with large numbers of threads /Tomas _______________________________________________ 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".
