2007/11/22, Burkhard Plaum <[EMAIL PROTECTED]>: > Should be detected by the source (e.g. the codec). libquicktime usually is > quite reliable when detecting the interlacing mode. For the very few cases, > where a source is misflagged, a simple filter (which does nothing but change > the interlacing flags) would be enough.
The problem is, that misflagged files are quite common, there are for example camcorders that record 24p and put that in a 60i "container" with pulldown, and those are not flagged. So the only option for "automatic" detection is image analysis. Everything else requires human interaction, and a lot of people do not even know about such stuff. > > Possible Problems: > > * Later Editing could introduce sudden changes in pulldown sequence > > Possible Approches: > > * Compare fields, to detect duplicates, which is common in > > pulleddown material. > > IMO pulldown should be detected and removed at the beginning of the pipeline. > It will also speed up things by descreasing the number of images. > Filters might change the image data such that later comparison of fields will > fail. Sure, this is true, no objections. Some clarification to the first Problem: it assumes that the content "was" already edited, be some other means that did not recognize that pulldown was present in the source, and therefore the pulldown cannot be removed by just putting the frames togother again, but instead the whole file needs to be analysed in advance to detect pulldown sequence changes. > > 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. > > Either the algorithms work out of the box with subsampled material > (e.g. Hue, Brightness, Saturation, Contrast, Scaling) or they need to > interpolate (== upsample) the missing chroma values and downsample > them again after processing. > > Now if you have a pipeline of multiple filters, which do > upsampling -> processing -> downsampling it's better to usample at the > beginning of > the pipeline and downsample at the very end (both speed and quality wise). I fully agree, but never the less, having some code available to do whatever is possible without upsampling is desirable in any way. That does not mean that it should be used for any case. > > 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. > > IMO, a pure software solution (in C) should be the *reference* not just > a *fallback*. OpenGL is an optional acceleration (pretty much like MMX > and SSE). > > If you make OpenGL the "default", you will loose the possibility to > use Algorithms (e.g. better scaling methods), which are not available > under GL. Sure, this was actually the intention of the description, but formulated slightly differently. ;-) In any way, the point is that two implementations would be nice, one in C, the other in OpenGL, for all cases, where it is _possible_. The matter of what is then the default or reference can be sorted out in any case. This of course includes that some things are just not implemented in the OpenGL variant (like advanced scaling). Actually the software implementation needs to be complete in any case, because lots of OpenGL capable hardware has not all the features available that would be needed. > > 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. > > This is handled by libquicktime and (AFAIK) by quicktime4linux as well. > Needless to say, that editing temporally compressed sources is suboptimal > to begin with... Indeed it is, but there is no perfect world, and there are camcorders where the native format is temporally compressed, and actually from a "disk-space available" point of view, it makes sense in times where HDV is getting ever more common. > Of course I'm biased here, but I'm pretty sure, that gavl is quite unique > with respect > to it's features. Even if it's suboptimal (in which case I like to know why), > it > saves you a *lot* of work. I fully agree to this, and this is actually why I use gavl. :-) It ROCKS. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
