"Relaying" video streams

Frank DiPrete fdiprete at comcast.net
Thu Nov 20 07:04:36 EST 2008



VirginSnow at vfemail.net wrote:
>> Date: Wed, 19 Nov 2008 08:22:15 -0500
>> From: Frank DiPrete <fdiprete at comcast.net>
>> Cc: GNHLUG mailing list <gnhlug-discuss at mail.gnhlug.org>
> 
>> 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?

you don't - it's a live stream without end. Apache will send the output 
chunked.

> 
>>   $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 at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
> 


More information about the gnhlug-discuss mailing list