[Ffmpeg-devel] question on cs_test testing semantics.

mmh mmh
Thu Mar 29 17:16:31 CEST 2007


Michael Niedermayer writes:
 > Hi
 > 
 > On Thu, Mar 29, 2007 at 08:40:56AM -0400, Marc Hoffman wrote:
 > > 
 > > This function is called in a big loop running over src with an offset
 > > which advances by 1 in each iteration.  This causes a misaligned
 > > access violation on some non X86 architectures. I'm curious as to why
 > > this test is written this way. Is the intent to start sampling the
 > > input pixels at odd memory locations as the beginning of the first
 > > sample?  
 > 
 > hmm i dont think the intent is to do missaligned accesses ...
 > 

Well I'm not sure then because the cs_test loop does the following:

cs_test:
    for(dstOffset=128; dstOffset<196; dstOffset++){
	    int srcOffset;
	    memset(dstBuffer, dstByte, SIZE);

	    for(srcOffset=128; srcOffset<196; srcOffset++){
		    uint8_t *src= srcBuffer+srcOffset;
		    uint8_t *dst= dstBuffer+dstOffset;
		    char *name=NULL;

		    if(failed) break; //don't fill the screen with shit ...

		    switch(funcNum){
		    case 0:
			    srcBpp=2;
			    dstBpp=2;
			    name="rgb15to16";
			    rgb15to16(src, dst, width*srcBpp);
			    break;

It might not have been the intent but it is what is happening. I think
X86's just handle this fine and considering the input pattern is fixed
55 one would never see this behavior.  On machines with strict
alignment this code doesn't work because:

   register unsigned x= *((uint32_t *)s);

which is an odd pointer based on srcOffset++.

How about we increment by 4 it doesn't really matter based on what
your testing here and then we can be assured this will just work.  Or
we can mask the input addresses which btw dst will be wrong as well.

If I'm missing something subtle please help me understand that fine detail.

Marc





More information about the ffmpeg-devel mailing list