Hi,
1. Does Appro RDK's SW OSD algorithm support foreign language (chinese) ?
[Feroz] OSD can display graphics. Font should just be a library. We will need check with our Chinese team. Since its such a large market for us, it is more likely customers have done this.
[Customer] - Did you get chance to confirm this ? What additional change is needed to support Chinese language ?
Comment> In OSD guide, details are given on how create fonts, once fonts created, then OSD lib will just overlay it
2. Does platinum encoders (H.264 and MJPEG) support privacy masking feature ?
[Feroz] Our IPNCs support privacy masking. This is more of a feature of the application/system and display rather than the video Codecs. Decompression is independent of this feature as I understand. Will confirm.
[Customer] - Ok. Let me check detailed requirement here. Customer has specifically asked whether codecs support this feature or not. Currently, we are doing this on captured raw data. Will get back with mode details.
Comment> in DM36x, h264 codec support privacy masking inside the code, but MJPEG/MPEG4 does not support it
3. We are using platinum H.264 encoder. With this, when we use EDMA for memory copy of YUV data (every captured frame), we get only 24 fps instead of 30 fps (expected). If I don't perform memory copy using EDMA, then I can 30 fps.
Since memory copy is completely offloaded to EDMA instead of CPU, don't you think that compromise of 6 fps is a big number ?
I noticed that memory copy is not taking time but using EDMA for copy makes encoder performance low.
Query - Is it possible that we are making encoder suffer by occupying EDMA for huge memory copy or that should not be an issue? Any idea what can be the issue ?
[Feroz] Which version of DM36x are you using? DM365@300MHz can do 720p30@30fps and some configs 720p60.
[Customer] - Davinci DM365, Variant 0x8. ARM clock rate is 432 MHz. 1080P_30 is expected, we are getting this without privacy masking (ultimately YUV memcpy of each frame).
As soon as we enable privacy masking feature (which performs EDMA based memcpy to fill a color region before encoding), we have to compromise 6 fps, although profiling shows that copy operation is not taking much time with EDMA, compared to CPU based copy.
Comment> Arbitrary EDMA will cause the load balancing done on each TC to go awry, can you tell us which TC you used, can you use TC=3 for this. Performance s very sensitive to DDR access and load, as this has been perfectly balanced for transfer on each TC. Also, what encoder preset are you using? Can you use XDM_HIGH_SPEED preset?
So EDMA enabling reduced the fps??? Strange! Perhaps EDMA overload occurs here. Will need to get more inputs here…
[Customer] - Yes. We enable EDMA for memory copy operation. When we don't do memory copy, we get 1080P_30. With EDMA based memory copy, we get 1080P_24, which seems to be a concern, when using EDMA.
