i am using the Pre-Processor API of the MPEG-Encoder for Bayer-Format to YUV420 conversion.
The application code i wrote produces a video file which content is garbage. How can i check if the preprocessing works correctly ?
As you would have seen, the first argument of the conversion function is pYUV420Buf buffer. After the conversion, this buffer contains the YUV420 converted data of each macroblock. You may put a breakpoint there to see this in image-viewer(VisualDSP++) for each macro block. If this image is not correct, then it means that there might be a problem in the application code and pre-processing is not working correctly. Also please check the DMA configuration parameters used in the Bayer-YUV420 conversion.Let us know if this works well and encoder still produces invalid data.
Thanks & Regards,
there was a mistake in the DMA configuration. Now the preprocessing seems to be working correctly but it is extremly slow.
In the preprocessing function i use the library functions "adi_Bayer2RGBBilinear" and "adi_RGB2YCbCrBT601Range0to255".
For the last step from YUV444 to YUV420 i wrote my own c-function. The code is excuted from L1 memory and the preprocess buffers are also in L1 memory. I meaused the core-cycles for preprocessing each Macroblock with the Profile-Macros and found out that about 20000 cycles are consumed by the YUV444 to YUV420 function. What can be done to accelerate the preprocessing? The performance should be 1.6MPixels @15fps (BF561 @600MHz). Is assembler necessary?
Good to know that the conversion is working fine. Could you please send us the YUV444 to YUV420 code so that we can have a look at that and suggest any methods to improve the performance. An ASM implementation will surely enhance the performance.
i forgot to enable the Compiler optimization. Now the code runs faster but the time for processing one frame still takes very long (about 400ms).
I calculated the time difference between processing one frame and pre-processing all Macroblocks, which i assume is the time spend for DMA and encoding: 400ms - (0.04ms * 6030 Macroblocks) = 159ms. I don't know why this takes so long.
My preprocess code is attached.
From the number of macroblocks in the frame, it looks that you are using a 2Mpixel sequence. As is mentioned in the User's guide for MPEG2 encoder, 30fps may not be possible. The time spend mentioned for encoding is expected for these many macroblocks(6030). Would like to know the Blackfin processor variant that you are using. The MIPS can be improved by coding the YUV444 to YUV420 and the "convert_bayer12bit_to_8bit" in ASM. Also would suggest to run this at less than 30fps.
the aim is email@example.comMPixels with BF561@600MHz.
When the encoding of one frame takes 159ms then in the best case a performance of 6fps can be achieved assuming no pre-processing.
Even with two cores 15fps are not possibel, correct? I have no experience with Blackfin Assembler and therefore can't estimate how profitable it would
be. Is a reduction from 40us to 20us per Macroblock realistic?
The encoding without the intended pre processing (Bayer 12 bit to YUV420) one average would take 70 cycles/pel.
This would mean 93.33 msecs, which means you can process 10 fps.
Let's say after optimiztion and a good conversion function in asm , the intended pre-processing will give 10 cycles/pel.
That will take the average cycles to 80 cycles/pel, taking one frame to 108 msecs. So, realistic would be 8-9 fps for a best case.
All calculations done taking 2 cores into account.
Why is the encoding taking 159 msecs without pre-processing ? (i.e 119 cy/pel. Measured cycle count for mpeg2 encoder is lesser than this, @ about 70-80 cy/pel depending on bitrate)
the 159 msecs is the time for single-core encoding of one frame which results in 60 cycles/pixel = 0,159 secs / (1,67E-9 secs x 1,6MPixels).
The 10 cycles/pixels for pre processing seems to be very hard to achieve. Can you give me assistance in changing the asm routine YUV422 to YUV420 from the MPEG Encoder example code to YUV444 to YUV420 ?
On review, we feel that this issue is best directed to private support. Please use the support form via the URL below, and include a link to this thread.
Raka et al;
Please post the results of this effort, as it may help me with similar issues on the JPEG encoder.
Sure. We will post the results here once the PR effort is closed.
Retrieving data ...