Hi Ross, Thanks for your help, I modified a few things and was able to make more progress. The stream can now be initialized and received, but it blocks there:
Received 185 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Sun, Oct 06 2019 13:25:06 GMT Range: npt=0.000- Session: A3020FA1 RTP-Info: url=rtsp:// 10.0.0.4:8554/testStream/track1;seq=41164;rtptime=366779134 Started playing session Receiving streamed data (signal with "kill -HUP 56216" or "kill -USR1 56216" to terminate)... Nothing happens afterwards and when I look at the H264 files created, they are indeed empty (despite my firewall being off). I also realized that RTSP streams over TCP, but I would need to stream over UDP, how should I convert? I really appreciate your help! Cheers, Philippe Noël <https://www.linkedin.com/pub/philippe-no%C3%ABl/124/284/148> AB Candidate in *Computer Science - Mind, Brain, Behavior*, Secondary in *Economics* Harvard College Class of 2020 857.272.9715 | philippe_n...@college.harvard.edu | www.philippemnoel.com On Sat, Oct 5, 2019 at 10:52 PM Ross Finlayson <finlay...@live555.com> wrote: > > > > On Oct 5, 2019, at 7:40 PM, Philippe Noël < > philippe_n...@college.harvard.edu> wrote: > > > > Hi Ross, > > > > It is not that, I tried turning off my firewall and it didn't work. The > fact is, with or without the firewall, the rtsp url from my application > doesn't move further than what I showed earlier, while a test url stream > like rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov > works without a problem, both with openRTSP and VLC. > > > > Any ideas? > > OK, the only other thing I can think of is that - for some reason - your > server’s code is not returning to the LIVE555 event loop to handle the > incoming TCP connection. This might happen if your device/encoder-handling > code has an infinite loop, or a ‘polling loop’ somewhere (perhaps while > waiting for an encoded frame/NAL unit to become available). You must not > do this! Remember that LIVE555-based applications are event based, using > an event loop for concurrency. If a frame/NAL unit is not *immediately* > available to be delivered, then your “doGetNextFrame()” implementation > *must* return immediately, so that the event loop can handle events (such > as incoming TCP connections). > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
