[FFmpeg-devel] [PATCH] RoQ decoder 4:4:4 update

[Michael Niedermayer]

Hi

On Mon, Jun 04, 2007 at 08:02:08PM -0400, Eric Lasota wrote:
> //Michael Niedermayer wrote:
> > what it certainly does though is it doubles the memory needed for the
> > codebooks and doubles the memory reads needed when copying them into the
> > image
> 
> I'd have to profile the code to find out, but 32-bit and 64-bit copies seem like the kind of thing most CPUs would have a field day with.

that assumes the speed is limited by the cpu instead of memory/cache and
that the code would use 32/64 bit read/writes instead of bytewise ones


> 
> > the reader sees roq_mbX and has no clue at all what that is
> > so he has to search for what it is and then wonders why uint8_t wasnt used
> 
> I don't see how that that obfuscates it any more than using roq_cell/roq_cell4 instead of uint8_t[1536] and uint8_t[1024] or similar does.

you can remove these too if you like

uint8_t cell[123] is clearer than roq_cell cell for someone not knowing
the code
additionally the roq_ prefixes add little information in roq*.{c,h}


> 
> I defined them as fixed array sizes to cause warnings if they're passed to incompatible functions.  The mb types are used somewhat liberally in the latest encoder changes, so how would you prefer macroblocks be represented?

you know the code better than i do, what i like is clean, simple, efficient,
... code
and in general i prefer if there are no wrapers around trivial operations,
types or functions
that said there are cases where such wrapers make sense (like a real type in
a decoder which can use real=double or real=float)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070605/1fe256c8/attachment.pgp>