Re: [CinCVS] Cinelerra tutorial consolidation project

[Christian Thaeter]

Dale Jovan Thomas wrote:
> Hey Scott and Cinelerra community,
> 
> Thanks for getting that information from Alex. I would like to ask the
> community a broader question.
> 
> I would like to spearhead a Cinelerra tutorial collection and
> restoration project. Let give you a simple outline:
> 
> 1. Collect tutorials that were lost in translation (as was the case with
> Alex's Masks Tutorial)
> 
> 2. Collect other tutorials
> 
> 3. Publish all these tutorials on one central website or place them in a
> wiki format (I do not how to do wiki's, I would need a little help)
> 
> I will pay for the site hosting and domain name of the website. I guess
> it could be something like www.cinetutorials.org
>  or something of that effect.

would be nicer and cheaper to collect them under cinelerra.org, we
already do that and hopefully soon with a better cms/wiki so that the
community can easily maintain the website. see below..

> 
> The only things I would need from the community are:
> 
> 1. Emails and contact information to tutorial creators and or
> maintaners. So that I could make document requests from them.
> 
> 2. Review and critiques of the site, for web usability and etc.
> 
> 3. Discussion and ideas.
> 
> Hopefully this repository can serve as a one stop place, to get all
> Cinelerra tutorials, it can also be set it up for folks to submit to new
> ones. I guess that is where the wiki format comes into play.
> 
> I think a site like this will be critical for the upcoming release of
> Cinelerra 3 :-).

"upcoming" is little bit overenthusiastic. But let me explain what I
plan for cinelerra3:

Cinelerra3 will be completely self-contained, we use git as distributed
revision control system, but this doesn't mean that users have to chase
different sites to gather all parts together. Actually the opposite is
true! We include the *whole* project in a repository with all needed
things, that is the sourcecode, deverlopers documentation, users
documentation, bugtracker etc. this might use the 'submodules' feature
of git later. But this still implies that a full clone of the repository
is the complete project, nothing less. I think it is very important to
work this way. This ensures that the project wont get diverted over
serveral places while still everyone can work on his own private branch
and all information is available freely to the community.

Further and before I continue on cin3 coding I am working on a wiki-like
repository browser for git (extending cgit), this will be finished soon.
You can take a (example) look at
http://www.pipapo.org/cgit?url=git://git.pipapo.org/cinelerra/mob/edit/README.BUILD

Note this is work in progress and not functional yet.

In future this might replace the cinelerra.org website altogether where
the web content is just maintained in a git as well, everything
(website, documentation, code) is wikilike editable (as mob repository;
we dont trust anyonymous commits; there will be some vandalism protection).

Why this way? First anyone can easily contribute to the project, biggier
things as usual, by checking the project out and going the common way
(proprosing changes, pushing them to mob) or just small changes like
website or documentation typo fixes or simple code fixes directly on the
web without bothering about having a local clone, learning git and all
about.

This web editable git unifies wiki and project repository approaches we
will not have syncronization problems with documentation which is kept
on some wiki and documentation which is maintained in the repository,
this is just the same. We can still use wiki markup for some things, or
go the opposite arround and use LaTeX or TeXinfo to generate the webpage
documentation, since it is all part of the project/repository people can
just do it in any desired way, no technical limits which will block anyone.


Christian

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] Cinelerra tutorial consolidation project

[Raffaella Traniello]

Hi Dale!

I'd like to make sure you know the Documentation page on
cv.cinelerra.org that lists Tutorials and HOWTOs. 
http://cvs.cinelerra.org/docs.php

The content of this page is written on the Cinelerra CV Manual too 
http://cvs.cinelerra.org/docs/split_manual_en/cinelerra_cv_manual_en_1.html#SEC6.

The Manual can be improved by editing its wiki version at 
http://cvs.cinelerra.org/docs/wiki/doku.php?id=english_manual:cinelerra_cv_en_1#tutorials

Wiki, Manual and website are kept in sync and regularly updated.

Ciao!
Raffaella





___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] Re: [piksel] Linux Video Editing Discussion

[Christian Thaeter]

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

[Herman Robak]

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

[Jonas Wulff]

> 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

[Christian Thaeter]

[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

Re: [CinCVS] introduction

[Herman Robak]

On Fri, 2007-11-23 at 13:49 -0800, Christian Einfeldt wrote:

> We have 54 hours so far loaded onto the Internet Archive's Digital
> Tipping Point Video Collection.  You can see our raw video here:
> 
> http://www.archive.org/details.php?identifier=digitaltippingpoint
> 
> That footage is raw footage, and will need to be re-rendered before it
> is used in any final project.  It is also much more poorly lighted
> than you are used to, and the audio is also only on one channel, to
> reduce overhead.  We have been to 5 nations and 3 continents on a shoe
> string budget, and so we didn't have the resources to drag lighting
> equipment along.  We shot everything with a Sony PD-170, which is a
> decent pro-sumer piece of equipment.  

 It is.  I have one tip to make the footage easier to work with:

When you are recording scenes that vary in contrast and colour,
such as indoor shots with large windows where the camera moves
around, you should use manual white balance.

Colour balance that suddenly shifts during a clip makes proper
grading much more painful.  Please consider locking the colour
balance for each shot.  Changes _between_ shots are easier to
manage in post-production.

-- 
 Herman Robak


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] introduction

[Valentina Messeri]

hi august,

which cinelerra version did you use there in Bek?

:D kaos.avi Federico gave me was really odd and couldn't import back  
in cinelerra, and according what he told me that was the best you  
could render from cinelerrai'm asking why render raw.dv or raw.mov  
didn't work for you


I think this is main problem

muacks

Vale


На Fri, 23 Nov 2007 22:11:57 +0100
Christian Thaeter <[EMAIL PROTECTED]> записано:


> First, what is the best way to export all to DVD?  I try to render
> MP2, but it has NEVER worked for me.  I find myself rendering to
> RGB and then encoding with ffmpeg(which also has some majore
> quirks)
render to DV or some other high quality master format (mjpeg) and then
reencode to the target format is sadly the suggested way for now.


You may render sound to required format and then render video with
yuv4mpegpipe and with pipe like:
ffmpeg -f yuv4mpegpipe -i - -i /path/to/audo/file -acodec copy -vcodec
xvid -y %

--
Сбт Ноя 24 10:04:27 KRAT 2007
Sat Nov 24 03:04:27 UTC 2007
--
Visit my home page http://www.akhil.nm.ru
(Last update at 19th Nov 22:35)
--
jabber: [EMAIL PROTECTED]
--
Позволь эмоциям быть твоей энергией на пути в бесконечность.
Ахметгалеев Ильдар aka AkhIL
--
Linux artstation 2.6.22-gentoo-r9 #6 PREEMPT Thu Nov 22 12:52:50 KRAT
2007 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux up 1 day,
21:02,  7 users,  load average: 2.69, 2.32, 1.88

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra





http://encosianima.net/


This message was sent using IMP, the Internet Messaging Program.


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra