[FFmpeg-devel] [PATCH] h264chroma: remove duplicate 9/10 bit functions.

[Michael Niedermayer]

On Sun, Feb 10, 2013 at 07:39:11PM -0800, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Feb 10, 2013 at 7:34 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sun, Feb 10, 2013 at 07:04:07PM -0800, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sun, Feb 10, 2013 at 5:22 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Sun, Feb 10, 2013 at 04:40:19PM -0800, Ronald S. Bultje wrote:
> >> >> From: "Ronald S. Bultje" <rsbultje at gmail.com>
> >> >>
> >> >> Also use the resulting 16bpp functions for anything >8 and <=16, not just
> >> >> 9 and 10. This fixes 12 and 14bpp H264 support.
> >> >
> >> > How can i test/verify this bugfix ?
> >> > I tried a few files but notice no difference, they either worked
> >> > already or still dont work
> >>
> >> You see that currently it uses 8bpp chroma for !=9 && !=10, right?
> >
> > yes, recent regression introduced by 79dad2a9
> > the new code should probably also use <=16 instead of <16
> >
> > But the SIMD changes look wrong, the code supports 10bit not >10bit
> 
> Why? Do intermediates overflow 16bit?

yes, for example:
cglobal %1_h264_chroma_mc8_10, 6,7,8
does a
psrlw         m2, 6
at the end thus would only output upto 10 bits

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

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130211/4ba79752/attachment.asc>