<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 17, 2018 at 5:31 PM, chen <span dir="ltr"><<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Hi,</div><div><br></div><div>Thank you report this bug.</div><div>I think the root cause is not sizeof(), the negative stride is invalid in encoder/decoder core.</div><div>To avoid these invalid input parameters, the x264 insert a middle-layer that convert color space and images, but x265 doesn't it.</div><div><br></div><div>Of course, crash is worst way to report invalid input parameters, we will fix it soon.</div><div><br></div><div>Thanks,</div><div>Min</div><div><div class="h5"><div style="zoom:1"></div><div id="m_-4290041171376042940divNeteaseMailCard"></div><br>At 2018-01-18 00:24:19, "Vittorio Giovara" <<a href="mailto:vittorio.giovara@gmail.com" target="_blank">vittorio.giovara@gmail.com</a>> wrote:<br> <blockquote id="m_-4290041171376042940isReplyContent" style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid"><div dir="ltr"><div>Hi,<br></div>I'm developing an app which flips a frame in this way<br clear="all"><div><div><br></div><div>    frame->stride[0] *= -1;<br>    frame->stride[1] *= -1;<br>    frame->stride[2] *= -1;<br>    frame->data[0]    = frame->data[1] + frame->stride[0];<br>    frame->data[1]    = frame->data[2] + frame->stride[1];<br>    frame->data[2]    = frame->data[2] + (((frame->height >> desc->log2_chroma_h) - 1) * -frame->stride[2]);<br></div><div><br></div><div>and then proceeds to encode it with either x264 or x265.</div><div><br></div><div>When feeding this frame to x265_encode(), I get a crash in x265_upShift_16_avx2 at picyuv.cpp:322. While debugging I noticed that there is something wrong in the division for the input stride: for a 640x480 yuv 10 bit frame (with negative strides) the computed value is <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline;float:none">9223372036854775168</span> instead of -640.</div><div><br></div><div>I believe the problem lies in the operation <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline;float:none">pic.stride[0] / sizeof(*yShort) </span>where <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline;float:none"></span>the result of every division is promoted to unsigned since<span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline;float:none"></span> sizeof() returns size_t (aka unsigned long). Unfortunately this issue is spread across the entire codebase, affecting every arithmetic operation whenever a stride is computed or updated. I think this was introduced four years ago in <a href="https://bitbucket.org/multicoreware/x265/commits/eadec14402d6" target="_blank">https://bitbucket.org/<wbr>multicoreware/x265/commits/<wbr>eadec14402d6</a>.<br></div><div><br></div><div>The solution would be to properly cast every sizeof() operation to ssize_t or int, or modify the internal functions to operate on bytes instead of pixels. The same frame fed to x264 is correctly encoded just fine.</div><div><br></div><div>Can anybody verify and apply a proper fix? Thank you<br></div><div><span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline;float:none"></span></div><div>-- <br><div class="m_-4290041171376042940gmail_signature">Vittorio</div>
</div></div></div>
</blockquote></div></div></div><br></blockquote></div><br></div><div class="gmail_extra">Hi, was there any progress on this?<br></div><div class="gmail_extra">I agree with Derek that there is value in supporting negative strides, as it's a common feature in multimedia systems.<br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Vittorio</div>
</div></div>