(more exactly the computer energy consumption)

Le 4 sept. 2013 à 16:24, Lucas Soltic <[email protected]> a écrit :

> Hi Kirill,
> 
> Do you know by how much it is slower? Because I'm not only interested in 
> speed, but also in CPU consumption.
> 
> Le 4 sept. 2013 à 16:21, Kirill Gavrilov <[email protected]> a écrit :
> 
>> Hi,
>> 
>> On Wed, Sep 4, 2013 at 5:33 PM, Attila Sukosd <[email protected]> 
>> wrote:
>> 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.
>> 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.
>> 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.
>> Because this stuff is really overcomplicated, painful and contradicts to 
>> implemented decoding+rendering pipeline - I haven't tried it in my 
>> application yet.
>> 
>> 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.
>> 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):
>> AVCodec* aCodecVda = avcodec_find_decoder_by_name ("h264_vda");
>> avcodec_open2 (theCodecCtx, aCodecVda, NULL);
>> 
>> I have tried this decoder on my old Macbook and it is significantly slower 
>> than software decoder.
>> There is also patch in mail list which introduces similar decoder (automatic 
>> GPU->CPU memory copying) with DXVA2 acceleration.
>> -----------------------------------------------
>> Kirill Gavrilov,
>> Software designer.
>> _______________________________________________
>> Libav-user mailing list
>> [email protected]
>> http://ffmpeg.org/mailman/listinfo/libav-user
> 
> _______________________________________________
> Libav-user mailing list
> [email protected]
> http://ffmpeg.org/mailman/listinfo/libav-user

_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user

Reply via email to