[FFmpeg-devel] [RFC] use ff_avc_find_startcode in ff_find_start_code

[Michael Niedermayer]

On Tue, Feb 19, 2008 at 12:04:08PM +0100, Reimar D?ffinger wrote:
> Hello,
> On Mon, Feb 18, 2008 at 11:07:38PM +0100, Reimar D?ffinger wrote:
> > First I wonder if that ff_find_start_code function is
> > not quite buggy anyway, or is it intentional that it searches for 
> > 00 00 01 00 in the part involving the state but for 00 00 01 ?? in the
> > later code? If so, could somebody document the code?.
> > Anyway, this is a quite ugly patch that makes the function use
> > ff_avc_find_startcode (since that is in lavf, it can't be used as is of
> > course).
> > It probably also breaks the original use of ff_avc_find_startcode,
> > though I found the current behaviour a bit strange as well, and this
> > function is undocumented, too.
> > This causes at least a 6% speedup when decoding
> > http://samples.mplayerhq.hu/GXF/THX_Science_FLT_1920.gxf (I only tested
> > with MPlayer though).
> 
> This one is a bit faster, but still not as fast as the original when
> using ffmpeg/ffplay but much faster when using mplayer (whether the data
> is in the cache or not really seems to be what makes the difference?!)...
> 
[...]
>      for( end -= 3; p < end; p += 4 ) {
>          uint32_t x = *(uint32_t*)p;
> -//      if( (x - 0x01000100) & (~x) & 0x80008000 ) // little endian
> -//      if( (x - 0x00010001) & (~x) & 0x00800080 ) // big endian
> -        if( (x - 0x01010101) & (~x) & 0x80808080 ) { // generic
> -            if( p[1] == 0 ) {
> -                if( p[0] == 0 && p[2] == 1 )
> -                    return p-1;
> -                if( p[2] == 0 && p[3] == 1 )
> -                    return p;
> -            }
> -            if( p[3] == 0 ) {
> -                if( p[2] == 0 && p[4] == 1 )
> -                    return p+1;
> -                if( p[4] == 0 && p[5] == 1 )
> -                    return p+2;
> -            }
> +#ifdef WORDS_BIGENDIAN
> +        if( (x - 0x00010001) & (~x) & 0x00800080 ) {
> +            if ((x & 0xffffff00) == 0x00000100)
> +                return p;
> +            if ((x & 0x00ffffff) == 0x00000001)
> +                return p+1;
> +            if ((x & 0x0000ffff) == 0 && p[4] == 1)
> +                return p+2;
> +            if ((x & 0x000000ff) == 0 && p[4] == 0 && p[5] == 1)
> +                return p+3;
> +        }
> +#else
> +        if( (x - 0x01000100) & (~x) & 0x80008000 ) {
> +            if ((x & 0x00ffffff) == 0x00010000)
> +                return p;
> +            if ((x & 0xffffff00) == 0x01000000)
> +                return p+1;
> +            if ((x & 0xffff0000) == 0 && p[4] == 1)
> +                return p+2;
> +            if ((x & 0xff000000) == 0 && p[4] == 0 && p[5] == 1)
> +                return p+3;
>          }
> +#endif

if(p[1]){
    if( p[2] == 0 && p[4] == 1 )
        return p+1;
    if( p[4] == 0 && p[5] == 1 )
        return p+2;
}else{
    if( p[0] == 0 && p[2] == 1 )
        return p-1;
    if( p[2] == 0 && p[3] == 1 )
        return p;
}

Should be faster IMO, also the original code in the if() should be faster
than your code. Only the change in the masks for BE/LE looks like it should
improve speed.
That is for large skips, for small ones the speed really doesnt matter.

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080219/8fe7a669/attachment.pgp>