Re: "Relaying" video streams
Seth Cohn wrote: >> I think we sorta solved it. I only want one stream going out, and then >> the "repeater" (PHP) will repeat it to multiple clients. >> > > I've sent Bruce the scripts that my coworker wrote, which use curl, > ffmpeg, and ffserver, and certainly the same idea with VLC and other > 'server' software could be substituted. > > I think the question is going to be stability, memory and cpu usage > (per client, per stream, per feed, etc). > The same basic principles will be used regardless, it's mostly a > matter of what works best (best being maximized good/fast/cheap where > the variables would be cpu/bandwidth/crashes/etc > Given past experience, I believe you are correct! > Bruce, sounds like you can experiment and see what works best in a > real world setup, so maybe a good page documenting it for future open > source webcammers? > That's in my plan. And possibly a presentation. I *hope* to get to this during the holiday season; its the only chance I have to get the necessary testing done. (Seems "retirement" didn't free up as much time as I thought it would.) --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: CALL FOR HELP: Video record of the Thr 20 Nov Nashua meet?
Okay, I think this is coming together. Someone has volunteered a camcorder. It even has a mic input. Someone else has volunteered a tripod. I'm going to borrow a wireless handheld microphone from work. (For... field testing. Yah, that's the ticket.) It's nothing special, but it works. I've already borrowed a mic stand from a friend. I'll bring power strips, extension cords, and various cables and adapters. I've got tons of that crap. Thanks, everybody! -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
On Wed, Nov 19, 2008 at 8:42 PM, Bruce Dawson <[EMAIL PROTECTED]> wrote: > Thomas Charron wrote: >> I dunno, but you web cams right now aren't in a happy state. Apache >> default directories and the such. :-D > Right. I just shutdown the Apache proxies so we could have some > bandwidth. Seems someone jumps on the cameras within minutes of setting > up the proxies. It would be OK if they were on for a minute or two, but > they're camping out, and they're usually from residental IPs. Then, > after a few hours, I've got about 6 users on them. Hrm, you sure you didn't end up on some webcam 'indexer' site that has a direct link to your webcams? -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
> I think we sorta solved it. I only want one stream going out, and then > the "repeater" (PHP) will repeat it to multiple clients. I've sent Bruce the scripts that my coworker wrote, which use curl, ffmpeg, and ffserver, and certainly the same idea with VLC and other 'server' software could be substituted. I think the question is going to be stability, memory and cpu usage (per client, per stream, per feed, etc). The same basic principles will be used regardless, it's mostly a matter of what works best (best being maximized good/fast/cheap where the variables would be cpu/bandwidth/crashes/etc Bruce, sounds like you can experiment and see what works best in a real world setup, so maybe a good page documenting it for future open source webcammers? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Thomas Charron wrote: > I dunno, but you web cams right now aren't in a happy state. Apache > default directories and the such. :-D > Right. I just shutdown the Apache proxies so we could have some bandwidth. Seems someone jumps on the cameras within minutes of setting up the proxies. It would be OK if they were on for a minute or two, but they're camping out, and they're usually from residental IPs. Then, after a few hours, I've got about 6 users on them. --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Thomas Charron wrote: > On Tue, Nov 18, 2008 at 8:06 PM, Bruce Dawson <[EMAIL PROTECTED]> wrote: > >> We've got several web cams that people like to visit >> (www.milessmithfarm.net). However, they're chewing up bandwidth when >> more than one person at a time views them. >> Is anyone aware of a Linux based video re-broadcaster (either software >> or a service)? >> We'd like to upload the video streams to a single server that multiple >> people can connect to and view them. This way, we're only sending one >> video stream up to the server, and the server can rebroadcast it to all >> the connected clients. >> > > I can't speak for their use for your purposes (I cant go check right > now, firewall says apperently webcams aren't work related, go figure), > but I did search thru my email when talking to someone else in the > past about this very subject. > > http://camstreams.com/ > > Interesting service, and looks like something I want - except it requires the "broadcaster" (me) to run the camstreams encoder on a Windows box. I don't mind encoding for such a service, but I don't want to run Windows. It must run on either Linux or Unix. --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Ben Scott wrote: > On Wed, Nov 19, 2008 at 12:52 AM, Ben Scott <[EMAIL PROTECTED]> wrote: > >> Sure. Just multicast, for that matter. The problem is that >> effectively zero public routers forward multicast datagrams ... >> > > FYI, I did find some resources on this: > > Multicast over TCP/IP HOWTO (1998) > http://tldp.org/HOWTO/Multicast-HOWTO.html > > RFC-3170: IP Multicast Applications: Challenges and Solutions (2001) > http://www.apps.ietf.org/rfc/rfc3170.html > Thanks, but I seem to remember a message indicating that the RFC's "expired" and the multicast addresses have been re-purposed. I'm not sure about that though - it may have occurred in a [bad] dream. However, your earlier point about public routers forwarding multicast datagrams is well taken, so I don't think multicast will work for the joe-beer-drinker or mom-and-pop crowd (which seem to be the main audience for these webcams). --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Bill Mullen wrote: > On Wed, 19 Nov 2008 07:38:05 -0500, > Bruce Dawson wrote: > > >> VirginSnow wrote: >> Date: Tue, 18 Nov 2008 20:06:35 -0500 From: Bruce Dawson We'd like to upload the video streams to a single server that multiple people can connect to and view them. This way, we're only sending one video stream up to the server, and the server can rebroadcast it to all the connected clients. >>> No matter where the server is, sending a fresh unicast copy to every >>> client will consume (ie, waste) bandwidth. >>> >> True, but the idea is to stream to multiple clients from an ISP that >> supports a high outgoing bandwidth, and to provide that stream from an >> ISP connection that doesn't (like DSL/broadband/...) The "high output" >> ISP would, in effect, become a "repeater". >> > > Perhaps VLC is the right tool for the job? > > http://wiki.videolan.org/Documentation:Streaming_HowTo > > >From a quick glance, it looks as if running VLC on said server would > allow you to have it connect from there to your source streams, and then > make those streams available to clients connecting to it from the WAN. > > HTH! > > I've looked at VLC and VLM, but can't tell if those will do what I want. I suspect it will stream without a problem, but I can't determine if it will allow multiple clients to attach to the same stream. --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Frank DiPrete wrote:
> Bruce Dawson wrote:
>
>> We've got several web cams that people like to visit
>> (www.milessmithfarm.net). However, they're chewing up bandwidth when
>> more than one person at a time views them.
>>
>> Is anyone aware of a Linux based video re-broadcaster (either software
>> or a service)?
>>
>> We'd like to upload the video streams to a single server that multiple
>> people can connect to and view them. This way, we're only sending one
>> video stream up to the server, and the server can rebroadcast it to all
>> the connected clients.
>>
>> --Bruce
>>
>
> It sounds like the sources are live streams (web cams) and not files
> that can be uploaded to another server for download / viewing.
>
> A multi unicast scenario.
>
...
The above is correct.
> But we haven't solved the original problem yet.
> Item 1) starts a stream from the webcam so you still pound your uplink
> for each request, but a little program logic may work here.
>
I think we sorta solved it. I only want one stream going out, and then
the "repeater" (PHP) will repeat it to multiple clients.
> I've done this sort of thing with php.
> These code examples are for an flv source for a youtube re-creatiom
> problem I worked on recently, but you would just change the mime / file
> type.
>
> Your server could:
>
> 1) anchor the stream with php curl
>
> function proxy_stream($flv_url) {
>
> $curl_handle=curl_init();
> curl_setopt($curl_handle, CURLOPT_URL, $flv_url );
> curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,3);
> curl_exec($curl_handle);
> curl_close($curl_handle);
>
> }
>
> 2) take that output to a pipe and shove it down the browser's throat
> The important bit is the fpassthru function so as not to mangle the
> stream but just send it out again raw.
>
> function transmit_stream($flv_file) {
>
> $pos = 0;
>
> header("Content-Type: video/x-flv");
> header('Content-Length: ' . filesize($flv_file));
> $fh = fopen($flv_file,"rb");
> fseek($fh, $pos);
> fpassthru($fh);
> fclose($fh);
>
> }
>
> The trick now it to connect the ouput pipe from curl into the retransmit
>function instead of operating on files. If a pipe from a webcam in
> proxy_stream() is already open, then don't call the curl function. In
> theory it would work (haven't tried it yet)
>
> Including a player frame on the server page is another added fun bit.
> I used flowplayer and ffmpeg.
>
>
OK. Thanks. I'll play with those. I'll probably "pipe" the output from
"proxy_stream" to shared memory so there will be only one connection.
Then have transmit_stream copy from the shared memory to the client.
This will avoid the problem of Apache/PHP creating a new proxy_stream
for each connection.
However, I'm concerned about corrupting data streams to the client if a
PHP process was unable to send out a shared memory segment.
--Bruce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: CALL FOR HELP: Video record of the Thr 20 Nov Nashua meet?
On Wed, Nov 19, 2008 at 4:22 PM, Mark E. Mallett <[EMAIL PROTECTED]> wrote: > I had thought to offer my little mini-DV camcorder, but I think it would > probably be an option of last resort ... We have luckily just recently had someone else step forward with an offer of a camcorder. So thank you, but I think you escaped this time. ;) > ... mainly because it doesn't have an external microphone jack (so the > sound would really be poor in that environment) ... If we had to, we could always record to a separate device, and sync A/V after the fact. That's why they invented clapperboards. Fortunately, it seems we won't have to. > ... nor do I have a tripod. We have also had someone else step forward with an offer for one of those. Amazing what happens when we work together. ;-) Thanks again, all! -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: CALL FOR HELP: Video record of the Thr 20 Nov Nashua meet?
On Wed, Nov 19, 2008 at 12:29:06AM -0500, Ben Scott wrote: > On Mon, Nov 17, 2008 at 10:13 PM, Ben Scott <[EMAIL PROTECTED]> wrote: > > In particular, it would be really good if someone could bring a > > decent quality video camera/recorder. (By "decent" I just mean "home > > movie". Better than "cell phone" or "$99 web cam" is what I'm after.) > > Anyone? Anyone? Bueller? I had thought to offer my little mini-DV camcorder, but I think it would probably be an option of last resort -- mainly because it doesn't have an external microphone jack (so the sound would really be poor in that environment), nor do I have a tripod. Not to mention that I probably won't be there and I don't really know how to get it to anyone other than having them come to the office. Nevertheless, there's an offer, weasly as it is. mm ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Assistance with archival script
On Wednesday 19 November 2008 14:21, Matt Snell wrote:
> find . -mindepth 1 -maxdepth 1 -type d -exec echo /usr/bin/7z a -t7z -mx=0
{}.7z {} \;
> What I want to do is prevent find from outputting "." as a directory as
I added a mindepth argument to your find above. That will keep it from
outputting . in the list and restrict only to the directories within the
current directory.
-N
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Assistance with archival script
>
> #!/bin/bash
> DLDIR='/var/lib/samba/shares/xfer/All Downloads/incoming/'
> cd "$DLDIR"
> find . -maxdepth 1 -type d -exec echo /usr/bin/7z a -t7z -mx=0 {}.7z {} \;
>
Not that you _can't_ do it with find, but if I'm understanding your goal,
I'd do it like this (not 100% tested):
for i in *; do
if [ -d "$i" ]; then
/usr/bin/7za a -t7z mx=0 $i.7z $i
fi
done
The [ -d ] tests to see if something is a directory. $i is in
quotes there in case there are spaces in any of the file/directory names
that the test is checking (actually in retrospect, then the $i
s in the 7z command line probably need to be quoted for the same reason,
ignore the quotes altogether if you are certain uyou have nothing with
spaces in the filename)
Anyway, just another way to look at the same problem. Wonderful thing about
shell scripting :)
-Shawn
>
> Here's what it returns:
>
> /usr/bin/7z a -t7z -mx=0 ..7z .
> /usr/bin/7z a -t7z -mx=0 ./oh four.7z ./oh four
> /usr/bin/7z a -t7z -mx=0 ./two.7z ./two
> /usr/bin/7z a -t7z -mx=0 ./three.7z ./three
> /usr/bin/7z a -t7z -mx=0 ./one.7z ./one
>
> What I want to do is prevent find from outputting "." as a directory as
> it's creating a file named "..7z" with each of the subdirs within it. I've
> had no luck with the man pages and Google (or more likely my search phrases)
> has failed me. Could anyone point me in the right direction? I'm open to
> suggestion, if you know of a better way to get the job done, I'm all ears
> (eyes?).
>
> If you need more detail, please let me know.
>
> --
> MDS
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Assistance with archival script
find . -maxdepth 1 -type d | sed -e s/..// | while read f
do
echo /usr/bin/7z a -t7z -mx=0 "${f}".7z "${f}"
done
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Assistance with archival script
Hi all,
I need a little help with find, or if find can't do what I need, a pointer
to the right tool for the job. Some background; I've got a base directory
where I store multiple sub directories, I will eventually write the subdirs
to individual 7z files and archive. I'm trying to automate the process
some, here's what I've got for the (admittedly rudimentary) script (at this
point I'm just echoing the actual command to the console to see what would
happen)
#!/bin/bash
DLDIR='/var/lib/samba/shares/xfer/All Downloads/incoming/'
cd "$DLDIR"
find . -maxdepth 1 -type d -exec echo /usr/bin/7z a -t7z -mx=0 {}.7z {} \;
Here's what it returns:
/usr/bin/7z a -t7z -mx=0 ..7z .
/usr/bin/7z a -t7z -mx=0 ./oh four.7z ./oh four
/usr/bin/7z a -t7z -mx=0 ./two.7z ./two
/usr/bin/7z a -t7z -mx=0 ./three.7z ./three
/usr/bin/7z a -t7z -mx=0 ./one.7z ./one
What I want to do is prevent find from outputting "." as a directory as it's
creating a file named "..7z" with each of the subdirs within it. I've had
no luck with the man pages and Google (or more likely my search phrases) has
failed me. Could anyone point me in the right direction? I'm open to
suggestion, if you know of a better way to get the job done, I'm all ears
(eyes?).
If you need more detail, please let me know.
--
MDS
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
On Wed, 19 Nov 2008 07:38:05 -0500, Bruce Dawson wrote: > VirginSnow wrote: > >> Date: Tue, 18 Nov 2008 20:06:35 -0500 > >> From: Bruce Dawson > > >> We'd like to upload the video streams to a single server that > >> multiple people can connect to and view them. This way, we're only > >> sending one video stream up to the server, and the server can > >> rebroadcast it to all the connected clients. > > > > No matter where the server is, sending a fresh unicast copy to every > > client will consume (ie, waste) bandwidth. > > True, but the idea is to stream to multiple clients from an ISP that > supports a high outgoing bandwidth, and to provide that stream from an > ISP connection that doesn't (like DSL/broadband/...) The "high output" > ISP would, in effect, become a "repeater". Perhaps VLC is the right tool for the job? http://wiki.videolan.org/Documentation:Streaming_HowTo >From a quick glance, it looks as if running VLC on said server would allow you to have it connect from there to your source streams, and then make those streams available to clients connecting to it from the WAN. HTH! -- Bill Mullen RLU #270075 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ben Scott Saved Our Bacon (Was: GNHLUG is back on the Internet)
Due to my error, this fundable actually ends _tonight_ rather than on Monday as I had intended, so those who who have not contributed still have a chance to do so today. Per Ben's request we'll be donating the funds to a food pantry rather than ThinkGeek. Thanks to all who have contributed! -Bill On 2008-11-12 1:37 AM, Bill McGonigle wrote: > Ben spent tons of hours working on our server recovery and even took a > day off of work to get it back in action. He's the guy who really keeps > our online presence running and we'd still be dead in the water without > his efforts. > > I'm collecting funds here: > > http://tinyurl.com/ben-scott-saved-our-bacon > > to buy Ben a ThinkGeek gift certificate as a thank-you for all his > efforts, in the past two weeks and as always. If you can spare ten > bucks, please chip in for this fundable. It's set to run only 5 days, so > please contribute now. > > -Bill ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
On 2008-11-19 8:22 AM, Frank DiPrete wrote: > I've used Darwin and it works well for streaming stored files on > request - as long as they are 3gp's or mp4 mov's. I think there's _some_ way to do it, e.g. from the FAQ: "Q. Can I configure DSS to stream live .mp4, .3gp, or .mov streams to simulate a radio or tv station to connected users? Yes. Use the PlaylistBroadcaster that is part of DSS, to stream hinted files from a server side playlist to DSS. All video files must have the same frame size and use the same codec and all audio files must have the same sample size and use the same codec." I think with an all-macintosh solution you'd use Quicktime Brodcaster to create the RTSP stream; but I've never actually done this so it's just what I'm reading. I'll have an opportunity to use someting like this in May for a nonprofit centennial so I'll pay attention here. -Bill ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
On Wed, Nov 19, 2008 at 12:52 AM, Ben Scott <[EMAIL PROTECTED]> wrote: > Sure. Just multicast, for that matter. The problem is that > effectively zero public routers forward multicast datagrams ... FYI, I did find some resources on this: Multicast over TCP/IP HOWTO (1998) http://tldp.org/HOWTO/Multicast-HOWTO.html RFC-3170: IP Multicast Applications: Challenges and Solutions (2001) http://www.apps.ietf.org/rfc/rfc3170.html -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
On Tue, Nov 18, 2008 at 8:06 PM, Bruce Dawson <[EMAIL PROTECTED]> wrote: > We've got several web cams that people like to visit > (www.milessmithfarm.net). However, they're chewing up bandwidth when > more than one person at a time views them. > Is anyone aware of a Linux based video re-broadcaster (either software > or a service)? > We'd like to upload the video streams to a single server that multiple > people can connect to and view them. This way, we're only sending one > video stream up to the server, and the server can rebroadcast it to all > the connected clients. I can't speak for their use for your purposes (I cant go check right now, firewall says apperently webcams aren't work related, go figure), but I did search thru my email when talking to someone else in the past about this very subject. http://camstreams.com/ -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
> Date: Wed, 19 Nov 2008 08:22:15 -0500
> From: Frank DiPrete <[EMAIL PROTECTED]>
> Cc: GNHLUG mailing list
> function proxy_stream($flv_url) {
>
> $curl_handle=curl_init();
> curl_setopt($curl_handle, CURLOPT_URL, $flv_url );
> curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,3);
> curl_exec($curl_handle);
> curl_close($curl_handle);
>
> }
>
> 2) take that output to a pipe and shove it down the browser's throat
> The important bit is the fpassthru function so as not to mangle the
> stream but just send it out again raw.
>
> function transmit_stream($flv_file) {
>
> $pos = 0;
>
> header("Content-Type: video/x-flv");
> header('Content-Length: ' . filesize($flv_file));
Wait, how do you plan to get the content length for the stream?
> $fh = fopen($flv_file,"rb");
> fseek($fh, $pos);
> fpassthru($fh);
For those on the list who don't know PHP, "rb" means binary read-only;
fpassthru reads $fh to EOF and stuffs it into the output buffer.
> fclose($fh);
>
> }
>
> The trick now it to connect the ouput pipe from curl into the retransmit
>function instead of operating on files. If a pipe from a webcam in
> proxy_stream() is already open, then don't call the curl function. In
> theory it would work (haven't tried it yet)
This *might* work, if the stream was in a raw format and the
passthrough was done in blocks the size of a single video frame. The
clients might not like jumping into a video stream mid-frame (which
could happen if you just start sending them stream data whenever they
connect). The client would miss out on all the header information, as
well as loose frame sync. Some codecs might be able to recover from
such an extraordinary lack of metadata. It seems risky to depend on
that level of resilience in the codec.
One thing that might work is a SIP proxy (maybe Asterisk?) on a host
with high bandwidth available. A single transmission to the proxy,
which could then conference everyone else in. That could require
viewers to have videoconferencing software, which might be asking too
much.
Perhaps some kind of RPC to the server could be used to spawn a farm
of "mencoder" filters with "-aoc copy -ovc copy" and an appropriately
calculated "-sb" value.
Oh, I got it! (See? You can solve any problem if you talk to yourself
enough!)
Have the video source (whatever machine is pulling the mpeg) count the
bytes and frames. Then, every 5 seconds or so, transmit a sync report
to the proxy. The proxy can then calculate and pass that "-sb" to
mencoder. Giving the user the ability to join the feed with a 5
second resolution would probably be just fine.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
I dunno, but you web cams right now aren't in a happy state. Apache default directories and the such. :-D On Tue, Nov 18, 2008 at 8:06 PM, Bruce Dawson <[EMAIL PROTECTED]> wrote: > We've got several web cams that people like to visit > (www.milessmithfarm.net). However, they're chewing up bandwidth when > more than one person at a time views them. > > Is anyone aware of a Linux based video re-broadcaster (either software > or a service)? > > We'd like to upload the video streams to a single server that multiple > people can connect to and view them. This way, we're only sending one > video stream up to the server, and the server can rebroadcast it to all > the connected clients. > > --Bruce > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ > -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
Bruce Dawson wrote:
> We've got several web cams that people like to visit
> (www.milessmithfarm.net). However, they're chewing up bandwidth when
> more than one person at a time views them.
>
> Is anyone aware of a Linux based video re-broadcaster (either software
> or a service)?
>
> We'd like to upload the video streams to a single server that multiple
> people can connect to and view them. This way, we're only sending one
> video stream up to the server, and the server can rebroadcast it to all
> the connected clients.
>
> --Bruce
It sounds like the sources are live streams (web cams) and not files
that can be uploaded to another server for download / viewing.
A multi unicast scenario.
I don't know of an off the shelf open video streaming server that does
this. I've used Darwin and it works well for streaming stored files on
request - as long as they are 3gp's or mp4 mov's.
What your server would have to do is:
1) anchor the stream from the webcam
2) send it back out to the viewing client on request
This can start to get tricky if you want people to be able to view it on
a web page as opposed to using whatever native client they have. Viewing
it on a web page often is done with a flash app flv movie player (ie
re-creating youtube - some people may know what I mean by that ;) )
In that case your server would
1) anchor the stream from the webcam
2) transcode the stream to flv
3) use a flash flv player to display the video
But we haven't solved the original problem yet.
Item 1) starts a stream from the webcam so you still pound your uplink
for each request, but a little program logic may work here.
I've done this sort of thing with php.
These code examples are for an flv source for a youtube re-creatiom
problem I worked on recently, but you would just change the mime / file
type.
Your server could:
1) anchor the stream with php curl
function proxy_stream($flv_url) {
$curl_handle=curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $flv_url );
curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,3);
curl_exec($curl_handle);
curl_close($curl_handle);
}
2) take that output to a pipe and shove it down the browser's throat
The important bit is the fpassthru function so as not to mangle the
stream but just send it out again raw.
function transmit_stream($flv_file) {
$pos = 0;
header("Content-Type: video/x-flv");
header('Content-Length: ' . filesize($flv_file));
$fh = fopen($flv_file,"rb");
fseek($fh, $pos);
fpassthru($fh);
fclose($fh);
}
The trick now it to connect the ouput pipe from curl into the retransmit
function instead of operating on files. If a pipe from a webcam in
proxy_stream() is already open, then don't call the curl function. In
theory it would work (haven't tried it yet)
Including a player frame on the server page is another added fun bit.
I used flowplayer and ffmpeg.
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: "Relaying" video streams
[EMAIL PROTECTED] wrote: >> Date: Tue, 18 Nov 2008 20:06:35 -0500 >> From: Bruce Dawson <[EMAIL PROTECTED]> >> >> We'd like to upload the video streams to a single server that multiple >> people can connect to and view them. This way, we're only sending one >> video stream up to the server, and the server can rebroadcast it to all >> the connected clients. >> > > No matter where the server is, sending a fresh unicast copy to every > client will consume (ie, waste) bandwidth. True, but the idea is to stream to multiple clients from an ISP that supports a high outgoing bandwidth, and to provide that stream from an ISP connection that doesn't (like DSL/broadband/...) The "high output" ISP would, in effect, become a "repeater". --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: [GNHLUG] MerriLUG Nashua, Thur 20 Nov, Photographic prowess via Linux tools
Jim Kuzdrall wrote: > Who : Máirín Duffy, Interaction Designer, Red Hat Engineering > What : Techniques for creating and adjusting photos > Where: Martha's Exchange > Day : Thur 20 Nov **Tomorrow** > Time : 6:00 PM for grub, 7:30 PM for discussion > > At this point, 2 of us plan to attend. --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
[GNHLUG] MerriLUG Nashua, Thur 20 Nov, Photographic prowess via Linux tools
Who : Máirín Duffy, Interaction Designer, Red Hat Engineering What : Techniques for creating and adjusting photos Where: Martha's Exchange Day : Thur 20 Nov **Tomorrow** Time : 6:00 PM for grub, 7:30 PM for discussion :: Overview Máirín Duffy is back to demonstrate the powerful image creation and correction programs Linux provides. She covers several tasks and problems many of us have encountered. After, you may ask her expert advice on your own image problem -- make that "photo problem". - Removing tint from photos: Too blue? Yellowish cast? Máirín briefly reviews a procedure for removing unwanted tint from photos. - Resizing photos without cropping or distortion: Make your photo just a bit wider or a bit taller without making your Aunt Bea look fat or giving your boss a pointy head. The GIMP liquid rescale plug-in preserves the composition while changing the aspect ratio. Máirín shows how. ( http://duffy.fedorapeople.org/temp/lqr/ ) - Face painting: Turn your kids into snowflake-bejeweled elves and reindeer using this cool GIMP trick. No messy facepaint needed! Christmas cards? (See http://duffy.fedorapeople.org/temp/barbara.png ) - Screen prints from photos: Make solid color-area representation of your photo for a logo, icon, or poster. Inkscape turns you into a budding Andy Warhol - or better. Example: http://duffy.fedorapeople.org/temp/photo-to-vector/maasai-woman.jpg.png >>> RSVP to Jim Kuzdrall for dinner to assure adequate seating. <<< !!! If you are not a "Regular Attendee" (50%), please let me know. !!! Driving directions: http://wiki.gnhlug.org/twiki2/bin/view/Www/PlaceMarthasExchange Thanks, Jim Kuzdrall [EMAIL PROTECTED] ___ gnhlug-announce mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
