[FFmpeg-devel] [PATCH] fix H.264 decoding on big-endian

[Michael Niedermayer]

On Sun, Feb 14, 2010 at 10:47:27PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Sun, Feb 14, 2010 at 09:27:32PM +0100, Reimar D?ffinger wrote:
> >> On Sun, Feb 14, 2010 at 09:21:10PM +0100, Reimar D?ffinger wrote:
> >> > no idea what I am doing, but this seems to work:
> >> 
> >> Sorry, now the same against latest SVN:
> >> Index: libavcodec/h264_direct.c
> >> ===================================================================
> >> --- libavcodec/h264_direct.c	(revision 21824)
> >> +++ libavcodec/h264_direct.c	(working copy)
> >> @@ -178,8 +178,13 @@
> >>  
> >>              int match_count= (left_ref==ref[list]) + (top_ref==ref[list]) + (refc==ref[list]);
> >>              if(match_count > 1){ //most common
> >> +#if HAVE_BIGENDIAN
> >> +                mv[list]= (mid_pred(A[0], B[0], C[0])<<16)
> >> +                         +(mid_pred(A[1], B[1], C[1])&0xFFFF);
> >> +#else
> >>                  mv[list]= (mid_pred(A[0], B[0], C[0])&0xFFFF)
> >>                           +(mid_pred(A[1], B[1], C[1])<<16);
> >> +#endif
> >
> > should be pack16to32()
> > and sorry for this, i would have noticed it normally but fate is so yellow
> > that its hard to spot breakages.
> > 1. mike should finally update the checksums of the 8 correctly changed files
> >    assuming they are still correct
> 
> He's waiting for you, I think...

?!

The files that changed due to my commit to ffmpeg.c are more correct now
they where demuxed asymetrically before having one stream violate the
requested -t length
and there is one file that needs its -t bumped because the single
frame thats duplicated dozen times in the output happens not to fit in
the specified t length or something like that IIRC.

If mike wants me to do something he will have to say that clearly, simply
waiting will not resolve this, from my point of view the checksums are
wrong or at least where when i looked at them a few hours after my commit

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100215/0333cfd4/attachment.pgp>