--- Begin Message ---
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-de...@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/
> 


--- End Message ---
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to