[Live-devel] Live555 HLS Proxy to Web Server

[Hunter Chisholm]

All my comments are on top.

The RTSP over TCP was the switch that was needed to actually start reading the RTSP feed and generating the m3u8 file, the .ts files were zero in size until I changed to RTSP over TCP.  Since this was the first time using, I did not know if something should have followed:

Beginning to read...
[URL:"rtsp://user:pass@67.x.x.x:4300/s2/"]: Started playing session...



While I caught the:

"cd" to a directory that's accessible by your web server (e.g., /usr/local/www/apache24/data )

It didn't make sense to me the server would read this document, which is the simple bit I was missing.

Anyway, works great and now I can move forward with my project.

Thank you very much.

Hunter


>> 
>> On Mar 9, 2023, at 4:04 AM, Hunter Chisholm via live-devel <live-devel at us.live555.com> wrote:
>> 
>> I think I am missing something very basic here but I can't find the answer on the web. I have a live h.264 IP camera stream being read by live555HLSProxy and an Nginx caching proxy server and web server. What I can't figure out is how to get the HLSProxy output to the Nginx server.
> 
> Yes, what you?re missing is that the ?LIVE555 HLS Proxy? - ***if (and only if)*** the connection to the back end RTSP stream is working properly - writes a ?.m3u8? file (and media transport stream segments) to the directory from which you ran the command.  That?s why the instructions say:
> 	"cd" to a directory that's accessible by your web server (e.g., /usr/local/www/apache24/data )
> 
> 
>> /usr/local/bin/live555HLSProxy rtsp://user:pass@67.x.x.x:4300/s2 test
>> 
>> This is the result of above:
>> 
>> LIVE555 HLS Proxy, documented at http://www.live555.com/hlsProxy/
>> (LIVE555 Streaming Media version 2023.01.19)
>> [URL:"rtsp://user:pass@132.x.x.x:4300/s2/"]: Initiated the "audio/MPEG4-GENERIC" subsession
>> [URL:"rtsp://user:pass@132.x.x.x:4300/s2/"]: Set up the "audio/MPEG4-GENERIC" subsession
>> [URL:"rtsp://user:pass@132.x.x.x:4300/s2/"]: Initiated the "video/H264" subsession
>> [URL:"rtsp://user:pass@132.x.x.x:4300/s2/"] Set up the "video/H264" subsession
>> Beginning to read...
>> [URL:"rtsp://user:pass@132.x.x.x:4300/s2/"]: Started playing session...
> 
> Do you ever see a message like
> 	Wrote segment ?test001.ts? ?
> Followed by:
> 	Wrote index file ?test.m3u8"; the stream can now be played from a URL pointing to this file.
> ?
> 
> If not, then this means that you?re not receiving the RTSP/RTP stream.  This is often because there is a firewall - somewhere between the server and your computer - that?s blocking UDP (and thus RTP/UDP) packets.  In this case, you can access the stream by requesting RTP-over-TCP, by adding the ?-t? option.
> 
> You can test this by running our ?openRTSP? command-line RTSP client application; see http://live555.com/openRTSP/
> I.e., run:
> 	openRTSP rtsp://user:pass@67.x.x.x:4300/s2
> Do you see any output files?  If not, then instead try
> 	openRTSP -t rtsp://user:pass@67.x.x.x:4300/s2
> If you now see output files, then you can try also adding the ?-t? option to ?live555HLSProxy?; i.e., run
> 	/usr/local/bin/live555HLSProxy -t rtsp://user:pass@67.x.x.x:4300/s2 tes
> 
> 
>> On the Nginx side I have a proxy cache block setup to receive the RTMP stream from HLS Proxy on port 1935 and a server block to make it available to a browser. I have worked with the SOUT function in VLC for other streaming projects and I have FFMPEG examples of sending the RTMP stream but coming up short in HLS Proxy.
> 
> I don?t understand any of this, because our software has nothing to do with RTMP.
> 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>