While I am slacking, you guys have fast forwarded. I'm still trying to catch up on all the previous posts, I wanted to ask if we were going to do any profiling at all on the OpenRISC.

I guess most of the profiling was done on the x86 platform. Trying to digest all the existing profiling info.

Thanks,
Guru

Hi Guru,
I think that at the moment profiling on OpenRISC is not necessary. It seems that this project is advancing in the direction of the following two stages:
1. creating H.264 encoder IP core which (in principle) could be connected to any suitable CPU.
2. Implementing SoC with the H264 encoder IP, OpenRISC CPU and other necessary peripherals (such as memory, camera, display controllers, etc.).

Later today, I'll post a more on the architecture thread.

-gil

BTW, please try to post on relevant threads. Your question here seems more related to the profiling thread.

Hi, all

I've uploaded a flow diagram used to explain HW/SW partition. It is based on the following basic point:

1) HW will encode one slice at a time when started;
2) Rate control is done at slice level, that is, all macroblocks in a slice have the same QP;
3) If the 2nd point is right, then we should modify the original x264 flow to slice level, since x264 rate control is at row level, please see the following code:

void x264_ratecontrol_mb( x264_t *h, int bits )
{
...

if( h->mb.i_mb_x != h->sps->i_mb_width - 1 || !rc->b_vbv )
return;
...
}

Can anyone please clear that what value should be returned by hardware? SATD and total bits of all the macroblocks in a slice? or only the sum of it?

Best Regards,

Jack

Jack, could you please explain why it would be better for us to implement rate-control by slice and not by row? practically, it means that we will only do rate-control per frame. That might be easier to implement, but will probably lead to worse results.

- gil

I would think slice-based rate control is better due to the configurable size of slices. They don't have to be the entire frame, right? Can we not make the slices equal to each row to begin with, giving us the flexibility of being able to change these sizes in the future?

Julius

Slices will normally have the size of a whole frame. that's the way it is implemented in x264. actually, only few months ago slicing support was added to x264, and it is only manual slicing (usually slicing frames to 4 rectangles). no dynamic (smart) slicing is implemented. Manual (static) slicing degrades encoding quality. I don't think that tying rate control with slicing is a good idea, because it will most probably lead to rate control by frames de-facto.

Hi every one i know a software which allows the HW-SW partitioning and allows simulation. The software name is POLIS, it works on Esterel and Ptolemy. I actually working on this software now for my academic purpose. Hope this information may be useful.

Can anyone plz suggest me any idea about a project which have Hardware and Software in it. And HW part will be burnt into a FPGA and SW part will be executed on Microblaze in Spartan 3e. Plz help me in selecting the project title.

Thank you