Re: [CinCVS] Re: [piksel] Linux Video Editing Discussion
Jonas Wulff wrote: >> Generally Richard, Herman and me (et al) agreed that we wan't no bulky >> overloaded supereffects but that it is somewhat essential for free >> software to develop effects which do simple things and then can be >> used to combine new functionality. In this case this means we need: >> 1) an analyzing part which derrives motion vectors maybe even more >> smaller ones for perspective and rotational detection. (cins current >> one does all at once) >> 2) Transform tools which operate on the vectors from 1) again diffrent >> ones (xy, zoom, rotation, perspective) >> >> 3) (not there yet) directional deblurring also using the vectors from >> 1) >> >> >> Christian >> >> >> ___ >> Cinelerra mailing list >> Cinelerra@skolelinux.no >> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra > > Sounds good -- but doesn't that imply the need for a much more > sophisticated plugin API? Otherwise one would need to use very ugly > workarounds to pass more info than just the picture itself... this is just general thinking not about an actual implementation, for cin3 we plan a backend which can cope with this. But we need to draw a line of things which are of general interest (algorithms and implementations) and things which are better left for the implementor of a video editing program, aka not produce yet-another-framework or plugin api. Sometimes the backend can cheat around plugin api deficiencies in other ways there is no way then this api cant be used, maybe improve it or switch to another one, time will show. Christan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [piksel] Linux Video Editing Discussion
On Sat, 2007-11-24 at 20:17 +0100, Jonas Wulff wrote: > > Generally Richard, Herman and me (et al) agreed that we wan't no bulky > > overloaded supereffects but that it is somewhat essential for free > > software to develop effects which do simple things and then can be > > used to combine new functionality. In this case this means we need: > > 1) an analyzing part which derrives motion vectors maybe even more > > smaller ones for perspective and rotational detection. (cins current > > one does all at once) > > 2) Transform tools which operate on the vectors from 1) again diffrent > > ones (xy, zoom, rotation, perspective) > > > > 3) (not there yet) directional deblurring also using the vectors from > > 1) ... > Sounds good -- but doesn't that imply the need for a much more > sophisticated plugin API? Otherwise one would need to use very ugly > workarounds to pass more info than just the picture itself... Some plugins need access to sequences of pictures, not just single pictures. That's all the input there is to begin with; after all, video is just a sequence of images. However, motion and rotation tracking use a lot of CPU time to produce a rather compact set of parameters. There should be a common way to store the output of such "solvers", for quick realtime reuse. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [piksel] Linux Video Editing Discussion
> Generally Richard, Herman and me (et al) agreed that we wan't no bulky > overloaded supereffects but that it is somewhat essential for free > software to develop effects which do simple things and then can be > used to combine new functionality. In this case this means we need: > 1) an analyzing part which derrives motion vectors maybe even more > smaller ones for perspective and rotational detection. (cins current > one does all at once) > 2) Transform tools which operate on the vectors from 1) again diffrent > ones (xy, zoom, rotation, perspective) > > 3) (not there yet) directional deblurring also using the vectors from > 1) > > > Christian > > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra Sounds good -- but doesn't that imply the need for a much more sophisticated plugin API? Otherwise one would need to use very ugly workarounds to pass more info than just the picture itself... ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [piksel] Linux Video Editing Discussion
[EMAIL PROTECTED] wrote: > On Fri, November 16, 2007 15:25, Richard Spindler wrote: >> Hi, >> >> The following document was created today, summarizing the discussion >> points that came up today, during an effort to create an overview about >> the problems where linux video editing is still without solution. >> >> Have fun, >> -Richard >> >> >> >> ---8<- >> Linux Video Editing: >> Open Problems >> >> >> Problem #1: Detect Interlacing in Videofiles/streams, through Image >> Analysis >> Subproblems: >> * Detect 3x2 Pulldown, vs. Video. >> * Topfield first vs. Bottomfield first. >> Relevant Links: >> * http://silicontrip.net/~mark/lavtools/ >> Possible Problems: >> * Later Editing could introduce sudden changes in pulldown sequence >> Possible Approches: >> * Compare fields, to detect duplicates, which is common in pulleddown >> material. >> * Look at deinterlacers in MPlayer etc. >> Unsolvable: Put a 60i Overlay, (Titles) on a 3x2 Pulldown source. >> >> Problem #2: Develop Algorithms and Processing code, for not-upsampled YUV >> 4:2:0 or 4:1:1 Source Footage. Common Filters and Operations. >> Chroma-Keyers, etc. >> >> Problem #3: Interaction between Cinelerra/Linux Video Editing, and >> Scientific Community, Research on Image-Processing, Algorithms, etc. Have >> someone that reviews scientific Papers for their relevance for Video >> Editing. >> >> Problem #4: General Purpose Image Processing Library, accellerated using >> OpenGL Graphics Hardware. >> Ideas: Processing Graph, Automating Parameters, Different Colorspaces, >> Packed vs. Unpacked, Software Fallbacks for unavailable Hardware features, >> Scaling, Aspect-Ratios, Interlacing, take model of OpenGL Shaders into >> account. >> >> Problem #5: Simple Control Protocol, most likely OSC, because it is widely >> used in the Audio Community. Jack-Transport for Playback Syncronization. >> Subproblems: >> * Jog-Dial Support/Daemon over OSC? >> * Hardware-Support, Slider-Decks, Knobs, etc. >> * MIDI to OSC? >> >> Problem #6: Temporally compressed Video processing, MPEG, GOPs >> Subproblem 1#: „Give me Frame 10“! No matter whether B, P or I >> Frame. No consideration of Performance. >> * Consider Memory Mapping Compressed Files, reusing kernel file cache >> * Fast-Forward, Seeking, Scrubbing, Sustained, illusion of instant >> access >> * Sparse fetching of compressed GOPs. >> * Detect and reproduce bitrates and stream restrictions (think: export >> to devices) >> * „clever“ reencoding around cuts, collapse GOPs if necessary? >> * (Keyframe marker in UI) >> * Index Building (File index, endianess neutral) >> >> Problem #7: Detect scene changes in footage, with image processing >> >> Problem #8: Multiprocessing: Multicore, Distributed. Research? >> * Distributing footage (e.g. NFS) vs. homebrow protocol >> * Review Scientific Papers to multiprocessing >> * Is abstraction between Multicore vs. Distribution possible. >> * Compression on Render nodes, means Network capacitiy is no bottleneck. >> * One GOP per Node? >> * Lossless Codec? >> * Failure Tolerance? Crashing Nodes? Failover? >> * Adding Node? Network Autodetection Avahi, Zeroconf? >> * Endianess, Different Operating Systems, Distributions. >> >> Simple Tasks: >> * Make Youtube simple uploader program in C with libcurl >> >> Problems that still need Discussion: >> * Intermediate Formats >> * Plugin generation >> > > > I'd like to add a couple of things: > > - shake elimination : to remove shaking of the caamera - using image > analysis to line up one frame with the next Works fine in cinelerra. A improvement would be to generate motion vectors and use this vectors to reduces the motion blur. Generally Richard, Herman and me (et al) agreed that we wan't no bulky overloaded supereffects but that it is somewhat essential for free software to develop effects which do simple things and then can be used to combine new functionality. In this case this means we need: 1) an analyzing part which derrives motion vectors maybe even more smaller ones for perspective and rotational detection. (cins current one does all at once) 2) Transform tools which operate on the vectors from 1) again diffrent ones (xy, zoom, rotation, perspective) 3) (not there yet) directional deblurring also using the vectors from 1) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
