<html><head></head><body>Hi,<br><br>Is there a use case for this code at all anymore? Do we even actually support rendering onto 8/15/16 bits RGB anymore? Aren't 24-bits the practical minimum nowadays?<br><br><div class="gmail_quote">Le 25 janvier 2019 09:42:23 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 24/01/2019 18:07, Francois Cartegnie wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le 22/01/2019 à 18:44, jnqnfe@gmail.com a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> patch attached<br><br> Incorrect pointer offset calculation in SSE2 (non-assembly version)<br> RGB15 unpacking.<br><br> Could, I believe, allow almost 128 bytes to be written past the end of<br> the end of the buffer on last loop iteration.<br></blockquote> So after investigating,<br> the only way to trigger that code path is (and probably why it never<br> happened):<br><br> - Build without swscale<br> - Build without asm tool (CAN_COMPILE_SSE2) but with intrinsics<br></blockquote><br>So not in our builds<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">In the use<br>- Have some I420 to RV15 conversion (unlikely in display)<br></blockquote><br>With ultra ancient (if any) graphics card (16 bits ones ?).<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">- Have unaligned pixels<br></blockquote><br>Which can happen with some GPU driver allocated memory on Windows. But <br>we don't use that anymore in the display.<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">And it will overflow by 16 bytes at the end of the buffer, only if there<br>is no alignment.<br></blockquote><br>Which can happen on 3.x the visible area is at least a multiple of 16x2 <br>pixels (width alignment x line alignment). In 4:2:0 that's divided by 4 <br>for U and V planes, so 8 bytes.<br><br>On 4.x the pixel padding is 16x16 so no worries.<br><br>Is there a real case use of this issue ?<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>