LiVES Survey

headers salsaman | 27 Apr 2013 20:05

_______________________________________________
piksel-dev mailing list
piksel-dev <at> piksel.no
http://piksel.no/cgi-bin/mailman/listinfo/piksel-dev
http://www.piksel.org

_______________________________________________
piksel-dev mailing list
piksel-dev <at> piksel.no
http://piksel.no/cgi-bin/mailman/listinfo/piksel-dev
http://www.piksel.org

We invite you to work in the remote assistant position.

This work takes 2-3 hours per week and requires absolutely no investment.
The essence of this work for incoming client requests in your city.
The starting salary is about ~2000 Euro per month + bonuses.

You get paid your salary every 2 weeks and your bonuses after fulfilling each task!

We guarantee work for everyone. But we accept applications this week only!
Therefore, you should write a request right now. And you will start earning money, starting from next week.

Please indicate in the request:
Your name:
Your email address:
City of residence:

Please send the request to my email Domingo <at> jobnorwayno.com and I will answer you personally as soon as possible

Sincerely,
Domingo Hood

_______________________________________________
piksel-dev mailing list
piksel-dev <at> piksel.no
http://piksel.no/cgi-bin/mailman/listinfo/piksel-dev
http://www.piksel.org

Just a test to see if this list has survived..;)

cheers
-gisle

--

-- 
Gisle Frøysland
Piksel Produksjoner
Georgernes Verft 12, 5011 Bergen, Norway
mob. 90665018 - mail: gif <at> piksel.no

|||||||||||||||||||||||||||||||||||||||||||||||||||
Piksel10 - 18-21 nov. 2010
www.piksel.no
|||||||||||||||||||||||||||||||||||||||||||||||||||

_______________________________________________
piksel-dev mailing list
piksel-dev <at> piksel.no
https://piksel.no/mailman/listinfo/piksel-dev
http://www.piksel.org

A renewed effort has begun towards the goal of Open Media Control - a
standardised cross-application syntax for OSC in various multimedia apps.

Feel free to jump in and contribute.

http://openmediacontrol.wetpaint.com/

Regards,
Salsaman.
http://lives.sourceforge.net

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

Hi all,
is there a formula for gamma correction in YUV space ? I would imagine it
would be something like:

Y clamped -> Y unclamped -> multiply by gamma_factor

where gamma_factor is the usual R -> R`, G -> G`, B -> B` factor.

Is that correct ?

Cheers,
Salsaman.
http://lives.sourceforge.net

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

On Tue, October 28, 2008 09:05, forum::für::umläute wrote:
> Carlo E. Prelz wrote:
>> 	Subject: [piksel-dev] question about dlopen()
>> 	Date: mar 28 ott 08 04:52:03 +0100
>>
>> Quoting salsaman <at> xs4all.nl (salsaman <at> xs4all.nl):
>>
>>> suppose I have a plugin which is loaded with dlopen(). The manpage of
>>> dlopen states that each time dlopen() is called, the same handle is
>>> returned - i.e. the plugin is "shared", including all of its static
>>> data.
>>> What I would like is each time dlopen is called to get a *new* copy of
>>> the
>>> lib. The reason is that there is some static data which must be unique
>>> for
>>> each instance of the plugin.
>>>
>>> Does anybody have an idea how to do this - or failing this, how can I
>>> make
>>> the static data be unique for each instance of the plugin ?
>>
>> The reason for existence of dynamic libraries is that you'd load just
>> one copy in memory for multiple applications. The first time you
>> request a .so object, it is loaded in memory, the following times you
>> get a pointer to the data that's already loaded. Static data are
>> contained inside the dynamic library - how could they be different?
>
> but it's a different thing to share one dylib between multiple
> applications and one application opening a single dylib multiple times.
> i always thought the reason for dylibs was the first case.
> i thin kthe 2nd case is not at all handled by the dylib mechanism...
>

Yes, right - I want the "load at runtime" feature of dynamic libs, but not
the "only load one copy" "feature".

>
>>
>> If you want different static data (strings? numbers?) I believe the
>> only way is to create multiple copies of your .so file, with
>> different names, by linking each one with a different small object
>> file containing different static data. This may work for a small
>> number of instances. I can easily think about a script that would
>> generate the copies.
>>
>> Obviously, each copy would occupy its own space in memory.
>
> i think this sounds awfully hackish (and i mean this in a not-positive
> way).
> i would suggest using non-static data in the dylibs in the first place.
> that is: ues a "constructor" like mechanism to initialize your data
> instance.
>
> for this you will obviously have to have access to the dylib's code (and
> modify it if it really uses static data)
>

Well, the best solution I have come up with so far is for the host to pass
in different identifiers to the plugin each time it calls a function in
the plugin. This identifier is then used as a key to look up which copy of
the static data to use. This is far from ideal - it requires that the host
generate and store a unique id for each instance of the plugin. It adds an
extra parameter to the plugin functions, and it requires that the plugin
search through multiple copies of the static-data struct and then
reference whichever one matches the host supplied identifier.

Since the plugins are relatively small (a few 10's of K) I would prefer
that each dlopen() load a new instance of the lib and return a different
handle.

Salsaman.

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

Hi all,
suppose I have a plugin which is loaded with dlopen(). The manpage of
dlopen states that each time dlopen() is called, the same handle is
returned - i.e. the plugin is "shared", including all of its static data.
What I would like is each time dlopen is called to get a *new* copy of the
lib. The reason is that there is some static data which must be unique for
each instance of the plugin.

Does anybody have an idea how to do this - or failing this, how can I make
the static data be unique for each instance of the plugin ?

Salsaman.

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

It may be related to FreiOr:
http://www.kdenlive.org/mantis/view.php?id=249

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

Dear Friends,

Kdenlive 0.7, a major step in video editing under GNU/Linux, will soon
be released. Kdenlive relies on MLT and therefore FreiOr for video
effects. You can check the project here: http://www.kdenlive.org.

The problem is that FreiOr does not seem to compile under AMD64
platform. A patch was sent on the ML, but never applied.

Could you release a stable tarball.
Or explain me how to use darcs.

So that maintainers of different GNU/Linux distribution (i.e. Christian
Marillat for Debian) can include FreiOr plugins in their distribution.

This is rather urgent.

Kind regards,
Jean-Michel Pouré

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

On Wed, August 6, 2008 23:39, Kentaro Fukuchi wrote:
> Hi,
>
> As you know, dividing a task into several sub-tasks and distributing them
> to
> several processes is known as good solution. That is the reason why I like
> the approach of Jack and vJack.
>
> In such case you have to add Inter-Process-Communication functions to your
> software. And of course, it is better to use existing widely-used protocol
> or library as possible than coding your own, no-tested, simple but
> non-flexible
> networking routine.
>
> So there is a question. If you want to use IPC over the network (IP), what
> is the better solution for that?
>
> Socket programming from scratch? Oh dear, it is 21st century. You have to
> care of the byte-order, size of your integer, error handling, timeout,
> buffer-overflow, etc., etc.
>
> Opensound control is one of the good protocols because it is widely used
> and easy to code. But it is mainly designed for one-way data passing.
> Query-and-result style of communication does not fit on OSC.
> # Actually you can do two-way IPC via OSC by using special addres "#reply"
> # that is employed by some OSC libraries, but it's still complicated.
>
> Do you know any better solution for this? I would like to code the IPC
> like this:
>
> Me: Hey computer, send "give me data" to that process!
> Com: Yes sir - he returned two integers and one string. The first integer
> is...
>
> best regards,
>
> Kentaro
>

Hey Kentaro,
I just noticed this on freshmeat:

https://public.msli.com/lcs/muscle/index.html

maybe of some interest to you as well ?

Regards,
Salsaman.
http://lives.sourceforge.net

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

1	April 2013
1	February 2013
1	November 2012
1	April 2010
1	December 2008
2	November 2008
18	October 2008
1	September 2008
6	August 2008
1	July 2008
3	June 2008
2	October 2007
2	September 2007
4	August 2007
1	July 2007
2	May 2007
32	March 2007
5	February 2007
58	December 2006
2	November 2006
10	October 2006
1	June 2006
1	February 2006
232	October 2005
9	September 2005
23	August 2005
3	July 2005
12	June 2005
19	May 2005
15	April 2005
1	March 2005
1	February 2005
6	January 2005
3	December 2004
442	November 2004
269	October 2004
31	September 2004
317	August 2004

LiVES Survey

LiVES Survey

compile dylib and FFmpeg support (OS X 10.6+)

We invite you to earn from 100 Euro per hour in your spare time.

test

Open Media Control documentation

Gamma correction in YUV space

Re: question about dlopen()

question about dlopen()

Water effect startup bug

Please release a stable version of FreiOr

Re: better libraries for IPC?

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30