5/8/2023 0 Comments H265 ffmpegOn the other hand, it fits pretty perfectly into a timeframe that is expected, as caching on Peripheral memory usually is disabled. And yes, this is on -O3 with -mfpu=neon and -ftree-vectorize (and it does, indeed, vectorize the code - without, it's running at 150ms per frame copy). Obviously, a copy time of anything more than 3 milliseconds for a Full-HD image is atrocious for a modern CPU. Receive_frame: 0ms // avcodec_receive_frame So I did a performance measurement using Wall time:Ĭode: Select all Send_frame: 5ms // avcodec_send_packet However, sws_scale() refuses to accept the SAND128 pixel format, so I'm doing it manually for now.Īnd, Indeed, it works and I get a good image in greyscale. Using this code, I'm fully aware that I'm only copying the Y-Component and broadcasting it to the BGR32/RGB32 pixel format. 2) Disabled cache (Peripheral addresses)įor (auto x_tile = 0 x_tile (m_outbuf.get() + y * rgblinesize) + x_tile*128 ) 1) Low locality (Column-Based (SAND) vs Row-Based (OpenGL)) Sand128 Pixel format: Layed out in columns of 128xheight, with columns being linesize*128 bytes apart (for the y-plane)Ĭonst auto* y_plane = source_frame->data Ĭonst auto colpitch = source_frame->linesize Ĭonst auto colwidth = source_frame->linesize Ĭonst auto height = source_frame->height Ĭonst auto rgblinesize = m_rgb_frame->linesize However, using the Standard AV_CODEC_HEVC with the DRM accelerator seems to be working just fine using AV_PIX_FMT_RPI4_8 for both the Hardware and Software frame layouts Interestingly, using "hevc_rpi" does not work properly, returning just 2 nameless hardware decoders (such that it is impossible to provide a hardware decoder to the Context). I'm not sure why some decoders are present, but reporting NULL as a name (via av_hwdevice_get_type_name(x->device_type)). Code: Select all OpenGL version: 3.1 Mesa 19.3.2
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |