<div dir="ltr"><div>Hi Vittorio,</div><div><br></div>I agree that we should support negative stride and going to work on this after sometime. Now we all are busy with some high priority tasks.<div>We would be very happy to see a patch from you supporting negative stride, provided you have some spare time.<br><div><br></div><div>Thanks</div><div>Ashok.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 25, 2018 at 6:04 PM, Vittorio Giovara <span dir="ltr"><<a href="mailto:vittorio.giovara@gmail.com" target="_blank">vittorio.giovara@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><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="m_-5670975499302015063h5"><div style="zoom:1"></div><div id="m_-5670975499302015063m_-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_-5670975499302015063m_-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/multicor<wbr>eware/x265/commits/eadec14402d<wbr>6</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_-5670975499302015063m_-4290041171376042940gmail_signature">Vittorio</div>
</div></div></div>
</blockquote></div></div></div><br></blockquote></div><br></div></div></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<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">-- <br><div class="m_-5670975499302015063gmail_signature" data-smartmail="gmail_signature">Vittorio</div>
</div></font></span></div>
<br>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
<br></blockquote></div><br></div></div></div></div>