Exposore time is not framerate. If you have enough light you can set a short exposure time. Also if you have fast movement of the object, you need a short exposure time. 1/500s or 1/1000s means you have a delay of around 2-3ms. But depending on the sensor this delay is a little longer, because of the rolling shutter.
Hi cplussharp,
Did you have any improvement from 1080p@55fps to 1080p@60fps in Tegra Tk1. I have similar use-case, where i will take input YUYV frame from mipi camera 1080p@60fps and convert the frame from YUYV to YUV420 and encode it
I was able to get 53fps with following maximum clocks
echo 0 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable;echo 1 > /sys/devices/system/cpu/cpu0/online;echo 1 > /sys/devices/system/cpu/cpu1/online;echo 1 > /sys/devices/system/cpu/cpu2/online;echo 1 > /sys/devices/system/cpu/cpu3/online;echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;echo 1 > /sys/kernel/debug/clock/override.gbus/state;echo 852000000 > /sys/kernel/debug/clock/override.gbus/rate;echo 1 > /sys/kernel/debug/clock/override.emc/state;echo 924000000 > /sys/kernel/debug/clock/override.emc/rate
Please find the Application source at
My Queries
-
Did you managed to use L2 cache to improve the framerate any further to 1080p@60fps ?
-
For me the pipeline for encode and drop the packets takes almost 240% cpu resource and i guess 100% memory bandwidth (Did a sample memory copy in parallel with application execution from RAM memory to RAM memory using tmpfs mount and observed sudden drop in frame rate from 53 fps to 45 fps). Is there any way to optimize further ?
-
I have shared the complete Application code in dropbox, Is there any way to optimize further to get better result ? (current result is 1080p@53fps at maximum cpu and RAM clock with 240% cpu load and Memory throughput not calculated)
-
To my understanding that 4 times memory operation are made
-
Camera → memory = 1 Write operation done by camera DMA unit
-
Memory → NEON → MEMORY = 1 READ and 1 WRITE operation with Memory
-
Memory → Encoder ->DISCARD = 1 READ from memory
Totally 4 operation = 19201080260 (Camera access)+ 19201080260 (READ access by NEON unit) + 192010801.560 (Write access by NEON)+ 192010801.560 (READ by encoder). = 830 MB/sec
It looks too low compared to the Nvida claim that 14 GB/sec Memory bandwidth. So, where my bandwidth is getting lost ?
Thanks and regards,
Ananth
Hi GAP,
no I haven’t got it any faster. The current values are enough for my application.
I think your problem is not only the memory bandwith. Have you measured the speed of your convert method yet? I had a realy big permformance boost in using OpenMP!
If you are working with NEON instructions, use aligned memory, so the CPU doesn’t need to do it in the background.
You can also try to look in the code of libyuv, if there is allready a NEON-optimized algorithm for your conversion.
You should be at least get the 55fps with your pipeline, because I had way more calculations in my conversion (BGBR => I420) then you have.
Hi cplussharp,
Thanks for pointing out the conversion time. After implemented the conversion code, i did not measure the time consumed for conversion (It was taking around 17.5 milli sec for non-cache able buffers and 5 milli sec for cache able buffers).
I found drastic improvement in the performance, once cache-able buffers are introduced to NEON block. Now able to take 1080p@60fps from camera then 1080p@60fps h264 format of encoding and save into local media, stream encoded video via network (Using Ethernet) and Display simultaneously.
Thanks and regards,
Ananth
Hello GAP,
can you tell me how to introduced cache-able buffers to NEON block?
hello.Recently, I want to achieve a 720p on tk1 real-time network monitoring, can you give me a little bit about some of your relevant information and code?
Kind regard!
Hi ayang/Rites,
We have used user pointer based v4l2 image capture instead of mmap and passed those buffer to other gstramer pipeline using appsrc plugin to achieve performance.
Thanks and regards,
Ananth.
Locking thread, please create another thread if any further issues are found.