<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>
<DIV>Hi Matt,<BR></DIV>
<DIV></DIV>
<DIV id="divNeteaseMailCard"></DIV>
<DIV> </DIV>
<DIV>Thanks your explain, I understand your idea, it is fast algorithm for Intra decide.</DIV>
<DIV> </DIV>
<DIV>But I don't know why you use intra_pred_allangs function to calculate</DIV>
<DIV>Chroma.</DIV>
<DIV>The function generate all of 33 Luma modes, and chroma have 5 modes</DIV>
<DIV>only, so I don't use it for Chroma.</DIV>
<DIV>In your case, I think intra_pred[] is better choice. <BR></DIV><PRE>Thanks!</PRE><PRE>Min</PRE><BR>At 2013-12-22 22:28:50,"Matt Johnson" <johnso87@illinois.edu> wrote:<BR>>Hi Min,<BR>> Unfortunately the code where I'm seeing the failure is part of a whole <BR>>separate program I wrote that makes use of x265's intra prediction and <BR>>SATD functions, so I don't have a minimal test case. Essentially I am <BR>>decomposing the frame into a regular grid of 4x4, .. 32x32 PUs, and <BR>>computing SATD values for all 35 intra prediction modes, for all blocks, <BR>>for all block sizes, for all 3 channels, using the original frame pixels <BR>>as the reference rather than the reconstructed pixels as the decoder <BR>>would see them. It's intended to be a way to quickly find the most <BR>>profitable intra prediction modes for high-bitrate scenarios where <BR>>reconstructed pixels approximately equal the original pixels; by using <BR>>the original pixels as reference, I can do prediction for the entire <BR>>frame at once, so it is profitable to offload the computation to a GPU.<BR>> In any case, I do call the intra_pred_allangs function pointer of my <BR>>primitives struct with bFilter==1 for luma blocks under 32x32 and <BR>>bFilter==0 otherwise. As an example of when the filtering clause gives <BR>>an incorrect result, consider a 4x4 chroma block.<BR>><BR>>Above neighbor array = [0x7B 0x7B 0x7B 0x7B 0x7B ...] (first element is <BR>>[-1][-1] index in the image, relative to the block in question (top-left <BR>>corner)<BR>>Left neighbor array = [0x7B 0x7B 0x7A 0x7B 0x7C ...] (first element is <BR>>also [-1][-1] index in the image)<BR>><BR>>For the vertical prediction mode on 4x4 chroma, you just copy the above <BR>>neighbors downward, so for example, the element in the second row and <BR>>the first column ([1][0] in row-major syntax, [0][1] in the standard) is <BR>>0x7B according to the standard. With the filtering clause, that same <BR>>element is calculated as 0x7B+((0x7A - 0x7B) >> 1) = 0x7A.<BR>><BR>>Whether this needs to be fixed probably depends on whether x265 ever <BR>>intends on doing intra prediction for chroma. If not, then I should <BR>>just pass "--cpuid 1" to use the serial C versions.<BR>><BR>>Thanks!<BR>>-Matt<BR>><BR>>On 12/22/2013 12:07 AM, chen wrote:<BR>>> Hello Matt,<BR>>> Could you tell me how to reproduce the hash mistake?<BR>>> I check the code again, the intra_pred_allangs() called only Luma path.<BR>>><BR>>> Thanks,<BR>>><BR>>> Min<BR>>><BR>>> At 2013-12-22 08:35:09,"Matt Johnson" <johnso87@illinois.edu> wrote:<BR>>>>Hi all,<BR>>>> I don't know x86 assembly well enough to easily diagnose the problem<BR>>>>myself, but I'm running into a problem with intra prediction in the<BR>>>>horizontal (mode 10) and vertical (mode 26) modes, where the SSE4 result<BR>>>>(--cpuid 255) mismatches the C result (--cpuid 1) and indeed any cpuid<BR>>>>value earlier than SSE4.<BR>>>> The problem seems to be with the filtering clause (Equation 8-54 in the<BR>>>>standard for mode 26, 8-62 for mode 10), which applies to 4x4, 8x8, and<BR>>>>16x16 luma blocks. I'm seeing the problem with 4x4 chroma blocks; it<BR>>>>looks like the C version respects the bLuma flag to all_angs_pred_c()<BR>>>>(which propagates to the bFilter argument to intra_pred_ang_c()), so the<BR>>>>filtering clause is not invoked for 4x4 chroma blocks and the normal<BR>>>>equations involving ref[], iIdx, and iFact come into play. It looks<BR>>>>like the SSE4 version doesn't implement that flag the same way; the<BR>>>>predicted pixels I'm getting back are consistent with the use of the<BR>>>>filtering clause.<BR>>>><BR>>>>Thanks,<BR>>>>Matt<BR>>>>_______________________________________________<BR>>>>x265-devel mailing list<BR>>>>x265-devel@videolan.org<BR>>>>https://mailman.videolan.org/listinfo/x265-devel<BR>>><BR>>><BR>>><BR>>> _______________________________________________<BR>>> x265-devel mailing list<BR>>> x265-devel@videolan.org<BR>>> https://mailman.videolan.org/listinfo/x265-devel<BR>>><BR>>_______________________________________________<BR>>x265-devel mailing list<BR>>x265-devel@videolan.org<BR>>https://mailman.videolan.org/listinfo/x265-devel<BR></DIV></div>