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

[Michael Niedermayer]

Hi

On Mon, Jun 04, 2007 at 09:52:10PM -0400, Eric Lasota wrote:
> Sorry about that last one, Thunderbird decided to switch to preformat 
> and I incorrectly assumed Mailman would fix the word wrap.
> 
> Michael Niedermayer wrote:
> > and
> > that the code would use 32/64 bit read/writes instead of bytewise ones
> 
> Considering block_copy is inlined with fixed sizes in the 
> implementations, gcc should be compiling it as such, but I'd have to dig 
> out nasm again for that.
> 
> > uint8_t cell[123] is clearer than roq_cell cell for someone not knowing
> > the code
> 
> I wouldn't think someone not knowing the code would glean any more 
> information off of a byte array than off of an unfamiliar type, but it 
> does seem more intuitive to have a type that specifically represents 
> data in a particular configuration than an unstructured array.
> 
> Admittedly it's a bit less important than with cells (which are 
> non-intuitive as an interleaved array), but I think something like 
> blah[cp][n] looks more intuitive as accessing a specific byte of a 
> specific plane of a macroblock than blah[cp*64+n]

that was not what i meant, my argument being uint8_t blah[cp][n] makes
more sense than blah, in first case you know its uint8_t and an 2d array
in the second case you know neither


> 
> Speaking of cells, should the cells and qcells fields of RoqContext be 
> renamed to something like codebook2x2 and codebook4x4 (or shorthand as 
> cb2 and cb4), representing their usage instead of their type?

i am strongly in favor of having 2x2 / 4x4 in their name, though iam
perfectly fine with both cb and codebook ...


> 
> c_stride could be deleted also, as it's no longer used in the update, as 
> long as it's okay to assume that all three planes will have the same 
> stride in 4:4:4.

well, strictly that isnt guranteed but other codecs assume that too and
noone ever reported a bug related to it ...

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/cfc56199/attachment.pgp>