Hi everyone, it's my first e-mail to this list (my classmates from college have sent a few though), so i'ld like first to greet everyone and congratulate all the people responsible for all the work with this theora project.
<br><br>So, to my question:<br><br>As you probably know, we are working on an implementation of the theora codec on hardware. I'm currently responsible for getting the function ReconRefFrame in dct_decode.c working, and after i understood the code and finished it in VHDL i found out (after 3 painfull debugging days) that i don't understand at all what is in LastFrameRecon, ThisFrameRecon and GoldenFrame (which types are YUV_BUFFER_ENTRY). Generally what i want to know is:
<span style="font-weight: bold;"><span style="font-weight: bold;">What is inside YUV_BUFFER_ENTRY?</span></span> More specifically, keep reading...<br><br>I know it is a buffer for the pixels, but i just recently found out that there are more things then just the pixels i need. This is a complicated issue, so i'll explain step by step what i understand (which i might be wrong) and finally to what i dont understand.
<br><br>1) What i understand: recon_pixel_index_table(i) returns the absolute location of a relative location. Example: if i do recon_pixel_Index_table(0), i would get the first pixel of the frame (although i dont quite get the visual idea of
<span style="font-weight: bold;">what is</span> the first pixel. Is it in that black area around the frame? is it the first real pixel? If i do recon_pixel_index_table(YPlaneFragments) do i get the first pixel in U Plane?)
<br><br>2) What i dont understand: i expected to YUV_BUFFER_ENTRY to contain only the pixels I'ld be using. So in my mind, if i did LastFrameRecon(0) to LastFrameRecon(YPlaneFragments), for example, i'ld get all the Y pixels. I realized after careful study of the recon_pixel_index_table that if i wanted the first pixel of the Y Plane it would not be 0, but in fact, ReconYDataOffset.
<br>Now, why is there such an offset? What is in between 0 and ReconYDataOffset? Is there any more "unexpected" data mixed in the pixels im using? Where am i going to be needing these pixels? It would help a bunch if i could eliminate them in hardware, since we're short on memory
<br><br>Sorry for the terribly long e-mail, but my last attempt at explaining all this in a hurry resulted in 2 very confused people with communication problems. So i put it as clear as i could<br>Thanks a lot for the help
<br><br>Arthur Valadares<br>