Weekly Edition
Return to the Press page
| |||||||||||
|
| |||||||||||
Linux for Video Production (O'ReillyNet)
Jono Bacon examines
the present and future of video production with Linux and open source
software, on O'ReillyNet. "At the GNOME User And Developers European
Conference (GUADEC) in Stuttgart, Germany, PiTiVi was one of the most
promising applications demonstrated. Currently being developed by
French-born Edward Hervey, PiTiVi offers a refreshing outlook for video
production on Linux. Hervey's goals for PiTiVi have been clear from the
beginning. His intention was to create a simple, intuitive, and powerful
editor that can be useful for both home and professional needs."
(Log in to post comments)
Linux for Video Production (O'ReillyNet) Posted Aug 19, 2005 17:40 UTC (Fri) by lolando (subscriber, #7139) [Link] The way I read that article, and after browsing the PiTiVi website, Jono Bacon briefly mentions the working present and then goes on to be very emphatic about what PiTiVi will (no doubt) bring in the future. Sad though I am that Kino is apparently getting stale, and even though I'd be perfectly amenable to switch to some other app, PiTiVi's feature list seems to make it little more than a video player for now. Okay, one with a library, so make it the video equivalent of F-Spot maybe, rather than just Eye of Gnome, but still far from Kino, which is said to be "too simple for many video editing requirements".
It almost sounds like a marketing leaflet.
Linux for Video Production (O'ReillyNet) Posted Aug 19, 2005 18:42 UTC (Fri) by cantsin (guest, #4420) [Link] I have my doubts about the project, too, because it's coded in Python.While the gstreamer backend is written in C, it's not even mature enough at this point to handle mere playback of audio/video files better than mplayer or libxine. Video editing and compositing is a much more demanding task. If gstreamer hasn't been designed for this from the beginning on, I doubt that bolting on such functionality will work. And even if it should, video editing even in NTSC/PAL resolution is so CPU-intensive that having parts of the program run Python sounds like a really, really bad idea. On the DTP front, for example, Scribus conversely started off as a Python program, but switched to C++ once it matured into a serious work application. This announcement sounds like so many Sourceforge vaporware projects that I would put at least three question marks behind it. Although I wouldn't mind being positively surprised.
Python Posted Aug 19, 2005 21:21 UTC (Fri) by dmarti (subscriber, #11625) [Link] You can write software radios in Python using GNU Radio, which is a mix of Python and C++. Software radio is even more CPU-intensive than video editing. Why not use Python for the parts that don't have to be super-fast?
Linux for Video Production (O'ReillyNet) Posted Aug 19, 2005 22:48 UTC (Fri) by jwb (guest, #15467) [Link] The complete lack of video editing software written in C should tip you off to how easy that kind of project would be. A video editing suite has a lot of codecs and data moving, to be sure, but 99% of the programming work is done in the interface. And if you've ever programmed, for example, GTK+ to the C API, you know it's just line after line after line of strcmp this, malloc that. Python is far more productive with pygtk!
I really don't think any project should be judged by its implementation details. In fact, when I see a project that describes itself as "Foobar 2.0 is a multithreaded C++ application ..." I know I shouldn't use it, because the developer is more interested in *how* the program is written than the features it has.
Linux for Video Production (O'ReillyNet) Posted Aug 20, 2005 5:43 UTC (Sat) by djabsolut (guest, #12799) [Link] There is a quasi-compiler for Python called Psyco (http://psyco.sourceforge.net) which provides considerable speedups (2x to 3x in my experience).
Linux for Video Production (O'ReillyNet) Posted Aug 20, 2005 7:29 UTC (Sat) by drag (subscriber, #31333) [Link] Psyco can offer _some_ very nice acceleration for Python apps... but at expense for memory usage...
Which isn't a bad thing. Python's garbage collector is very agressive and Python program's average memory usage is MUCH smaller then something like Java or .NET even.
The problem with having a x2 to x3 speed up is that it's still very much slower then (good) c/c++ programming. (it's a hell of a lot faster then bad c/c++ programming)
The problem with saying something like 'Oh, it's using python so it much be slow' is because it's a very ignorant (and forgivable) statement.
What is missing is a understanding of python-style developement for applications that require good speed, which is basicly that you don't program in python when speed matters, you program in C or C++ and then incorpate that functionality as code into your larger python-based program.
What you generally do is initially write out your program in Python and using pre-made/tested/optimized modules/frameworks from third parties were appropriate. Then after you get it 'correct', or close enough to what you want and have it provide the functionality you want, then you break out the profiler and study what parts of the programs are taking the most time to accomplish.
Typically the majority of the program consumes the minority of the resources.. it's certain things, certain parts of the program that end up being time-critical. You rewrite those parts that are causing the slow-downs as modules in C/C++ code.
Then everytime you want to make a change you don't have to recompile the entire stupid thing.. end users have much more access to the code so they can 'fix' problems themselves. Then the important parts are written in C and are designed to only take specific inputs from the python stuff, proccess as fast as possible, and then give specific outputs that can be intellegently delt with by the python code.
In this specific application's case, PiTiVi, Python may make a good choice. A bad UI written in C is going to slow down users much more then a good UI in python (that would also be easily modifiable and scriptable if done correctly). At it's core it's going to depend on gstreamer to do the heavy lifting... And that's definately not written in Python and should be just as fast as any other C code. So it all depends on how robust gstreamer will be. (will I like gstreamer idea's alot.. I still can't get it to run totem on powerpc without crashing)
Linux for Video Production (O'ReillyNet) Posted Aug 20, 2005 8:05 UTC (Sat) by cantsin (guest, #4420) [Link] I see and understand you point. But since video editing is a realtime task, only the trivial parts - i.e. only the GUI - of the application could be coded in Python. One should consider that Cinelerra, a program written in C++, recommends the use of Dual Opterons in connection with a 16-node cluster to do realtime compositing and editing. It seems highly speculative on behalf of the programmer to expect that those critical parts of the program will be simply provided by gstreamer (a framework that at the moment isn't even mature for multimedia playback) and a number of plugins, and that the realtime arbitration between them and gstreamer will be handled by the Python frontend. It might be feasible at the moment to writer a multimedia player frontend in Python using libxine/mplayer/gstreamer as backend at this moment, but I don't see video editing being feasible this way.
Linux for Video Production (O'ReillyNet) Posted Aug 20, 2005 11:23 UTC (Sat) by cantsin (guest, #4420) [Link] Sorry, I should have written:...feasible this way any time soon.
Linux for Video Production (O'ReillyNet) Posted Aug 20, 2005 11:57 UTC (Sat) by drag (subscriber, #31333) [Link] Well I agree with you entirely.
All of it rests on the shoulders of gstreamer framework.
Be aware that the framework was designed for this sort of thing from the beginning more or less.. It's not intended just for playback but for the specific ability to pipe data between plugins/whatever... Use filters, transcoders and codecs like Bash uses grep, sed, and awk.
The python, I expect is just for "glue" to allow a easy way for end users to start, stop, and connect gstreamer's various parts together in a convient manner. I doubt that python will handle the data in any serious way... Maybe for small specialized tasks and such.
Other examples of people using python in programs would be stuff like Panda3d. (which is open source) It's used in a few commercial games and is designed specificly to work with python. There is a python scripting framework for Blender (which itself is increadably powerfull and fast) that people are using to do some very advanced things, like modelling based on bitmaps or whatnot while also making it easier for normal people to write stuff like import and export scripts. And of course script-foo for the Gimp and such.
Also don't forget that Google uses Python in their stuff, and Zope is used on some very busy commercial sites.
But for this paticular thing to succeed it all depends on gstreamer. They could of just as easily used Mono and .NET or Java instead of python for all that matters. (although obviously I like python a lot)
Linux for Video Production (O'ReillyNet) Posted Aug 25, 2005 9:13 UTC (Thu) by wingo (subscriber, #26929) [Link] Hi cantsin,
A few points about your comment.
First, the fact that it is coded in python is an incredible advantage. Edward has been able to do some wonderful experimenting with different UI ideas, which is just not feasible when writing GUIs in C. At the very least it would have given him a design which could be rewritten in C later, but as it turns out the GUI doesn't take much processing power at all.
The reason no time is spent running Python is because GStreamer handles all of the processing. GStreamer was designed for this sort of thing from the beginning; playback was just one of the cases. Your bad experience with GStreamer probably results from some, er, "sub-optimal" design decisions in 0.8, which we have fixed in the development series.
Finally, it is true that, due to the rewrite, PiTiVi doesn't do much more than transcode and concatenate at the moment, and that the GStreamer version it depends on is still in a development cycle (although finishing up). But it does mean something that Fluendo has hired him just to hack PiTiVi (as free software!) -- we think the project has enormous potential.
(Sorry for the pseudo-marketing speak, and no Fluendo didn't ask for the article -- I'll get back to hacking now ;)
|
|||||||||||