I've been using transcode for a few months now to convert video (avi etc)
into DVDs. I've got it working pretty reliably after lots of
experimentation. I have two different ways of making a DVD:
1. A standard format DVD (transcode --export_prof dvd, mplex, and
dvdauthor)
2. A set of mpg files that my DVD player lists in a menu and allows me to
select (must be done with constant bitrate or the player freaks out and
crashes).
Anyway... I've noticed a significant speed (FPS) difference in these two
methods. After a bit of testing, I figured it must be because method 1) is
doing a frame resize to match the DVD specs. 2) just uses whatever size
the AVI file is.
That's surely one of reasons, frame resizing doesn't come for free (as in "free beer" ;) ).
Other possible slowdown causes are amount and type of filters used during processing,
as well as codec employed for coding.
At the same time I was messing around with Fedora Core 6 and compiz -- and
I realised that OpenGL was happily whizzing around and resizing images
incredibly quickly (and even anti-aliasing them)... and I wonder if OpenGL
(optional, of course) had even been considered as a way of speeding up
transcoding. In other words: if OpenGL is available... using that to do
image resizing for a start.
Definitively, yes.
using GPU for DSP processing is one of my future interests (see http://www.gpgpu.org).
(That's also a very good kickstart for learning about OpenGL an GPUs).
There already are a few problems in doing that
1) architectural questions, part 1: transcode itself definitively needs some preliminary work
to cleanup infrastructure, solve long-standing bugs, implement long-waited, or just new, features
and so on. We have different priorities than OpenGL hacking righe now.
2) I must (and I'll happily do!) OpenGL and GPGPU programming before to start doing something
really funny :)
3) GPGPU programming isn't itself trivial, and existing frameworks aren't still established enough.
4) I personally don't like so much being more and more dependant on non-free stuff for more and
more tasks
Is it feasible? Would it have any benefit... would having to shift the
data to/from the card negate any speed benefits from offloading it to the
GPU?
...5) architectural questions, part II: the concern taht you've mentioned is one of main of mine.
In order to achieve the maximum speedup, the most processing as is possible should performed
on GPU and on it's memory. This means:
5.1) possibily, decoder and encoder too should run on GPU (that isn't easy without heavy hardware support)
5.2) Video Card must carry large amounts of memory (don't forget that transcode just can't lock exclusively
the videocard, it must be avalaible to X server too...) for frame buffering
And much more :)
How involved would it be to implement... I mean, do you have to know
the intimate details of transcode and OpenGL to even consider implementing
it.
I can probably fit for first requisite, but I surely lack on second one ;)
As I said, I'm a newbie at this stuff so I apologise if this has been
considered or is just, well, wrong.
The idea is really appealing. But it's pretty hard to achieve, IMHO.
Francesco Romani
