Hi Timo, On Thu, Sep 1, 2016 at 7:34 AM, Timo Rothenpieler <t...@rothenpieler.org> wrote:
> > Hi, > > > > On Thu, Sep 1, 2016 at 7:00 AM, Ali KIZIL <aliki...@gmail.com> wrote: > > > >> Hi Oliver, > >> > >> I just setup my DDR3 RAM speed to 2133 Mhz on i7 4960x server. It dosnt > >> make a much difference. FPS is still waiving 41-44 fps for UHD P010LE > HEVC > >> Main 10 encoding. > >> > >> Also, rawvideo P010LE encodding waiving 39-42 fps. For your note;while > FPS > >> waves from 39-42 fps for YUV420P to P010LE, YUV420P to YUV420P10LE fps > is > >> like 75-76: > > > > > > I think this is expected, the p010le conversion is C (no SIMD). The > > yuv420p10le conversion is using x86 SIMD (probably AVX). > > > > To fix this, add x86 SIMD implementations of the p010le conversions in > > swscale. Better yet, add direct conversions from yuv420p10 (which I > assume > > is the internal format of your actual source after decoding?) to p010le, > > first C and then later x86 SIMD. > > I think 40-50 FPS is quite a nice result for UHD with the plain stupid C > implementation. > I agree. I didn't mean to offend you for writing bad C code, or for not writing SIMD code. I simply meant to point out that if you want to go from 40-50fps to 100+fps, SIMD is probably the easiest way to move in that direction. Also, isn't the internal representation of YUV 10bit in swscale > essentially yuv420p10 anyway, so the conversion already is as direct as > it gets? There is probably no conversion at all, right. But given that there's also a video being decoded, which is much more CPU-intensive than colorspace conversion, you wouldn't expect the colorspace conversion to slow it down by >2x. (Unless it's C, of course. :-).) > I have no idea why you would want to convert from yuv420p to p010le or > > yuv420p10le. I understand swscale supports it (it should) but I doubt > > that's how you want to generate 10 bits content. > > P010 is the only YUV420 10bit format NVENC supports. His source in the given example was yuv420p. If your source is 8bit, encode 8bits, not 10bits. For 10bit encoding, use 10bit source. Right? So even if this is only a performance test, we need to think about whether the test tells us something meaningful. In particular, to repeat what I said earlier, if the source is represented as yuv420p10le after decoding, a direct yuv420p10le to p010le conversion in C and SIMD is probably going to be even-more-efficient than a SIMD implementation of the p010le (or be) input/output that you wrote earlier, since that's the "slow" conversion path. If this is confusing, poke me at VDD (QtCon) and I'll explain in more detail. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
