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

[Wei Gao]

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.


And another point, a lot of the code seems to be copy/pasted from VLC,
without attribution to the original authors.

Yes, I copy the VLC code, I will write the attribution later.Sorry for that.

Thank you for your reply.We will fix our patch and submit soon.Thank you
very much.

2012/12/26 Hendrik Leppkes <h.leppkes at gmail.com>

> On Wed, Dec 26, 2012 at 7:18 AM, Wei Gao <highgod0401 at gmail.com> wrote:
> > From 8dddb4d8712ea5bcd91455b393e9563507fc9852 Mon Sep 17 00:00:00 2001
> > From: highgod0401 <highgod0401 at gmail.com>
> > Date: Wed, 26 Dec 2012 14:05:38 +0800
> > Subject: [PATCH] add h.264 dxva2 decoder to ffmpeg
> >
>
> 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.
>
> 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)
>
> And another point, a lot of the code seems to be copy/pasted from VLC,
> without attribution to the original authors.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>