--- Log opened Fri Feb 01 00:00:29 2008
00:02 < Velmont> Maybe PING can host... :-)
00:02 < oracle2025_> lol
00:03 < raffa> Hostping service
00:03 < Velmont> Wow, shit.
00:03 < Velmont> I didn't see that.
00:04 < Velmont> PING is my student union at university.
00:04 < Velmont> We do hosting. ;p
00:04 < oracle2025_> really?
00:04 < Velmont> (not really, but we do anyway)
00:04 < Velmont> We're mostly social etc. 
00:04 < Velmont> But I'm an admin; so I can always be responible for hosting Cinelerra-stuff.
00:04 < hermanr_> I don't think PING will like our big files, large and numerous automatic builds and fat downloads.
00:05 < hermanr_> Velmont: Hmmm
00:05 < hermanr_> Like, large test videos?
00:05 < Velmont> hermanr_: Well, then we can fix a dedicated server. And anyway; it's the university's bandwidth. :]
00:06 < hermanr_> We need automatic builds and regression tests (some of them may require qemu images; CPU-heavy!)
00:06 < Velmont> But; I got to go - someone is not happy that I'm sitting here. --- I'll talk with some people at PING tomorrow (if I meet them).
00:07 < hermanr_> Thanks, Odin.
00:07 < Velmont> hermanr_: Yes, we need 7000NOK for a heavy server then. ;-) 
00:07 < Velmont> Or we can just get something a bit less sexy for free.
00:07 < hermanr_> A hosting provider may be cheaper.
00:07 < hermanr_> ..._will_ be cheaper.
00:07 < Velmont> I'm not so sure. We'll see and find out.
00:14 -!- raffa [n=raffa@212.45.157.169] has left #openvideo ["Konversation terminated!"]
00:23 -!- malefic-o [n=malefico@200.127.125.71] has joined #openvideo
00:44 < hermanr_> https://lists.riseup.net/www/arc/estudiolivre/2008-01/msg00428.html
00:53 -!- malefic-o [n=malefico@200.127.125.71] has quit [Excess Flood]
00:56 -!- malefic-o [n=malefico@200.127.125.71] has joined #openvideo
01:26 < hermanr_> Velmont: http://ingex.sourceforge.net./P2_structure.html
01:32 -!- malefic-o [n=malefico@200.127.125.71] has quit [Excess Flood]
01:32 -!- malefic-o [n=malefico@200.127.125.71] has joined #openvideo
01:38 -!- goibhniu [n=cillian@87-194-222-145.bethere.co.uk] has quit [Connection timed out]
02:09 -!- oracle2025_ [n=oracle@85.124.47.133] has quit ["Ex-Chat"]
02:28 -!- malefic-o [n=malefico@200.127.125.71] has left #openvideo ["I'll be around..."]
02:33 < hermanr_> http://womble.decadent.org.uk/tmp/lca_mm_2008_slides_dirac.odp
03:03 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #openvideo
03:49 -!- ichthyo [n=hiv@p5B0C12DE.dip0.t-ipconnect.de] has quit ["bye bye ..."]
05:35 -!- tim168 [n=tim@d515380C9.access.telenet.be] has joined #openvideo
06:47 -!- hermanr_ [n=herman@cC95DBF51.dhcp.bluecom.no] has quit [Read error: 60 (Operation timed out)]
07:45 -!- aalex [n=aalex@modemcable208.158-57-74.mc.videotron.ca] has quit ["This computer has gone to sleep"]
07:51 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 113 (No route to host)]
09:08 -!- wimo [n=lucas@250.Red-83-61-113.dynamicIP.rima-tde.net] has joined #openvideo
10:28 -!- luisbg_ [n=luisbg@212.145.71.119] has joined #openvideo
10:44 -!- goibhniu [n=cillian@87-194-222-145.bethere.co.uk] has joined #openvideo
11:57 -!- bilboed [n=bilboed@pdpc/supporter/active/bilboed] has joined #openvideo
11:57 < bilboed> damn, wished I knew this channel existed before :)
11:57  * bilboed waves to all
12:02 < bilboed> I need to get round at wrapping gavl in gstreamer at some point
12:08 < b0ef> is there supposed to be a meeting, today?
12:09 < bilboed> a 9pm GMT apparently
12:10 < b0ef> aiight, thanks
12:13 -!- baver [n=baver@196.1.52.58] has joined #openvideo
12:17 -!- goibhniu [n=cillian@87-194-222-145.bethere.co.uk] has quit [Read error: 110 (Connection timed out)]
12:21 -!- raffa [n=raffa@212.45.157.169] has joined #openvideo
12:47 -!- raffa [n=raffa@212.45.157.169] has quit [Remote closed the connection]
12:57 -!- kilonux [n=frode@jau72-2-88-164-44-51.fbx.proxad.net] has joined #openvideo
12:59 -!- baver [n=baver@196.1.52.58] has quit [Read error: 113 (No route to host)]
13:00 < kilonux> hello, I try to pick some parts of a home-recorded dvd in order to make a compilation, 
13:00 < kilonux> -- problems with splitting them 
13:04 -!- j^ [n=j@cl-732.ham-01.de.sixxs.net] has quit [Remote closed the connection]
13:13 -!- zap0 [n=zap0@203-217-85-178.dyn.iinet.net.au] has joined #openvideo
13:23 -!- hermanr_ [n=herman@cC95DBF51.dhcp.bluecom.no] has joined #openvideo
13:24 -!- goibhniu [n=cillian@host81-159-234-166.range81-159.btcentralplus.com] has joined #openvideo
13:49 -!- zap1 [n=zap0@203-217-91-46.dyn.iinet.net.au] has joined #openvideo
13:49 < cehteh> eh
14:04 -!- zap0 [n=zap0@203-217-85-178.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
14:12 < cehteh> no much topics added for the meeting .. any more ideas?
14:20 < hermanr_> Not at the moment
14:22 -!- kilonux [n=frode@jau72-2-88-164-44-51.fbx.proxad.net] has quit ["Man skal jo koble av av og til"]
14:24 -!- luisbg_ [n=luisbg@212.145.71.119] has quit [Connection timed out]
14:32 -!- goibhniu [n=cillian@host81-159-234-166.range81-159.btcentralplus.com] has quit [Read error: 110 (Connection timed out)]
14:34 -!- goibhniu [n=cillian@80.176.191.147] has joined #openvideo
14:57 -!- wimo [n=lucas@250.Red-83-61-113.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
15:11 < zap1> meeting?
15:12 < hermanr_> zap1: 21:00 UTC
15:12 < hermanr_> Almost 7 hours to go.
15:12 < zap1> oh ok.
15:12 < zap1> is there a schedule/agenda ?
15:12 < hermanr_> Sorta...
15:13 < hermanr_> http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/MonthlyDeveloperMeetingOnIRC
15:14 -!- aalex [n=aalex@modemcable208.158-57-74.mc.videotron.ca] has joined #openvideo
15:14 -!- mode/#openvideo [+o hermanr_] by ChanServ
15:14 < cehteh> http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings   better that page
15:15 -!- hermanr_ changed the topic of #openvideo to: About Free Software for video | Meeting at 21:00 UTC today, agenda:
15:15 -!- hermanr_ changed the topic of #openvideo to: About Free Software for video | Meeting at 21:00 UTC today, agenda: http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/MonthlyDeveloperMeetingOnIRC
15:16 -!- hermanr_ changed the topic of #openvideo to: Meeting 21:00 UTC today: http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/MonthlyDeveloperMeetingOnIRC
15:17 -!- hermanr_ changed the topic of #openvideo to: Meeting 21:00 UTC today: http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings
15:18 -!- mode/#openvideo [-o hermanr_] by hermanr_
15:20 < zap1> 21-11 = 10, now 1.30.. 10-1.3 is about 8.5hours from now.. ?
15:22 < hermanr_> Yup.
15:22 < hermanr_> Get some sleep first ;-)
15:23 < hermanr_> AkhIL, our guy in Remotistan will not attend.
15:26 -!- tester [n=tester@123.117.11.135] has joined #openvideo
15:32 < cehteh> Remotistan :)
15:33 < hermanr_> It's next to the kingdom Far, Far Away.
15:34 < cehteh> but still not down-under :)
15:35 < cehteh> hermanr_: what do you mean with '/ my fair share'
15:36 < hermanr_> cehteh: That's negotiable :-P
15:37 < cehteh> i mean .. this prices where meant only as suggestion ... yes they are alle meant to be negitiated
15:37 < cehteh> just an idea what everyone thinks
15:37 < cehteh> its not final
15:38 < hermanr_> I can afford 15 Euros a month, probably more, too.  However, my willingness may depend on what we get for the money.
15:38 < hermanr_> All of the above is pretty obvious.
15:39 < cehteh> another friend of me prolly only want a small personal website .. i suggested he can enter 5eur for that .. after all i we should acknowledge between us what we run and so on the servers
15:40 < cehteh> that could save a lot of resources and money when we work together and not everyone just does his own stuff in his single vserver
15:40 < cehteh> extra ip's and ipv6 is quite expensive at hetzner
15:41 < cehteh> .. i am open for suggestions of other hosters too, but so far i didnt seen a good alternative
15:42 -!- Gasten [n=Gasten@h198n7c1o1095.bredband.skanova.com] has joined #openvideo
15:44 < hermanr_> cehteh: So?  IPv6 is still "special"?
15:44 < hermanr_> That may change sooner than we expected.
15:44 < cehteh> only at hetzner .. :/
15:44 < cehteh> 29eur/month
15:44  * hermanr_ rolls eyes
15:45 < cehteh> i expect they have to drop that price or even make it free someday ... but i wont gurantee that
15:45 < hermanr_> They probably have an expensive tunnel broker providing IPv6 to them.
15:45 < cehteh> other hosters have ipv6 for free .. but only 1 ip and lots of other limitations
15:45 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has joined #openvideo
15:45 < cehteh> my isp has native ipv6 .. but hosting is quite expensive there
15:46 < cehteh> http://www.1und1.info/xml/order/ServerRoot  another one also not as good as hetzner for our purposes
15:48 < hermanr_> Velmont: What did you fellow PINGers say about hosting?
15:49 < hermanr_> We don't _need_ IPv6 for our purposes, as far as I can tell.
15:49 < cehteh> yes .. that was my thinking too
15:49 < hermanr_> But it would be nice with a /16 mask of addresses instead of just a handful :->
15:49 < cehteh> and the day we really need ipv6 prices will be dropped
15:50 < cehteh> thats a problem .. only 6 IP's at hetzner by default
15:50 < cehteh> more cost extra
15:51 < hermanr_> Oh, well.  Do you want more than five entities there anyway?
15:52 < hermanr_> pipapo, OME, cinCV, cin3 ?
15:52 < cehteh> yes .. but not each entity needs its own ip
15:52 < hermanr_> Sure, they don't.
15:52 < cehteh> more people less cost
15:53 < cehteh> and websites can be hosted by one front apache/ip
15:53 < hermanr_> But those who share IP need to cooperate more closely.
15:53 < cehteh> maybe forwareded internaly to customized webservers 
15:53 < cehteh> or put a reverse squid in front
15:53 < hermanr_> (just like our piggybacking on Skolelinux)
15:54 < cehteh> yes i want to make it cooperative
15:54 < hermanr_> Still, you need cooperation.
15:54 < hermanr_> And I'd consider whom have a natural interest in intimate cooperation, and who have not.
15:54 < cehteh> means when we have a single frontend DNS, MX, Apache .. then everyone in the crowed gets access, prolly even root access 
15:54 < hermanr_> hmmm...
15:55 < hermanr_> Too many cooks!
15:55 < cehteh> (on that vserver, not on the host box)
15:55 < cehteh> the content itself shall be in personal vservers .. so accessing that frontend servers is just a emergency or gobal configuration case
15:56 < hermanr_> Maybe a reverse Squid would be a Good Thing...  It provides an extra layer for attackers to poke through.
15:56 < cehteh> root access for the underlying host server has only me and 1 or 2 other trusted persons
15:57 -!- pabs3 [i=pabs@d122-105-76-173.per9.wa.optusnet.com.au] has quit [Remote closed the connection]
16:01 -!- pabs3 [i=pabs@d122-105-76-173.per9.wa.optusnet.com.au] has joined #openvideo
16:02 -!- goibhniu [n=cillian@80.176.191.147] has quit [Read error: 110 (Connection timed out)]
16:21 -!- tester [n=tester@123.117.11.135] has quit [Remote closed the connection]
16:22 -!- limoo1 [n=officine@ppp-9-70.29-151.libero.it] has joined #openvideo
16:30 -!- goibhniu [n=cillian@87-194-222-145.bethere.co.uk] has joined #openvideo
16:31 -!- hermanr_ [n=herman@cC95DBF51.dhcp.bluecom.no] has quit [Read error: 110 (Connection timed out)]
16:35 -!- Gasten [n=Gasten@h198n7c1o1095.bredband.skanova.com] has quit [Remote closed the connection]
17:03 -!- hermanr_ [n=herman@cC95DBF51.dhcp.bluecom.no] has joined #openvideo
17:25 -!- aalex [n=aalex@modemcable208.158-57-74.mc.videotron.ca] has quit ["This computer has gone to sleep"]
17:35 -!- brad_up [n=brad@m7b0e36d0.tmodns.net] has joined #openvideo
17:40 -!- brad_up [n=brad@m7b0e36d0.tmodns.net] has quit [Read error: 104 (Connection reset by peer)]
17:40 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has quit [Read error: 104 (Connection reset by peer)]
17:50 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has joined #openvideo
18:41 -!- bilboed [n=bilboed@pdpc/supporter/active/bilboed] has quit ["No! Don't pull that plu..."]
18:45 -!- h01ger [n=holger@socket.layer-acht.org] has joined #openvideo
18:45 < h01ger> hi 
18:46 < hermanr_> 'nabend, Holger.
18:47 < h01ger> hey hermanr_ 
18:47 < hermanr_> We are still finding our feet here.  Maybe this meeting will make things more clear.
18:50  * h01ger will not attend but read backlog. just arrived in narvik at the debian edu gathering... 
18:51 < cehteh> i suggested to write a protocol afterwards, as well as publishing the log
18:54 < hermanr_> h01ger: Cool.  Give them my regards. :-)
18:54 < hermanr_> FYI, Narvik is in Northern Norway, waaay up North.
18:56 -!- brad_up [n=brad@m7b0e36d0.tmodns.net] has joined #openvideo
18:58 < h01ger> if you want me, i can send meetbot here, who will keep logs and supply notes. see meetbot.debian.net for a howto and http://meetbot.debian.net/meetbot/debian-edu.20080121_1900.html for an example of the notes created
18:58 < h01ger> it needs a human chair so, who tells meetbot the topics, the agreements and so on
18:58 -!- gmerlin [n=pix@p5B16636F.dip.t-dialin.net] has joined #openvideo
18:58 < hermanr_> cehteh: Your call
18:59 < gmerlin> Hi
18:59 < hermanr_> gmerlin: Burkhard?
18:59 < gmerlin> Yes
18:59 < hermanr_> Welcome! :-)
18:59 < cehteh> welcome
18:59 < gmerlin> We're early :)
19:00 < cehteh> nah .. you are early, we are always here :P
19:00 < gmerlin> I usually don't do IRC
19:00 < cehteh> any ideas about more topics/agenda?
19:01 < gmerlin> No, but some ideas about the topics
19:01 < cehteh> http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings  just add it there
19:02 < gmerlin> Ahh, I forgot that URL
19:02 < gmerlin> Can't this protocol be an IRC log?
19:02 < cehteh> i hate reading irc logs too much noise
19:03 < gmerlin> That's true
19:03 < cehteh> if noone else does it, i will make a few lines protocol
19:03 < cehteh> actually only conclusions and plans shall be noted and some quotes about the rationales behind
19:03 < gmerlin> I guess noone will object :)
19:04 < cehteh> well .. if someone else does it, i wont object either :)
19:04 < gmerlin> I don't care about the name as long as it's not offensive
19:04 < cehteh> but it would be nice to have such protocols for future
19:05 < cehteh> and they could be send to the ML as well then everyone gets briefed
19:06 < gmerlin> 3. Who works on what, what are the short term goals
19:06 < gmerlin> I think I can do a lot in the data backend
19:07 < cehteh> thats what i want to continue soon
19:07 < gmerlin> IMO that parameter stuff is important right now
19:08 < cehteh> wait a moment i am back in a few minutes then i can explain you what i planned so far
19:08 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has quit [Read error: 110 (Connection timed out)]
19:14 < cehteh> so back
19:15 < gmerlin> I'm mostly interested in the plugin-side
19:15 < cehteh> the memory backend doesnt know anything about video/parameters, it just manages buffers
19:15 < gmerlin> A/V buffers?
19:15 < cehteh> whatever .. 'buffers' 
19:16 < cehteh> these could be video or audio frames, metadata
19:16 < gmerlin> parameters?
19:16 < cehteh> parameters to effects? .. could be cached in the backend
19:17 < gmerlin> parameters for inputs are also important
19:17 < cehteh> actually it manages streams of such buffers and the render core can define "i need such a buffer here"
19:18 < gmerlin> Then the the data backend decides what to do...
19:18 < cehteh> basically it just manages data .. there is some slight difference between things which will only be read
19:18 < cehteh> things which will be written .. and writing in place or via a small write chache
19:19 < gmerlin> I think I understand...
19:19 < cehteh> all this buffers are mmaped buffers, either temporarly or in case of real existing footage directly/readonly
19:19 < cehteh> indices for footage will also be a stream of such small buffers
19:20 < cehteh> each buffer can have some metadata, you can invalidate buffers when parameters change and so on
19:21 < cehteh> we speak about frames when we mean buffers since thats what they are most used for
19:21 < gmerlin> This will need LOTS of filedescriptors or not?
19:21 < cehteh> but you can use them for other data too
19:21 < cehteh> yes there is a file-descriptor cache and management .. we want to support to use more than FD_MAX files anyways
19:22 < cehteh> mmap() ing doesnt cost descriptors actually you can close the fd after you mapped something only need to reopen it when you want to change the mmaping
19:22 < cehteh> (wich will be done on a most-frequently used base, only closing things when needed)
19:23 < gmerlin> Is this better than trusting the kernel swapping?
19:24 < cehteh> the performance is the same, but we dont need to copy footage into kernel swap and the buffers can be persistent
19:24 -!- Gregor__ [n=gregor@xdsl-87-78-113-15.netcologne.de] has joined #openvideo
19:24 < cehteh> gives more control 
19:24 < gmerlin> Ahh, ok.
19:24 < cehteh> and better memory utilization
19:25 < cehteh> imagine the normal scenario where you malloc() a buffer and then read() data into it
19:25 < cehteh> that means malloc() takes some pages, then the read initiates some DMA to move data from the hd into kernel space
19:25 -!- gordonjcp [n=gordonjc@symmetria.fi] has joined #openvideo
19:25 < cehteh> and then the kernel copies it into your malloced area
19:27 < cehteh> with mmaping this memory is always in kernel space and just maped into your application, saves an unnecessary copy and halves the memory usage (well one half are kernel buffers which would be droped when needed)
19:27 < gmerlin> Sounds reasonable
19:28 < hermanr_> It kinda matters with multi-GB files.
19:29 < cehteh> another question .. can gavl handle single channels or only frames?
19:30 < gmerlin> Multichannel Frames. But splitting them into 1-channel frames is trivial
19:30  * cehteh would like if he can assemble a frame from diffrent channel data
19:31 < cehteh> i had the idea for things like YUVAZ ... where Z is a depth, layering and such
19:31 < hermanr_> colour and alpha channels?
19:31 < cehteh> also we want to be able to route channels diffrently
19:31 < gmerlin> A routine gavl_audio_frame_copy_channel() would be easy to write
19:31 < hermanr_> RGBxy, where x and y are motion vectors :->
19:31 < cehteh> hehe
19:31 < cehteh> yes
19:32 < gmerlin> You give indices of the src and dst channel
19:32 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has joined #openvideo
19:32 < cehteh> and maybe carefully design some custom color models which can be used internally
19:32 < cehteh> subsampling too
19:33 < gmerlin> Imo a grayscale format is the most important.
19:33 < hermanr_> caching of motion vectors... (expensive to compute)
19:33 < gmerlin> One value per pixel, in int8, int16 and float
19:33 < gmerlin> Then you can to what you want with them
19:33 < cehteh> hermanr_: this would be frames in our methology ... just only containing float x; float y; ...
19:33 < cehteh> maybe rotation
19:34 < cehteh> or do you mean per-pixel?
19:34 < cehteh> then no rotation :)
19:34 < hermanr_> cehteh: Per-pixel if needed, or if available.
19:35 < hermanr_> Prolly with some Level of Detail smartness.
19:35 < cehteh> as richard pointed out, the requirements for a global motion tracker (stabilizer) and a local motion tracker (motion interpolation) are quite different
19:35 < gmerlin> Actually, completly abstractred colormodel definition would prevent writing optimized rotuines
19:36 < cehteh> gmerlin: yes
19:37 < gmerlin> Additional frames with one float per pixel each are ok to store motion vectors or whatever
19:37 < cehteh> in long term we also thinking about throwing most frames out ... imagine a render pipe definition which is translated to a pure function which defines how input pixels are mapped to output pixels
19:37 < hermanr_> cehteh: Most motion estimation solvers don't calculate vectors for every pixel.  So RGBxy would often be wasteful.
19:38 < cehteh> not apply effect on input frame to produce outpur frame over and over
19:38 < cehteh> hermanr_: some kind of tree structure comes in mind
19:38  * hermanr_ nods
19:39 < gmerlin> I think I'll add grayscale, YUVA16 and float YUV(A)
19:40 < cehteh> how about YUV+x   where x can be independently defined?
19:41 < gmerlin> Then the next wants YUV+x+y....
19:41 < cehteh> yes
19:41 < cehteh> x was meant as could be  (x+y)
19:41 < gmerlin> 1 cinelerra frame == 1 colordata frame + n aux frames
19:42 < gmerlin> There's no need to define these inside gavl
19:42 < cehteh> ok
19:42 < gmerlin> I want to keep this as clean as possible :)
19:43 < cehteh> weird formats like   YfloatU16V16A8 4:2:2 or such? ... 
19:44 < gmerlin> And if you want rescale such aux frames, tell gavl it's grayscale at it will scale it.
19:44 < cehteh> well i think that complicates it way too much .. 
19:44 < gmerlin> And doesn't make sense
19:45 < cehteh> for some applications it might be
19:45 < gmerlin> the vp6 codec has a YUVA4:2:0:4 mode
19:45 < cehteh> are logarithmic 12 bit scales still used by pixar?
19:46 < cehteh> RGB 12 bit
19:46 < gmerlin> No idea, but using float instead will probably be faster
19:47 < cehteh> with HD video memory/bandwidth is a big concern
19:47 < gmerlin> On my maching, the float gavl routines sometimes beat the 16 bit ones
19:47 < gmerlin> I/O is an issue of course
19:47 < cehteh> maybe not for a player .. but when you have an editor which pulls serveral HD source streams then you can easily run into problems
19:48 < gmerlin> But for processing, having data types, which are no native CPU types is not good.
19:49 < gmerlin> Whenever you do arithmetics, you'll have to convert them anyway.
19:49 < cehteh> they certainly use hand crafted algorithms for that
19:49 < hermanr_> Or hand crafted hardware ;-)
19:50 < cehteh> well you can do 2x 12 bit caclucations in a 32 bit int with some headroom
19:50 < gmerlin> But you can, if they are log scaled
19:50 < gmerlin> can't
19:51 -!- Enselic [n=martin@c-5f11e455.017-113-6c756e10.cust.bredbandsbolaget.se] has joined #openvideo
19:51 < Enselic> Hello, this is where the meeting at 21:00 GMT will take place, right?
19:51 < cehteh> yes
19:51 < Enselic> oh its even in the topic
19:51 < Enselic> how embarasing
19:51 -!- brad_up [n=brad@m7b0e36d0.tmodns.net] has quit [Read error: 110 (Connection timed out)]
19:52 < cehteh> we already talking a bit .. :)
19:52 < gmerlin> gavl only handles CPU native types
19:52 < cehteh> if you have ideas, add them to the wiki page
19:52 < gmerlin> Can everyone change it?
19:52 < cehteh> yes sure
19:53 < cehteh> if not, its a bug, or he tried to add spam
19:53 < gmerlin> gavl also is native endian always
19:53 < gmerlin> It reduces the needed routines by some orders of magnitudes
19:53 < cehteh> at piksel we tought about an open video index format, if that should be endian neutral/portable
19:54 < cehteh> but i think more and more it should just be native endian
19:54 -!- brad_u [n=brad@m7b0e36d0.tmodns.net] has quit [Read error: 110 (Connection timed out)]
19:54 -!- brad_u [n=brad@m3a0e36d0.tmodns.net] has joined #openvideo
19:55 < gmerlin> Make it with an endian identifier: Endian will be swapped only after the file was transferred from a LE to a BE machine
19:55 < cehteh> just a index-sequential table  struct { unsigned long long offset; blah_t some_flags; blah_t some_custom_flags;}
19:56 < cehteh> yes first field with endian and version identifier
19:56 < gmerlin> I serialize gavl audio frames for sending via pipe/socket, it's also with endian identifier
19:57 < hermanr_> Endianness makes little baby Jesus cry
19:57 < gmerlin> I consider it a job of the codec to get endianess right. Then It doesn't bother you elsewhere.
19:58 < cehteh> flags = mark frame type (gop header, ...)    custom flags = application specific like invaldation markers
19:59 < cehteh> hermanr_ was once burned by quicktime on ppc ;)
19:59 < cehteh> is that fixed now?
20:01 < gmerlin> plugin parameters......
20:01 < cehteh> ..
20:02 < cehteh> = frames :)
20:02 < gmerlin> How does a plugin tell the core, what parameters are supported?
20:02 < gmerlin> And how are these defined?
20:02 < gmerlin> Fixed predefined types +
20:02 < gmerlin> costom types?
20:02 < gmerlin> custom
20:03 < cehteh> not yet fully decided .. but basically (like i would do it) the plugin defines   struct myparameters { ....}
20:03 < hermanr_> cehteh: I have not verified a fix of DV on Debian PPC.  Haven't tried it for a while.
20:03 < cehteh> creates a cache/buffer stream for this kinds of frames
20:04 < cehteh> and manipulation of those is done over a to-be-defined interface
20:05 -!- zap1 [n=zap0@203-217-91-46.dyn.iinet.net.au] has quit ["bye"]
20:05 < gmerlin> One can also define the parameters in a standardized struct and pass this to the core
20:06 < gmerlin> Without cache/buffer
20:06 < cehteh> there shall be callbacks which calculate these parameters between keyframes, naturally we dont want to re-calculate them for any frame but only for certain keyframes where the user changed a value
20:06 < gmerlin> like cinelerra_parameter_t * get_plugin_parameters(...);
20:07 < gmerlin> The rest can be done by the core
20:07 < cehteh> did you seen the (not yet finished) plugin interface i've written?
20:07 < gmerlin> It makes plugins simpler and less code duplication
20:07 < gmerlin> Yes.
20:08 < cehteh> it is certainly not perfect yet, just a base to build upon / to be extended
20:08 < cehteh> i am open for better ideas :)
20:08 < gmerlin> do you have the git command to get this at hand?
20:09 < cehteh> git clone git://git.pipapo.org/cinelerra3/ct cin3
20:09 < gmerlin> thx
20:09 < cehteh> cd cin3; firefox wiki/support_library.html
20:10 < cehteh> err
20:10 < cehteh> yes
20:13 < gmerlin> the CINELERRA_INTERFACE_* macros look good
20:15 < gmerlin> Is there some global plugin registry?
20:19 -!- pxegeek [i=86868804@gateway/web/ajax/mibbit.com/x-786c03fd0b580cb1] has joined #openvideo
20:24 -!- brad_up [n=brad@m3a0e36d0.tmodns.net] has joined #openvideo
20:26 -!- pippin [n=pippin@bilk.XCF.Berkeley.EDU] has joined #openvideo
20:27 < gmerlin> What are the global open() and close() functions in struct cinelerra_interface good for?
20:29 < cehteh> re
20:30 < cehteh> no global registry yet ... but we need it and we need proper interface deduction
20:30 < gmerlin> Ok.
20:31 < cehteh> open and close are init/deinit to hook in other plugins which need it .. as frei0r *G* 
20:31 < cehteh> well richard removes it .. but we cant be sure that others dont have it and i added a refcount for them
20:32 < gmerlin> I would kick them out, and also use_count. It encourages people to do stupid things ;)
20:32 < gmerlin> The only thing they are neede for is X11 grabbing with wxWindows
20:33 < cehteh> well our interface is meant as metainterface to wrap other interfaces too
20:33 < gmerlin> I know no interface (except frei0r) which uses it.
20:33 < cehteh> and if this interfaces require init/deinit we have to care
20:33 < cehteh> maybe i can throw them out .. but i can clearly see interfaces which might need it
20:33 < gmerlin> Which ones?
20:34 < cehteh> imagine you want to hook in something written in a scripting language which gets forked in the back and talk over a socket
20:34 < cehteh> you dont want to check/establish this socket every time you call the interface
20:34 -!- joeedh [n=chatzill@client2076.student-vpn.nau.edu] has joined #openvideo
20:34 < gmerlin> This should be done per instance or not?
20:35 < cehteh> would be an implementation detail or?
20:35 < gmerlin> No, plugins which do such things globally are not multi-instance safe
20:35 < cehteh> well its really negotiateable .. lets see if we can go without, actually i just placed them there 'in-case-of'
20:36 < cehteh> most important thing for me is that the interface does proper versioning, i think that works
20:36 < gmerlin> I would be fine with a comment "optional, only when a support library need it
20:36 < cehteh> next would be plugin deduction if there is no exact match
20:37 < cehteh> yes i can add that comment :)
20:37 < gmerlin> If there is a registry, which can be queried, there will always be exact matches.
20:38 < cehteh> not yet, but will be done
20:39 < gmerlin> IMO the functions for creating/destroying instances can also be in the generic part.
20:39 < cehteh> i thought about something similar to xfont selection for querying plugins
20:40 < gmerlin> Is that necessary?
20:40 < cehteh> for high quality plugins yes ... aka implement the same effect for different color models natively   
20:41 < gmerlin> Then there will be one plugin, which supports all the colormodels :)
20:41 < cehteh> we dont constantly convert to diffrent color models and for previewing we need something fast, less accurate for example
20:41 < cehteh> that would be ideal, but we cant expect that
20:42 < cehteh> frei0r does only 8bit RGB
20:42 < gmerlin> RGBA
20:42 < cehteh> yes
20:42 < gmerlin> Ok, but you still don't need multiple plugins for that.
20:42 < cehteh> and writing a plugin for *all* colormodels is much more work and not always required
20:43 < gmerlin> And not always possible.
20:43 < cehteh> no we dont need .. one plugin can offer many instances of the same interface 
20:44 < cehteh> like a blur might export a "single_frame_effect" as "blur_rgb_422" and "blur_yuv_444"
20:44 -!- brad_u [n=brad@m3a0e36d0.tmodns.net] has quit [Read error: 110 (Connection timed out)]
20:45 < gmerlin> Blur is done with gavl_video_scaler_init_colvolve() and works for all colormodels :)
20:45 < cehteh> you see there are more parameters of what the color model consists, 
20:45 < cehteh> yes that was only an example
20:46 < cehteh> some effects have to care for subsampling diffrently, some not, some need an alpha channel, some not and such
20:46 < gmerlin> It only gets weird, if you have multiple plugins for the same effect, but in different colormodels
20:46 < gmerlin> Then you need something like xfontsel
20:46 < cehteh> this needs an smart deduction algorithm which returns the best (looseless) match and maybe the next-best match to do the job
20:46 < cehteh> yes
20:47 < gmerlin> I think it's actually quite simple:
20:47 < cehteh> or give a list of all results back with cost/quality associated
20:47 < gmerlin> Each filter has an optional format converter in front of it
20:47 < cehteh> no .. thats where cinelerra currently wastes a lot of cpu for, i dont want it
20:48 < cehteh> in cin2 you can have a YUV project and the render pipe does something like:
20:49 < cehteh> input -> to RGB -> apply_effect -> to YUV -> to RGB -> apply_effect -> to YUV ...
20:49 < gmerlin> I know, but the only solution is to support each effect in each supported colormodel
20:49 < cehteh> no it is not
20:49 < gmerlin> Reorder effects?
20:49 < cehteh> with the deduction algorithem the render core can find it if it has to insert a color model correction node once
20:49 < cehteh> input -> to RGB -> apply_effect -> apply_effect -> to YUV ...
20:50 < gmerlin> But then the core must know exactly what the effect does
20:50 -!- ichthyo [n=hiv@p5B0C3531.dip0.t-ipconnect.de] has joined #openvideo
20:50 < Gregor__> hi :)
20:50 < cehteh> not exactly .. the effect shall hint which version is the best in sens of quality/cost
20:51 < cehteh> hey ichthyo 
20:51 < ichthyo> hey cehteh
20:51 -!- limoo1 [n=officine@ppp-9-70.29-151.libero.it] has left #openvideo []
20:51 < cehteh> hi Gregor__ too :)
20:52 < gmerlin> Actually by far the most conversions can be implemented in both RGB(A) and YUV(A)
20:52 < gmerlin> Subsampling is more difficult to handle than colorspace.
20:52 < cehteh> colormodel was only a placeholder for other frame data, subsampling, alpha channel, interlacing
20:52 < cehteh> yes
20:53 -!- j^ [n=j@cl-732.ham-01.de.sixxs.net] has joined #openvideo
20:53 < cehteh> i found the discussion about the best de-interlacer a bit amusing .. what i really want is native interlace support
20:54 < hermanr_> +1!
20:54 < ichthyo> +1
20:54 < cehteh> that is frame are taken in pairs, the effects are aware of the new aspect ratio and subsampling/line shifts
20:55 -!- Dasypus [n=jonas@dslb-088-076-034-255.pools.arcor-ip.net] has joined #openvideo
20:55 < cehteh> hermanr_: do you still remember this excellent link where subsampling and interlacing was explained?
20:56 < hermanr_> The one from the SGI guy?
20:56 < cehteh> i tihnk yes 
20:56 < hermanr_> That one had quite high Google ranking.
20:56 < cehteh> lets look in my link collection
20:57 < Dasypus> do you mean 100fps.com?
20:58 < hermanr_> Will a motion estimator need to know about "rolling shutters" like you have in tube cameras (and CMOS sensors, AFAIK)
20:58 < cehteh> if i know, i wouldnt ask :)
20:58 < hermanr_> ?
20:58 < ichthyo> btw...  hello gmerlin!
20:58 < gmerlin> Hi
20:59 < hermanr_> Dasypus: nope
20:59 < cehteh> no was not 100fps.com
21:00 < hermanr_> It's Luker's Guide.
21:00 < hermanr_> http://lurkertech.com/lg/
21:01 < hermanr_> cehteh: http://lurkertech.com/lg/fields/#reality_camera
21:01 < hermanr_> cehteh: That was about the rolling shutter distortion
21:02  * cehteh printed the pages and put it somewhere ... 
21:02 < ichthyo> gmerlin: on the ML I see uni-stuttgart.de -- I am living in munich...
21:02 < cehteh> heh but i dont know where and i dont know the url anymore
21:02 < gmerlin> Ahh, not far away
21:02 < ichthyo> :-)
21:02 < gmerlin> I go to Garching sometimes
21:03 < ichthyo> really?
21:03 < ichthyo> doing physics or what?
21:03 < gmerlin> Yes, a partner institute is there
21:03  * ichthyo studied physics a long time ago and spent some time in Garching
21:03 < hermanr_> With a per-pixel motion estimator, a clever effect would be to reverse rolling shutter distortion. 8-)
21:04  * cehteh is in karlsruhe
21:04 < gmerlin> Ahh, also been to FZK several times...
21:04 < ichthyo> and where lives Richard Spindler?
21:05 < hermanr_> Austria, IIRC
21:05 < gmerlin> Yes
21:05 < Dasypus> herman: but if I think correctly you would either need to know the precise details of the rolling shutter or couldn't use the pixel surrounding, which makes matching techniques quite complicated, wouldn't you?
21:06 < hermanr_> Yes.
21:07 < hermanr_> You would have to know quite precisely what the temporal interval each line/pixel samples.
21:07 < Dasypus> yes, right... is that constant (enough) for a certain cmos model?
21:07 < gmerlin> cehteh: What about a query function for each filter, which returns the supported colormodels? So the core can minimize the conversions.
21:07 < hermanr_> But for a CRT camera, that interval is quite regular.
21:08 < hermanr_> I dunno for CMOS.
21:08 < ichthyo> gmerlin: yes, we need such
21:08 < gmerlin> Ok, should be part of the API then
21:08 < Dasypus> herman: you could of course search for strong enough edges and their offset between two scanlines... might at least give you some assumption
21:09 < cehteh> gmerlin: i think that add much code duplication, each filter should just have a static initialized table of what it offers
21:09 < cehteh> querying/deduction is then job of the querier who knows better what he intends to do
21:09 < hermanr_> Dasypus: I'm not sure how accurate the knowledge would have to be to yield adequate correction.
21:09 < gmerlin> If the filter has it's own logic how input colormodels are mapped to output colormodels....
21:10 < gmerlin> Input colormodels can the static array, right
21:10 < cehteh> it that could offered by the static table .. my former talk was quite simplified
21:10 < cehteh> actually coversions are themself nodes and could be queried by the same mechanism then
21:11 < ichthyo> yes
21:11 < hermanr_> Dasypus: Maybe a calibration test recording per camera would be needed:  Panning across vertical contours, or something like that.
21:11 < gmerlin> And an optional function (for filters which change it) for querying the output colormodel
21:11 < cehteh> yes 
21:11 < gmerlin> Ok.
21:12 < hermanr_> Dasypus: R&D needed! ;-)
21:12 < cehteh> as saied the deduction is still not decided yet
21:12 < gmerlin> What about synchronicity?
21:12 < ichthyo> well, in the core we do "pull"
21:12 < cehteh> syncwhat? :)
21:12 < cehteh> effects are stateless 
21:12 < gmerlin> Is one frame in - one frame out required?
21:12 < ichthyo> no
21:13 < ichthyo> we pull frames from the output
21:13 < cehteh> if they need state they define that over frame-buffers they create themself
21:13 < cehteh> the inside of an effect is completely stateless
21:13 < cehteh> if it depends for example on the frame before it has to pull it from the backend
21:14 < ichthyo> cehteh: thats the ideal, I'not sure if we can make it 100% that way
21:14 < cehteh> this pull is done with quality/ttl/timing parameters not to iterate back to the first frame
21:14 < ichthyo> because many external effects asume sequential processing
21:14 < cehteh> ichthyo: i think we can
21:15 < gmerlin> Also input plugins would seek back and forth all the time
21:15 < cehteh> yes .. then pull a sequence of frames and stuff them into the external effect
21:15 < cehteh> i think the backend should proviode something like sliding windows over frames
21:16 < ichthyo> for example LADSPA have such a process() callback (if I recall right)
21:16 < ichthyo> and can asume they are called progressivly
21:16 < ichthyo> in that case, my idea was to provide context frames
21:16 < gmerlin> Ladspa is 100% synchronous. no callbacls
21:17 < cehteh> and if the effect is expensive and can only produces sequential output.. thats right the place where the cache comes in, just tag its generated sequence as precious that the cache wont drop it
21:17 < ichthyo> yes
21:17 < ichthyo> motion tracke is a good example
21:17 < cehteh> after things are rendered in the cache you have random access again
21:18 < ichthyo> 2min of motion tracker renderd last week 6 hour for me
21:18 < cehteh> outch
21:18 < ichthyo> (just to find i made a mistake with the parameter settings, haha)
21:18 < cehteh> too big tracking window/depth? :)
21:18 < ichthyo> well, was HDV and upscaled to 50fps because of interlacing, ;-)
21:19 < ichthyo> making the motion tracker really manageable is one of my important goals
21:19 < ichthyo> I believe, it needs some infrastructure suport. It should ouput just normal automation data
21:20 < cehteh> yes
21:20 < ichthyo> which means the handling of automation data needs to be unified
21:20 < cehteh> ->frames :)
21:20 < ichthyo> yes
21:20 < ichthyo> so in this case, the "precious" output would be frames of automation data
21:20 < ichthyo> in the EDL they appear as a "dataset" object
21:21 < cehteh> thats also why i want to mmap to files and not use swap .. persistence
21:21 < ichthyo> ...and can be edited like hand-made automation
21:22 < gmerlin> One other thing plan is to make gmerlin avdecoder sample accurate
21:22 < ichthyo> well guys, we are already happily discussing. Who is expected to join at 21:00 GMT to find the party 's already over ;-)
21:23 < cehteh> hehe
21:23 < cehteh> well there are some organizational things left on the page .. we discuss them then :P
21:23 < ichthyo> :-P
21:23  * cehteh goes making a tea ... brb
21:24  * ichthyo does the same with coffee
21:25  * gmerlin gets a beer
21:25 -!- bobo1on1 [n=bob@boob.xs4all.nl] has joined #openvideo
21:25 < bobo1on1> hi
21:25 < Dasypus> hi
21:25 < ichthyo> hi
21:34 < Gregor__> gmerlin: a free beer?
21:34 < gmerlin> I paid it
21:34 < Gregor__> is it a free beer, like free in freedom? :P
21:34 < cehteh> hi
21:34 < hermanr_> Someone summon Richard (oracle2025) if he doesn't show up soon...
21:34 < cehteh> Ommmmmmmm
21:34 < gmerlin> Always
21:35 < hermanr_> Are you done already?
21:36 < cehteh> with the beer? tea? summoning?
21:36  * ichthyo just telephoning
21:38 < gmerlin> cehteh: Should filter be allowed to pick random frames or only sequential ones?
21:38 < cehteh> random
21:39 < bobo1on1> I have the freedom to say I like free beer
21:39 < cehteh> or even more sophisticated there will be an api "give me the next frame to N which is available in $time (asap)"
21:40 < bobo1on1> so
21:40 < gmerlin> Will make a huge API :)
21:40 < pippin> cehteh: in gggl I had a separate pixel format negotiation passon the graph before actual processing was started, (with the insertion of temporary conversion nodes),I think I ended up getting the logic right for it in there back then, these days I simply postpone such issues to the future
21:40 < bobo1on1> will the titler plugin finally have support for outlines? :P
21:41 < cehteh> gmerlin: not too simple, agreed, sophisticated and as small as possible
21:41 < ichthyo> gmerlin: depends what you call "the API"
21:41 < gmerlin> Outlines are easy with newest libfreetype
21:41 < gmerlin> API is the functions a plugin exports
21:41 < ichthyo> most of the negotiation stuff is used only within the core, so only the bottom layer and the middle layer use it
21:41 < bobo1on1> I hacked the titler plugin a while ago to get outlines
21:42 < bobo1on1> I just drew a square of drop shadows
21:42 < bobo1on1> worked great
21:42 < hermanr_> Did j6t accept the patch?
21:42 < bobo1on1> I posted a patch but nobody wanted it
21:42 < gmerlin> If it must be larger for what it needs to do, it's ok.
21:42  * cehteh did a titler twice one black in background with blur
21:43 < bobo1on1> :(
21:43 -!- kilonux [n=frode@jau72-2-88-164-44-51.fbx.proxad.net] has joined #openvideo
21:43 < cehteh> bobo1on1: where did you posted it?
21:43 < bobo1on1> on the mailing list
21:43  * cehteh suggest to drop it in the mob repository
21:43 < bobo1on1> here you can see an example of it http://www.youtube.com/watch?v=lS-wWt4imCg
21:44  * gmerlin renders subtitles with real outlines for years :)
21:44 < cehteh> that will be the way we work for cin3^W$unnamed
21:44 < bobo1on1> where is the mob repository?
21:45 < cehteh> git://git.pipapo.org/cinelerra/mob
21:45 < cehteh> http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings  .. one point more .. anyone else with suggestions, edit it :)
21:46 < hermanr_> bobo1on1: http://www.pipapo.org/gitweb?p=cinelerra/mob;a=summary <-- Web interface, soon to be replaced by webgit
21:46 < cehteh> ;)
21:46 < hermanr_> http://www.pipapo.org/webgit?repo=webgit_mob&action=summary
21:47 < cehteh> well thats webgit's mob not cin3
21:47 < cehteh> cin2 even
21:47 < bobo1on1> hm now I have to figure out how to use git
21:47 < gmerlin> me too
21:47 < ichthyo> cehteh: what do you mean with "introduce the development model"? 
21:47 < cehteh> bobo1on1: we have a small intro there .. if you need help ask me later (after the meeting or tomorrow)
21:48 -!- bobo1on1 [n=bob@boob.xs4all.nl] has quit [Read error: 104 (Connection reset by peer)]
21:48 < cehteh> ichthyo: just how we want to attract people to contribute and how things are decided / managed / done
21:48 < ichthyo> cehteh: more formalizing the dev model, or just explaining it?
21:48 < hermanr_> cehteh: Isn't cinelerra/mob/ available from webgit?
21:48 < cehteh> just explaining it
21:48 < ichthyo> understand
21:48 < cehteh> hermanr_: not yet 
21:49 < cehteh> i could add it .. i just added some examples so far
21:49 < cehteh> http://www.pipapo.org/webgit outch
21:50 < cehteh> there was a reason why i didnt enabled it :)
21:50 -!- bobo1on1 [n=bob@boob.xs4all.nl] has joined #openvideo
21:50 < bobo1on1> right
21:50 < bobo1on1> computer froze up
21:51 < cehteh> huh
21:51 < hermanr_> So you did not run off in terror by the prospect of using git.
21:52 < bobo1on1> nope
21:52 < bobo1on1> but my computer got scared
21:52 < gmerlin> How many people are working on cin-3 altogether?
21:52 < hermanr_> aaaawww
21:52 < cehteh> gmerlin: better dont ask :)
21:53 < hermanr_> The fewer the easier for gmerlin ;-)
21:53 < pippin> gmerlin: I'm not ;)
21:53 < gmerlin> Development model depends on the number of people and traffic
21:53 < ichthyo> cehteh: just added something to the agenda: details of the monthly meeting..
21:53 < cehteh> or ask after this meeting .. i hope some will join and we intend to support short time contributors
21:53 < cehteh> well we will start in 7 minutes :)
21:54 < cehteh> shall we wait for oracle?
21:54 < Dasypus> ... now *that* sounds good (short time contributors)
21:54 < ichthyo> tick...tick... tick...tick...
21:54 < pippin> Dasypus: one of the important things to enable that is to make it easy to write plug-ins,. as well as generally end up with a modular design
21:55 < hermanr_> Who are the "cleaning up after short time contributors' mess" people? :-P
21:55 < cehteh> Dasypus: cin2 had a somewhat fluctating developer base, certainly it need core devs, but people who just want to fix/add a small thing should be encuraged to do that instead scared away
21:55 < cehteh> which still means they should deliver documented/maintainable code, else it will be a big mess
21:55 < bobo1on1> hm
21:55 < gmerlin> hermanr_: I don't care how many there are :)
21:56 < ichthyo> ...and we have another requirement: Write tests
21:56 < cehteh> ;)
21:56 -!- Plugh [n=kcozens@CPE000f9f67c5c3-CM000f9f500b9c.cpe.net.cable.rogers.com] has joined #openvideo
21:56 < cehteh> test-driven-brainstorming :)
21:56 < pippin> gmerlin: then why do you ask? :d
21:57 < gmerlin> Curiosity
21:57 < Plugh> Ah, pippin is here for the meeting.
21:57 < gmerlin> And I was thinking about development models
21:57 -!- raffa [n=raffa@212.45.157.169] has joined #openvideo
21:57 < cehteh> gmerlin: lets say extreme pogramming with pair-programming is currently not really an option :)
21:58 -!- SimAV [n=SimAV@c28.shuttle.de] has joined #openvideo
21:58 -!- Plouj [n=Plouj@red.cs.yorku.ca] has joined #openvideo
21:58 < Plouj> ichthyo: yes
21:58 < cehteh> wow 
21:58 < Plouj> thanks for reminding me
21:58 < pippin> Plugh: yeah, I've been tricked to increase the number of tabs in irssi to >19 :]
21:58 < Plouj> I've got way too many things happening right now
21:58 < Plugh> 19?
21:58 < Plugh> This channel only brings me to 4
21:59 -!- ichthyo [n=hiv@p5B0C3531.dip0.t-ipconnect.de] has quit ["bye bye ..."]
21:59 < cehteh> huh 
21:59  * hermanr_ sent SMS to Richard (oracle2025)
21:59 < bobo1on1> soo
21:59 -!- ichthyo [n=hiv@p5B0C3531.dip0.t-ipconnect.de] has joined #openvideo
21:59 < cehteh> heh and ichthyo leaves :P
21:59 < bobo1on1> how do I use git?
21:59 < cehteh> bobo1on1: i explain you later ok?
21:59 < bobo1on1> ok
22:00 < cehteh> meanwhile ensure that you have at least v 1.5.2 installed
22:00 -!- schlaile [n=chatzill@91.89.241.251] has joined #openvideo
22:00 < ichthyo> well the bell is ringing...
22:01 < bobo1on1> uhm probably not
22:01 < cehteh> so 22:00 :) do we want to start, again?
22:01 < hermanr_> Give it another minute.  SMS can be slow.
22:01 < cehteh> haha
22:02 < bobo1on1> Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd.
22:02 < bobo1on1> that is the version I have
22:02 < hermanr_> cehteh: You have Richard's phone number...
22:03 < cehteh> urgs .. ircnet disconnected me .. hopefully that was a problem there and not my connection
22:03 < cehteh> yes
22:03 < ichthyo> bobo1on1: we are about to start a developer meeting here, we'll answer questions afterwards...
22:03 < bobo1on1> ok sorry
22:04 < cehteh> hermanr_: you meant i shall call him?
22:04 < cehteh> ringring
22:05 < hermanr_> cehteh: yes
22:05 < cehteh> ...
22:05 < hermanr_> http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings
22:06 < hermanr_> Item #1: Who will write the protocol ?
22:06 < cehteh> ok .. he cant come online .. we shall send him the protocol and he will rant/flame about that later
22:06 < hermanr_> Tant pis :-(
22:06 < ichthyo> last time, cehteh wrote it.
22:06 < cehteh> last time?
22:07 < hermanr_> ;-)
22:07 < ichthyo> fall 07, long time ago
22:07 < ichthyo> its in the tiddlywiki
22:07 < cehteh> ok ok :P well was not that offical this here is the first official meeting
22:07 < hermanr_> cehteh was unanimously accepted as the referent
22:07 < hermanr_> Any objections?
22:07 < cehteh> yes :P o/
22:08 < cehteh> anyone else want to do it?
22:08 < ichthyo> i can do it as well
22:08 < hermanr_> *sold*
22:08 < ichthyo> (its work...)
22:08 < cehteh> :)
22:08 < ichthyo> ok, I'll write the protocol
22:08 < hermanr_> So ichthyo writes.  Next?
22:08 < cehteh> so who is here? ... not actually ideleing
22:08 -!- hermanr_ changed the topic of #openvideo to: Meeting: http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings
22:09  * Plouj 
22:09  * SimAV  
22:09  * pippin http://pippin.gimp.org/ http://codecave.org/
22:09  * dooglus 
22:09  * Dasypus listens
22:09 < ichthyo> .
22:09  * Plugh is listening
22:09 -!- hermanr_ changed the topic of #openvideo to: Meeting: http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings | 2.Discuss the open points in Cinelerra3/DesignProcess do we need this formalism?
22:09  * hermanr_ listens
22:10 < cehteh> ok .. then i start about that point:
22:10 < cehteh> i've proposed a kindof formal way to plan things and add feature request ideas
22:11 < cehteh> it never used that much .. prolly we can drop it or make it, i just want to hear comments about it
22:11 < cehteh> opinions?
22:11 < ichthyo> i am for keeping this alive
22:11 < cehteh> or make it optional. ... 
22:11 < hermanr_> cehteh: URL to the proposal
22:11 < hermanr_> ?
22:11 < gmerlin> +1
22:11 < Plouj> what hermanr_ said
22:12 < hermanr_> For the homework challenged ;-)
22:12 < pippin> http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess
22:12 < cehteh> http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess
22:12 < ichthyo> not for every implementation detail, but for important/mayor plans/whishes/decisions
22:13 < Plouj> sounds good to me :)
22:13 < Dasypus> Looks good to me... I would think the problem is not in the process design but in the 'entry point' (e.g. where/how to submit a proposal)
22:13 < cehteh> ok .. but that requires that we maintain it and all accept this process, currently there are some things piled up ..
22:14 < cehteh> we can make it a point for future meetings to go over the drafts
22:14 < Dasypus> homework assignment :)
22:14 < cehteh> Dasypus: the proposal is right added at that wiki page
22:15 < cehteh> see the form field and the [create!] button :)
22:16 < ichthyo> then we need several final states: accepted, rejected and "somewhat outdated or superseede" (any better term?)
22:16 < cehteh> ok
22:16 < Plouj> cehteh: I agree with the idea of going over drafts in future meetings
22:17 < Plouj> ichthyo: oudated and superceeded are different sates, IMHO
22:17 < cehteh> ichthyo: current there is final and dropped ... dropped can mean both superseeded or rejected
22:17 < hermanr_> Has this item been debated exhaustively for now?
22:17 < ichthyo> cehteh: agreed, dont make more final states. "dropped" is fine for me
22:17 < Plouj> superceded*
22:17 < gmerlin> Have all dropped proposals a reason for being dropped attached?
22:18 < cehteh> yes
22:18 < cehteh> hermanr_: no :)
22:18 < ichthyo> we have to go through the open ones..
22:18 < cehteh> well now ... *CONCLUSION* keep it, go over monthly
22:18 < gmerlin> Looks good
22:19 < cehteh> gmerlin: after all it is a wiki, it can always be edited and the template can be extended if needed
22:19 < gmerlin> ok
22:19 < cehteh> but imo it should be kept as simple as possible .. hence only 'dropped'
22:19 < cehteh> bugzilla confuses me :P
22:20 < Plouj> heh
22:20 < cehteh> ok .. do we want to discuss the open point later today?
22:20 < gmerlin> Maybe dropped on the frontpage and some prefefined subcategories on the subpage
22:20 < cehteh> gmerlin: all doable :)
22:21 < hermanr_> This is typical incremental stuff, not suitable for the waterfall method.
22:21 < cehteh> yes
22:21 < hermanr_> So next?
22:21 < cehteh> i would talk about point 5 now
22:21 < hermanr_> Oh.
22:21 < ichthyo> OK
22:22 < cehteh> little out of order but prolly good to introduce first
22:22 < Plouj> hang on
22:22 < Plouj> what states did we decide on?
22:22 < cehteh> Introduce the development model
22:22 < cehteh> Plouj: keep the current and improve on demand?
22:23 -!- hermanr_ changed the topic of #openvideo to: Meeting: http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings | 6. How to handle the regular meetings in future (day, time, where to put sumaries)
22:23 < hermanr_> Bummer
22:23 < cehteh> wrong paste :P
22:23 < Plouj> humm, I mean the states for proposals, currently the wiki shows Idea, Draft, Final, Dropped
22:23 < cehteh> yes 
22:23 -!- hermanr_ changed the topic of #openvideo to: Meeting: http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings | 5:Introduce the development model
22:23 < cehteh> later add dropped/reason
22:23 < Plouj> ok, I just noticed that I don't see the functional difference between Idea and Draft
22:23 < cehteh> with some subcategories for reason 
22:24 < cehteh> idea is still in edit by the proposer
22:24 < ichthyo> Plouj: the Idea can be raw/brainstorming
22:24 < cehteh> means people shall not start rant on it
22:24 < Plouj> oh, alright then
22:25 < ichthyo> well, development model...
22:25 < cehteh> that time it might be collaboratively improved to become an acceptable draft
22:25 < cehteh> ok
22:25 < cehteh> ichthyo: do you want to tell?
22:25 < ichthyo> ok
22:25 < ichthyo> we have a distributed model based on GIT
22:25 < Plouj> ok, I'm good then
22:25 < Plouj> move on to the next topic
22:25 < ichthyo> each dev has its own GIT repo
22:26 < ichthyo> devs are pulling from each other and try to make it work together
22:27 < Plouj> I'm not sure about thi
22:27 < Plouj> s
22:27 < ichthyo> important decisions --> make a proposal as said
22:27 < Plouj> last time I was involved int his we ended up pulling everything from everyone
22:27 < pippin> will people be able to download tarballs or will sha1 hashes be declared stable? :]
22:27 < cehteh> yes
22:27 < Plouj> in other words: there was no cherry picking which I think is the idea of distributed development
22:28 < cehteh> Plouj: you didnt do it, but it is possible
22:28 < ichthyo> we have to decide on a "official" branch at some point in the future
22:28 < Plouj> cehteh: very true :)
22:28 < ichthyo> but as long as we are about 3-8 core devs, it will work without
22:28 < Plouj> ichthyo: you mean with cherry picking?
22:28 < pippin> ichthyo: the way cairo works with an offical repo that people gain access to push to (or can push other w/o ssh key) changes into seems to be a nice thing
22:29 < cehteh> point is that everyone can start coding, clone the git, negotionate with the others what you want to do, hack on
22:29 < Dasypus> but what about very small changes then? maybe not now, but something like a bugfix... how would it be handled?
22:29 < ichthyo> mob git
22:29 < cehteh> yes i provide anonymously pushable git (which is untrusted of course)
22:29 < Dasypus> ok
22:30 < cehteh> people can hack and push there, no need to ask for commit access
22:30 < hermanr_> What is currently missing, I think, is _frequent_ builds and testruns.
22:30 < hermanr_> Not just public builds, but regression test builds.
22:30 < ichthyo> btw: every dev signs of his tree with a standardized signature (always overwriting his last signature)
22:30 < cehteh> i even work currently on a git web frontend which makes the codebase in the mob web-editable like a wiki
22:31 < cehteh> thats for small fixes and documentation improvement
22:31 < ichthyo> I want to propose some small requirement, though:
22:31 < pippin> (cehteh: the cairo wiki is markdown based and allows editing both through git and the web, not sure how they rigged it up exactly though)
22:31 < cehteh> hermanr_: my server has not the resources to do so, my desktop maybe .. but someone has to write some infrastructure for that
22:32 < cehteh> pippin: also the codebase?
22:32 < hermanr_> cehteh: Indeed.  Or we need to chip in on a shared server ;-)
22:32 < ichthyo> I want to propose some small requirement for every GIT repo:
22:32 < ichthyo> the code tree on the master branch should:
22:32 < ichthyo> - pass the compiler
22:33 < ichthyo> - pass the testsuite
22:33 < ichthyo> all "raw" coding should be done on branches
22:33 < pippin> cehteh: nope, not the codebase, but the wwebsite(wiki) is editable using a text editor and pushing with git, for the lazy developer bunch :]
22:33  * SimAV agrees
22:33 < Plouj> ichthyo: are you proposing automatic pre-commit checks for those things?
22:33 < ichthyo> rationale is: I need to pull only if I see someone merges to his master
22:33 < ichthyo> not yet
22:33 < cehteh> pippin: that will be a side effect on what i am planning .. but making the codebase editable in a mob branch means to lower the entry barrier for contributors as much as possible
22:34 < ichthyo> Plouj: later on we will have an integration server doing automated test runs (but its to early for this much infrastructure)
22:35 < cehteh> biggest problem is that someone has to code or setuo this infrastructure .. hands up please :P
22:35 < cehteh> ah .. apropos development model:
22:36 < cehteh> we keep the whole project in the git repository (later maybe splitted in submodules)
22:36 < cehteh> that is documentation, sourcecode, developer docs, bugs!
22:37 < ichthyo> and...
22:37 < pippin> somewhat related,. what is the stance on dependencies/NIH?
22:37 < cehteh> likely even the homepage when we have one
22:37 < ichthyo> ...mostly no generated files in the repo
22:37 < ichthyo> (at the moment, there is one exception: the gifs generated by bouml, because i link to them form the wiki)
22:38 < ichthyo> btw, cehteh:
22:38 < cehteh> pippin: whatever it needs, optional if possible .. 
22:38 < gmerlin> ichthyo: Agree
22:38 < ichthyo> can we delete the sub-branch in your wiki, were you checked in doxygen some time ago
22:38 < cehteh> will be hard to target minimal dependencies for such a project, but shall not bloat wither
22:38 < cehteh> ichthyo: yes
22:39 < pippin> cehteh: ok, NIH based work somewhat encouraged then
22:39 < cehteh> what means NIH btw? :)
22:39 < ichthyo> not invented here
22:39 < pippin> not invented here (syndrome)
22:39 < cehteh> heh ok
22:39 < ichthyo> I think, we need some commonsense here.
22:39 < cehteh> ack
22:39 < ichthyo> If an external dependency saves work, well fine, use it
22:40 < pippin> GUI toolkit of cinelerra is the result of NIH for instance
22:40 < ichthyo> If an external dependency is not maintained, difficult to build, not GPL, better code it yourself!
22:40 < cehteh> cin2? :)
22:40 < ichthyo> I would propose to think at the focus of the project:
22:41 < gmerlin> pippin: At one point we'll depend on ffmpeg, and every other dependency is more painless that that
22:41 < gmerlin> than that
22:41 < cehteh> haha
22:41 < hermanr_> +1
22:41 < pippin> gmerlin: ffmpeg dependency should be delegated to a plug-in and not the core
22:41 < ichthyo> (re)inventing something related to video/audio/editing maybe ok
22:41 < ichthyo> but (re)inventing GUI toolkits is beyond the focus of the project, IMHO
22:41 < pippin> gmerlin: that plug-in should also be swappable for alternate video frame/audio sample backend,. / encoders
22:41 < cehteh> well yes .. thats it .. encoders/decoders are just nodes in the reder graph and thus plugins
22:41 < gmerlin> pippin: But an important plugin :)
22:42 < Enselic> if Cinelerra aspiers being an official GNU project I guess GTK is the only GUI toolkit choice available
22:42 < pippin> gmerlin: sure, but a lot of the neded leg work is done since similar code exist
22:42 < cehteh> i've written a debugging library some time ago and we use it, thats prolly the only weird dependency we already have
22:42 < cehteh> the C++ part uses boost .. but conservatively (or?)
22:43 < gmerlin> gavl itself has -lc AFAIK
22:43 < gmerlin> libpng for the testsuite....
22:43 < ichthyo> well, to continue with the dev model...
22:43 < cehteh> side-note will GPL3 cause patent problem for US contributors?
22:44 < pippin> (and should one care if it does?)
22:44 < ichthyo> I propose making GPL3 an topic for the next meeting
22:44 < hermanr_> pippin: Quiet, you ... European!
22:44 < cehteh> dev model related .. I want cin3 to be free software shared over a community, no copyright assignments
22:44 < cehteh> ok 
22:45 < ichthyo> cehteh: I always thought the original dev need to claim a copyright in order to be able to put it under GPL
22:45 < cehteh> so any questions about the devel model?
22:45 < Gregor__> http://regmedia.co.uk/2008/01/19/macbookcommodorecompare.jpg
22:46 < ichthyo> I have something to add to the dev model:
22:46 < cehteh> ichthyo: we have it already under gpl2-or-any-later just follow cin2
22:46 < pippin> hermanr_: I'm not european, I'm simply !US == (world-us)
22:46 < ichthyo> we have currently three mayor layers
22:46 < ichthyo> backend, middle, gui
22:46 < ichthyo> they will probably evolve into sub projects
22:46 < cehteh> and common support-library 
22:47 < ichthyo> I propose to have for each project a "primus inter pares"
22:47 < ichthyo> I don't want "leadership" (for sheep)
22:48 < hermanr_> Next point is?
22:48 < cehteh> now in german^Wenglish
22:48 < ichthyo> but there needs to be someone who has the last word, if there are quarrels
22:48 < gmerlin> +1
22:49 < ichthyo> the obvious proposal is (starting from status quo): cehteh for the backend, me for the middle layer, no one yet for the GUI
22:49 < cehteh> yes .. i personally think things should be technically rated and someone shoudl have a final word about something, defined by his technical experience and/or how much he is involved by the part of the code
22:50 < cehteh> i really dont want to vote for features .. and *REALLY* no gui related votes :)
22:50 < cehteh> maybe informal asking around
22:50 < hermanr_> You may send prayers, which _may_ be heard :->
22:50 < cehteh> hehe
22:50 < ichthyo> I thik we should start seeking a dev willing to start the gui part, and he will se how he deals with the user input
22:51 < Dasypus> hehe.. delegate the problem? :)
22:51 < cehteh> i think we shall still delay the gui thing
22:51 < pippin> $EDITOR should be the initial gui :d
22:51 < ichthyo> I like much GUI programming, but for this project I am determined to keep myself out of the GUI thing
22:51 < hermanr_> Can't they meet on the middle?
22:51 < cehteh> probably most of us have ideas about the GUI, at least i have
22:51 < cehteh> but i dont want to care now
22:52  * ichthyo same
22:52 < ichthyo> similar: I have some (partial strong) opinions regarding the raw processing, but I will keep myself out of this questions
22:52 < hermanr_> I believe a GOOD UI will take quite some time to evolve.
22:52 < cehteh> hermanr_: i dont think so .. or at least i would like to be involved then
22:53 < ichthyo> hermanr_: I agree
22:53 < Dasypus> but wouldn't it be a good thing to document these ideas as "ideas"?... so at least there is *something* where people can comment on / give their own ideas / etc...
22:53 < ichthyo> the dev doing the GUI will need quite some time to plan and sort proposals
22:53 < ichthyo> Dasypus: I agree, we should allow GUI related proposals on the wiki
22:54 < cehteh> Dasypus: i see a problem that there is some danger that a GUI/Design/theme war emerges, without no one really cares for do the work then
22:54 < ichthyo> cehteh: no risk, no fun!
22:54 < gmerlin> But if noone really cares, people are not so eager to fight flamewars
22:54 < cehteh> discussion about gui shall be started when there are people willing to work on it
22:54 < ichthyo> (we need ideas from the users)
22:54 < hermanr_> cehteh: We don't have to keep the GUI development wide open, if we think that's an issue.
22:55 < cehteh> imo first gui prototype shall be very close to cin2 .. but thats me ;)
22:55 < gmerlin> +1
22:55 < ichthyo> but currently the issue is rather, we have no one willing to take the position of the GUI programmer
22:55 < ichthyo> cehteh: +1
22:56 < cehteh> yes ... first one willing to do it, then he takes the lead and decides
22:56 < ichthyo> IMHO the people brainstorming about GTK versus KDE on the cinelerra Mailinlist are no problem (you can ignore the threads)
22:56 < cehteh> thats the way i would like to see... everyone is boss at the thing he works on
22:57 < cehteh> was there any thread? :)
22:57 < Dasypus> ichtyo: yes... contributions should only be taken seriously if there are reasons and/or _constructive_ criticism...
22:57  * cehteh ignores any critic which doesnt show an alternative
22:58 < ichthyo> Well, back to the development model: I have to add an obvous thing for sake of completeness:
22:58 < cehteh> gmerlin did that very good when he told me that my time handling is suboptimal and gavl is better ... 
22:58 < cehteh> we use gavl now :)
22:59 < gmerlin> I like ranting, but never without looking at the code and rethink if my stuff is really better
22:59 < ichthyo> We try to stick to modern programming standards. That means, modules have interfaces, interfaces need some (minimal) documentaton, and it is not allowed to bypass the interfaces and tangle everyting in a wild fashion as it happened to the Cin2 codebase
23:00  * cehteh almost never hacks perfect code at the first try .. thats why we use git, anyone can improve anything .. make it work
23:00 < ichthyo> (thats obvious, but it belongs to "development model")
23:00 < cehteh> +10 ;)
23:00  * ichthyo likes frequent refacturing
23:01  * gmerlin likes minimalistic interfaces
23:01 < ichthyo> Someone said some days ago in the ML: he wants to draw a red circle around some feature he is interested in and ignore most of the rest
23:01 -!- SimAV [n=SimAV@c28.shuttle.de] has quit ["Leaving"]
23:01 < cehteh> we shall aim for that .. but i have some doubts that it will be always possible
23:01 < ichthyo> yes
23:02 < gmerlin> Any other topics?
23:02 < ichthyo> yes
23:02 < cehteh> some things have to be little more complciated when we aim pro/high quality
23:02 < cehteh> ok development model explained extensively .. questions?
23:03 < ichthyo> thats why we will be talking/discussing much, and have monthly meetings etc.
23:03 < cehteh> no conclusion for this point :)
23:03  * ichthyo proposes to continue with 6.): details of the monthly meeting
23:03 < cehteh> hermanr_: point 3 please :)
23:03 < cehteh> or that
23:04 < ichthyo> I have some proposals:
23:04 < ichthyo> 1) make it thursday, not friday
23:04 < gmerlin> +1
23:04 -!- hermanr_ changed the topic of #openvideo to: Meeting | 3: Who works on what, what are the short term goals, what tasks are open
23:04 < cehteh> haha
23:04 -!- cehteh changed the topic of #openvideo to: Meeting | 6.): details of the monthly meeting
23:05 -!- cehteh changed the topic of #openvideo to: Meeting | 6.): details of the monthly meeting    (out of order execution)
23:05 < ichthyo> 2) write a short status update prior to each meating for each of the mayor parts (backend, middle, gui)
23:05 < cehteh> i am fine .. last monday each month and weekend could be problematic
23:05 < Dasypus> ichthyo: maybe include a short-term to-do list in that status report?
23:06 < ichthyo> yes
23:06 < ichthyo> rationale: not so much to talk in the meeting
23:06 < cehteh> +ack
23:06 < ichthyo> and the time? let it at 21:00 GMT for now, until someone expresses problems with this time?
23:07 < cehteh> we have some people who coudlnt attend because of the time
23:07 < cehteh> i think we might alternate between an early and an late time
23:07 < ichthyo> ok
23:07 < cehteh> 21:00 14:00 or whatever (ask that people first)
23:08 < ichthyo> any further points for the meeting?
23:08 < ichthyo> ok, conclusion
23:08 < cehteh> just the 'standard' points .. i'd like the protocol writning as proprosed and then send to the ml
23:09 < cehteh> going over the DesignProcess drafts
23:09 < cehteh> agree on the next meeting
23:09 < ichthyo> for now we continue to use the cinelerra-Mailinglist, right?
23:09 < cehteh> yes
23:09 < ichthyo> +1
23:10 < cehteh> well i can cross-post anncounces again
23:10 < cehteh> was estrudiovlive piksel cinelerra .. any other ml?
23:10 < ichthyo> where to put the protocol? I'd prefer the main TiddlyWiki in GIT
23:10 < cehteh> next time little earlier than 3 days in advance
23:11 < cehteh> tiddlywiki (or doc/meeting_protocols? )
23:11 < cehteh> on my wiki
23:11 < cehteh> send it to the ml 
23:11 < cehteh> ah richards ml as well
23:12 < ichthyo> ok, conclusion:
23:12 < gmerlin> ahh, what was the reason against a dedicated cin3 ml?
23:12 < hermanr_> gmerlin: cehteh isn't too hot on mailing lists in general.
23:13 < gmerlin> Oops...
23:13 < ichthyo> next meeting: the first Thursday in March, planned for 21:00 but the time may be changed
23:13 < ichthyo> Announce on ML
23:13 < ichthyo> write a short status report prior to the meeting on pipapo.git
23:13 < cehteh> gmerlin: idea is ther is volatile discussion that is irc and personal mails .. and NO-noise conclisions documented in the project repository
23:14 < ichthyo> put the protocol in TiddlyWiki, pipapo wiki and post int to the ML
23:14 < Velmont> 6th of March that is then
23:14 < gmerlin> cehteh: Ok
23:14 < ichthyo> 6th March, planned for 21:00 GMT
23:15 < ichthyo> gmerlin: regarding the ML
23:15 < ichthyo> I think we should keep up the connection to the cinnelrra community, not start a complete separete community for now
23:15 < cehteh> we planning to rent a server and/or i can install a mailman on pipapo.org .. if we *really* want one
23:15 < ichthyo> that's why I thik it's good to be present on the cinelerra ML
23:15 < cehteh> developers ml maybe .. but richards ml works well for that
23:15 < ichthyo> yes
23:15 < cehteh> i dont want that many ml's
23:16 < hermanr_> +1
23:16 < ichthyo> Its good when people notice our project is alive and constantly evolving
23:16 < gmerlin> so cin3-general == cinelerra-cv, cin3-dev == libopenvideo
23:16 < cehteh> yes .. but keep the trolls out
23:16 < ichthyo> I want *one* community of users, no problems if we have two applications
23:17 < cehteh> ack
23:17 < ichthyo> the existing Cin2 and the new one, but *one* community
23:17 < ichthyo> as of me, we are throught with point 6) (monthly meeting)
23:17 < cehteh> ok
23:17 < hermanr_> #3 then?
23:18 < ichthyo> agreed
23:18 -!- hermanr_ changed the topic of #openvideo to: Meeting | 3: Who works on what, what are the short term goals, what tasks are open
23:18 < cehteh> yes .. 3 minute toilet pause :P
23:18 < gmerlin> +1
23:18 < Velmont> -1
23:18 < ichthyo> piss on the floor
23:20 -!- raffa [n=raffa@212.45.157.169] has quit [Remote closed the connection]
23:22 < hermanr_> ...
23:22 < ichthyo> ....
23:22 < cehteh> ..
23:22 < gmerlin> ..
23:23 < hermanr_> So nobody works on anything?
23:23 < cehteh> all back?
23:23 < cehteh> exactly :(
23:23 < cehteh> well ichthyo work on the processing layer
23:23 < ichthyo> yes, short summary...
23:24  * gmerlin will implement grayscale support for gavl, so the upper layers can store arbitrary data in it
23:24 < ichthyo> my main goal is
23:24 < ichthyo> to get the core of the builder fleshed out
23:24 < ichthyo> next goal is: 
23:25 < ichthyo> i want to create a clip object (with dummy values)
23:25 < ichthyo> add it to the edl, get the edl handed over to the builder and let the builder makel the first (preliminary) render nodes
23:26 < ichthyo> note: left many details for later
23:26 < cehteh> clip is what? start-pos/end-pos to a asset?
23:26 < Dasypus> what exactly does the "builder" do?
23:26 < ichthyo> Dasypus: i started a design and started coding it and it seems to work out as I intended:
23:27 < ichthyo> i have a high-level model and a low-level model
23:27 < ichthyo> user sees the high level model = objects in the EDL (actually N EDLs)
23:27 < ichthyo> plus assets referenced by the objects
23:27 < pippin> ichthyo: generating graphs on the fly for each render, might cause you to lose some benefits possible from caching
23:27 < ichthyo> low level model is:
23:27 < cehteh> http://www.pipapo.org/pipawiki/Cinelerra3/Developers/SimAV/German/TimelineAndFeatureTalkWithIchthyo .. for the germans
23:28 < ichthyo> graph of render nodes
23:28 < ichthyo> using pull model and able to be driven by the backend
23:28 < ichthyo> the builder translates high-level into low level
23:28 < cehteh> pippin: caching will be aware
23:28 < ichthyo> I don't have a separate network for each frame,
23:28 < Velmont> I've been reading the code and building a plugin that doesn't do anything. Since cin3 doesn't do anything yet, it is hard for inexperienced people like me to fiddle around :p
23:29 < ichthyo> rather, I segment the timeline in "constant" parts
23:29 < ichthyo> i.e. parts were the config remains constant
23:29 < ichthyo> and only automation changes
23:29 < pippin> ichthyo: I had good experience with rigging up the full graph from the higher level model, and only rewiring the used parts to the final output node
23:29 < cehteh> (but parameters change due automation)
23:30 < ichthyo> cehteh: thats what I mean
23:30  * cehteh only contemplates you
23:30 < ichthyo> :-)
23:30 < ichthyo> I use sort of an "isolation" layer between the two models. I call this "the fixture"
23:31 -!- Enselic [n=martin@c-5f11e455.017-113-6c756e10.cust.bredbandsbolaget.se] has quit [Remote closed the connection]
23:31 < ichthyo> it is a copy of all active parts in all edls, but every position is solved and made explicit
23:31 < ichthyo> so, edit operations -> change objects and trigger "rebuildFixture()"
23:32 < ichthyo> afterwards, builder detects what parts of the render-network to rebuild
23:32 < ichthyo> remember: the render nodes themselfs are stateless
23:32 < ichthyo> (all context, and data frames are provided/managed by the backend and passed in as context)
23:33 < ichthyo> now to the current state in my part:
23:33 < ichthyo> basic asset manager is done
23:34 < ichthyo> I can create asset objects (it's a hierarchy), which will be registered automatically. Memory management done with boost::shared_ptr
23:34 < ichthyo> written some support/lib parts (factory, singleton, a settings manager) etc. This parts go up on demand and shutdown without memory leaks
23:34 < ichthyo> I am able to create a clip asset and create a clip "Media object" from that
23:35 < ichthyo> and I am just in the middle of the builder, nothing finished there
23:36 < ichthyo> currently, the test suite is the only interesting executable
23:36 < ichthyo> and this will remain so for quite a time
23:36 < ichthyo> further plans/ ideas:
23:36 < ichthyo> I rather very much want to embed a prolog interpreter (YAP) prolog
23:36 < ichthyo> to handle all sorts of configuration queries
23:37 < ichthyo> Background is: I did the same several times in my work job
23:37 < ichthyo> it really pays off
23:37 < ichthyo> but for now I use a mock implementation for the queries and concentrate on the builder
23:38 < ichthyo> Things I can't do in the next future:
23:38 < ichthyo> care for session loading/saving, object serializing, (storage backends)
23:38 < ichthyo> care for a db-based implementation of the asset manager and integration with external tools etc.
23:39 < ichthyo> care for the scheduler needed for doing any edit operations from the gui
23:39 < ichthyo> well...
23:39 < cehteh> :)
23:40 -!- raffa [n=raffa@212.45.157.169] has joined #openvideo
23:40 < cehteh> raffa will do it :P
23:40 < ichthyo> small personal note to thos new to the project:
23:40 < raffa> Uh?  ;-)
23:41 < ichthyo> I do other projects in parallel, primarily sound recording (classical music)
23:41 < ichthyo> thats, why from time to time I seem to disappear for some weeks
23:41 < ichthyo> (sometimes tight deadlines there)
23:42 < ichthyo> and of course i have a work job to earn a living (doing software development, financial context...)
23:42 -!- tester [n=tester@125.34.161.252] has joined #openvideo
23:42 < ichthyo> ok...
23:43 < cehteh> so about the things to do ... serializaton backend is sometime on my schedule, but thats ahead and if someone else helps or takes over it would be ok
23:43 < ichthyo> cehteh: maybe you continue with backend plans
23:44 < cehteh> db backend too .. but here even less priority
23:44 < ichthyo> tell something about your cache ideas
23:44 < cehteh> yes
23:44 < cehteh> well first of all, the ones who looked at my git repository might have noticed that i didnt do anything since october
23:45 < cehteh> thats because i had other things to do and now i am working on the webgit mentioned earlier which will be used for the cin3 infrastructure
23:46 < cehteh> kudos to goibhniu who does the web design work :) ... and if anyone wants to help there, would be nice but it is slightly unrelated to cin3
23:46 < cehteh> it should be useable in about 2 weeks i hope and then i continue with cin3
23:46 < cehteh> .. now data backend:
23:46 < Plugh> ichthyo: Why a Prolog interpreter?
23:47 < cehteh> or first questions to ichthyo :)
23:47 < ichthyo> Plugh: can we discuss it later?
23:47 < Plugh> np.
23:47 < cehteh> or? :)
23:47 < cehteh> ok :P
23:47 < cehteh> data backend ... the idea is that the middle layer where ichthyo is workin on is completely stateless and all data is served from below
23:48 < cehteh> we speak of frames here even if this data might be some kind of metadata or temporary data from effects
23:49 < Dasypus> are configurations / node "options" (like fx settings) handled there aswell?
23:49 < cehteh> for the data backend its all the same .. a sequence of memory blocks
23:49 < cehteh> yes
23:50 < ichthyo> the builder delivers a complete network, ready-to-use
23:50 < pippin> are frames (video) always handled as single chunks of linear data (possible planes for chroma subsampling) or will things accomodate for processing of regions smaller than frames?
23:51 < cehteh> you can freely address things .. even inside frames
23:52 < cehteh> audio for example will be blocked for buffering .. but you still need to address single samples
23:52 < cehteh> the general idea is to take the memory management over by using mmap() .. 
23:53 < gmerlin> I think the question was more if they are passed around as complete frames, or in parts
23:53 < ichthyo> do we have an opinion on that yet?
23:53 < cehteh> thats why i asked you earlier if it is possible in gavl to seperate frames in channels
23:53 < pippin> yep, since it affects large parts of the processing design (as well as limitations on how far it scales)
23:54 < cehteh> but even if not, it wont cost anything to pass whole frames around
23:54 < gmerlin> Well once a generic one-channel support is threre, it's no problem
23:55 < gmerlin> You can extract /combine as you like
23:55 -!- luisbg [n=d33p@ubuntu/member/luisbg] has quit [Read error: 104 (Connection reset by peer)]
23:55 < cehteh> incoming footage will be readonly mmaped in huge chunks and the backend will do the best to schedule/prefetch data
23:55 < pippin> cehteh: ideally I wouldn't want things to bork when editing 7680x4320 4:4:4
23:55 -!- luisbg [n=d33p@ubuntu/member/luisbg] has joined #openvideo
23:56 < cehteh> yes ...  temrorary data will be backed by files and thus swapped out ... but this swapout and size of temporary data is monitored and adjusted on load .. and all temporary data is kept as most-recent-used cache dicipline
23:57 < cehteh> when you have gigantic frames it cant handle that much in memory .. but actually if you overload your hardware i cant help you
23:58 < cehteh> well in some extent the scheduler might help
23:58 < pippin> cehteh: ok, that is a design principle then, frames sizes shouldn't be much more than ~40% of RAM
23:58 < ichthyo> so, basically you don't want to tile the memory, but stay by whole blocks
23:58 < cehteh> yes
23:58 < cehteh> or even much biggier ... 
23:59 < pippin> (40% being an optimistic estimate, since you often will need multiple frames in memory)
23:59 < cehteh> for incoming footage on a 64 bit machine i could mmap many GB's 
23:59 < cehteh> not everything needs to stay long time in cache
--- Log closed Sat Feb 02 00:00:17 2008