|
|
| Mk4ever |
| Posted: Nov 10 2009, 10:15 AM |
 |
|
Newbie
Group: Members
Posts: 3
Member No.: 26447
Joined: 10-November 09
|
Hello,
I am an ITC student, and I have decided that my graduation project will be : "Utilizing GPU instead of CPU for video encoding"
I am targeting the new OpenCL, from ATI, on my ATI HD 4670, and I decided that I will use VirtualDub for my project.
Basically my final goal is do x.264 encodings utilizing the GPU, through building a custom VirtualDub build with ATI's OpenCL SDK.
Though my coding knowledge experience is next to zero, it's something I really wanna work on, and I know it'll be something I enjoy (besides the times when things don't work and I feel like committing a suicide! ).
What I wanna know is:
* Is VirtualDub a suitable program for my project as I think? or do you guys advice me to pick something else?
* For the purpose of my project (obtaining much higher speed through offloading video processing/encoding to gpu instead of cpu), do I need to work on the x.264 codec itself + VirtualDub? or modifying VirtualDub alone is what I need to do?
Thank you for your time.
|
|
| stephanV |
| Posted: Nov 10 2009, 04:34 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
I think VirtualDub has very little to do with this. Encoding speed is completely dependent on the encoder. I've heard from previous GPU experiments (CUDA IIRC) that it almost never helps. If I were you I'd make contact with x264 devs first.
Also, I'm not sure if you aren't aiming a little high if you have very little experience with coding...
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| Mk4ever |
| Posted: Nov 11 2009, 05:12 AM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 26447
Joined: 10-November 09
|
Thank you for your reply.
I thought the program itself should know how to do massive parallelism, to take advantage of the many stream processors in modern GPUs. I know that x.264 allowed for utilizing several processors for sometime now, although I still don't know if these processors should be x86 processors, or stream procesors of GPUs will do. I'll try to search more in this regard.
| QUOTE | I'm not sure if you aren't aiming a little high if you have very little experience with coding...
|
I agree, but the truth is, I am a smart, but a very lazy guy. I have followed most advances in video encoding for the last 7-8 years without getting involved. I'm counting on the fact that having deadlines and marks now will force me to finally achieve something.
The other helpful thing is I live in the middle east, and graduation projects here are a joke, and our Professor is dying to see some innovation. Even if I fail to achieve my purpose, my professor is still gonna reward me for my hard work, and my project can turn into research " as in I tried this method but it didn't work for the following reasons.."
You see I have to learn, and I have nothing to loose.
Also, I don't intend to replicate all VirtualDub's functionality to utilize the GPU. I am focusing only on transcoding to x.264. This is the goal of my project. Once/if I achieve that, I will decide where I wanna go further from that point, for my personal developement.
I will contact x.264 developers at doom9 and VLAN forums and see what can be done, as you suggested.
Meanwhile it will be very helpful if you can tell me more about previous experiments with CUDA and if there's a way to contact the people involved.
Thank you again for trying to help me.
|
|
| phaeron |
| Posted: Nov 11 2009, 05:43 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The problem with utilizing the GPU for an operation like encoding is that while there are parts that are embarrassingly parallel, there are also parts that are inherently sequential, and those become your bottleneck. Entropy encoding, where coded values are compressed using Huffman or arithmetic encoding, is one such area. If this comprises half of the total operation, even 100 stream processors will not help as the best you can attain is 51% of the time of sequential operation even with perfect distribution of the parallelizable portion amongst the parallel processors.
For your case, I'd recommend (1) not using VirtualDub, and (2) starting with a simpler format like MPEG-1 or H.261. You don't want to get bogged down in issues such as VirtualDub's threading model or how to connect synchronous CPU-based processes with a new asynchronous GPU engine, and if you're looking for innovation, you probably don't want to immediately get bogged down in supporting a lot of non-interesting complexity such as AC prediction. Ideally you'd start with a working encoder with nicely isolated stages such that you can easily replace and test one part, but those are rare.
|
|
| Mk4ever |
| Posted: Nov 11 2009, 06:12 AM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 26447
Joined: 10-November 09
|
Thank you for your reply.
The thing is, in my project proposal, I specified the x.264 codec. I'm stuck with that part, even if it's not such a good idea with my programming skills.
Would you recommend a specific software to look at the code? Would you suggest writing a simple cli program from scratch, where it takes the video decoded from DXVA utilizing GPU directly (which means less coding for me on the decoding part), and then I do the programming for the encoding part?
If I can trust my ability to read in between the lines, I guess you are confirming the fact the utilizing many processors is optimization at the codec level more than the program itself, which means I must get involved most with x.264 developers. Did I get this part right?
On a side note, as I understood from the notes with OpenCL released recently from ATI, the SDK supports using both GPU and CPU. I am still not sure though if the compiler will automatically optimize specific parts of the code to different types of hardware. If it can be done automatically, or if some experienced developer can help me with such optimization (ie, parts that need parallelism are handled by GPU and the rest is handled by the CPU), I believe the overall result will be faster, unless there's something I am missing?
Again thank you for your help. Your work with VirtualDub has a great influence on me. I really appreciate that you dedicate a part of your time to help newbies like me. |
|
|
