Re: [Live-devel] i want WEBRTC code of live555

2019-08-29 Thread Kevin Bailey
Webrtc is typically used in p2p applications. RTSP strikes me more as a server/client relationship which would be better suited for websockets. On Thu, Aug 29, 2019 at 9:06 AM Vishnu Mohan wrote: > Hi Ross, > >I was using HLS based transport streams for stream over HTTP, Some > times with so

[Live-devel] Is data parsed before being sent by live555

2019-02-25 Thread Kevin Bailey
I've noticed that if I made specific modification to my NAL units before passing them over to live555 (including totally randomizing the bits) the NAL unit will not be sent at all to the client. Does live555 parse NAL units prior to sending them out to clients? And if so how can I get live555 to st

Re: [Live-devel] Encrypting rtp stream

2019-02-22 Thread Kevin Bailey
I promise I won't feel entitled to any sort of encryption with RTSP. Like I said I'll implement it manually with libsodium. That being said, isn't the extra copy unavoidable? It seems that before any h264 NAL unit is passed to RTP, it first needs to be encrypted and have some sort of authentication

Re: [Live-devel] Encrypting rtp stream

2019-02-22 Thread Kevin Bailey
My plan was to just add a layer ontop of live555 like libsodium to handle my encryption. They also have options for handling dropped packets, something UDP is very susceptible to. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live5

[Live-devel] Encrypting rtp stream

2019-02-21 Thread Kevin Bailey
I am trying to encrypt my h264 packets sent with live555 using a pretty basic stream cipher. One of the main requirements of a stream cipher is that after a portion of a key is consumed to encrypt a bit of data that portion can never be used again. So because of this the amount of data being encryp

Re: [Live-devel] Cleanly close RTSP Server

2019-02-19 Thread Kevin Bailey
And I am also noticing now that netstat says that the rtsp port I am using is in the following state "FIN_WAIT2". After I kill my client then it moves to "TIME_WAIT". Which leads me to believe that the clean up code listed in testProgs/testRTSPClient.cpp does not sufficiently close the rtsp connect

[Live-devel] UDP RTSP Stream

2019-02-19 Thread Kevin Bailey
I wanted my RTSP stream to be UDP based not TCP based to take advantage of the latency advantage UDP has over TCP. However I noticed the following when I took a look at netstat while my program was running: ~# netstat | grep 8554 tcp0 0 x.x.x.x:8554wsip-x-x-x-x:39224 ESTABLISHED

Re: [Live-devel] Cleanly close RTSP Server

2019-02-19 Thread Kevin Bailey
My particular use case has my program started and stopped rapidly in short periods of time. But I can't start and stop it like this if I can't quickly re-bind to the rtsp port. Maybe this doesn't have anything to do with my clean up code? Is it related to this: https://live-devel.live555.narkive.co

[Live-devel] Cleanly close RTSP Server

2019-02-19 Thread Kevin Bailey
Hi all, in the code for testProgs/testOnDemandRTSPServer.cpp there is no code specified that should be used to clean up the RTSP server cleanly. testProgs/testRTSPClient.cpp actually does specify some code to clean up the program RTSP client. I have tried adding "Medium::close" and an "eventLoopWa

Re: [Live-devel] ] isCurrentlyAwaitingData

2019-02-07 Thread Kevin Bailey
I don't call "getNextFrame()" or "doGetNextFrame()" anywhere in my code... where is it being called from? On Thu, Feb 7, 2019 at 2:45 PM Ross Finlayson wrote: > In LIVE555 applications, a “FramedSource” (subclass) object can be read > from (using “getNextFrame()”) only once at a time. In other

Re: [Live-devel] ] isCurrentlyAwaitingData

2019-02-07 Thread Kevin Bailey
Okay, now is there any correlation between "doGetNextFrame()" being called by whatever process calls it and "isCurrentlyAwaitingData()" being set to true? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/l

[Live-devel] isCurrentlyAwaitingData

2019-02-07 Thread Kevin Bailey
What does this function do? I am not seeing any documentation on this. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] High CPU usage

2019-01-14 Thread Kevin Bailey
Hi! I have set up an RTSP server based on this code: https://github.com/RafaelPalomar/H264LiveStreamer. The program however jumps up to 100% CPU usage every time any client connects. Why might this be? I have even tried commenting out the x264 encode part (and I instead pass in empty nal units) to

Re: [Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
I also have discovered that this delay occurs when I stream from VLC. Which means this is likely not an issue my client is causing but rather something on the RTSP server end what could it be? ___ live-devel mailing list live-devel@lists.live555.com h

Re: [Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
Okay I have just incorporated a jitter buffer and It is working but there is still a very strange delay occasionally in the stream. It will buffer for a whole second before displaying any frame on the screen. I'm a bit lost now as to what could be causing this issue. Any advice? ___

Re: [Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
Firstly, I apologize for not cutting off previous replies in this email chain before replying. Also with the packets that come in with the identical presentation time (down to the millisecond) should I wait and collect them all together before passing them into the decoder or should I pass them in

Re: [Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
time that the frame should be rendered. Seems impossible On Thu, Jan 3, 2019 at 3:39 PM Ross Finlayson wrote: > > > > On Jan 4, 2019, at 12:29 PM, Kevin Bailey > wrote: > > > > What exactly does the presentation time entail? Is it actually the time > in which a fra

Re: [Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
disappear after any period of still frames. On Thu, Jan 3, 2019 at 3:22 PM Ross Finlayson wrote: > > > > On Jan 4, 2019, at 12:07 PM, Kevin Bailey > wrote: > > > > Hi all! Can anyone point me to an example of how to implement a jitter > buffer into an rtsp clien

[Live-devel] Jitter Buffer h264 rtsp client

2019-01-03 Thread Kevin Bailey
Hi all! Can anyone point me to an example of how to implement a jitter buffer into an rtsp client using live555? The example that is included with live555 doesn't have any sort of jitter buffer and the stream frequently freezes. Thank you! ___ live-devel

Re: [Live-devel] Zero Latency Live Streaming

2018-12-31 Thread Kevin Bailey
I am fairly confident that I am slicing my NAL units, but is there any chance you might be able to link me to an example of how to appropriately slice NAL units with x264? Figured you might know where an example might be considering you've dealt with that kind of issue on many occasions. I will lo

Re: [Live-devel] Zero Latency Live Streaming

2018-12-31 Thread Kevin Bailey
Thank you again for the support. I have split up my h264 key frames into smaller NAL slices and I am still seeing artifacts on the screen. It is also important to note that my h264 key frame sizes were already smaller than 100,000 bytes each (closer to 20,000 bytes each). Could this be the cause o

Re: [Live-devel] Zero Latency Live Streaming

2018-12-28 Thread Kevin Bailey
Thank you all for your feedback. So with Ross's suggestion I implemented a rtsp client based on this live555 example: https://github.com/rgaufman/live555/blob/master/testProgs/testRTSPClient.cpp. The latency may have gone down a bit actually (looks like my client may have been at fault for some amo

[Live-devel] Zero Latency Live Streaming

2018-12-28 Thread Kevin Bailey
Hi all! I am not quite understanding why my code has so much latency... My main use case is not for gaming, but I did try to play a game over the stream and the latency is HORRIBLE. I am not quite understanding what the cause could be... Here are some links to my code on pastebin: https://pastebi