
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div>1. VDA is faster then CPU decoding in general. <div>2. CPU usage of VDA API depends on your video-card. Old cards don't support full decoding acceleration and some job is still done by CPU. All cards have limitation on image size.<br><div>3. VDA decoded frames could be rendered without copying frame to RAM, using OpenGL. Anyway ffmpeg stores all frames in RAM, so h264_vda decoder copies each frame to RAM that's way h264_vda could be slower then classical h264 decoder.</div><div><br></div><div><br><div><div>04.09.2013, в 17:21, Kirill Gavrilov написал(а):</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"><div>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></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>

<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></div></div></body></html>