2008/2/16, Sami Kallinen <[EMAIL PROTECTED]>: > a few questions and thoughts re cin3, (partially already answered): > > first off: as far as i can see in terms of f(l)oss we have only > playback, 3d and compression pretty well covered at the moment. with > cin3 the ambition is to also cover nles. but that still leaves pro > level grading and compositing not available to my knowledge. would > cin3 architecture be a good base for developing such solutions? > either inside cin3 or as standalone using the same backend/rendering > engine? could imagine such solutions might need different kind of > emphasis, although hope not.
Hi, first of all, just a little Background about who I am and how I am interested cin3 development. I have written and will continue to work on my own Linux video editing software called "Open Movie Editor". Therefore I am not so much interested in the core architecture of cin3, but more in the "peripheral" parts, because I believe that such groundwork is necessary and can benefit current and future video software development in Linux/FLOSS. Hopefully you will see what I mean with this in my comments. ;-) > since the ambition is to build a professional app, will the > architecture allow for following features down the line: > > 1. selectable precision in processing, including floating point for > both in RGB and YUV (or Y'CrCb)? > as far as i understood from cehteh this should not be a problem you mentioned pro level grading and compositing earlier. From a theoretical Point of View, this is not that difficult, a selection of functions to do basic pixel operations on float-based pixel formats FAST, would be a first step into implementing this. For HD and stuff it would be ideal to put that compute intensive stuff to the GPU (OpenGL). Interesting Starting points for GPU based Video Processing are: http://yuvtools.wiki.sourceforge.net/ http://djv.sourceforge.net/ For Rendering, basic operations on float-pixels should be done for a CPU too, here the "trivial" implementation is very easy, a "fast" implementation would likely require SSE and other accelerating CPU functions. Gmerlin has interesting code in that respect: http://gmerlin.sourceforge.net/ And liboil is supposed to have stuff, but I am not convinced of its utility yet: http://liboil.freedesktop.org/wiki/ > 5. multiple format timelines working seamlessly? playback without > rendering (while editing). Playback without rendering is a "difficult" problem for all transformations that can only be done "incrementally", or that need an expensive analysis step. Think of iterative video-filters, accurate motion tracking, adaptive/motionbased pulldown/deinterlacing/timestretching, etc... > 6. some sort of user friendly and high quality intermediate codec > solution for tricky acquisition codecs? libquicktime supports a decent selection of uncompressed yuv codecs, other options include ffv1 and similar codecs in ffmpeg. I also see "Dirac Pro" as an interesting Idea, that is a dirac profile for high quality intermediates. So there are some options readily available. I am not sure though how far dirac pro is already implemented, and if schroedinger (a dirac implementation) can do that profile too. Lagarith would be another option, but as far as I know it has not been ported to Linux just yet, so this would need some work, but as a codec it is open source and supports more color-space options natively than the uncompressed codecs from ffmpeg as mentioned above. Cheers -Richard -- Don't contribute to the Y10K problem! _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
