On Thu, Feb 17, 2011 at 6:55 AM, <[email protected]> wrote:

> On Fri, February 11, 2011 14:26, Harrie Hoogeveen wrote:
> > On Fri, Feb 11, 2011 at 10:12 AM, <[email protected]> wrote:
> >
> >> On Thu, February 10, 2011 19:26, Harrie Hoogeveen wrote:
> >> >> Reply to:
> >> >> OK, but why are you using yuv_to_v4l ? Is there some reason you can't
> >> >> use
> >> >> the v4l_output in LiVES directly ?
> >> >>
> >> >>
> >> >> Regards,
> >> >> Gabriel.
> >> >
> >> > First, sorry for the crappy response style. My list settings were
> >> still
> >> on
> >> > digest so I missed your message and I can not use the reply button
> >> > properly.
> >> > I fixed that now.
> >> >
> >> > I was not aware of a v4l_output in LiVES. I see now. I use version
> >> 1.3.3
> >> > at
> >> > the moment, Gentoo build. I checked the change log, "Added vloopback
> >> > playback module." in 1.3.5, I was looking for v4l instead of
> >> vloopback.
> >> > This
> >> > should be it. I will update. Thank you very much.
> >> >
> >> > Regards,
> >> > Harrie
> >>
> >> OK, no worries. Try with the new output plugin and see if it works any
> >> better for you.
> >>
> >> Regards,
> >> Gabriel.
> >>
> >
> > I upgraded to 1.3.10, ebuilds and patches here:
> > http://bugs.gentoo.org/show_bug.cgi?id=344457
> > And if I configure YUV color space for the vloopback output stream all
> the
> > colors are fine.
> > But if if I configure the RGB24 color space, the color's are mixed. Also
> > for
> > xawtv.
> > So I am fine and happy building my pd patch, but maybe you should take a
> > look at the RGB24 color space. It seems something go's wrong in the
> > conversion of the colors.
> >
>
> OK, it may be something to do with endianness, I will check into it once
> you make the patches available.
>
>
> > I had one more question.
> > I want to launch 5 instances of lives like:
> > lives-exe -nogui -set set1 -oscstart 9995&
> > lives-exe -nogui -set set2 -oscstart 9996&
> > lives-exe -nogui -set set3 -oscstart 9997&
> > lives-exe -nogui -set set4 -oscstart 9998&
> > lives-exe -nogui -set set5 -oscstart 9999&
> >
> > Next I would be able to load clip, and set full/separate screen through
> > oscp, but they will all be using the same configured video device.
> >
> > I want each instance to output the vloopback stream to a different video
> > device.
> > /etc/modprobe.d/vloopback.conf:
> > options vloopback pipes=5
> >
> > ls /dev/video*
> > /dev/video0  /dev/video2  /dev/video4  /dev/video6  /dev/video8
> > /dev/video1  /dev/video3  /dev/video5  /dev/video7  /dev/video9
> >
> > How would I start different instances with other configuration properties
> > for the output stream?
> > Would this be possible to set using oscp?
> >
> > Regards,
> > Harrie
> >
>
>
> LiVES stores the video playback device settings in a file called
> ~/.lives-dir/vpp_defaults, however this file is only updated when LiVES
> exits. So what you can do is, start lives, set the first video device,
> quit the application. Then copy the file, e.g.
>
> cp ~/.lives-dir/vpp_defaults ~/.lives-dir/vpp_defaults_dev_video0
>
>
> then start up LiVES, set the second video device, exit and:
>
>
> cp ~/.lives-dir/vpp_defaults ~/.lives-dir/vpp_defaults_dev_video1
>
>
>
> Then you can do the following:
>
> cp ~/.lives-dir/vpp_defaults_dev_video0 ~/.lives-dir/vpp_defaults
> lives-exe -nogui -set set1 -oscstart 9995&
>
>
> cp ~/.lives-dir/vpp_defaults_dev_video1 ~/.lives-dir/vpp_defaults
> lives-exe -nogui -set set2 -oscstart 9996&
>
> etc.
>
>
> Also note that as of the current svn version, the default port for LiVES
> OSC has been changed from 9999 to 29999. This is because udp port 9999 is
> a reserved
> port, and I was advised by IANA to use a port in the unassigned range.
> However unless you are running this over the public internet it doesn't
> really matter which port numbers you use.
>
> One thing you might consider though is leaving a larger gap (3 or more)
> between the port numbers you are using. This is because traditionally,
> port nnnnn is used for the command socket, port nnnn-1 is used for the
> status socket, and port nnnn-2 is used for the notify socket. This is
> important in case you want to implement these features in the future.
>
> Anyway, I hope you will make your patches available as promised. I will be
> giving a short course on pd and LiVES in a few weeks, and I am interested
> to see how you are handling the video output from LiVES in pd.
>
> Regards,
> Gabriel,
>
>
Yes, I discovered that just yesterday :)
I made this script:

#!/bin/bash
sudo modprobe vloopback
qjackctl&
sleep 2
cp ~/.lives-dir/vpp_defaults.vid0 ~/.lives-dir/vpp_defaults
lives-exe -nogui -set set1 -oscstart 9995&
sleep 5
cp ~/.lives-dir/vpp_defaults.vid2 ~/.lives-dir/vpp_defaults
lives-exe -nogui -set set2 -oscstart 9996&
sleep 5
cp ~/.lives-dir/vpp_defaults.vid4 ~/.lives-dir/vpp_defaults
lives-exe -nogui -set set3 -oscstart 9997&
sleep 5
cp ~/.lives-dir/vpp_defaults.vid6 ~/.lives-dir/vpp_defaults
lives-exe -nogui -set set4 -oscstart 9998&
sleep 5
cp ~/.lives-dir/vpp_defaults.vid8 ~/.lives-dir/vpp_defaults
lives-exe -nogui -set set5 -oscstart 9999&
sleep 5
pdextended -lib Gem -jack -alsamidi LiVES_realtime_videomapping.pd

I will update the port numbers later.

I am still working on the patch. It cost some time to make a good object
placement interface. I make one based on the behringer bcr2000 controller
and I will shoot a small video to demonstrate it. Also the video will give
better opportunity to discus issues and structure of the patch. It also
contains oscp effect sequencers, but they still have some behavioral
problems. Will keep you updated.

Wanted to thank you also for the great work you have done on LiVES so far.
Things LiVES made possible:
http://vimeo.com/17566024
http://www.youtube.com/watch?v=YO73pOonLrk
http://www.youtube.com/watch?v=-hdcYN5jg9k
http://www.facebook.com/album.php?aid=56942&l=1aa4baa0ec&id=132071736818286

Doh it still is a hobby which I have to do in the late extra hours and costs
me more money I get out of it, I have the feeling soon the tables will turn.
:)

Regards,
Harrie

more material made with LiVES: http://vimeo.com/harriebo/videos
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Lives-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lives-users

Reply via email to