[FFmpeg-devel] [PATCH] h264: hl_decode_mb_internal optimisation

Paul Kendall paul
Thu Jul 31 20:09:46 CEST 2008

On Thursday 31 July 2008 22:56:06 Michael Niedermayer wrote:
> On Thu, Jul 31, 2008 at 06:10:37PM +1200, Paul Kendall wrote:
> > On Thursday 31 July 2008 01:09:38 Michael Niedermayer wrote:
> > > On Mon, Jul 28, 2008 at 05:51:47PM +1200, Paul Kendall wrote:
> > I see you have committed a change for PCM stuff in revision 14476.
> > I think you need to revisit it! The memcpy in the first part of the
> > commit is cannot work as h->mb is of type DCTELEM[] (short) and desty is
> > uint8_t!
> >
> > The same goes for the final section. Also, the other sections are not
> > copying the data in the same order as was there previously! I copied the
> > code there to a small C file with then printed the indexes from the
> > calculations and it is certainly not sequential!
> My code is correct, my code is always correct ;)
> And yes the data is now stored in a different order internally, thats plain
> because it leads to simpler code, it may be faster as well but thats
> irrelevant due to rareity of these blocks.
> And yes i did test it with files containing PCM blocks and they are binary
> identical.
> [...]

It's always good to have faith in yourself ;-)

Ok, so it doesn't matter that you are using bytes in the mb[] instead of 
shorts because the other side of the code care either! I wasn't sure that the 
mb[] wasn't being used in other areas as well which expected shorts.

It's great that there are test files that check this stuff is 100%, and folk 
like you that know what they are doing.


More information about the ffmpeg-devel mailing list