<div dir="ltr"><div>If you throw it up on a github, it'd probably get a few people who could use it, at least.</div><div><br></div><div>ffmpeg's been working on a gpu replacement/enhancement of swscale for a long time, but in the meantime, bespoke solutions have to fill the gap.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 26, 2020 at 10:37 PM Chris Hiszpanski <<a href="mailto:chris@hiszpanski.name">chris@hiszpanski.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Colorspace conversion is a bit out of scope for libx264, since that's<br>
> a very deep rabbit hole to go into.<br>
<br>
Makes sense, thanks.<br>
<br>
> Note that YUY2 (YUYV) input is natively supported for 4:2:2 encoding<br>
> already, although afaik it only has SIMD on x86.<br>
<br>
Good to know. Yeah, not sure if it makes sense adding SIMD on ARM as<br>
they're mostly used in relatively lower-powered embedded devices that<br>
typically have hardware encoders (bizarre to me that i.MX8M does not),<br>
and the SIMD instructions would barely achieve real-time frame rates._______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x264-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div>