<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Le 4 sept. 2013 à 16:21, Kirill Gavrilov <<a href="mailto:gavr.mail@gmail.com">gavr.mail@gmail.com</a>> a écrit :</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Hi,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 5:33 PM, Attila Sukosd <span dir="ltr"><<a href="mailto:attila.sukosd@gmail.com" target="_blank">attila.sukosd@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I've looked at OS X's VDA acceleration, but it seems as though you need to do some extra work in the application to support the different hwaccels, but I haven't found any nice examples on how to do it.<br>
</div></blockquote></div>Most accelerated decoders decode picture into API-specific surface in GPU memory, which can be drawn using OpenGL (VDPAU) or Direct3D (DXVA2) without extra copying it back to CPU memory.<br>
</div><div class="gmail_extra">For this reason you need to do a lot of extra work to configure FFmpeg using specific hardware decoder (or detect when it can not be used), render result on the screen using more complicated scenarios.<br>
</div><div class="gmail_extra">Because this stuff is really overcomplicated, painful and contradicts to implemented decoding+rendering pipeline - I haven't tried it in my application yet.<br></div><div class="gmail_extra">
<br>VDA is somewhat simpler than most others because the original Apple API doesn't provide the way to render result directly and you should copy frame back to CPU memory anyway.<br></div><div class="gmail_extra">Technically you should just try to open another decoder and use it instead of auto-detected one in avcodec_open2 (with extra checks and + probably overridden get_format2 if you like planar YUV420P):<br>
<pre><span class="">AVCodec* aCodecVda</span><span class=""> = </span><span class="">avcodec_find_decoder_by_name</span><span class=""> (</span><span class="">"h264_vda"</span><span class="">);<br></span><span class=""><span class="">avcodec_open2</span><span class=""> (the</span><span class="">CodecCtx</span><span class="">,</span> </span><span class="">aCodecVda</span><span class=""></span><span class=""><span class="">,</span> <span class="">NULL</span><span class="">)</span>;<br>
</span></pre></div><div class="gmail_extra">I have tried this decoder on my old Macbook and it is significantly slower than software decoder.<br></div><div class="gmail_extra">There is also patch in mail list which introduces similar decoder (automatic GPU->CPU memory copying) with DXVA2 acceleration.<br></div></div></blockquote><div><br></div><div>On my side, when I had tried Apple's VDA, I don't remember it was too slow for real time decoding. Plus I didn't need to explicitly give the codec name for the hwaccel to be used (or at least that's what I guess because the CPU consumption was really lower).</div><div><br></div><div>What you say about the modifications required to use most hwaccel isn't a good news... and makes it really less interesting...</div><div><br></div><div>Is Apple's VDA the only hwaccel working that way?</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<span style="color:rgb(192,192,192)">-----------------------------------------------</span><br style="color:rgb(192,192,192)"><span style="color:rgb(192,192,192)">Kirill Gavrilov,</span><br style="color:rgb(192,192,192)">

<span style="color:rgb(192,192,192)">Software designer.</span><br><a href="mailto:kirill@sview.ru" target="_blank"></a>
</div></div>
_______________________________________________<br>Libav-user mailing list<br><a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>http://ffmpeg.org/mailman/listinfo/libav-user<br></blockquote></div><br></body></html>