[FFmpeg-devel] [PATCH] libavcodec: add h.264 dxva2 decoder to ffmpeg

[Michael Niedermayer]

Hi

On Thu, Dec 27, 2012 at 12:54:32PM +0800, Wei Gao wrote:
> I'm not sure this patch as a whole is a good idea, because i'm not
> seeing the benefits, and a whole bunch of technical issues.
> On any half-competent system, the software decoder is significantly
> faster then the hardware decoders in most GPUs, which makes it
> somewhat useless for transcoding in ffmpeg.
> The only real use-case for hardware acceleration is in playback on
> low-end hardware or in mobile applications to reduce power usage.
> 
> Thank you for your reply.Please let me explain our idea.We are amateurs who
> fun with making full use of GPU. Our idea is to make full use of GPU, and
> this is the first stage also we want to submit DXVA2 for VC1, wmv3,mpeg2
> code.
> The second stage, we want to submit other hardware decoder code and our GPU
> code for some filters,and the third stage,we want to submit our hardware
> encoder code.
> So the pileline will be DXVA2-GPU filter - Hardware encoder,this will
> reduce time that copy data between CPU and GPU, and make the performance
> higher.
> also this will release CPU and make it have more resource to do other
> things.
> and also we think hwaccel has some advantage:
> 1.for hight bitrate video the speed is higher than software
> 2.for some video format such as VC1 or wmv3,the speed is higher
> 3.for h264 video, if the reference frames is more in video,the dxva2 has
> more advantage.the table is the test data of my computer:
> 
>    videosize 1920X1080
> GPU HD6730
> CPU I5-2430m ref frames fps   CPU DXVA2   2 72 58   4 65 76   6 65 76   8 66
> 76   11 66 75   13 65 76   16 65 75
> On the technical side of things, why do we have HWAccels if every
> HWAccel gets its decoder "wrapper"? Personally i prefer the concept of
> the HWAccel, even if the implementation isn't perfect.
> Especially with DXVA, which has so many variables to control, a
> generic decoder is probably not a good idea, and would end up a
> maintenance nightmare (i know, because i maintain my own user-code
> which uses the DXVA HWAccel, the fun never ends)
> 
> The purpose we add the wrappers is that, we want to submit VC1,wmv3,mpeg2
> dxva2 code.so the other video format can reuse the code.Sorry that it may
> add more maintenance.But I think it is convenient for users who want to use
> dxva2.As you said,DXVA2 has many parameters.so if we supply a API for
> users,they can call it easier rather than write it from start.This is our
> opinion.Thanks.

Some questions
Would this decoder allow a fate dxva2 regression test, that is a
test that tests the existing hw accel DXVA2 code ?

If yes, could you add such regression test? And would you in that
case be willing to run a fate client that regularly runs this test
and submits data to fate.ffmpeg.org?

I think a regression test that covers as much as possible of our dxva2
code would be very usefull to detect regressions early.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121227/5513f653/attachment.asc>