New day! New blog post!
This post will describe the last idea in my head which I did mention in my proposal but has a serious con. But this idea suddenly seems to be an attractive option as the limited BRAM memory seems to be a problem.
The idea is basically to divide the picture into two parts and then process them simultaneously. Send them two computer and then stitch them together.
This has two advantage:
1) Currently 1 buffer of 16 lines is being used. To implement this I need to split the buffer into half. So extra input buffer is not required but an extra output buffer will be required in case the right half of the image gets processed first.This buffer will obviously be of smaller size as it is storing a compressed image. Of course, some extra pipe lining buffers will be added due to an extra jpeg core but the main reason for increased memory utilization the input buffer size remains the same.
2) Since each jpeg encoder has a smaller size(half) data to process, processing will be faster.
The biggest problem with this is that the HDMI2USB will output two frames one after the another, which will then be decoded by the UVC driver and then have to be stitched back together. Honestly I don't have much idea about UVC drivers and how much extra time the "stitching" process will take (Joel if you can give me some pointers on this it would be great) but one thing is for sure: HDMI2USB WILL NO LONGER BE PLUG AND PLAY DEVICE. This is why Jahanzeb was not impressed with this idea. Also whether this will be suitable for streaming, how much extra resources will be used etc can only be accurately stated once it has been implemented.
Currently I am reviewing the code of JPEG encoder. If I do get something interesting I will blog about it.
This post will describe the last idea in my head which I did mention in my proposal but has a serious con. But this idea suddenly seems to be an attractive option as the limited BRAM memory seems to be a problem.
The idea is basically to divide the picture into two parts and then process them simultaneously. Send them two computer and then stitch them together.
 |
| (Taken from my proposal) |
This has two advantage:
1) Currently 1 buffer of 16 lines is being used. To implement this I need to split the buffer into half. So extra input buffer is not required but an extra output buffer will be required in case the right half of the image gets processed first.This buffer will obviously be of smaller size as it is storing a compressed image. Of course, some extra pipe lining buffers will be added due to an extra jpeg core but the main reason for increased memory utilization the input buffer size remains the same.
2) Since each jpeg encoder has a smaller size(half) data to process, processing will be faster.
The biggest problem with this is that the HDMI2USB will output two frames one after the another, which will then be decoded by the UVC driver and then have to be stitched back together. Honestly I don't have much idea about UVC drivers and how much extra time the "stitching" process will take (Joel if you can give me some pointers on this it would be great) but one thing is for sure: HDMI2USB WILL NO LONGER BE PLUG AND PLAY DEVICE. This is why Jahanzeb was not impressed with this idea. Also whether this will be suitable for streaming, how much extra resources will be used etc can only be accurately stated once it has been implemented.
Currently I am reviewing the code of JPEG encoder. If I do get something interesting I will blog about it.
No comments:
Post a Comment