[x265] SSE4 Angular Mode 26 Intra function
chen
chenm003 at 163.com
Sun Dec 22 07:07:36 CET 2013
Hello Matt,
Could you tell me how to reproduce the hash mistake?
I check the code again, the intra_pred_allangs() called only Luma path.
Thanks,
Min
At 2013-12-22 08:35:09,"Matt Johnson" <johnso87 at illinois.edu> wrote:
>Hi all,
> I don't know x86 assembly well enough to easily diagnose the problem
>myself, but I'm running into a problem with intra prediction in the
>horizontal (mode 10) and vertical (mode 26) modes, where the SSE4 result
>(--cpuid 255) mismatches the C result (--cpuid 1) and indeed any cpuid
>value earlier than SSE4.
> The problem seems to be with the filtering clause (Equation 8-54 in the
>standard for mode 26, 8-62 for mode 10), which applies to 4x4, 8x8, and
>16x16 luma blocks. I'm seeing the problem with 4x4 chroma blocks; it
>looks like the C version respects the bLuma flag to all_angs_pred_c()
>(which propagates to the bFilter argument to intra_pred_ang_c()), so the
>filtering clause is not invoked for 4x4 chroma blocks and the normal
>equations involving ref[], iIdx, and iFact come into play. It looks
>like the SSE4 version doesn't implement that flag the same way; the
>predicted pixels I'm getting back are consistent with the use of the
>filtering clause.
>
>Thanks,
>Matt
>_______________________________________________
>x265-devel mailing list
>x265-devel at videolan.org
>https://mailman.videolan.org/listinfo/x265-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20131222/e43abf1d/attachment.html>
More information about the x265-devel
mailing list