From A.Kovacs at Noldus.NL Tue Jun 3 07:16:58 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Tue, 3 Jun 2014 14:16:58 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <3ce11cf6b0ec4a5e94c6b9716d5c5dba@NIT-VS11.noldusbv.local> Problem: I am working on a direct show filter, which can stream multiple types of video/audio streams. It works well, if I use only one instance. My basic test scenario is to stream a video and view it in VLC. But if I use 4 instances of the filter in same graph I have problems. If I try to open streams in my computer, I can open all four streams, but after a while strange things happen: streams stop to play and I loose my net connection for a while (after I kill my streaming test scenario, my network will be restored in 1 minute). If I try to open the streams on another computer, I can open only 1 or 2 in VLC, 3rd instance can't connect. The problem happens with more type of streams (H264, MJPEG), so it's not a stream type specific. I use different ports for each stream. My feeling was that the problem is in Groupsock object creation, because I used here I used the same port for Groupsock objects in each filter instance, but after I changed to different, it's still not ok. (I use 255 Ttl.) //Groupsock: struct in_addr destinationAddress = {0}; destinationAddress.s_addr = chooseRandomIPv4SSMAddress(*m_pEnv); Groupsock* m_pRtcpGS = new Groupsock(*m_pEnv, destinationAddress, port, g_chTtl); m_pRtcpGS->multicastSendOnly(); //RTCPInstance: gethostname((char*)szHostName, nMaxSize); m_pRtcp = RTCPInstance::createNew(*m_pEnv, m_pRtcpGS, g_cnBandwidth, szHostName, m_pVideoSink, NULL, True); //RTSPServer: m_pRtspServer = RTSPServer::createNew(*m_pEnv, (Port)(m_nPort), m_pAuthDB); //ServerMediaSession: m_pSms = ServerMediaSession::createNew(*m_pEnv, crstrStreamPath.c_str(), "", crstrStreamDescription.c_str(), True /*SSM*/); //RTPSink (for example MJPEG): if (m_pRtpGS == NULL) { m_pRtpGS = CreateGroupsock(port); // this port is different than the port is used for m_pRtcpGS } OutPacketBuffer::maxSize = g_cnBuffersize; m_pVideoSink = JPEGVideoRTPSink::createNew(*m_pEnv, m_pRtpGS); m_pVideoSource = NCRtspMJPEGFramedSource::createNew(*m_pEnv); m_pVideoSink->startPlaying(*m_pVideoSource, NULL, NULL); Do you have ide which part can cause the problem, and how can I try to fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppulliam at llnw.com Wed Jun 4 14:57:07 2014 From: ppulliam at llnw.com (Pete Pulliam) Date: Wed, 4 Jun 2014 14:57:07 -0700 Subject: [Live-devel] Fwd: Logging for analytics In-Reply-To: References: Message-ID: I'm looking to log information about connections for analytics. I've written a proxy style RTSP server on top of the RTSPServer class, which is very loosely based on the proxy example with the library. Logging new connection information is easy, but what I would like to do create a single line log entry containing the streamName and bytes sent ?? at connection teardown time. It would be nice to have the connection's starting time and ending time in that line too. I ?don't see any easy to use hooks, ?while OnDemandServerMediaSubsession::deleteStream ? is called when a client connection ends, I'd hate to make custom implementations ?of the entire tree just to implement the equivalent of a callback with logging info, not to mention getting the specific data I'm interested in there. Any advice for how to best go about this? Has anyone else already done this? We're likely to push ? ? ?any? changes in the library level back to the live555 project. ? ?Pete? -- The information in this message may be confidential. It is intended solely for the addressee(s). If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 5 03:04:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jun 2014 04:04:46 -0600 Subject: [Live-devel] streaming multiple videos with multiple streams In-Reply-To: <3ce11cf6b0ec4a5e94c6b9716d5c5dba@NIT-VS11.noldusbv.local> References: <3ce11cf6b0ec4a5e94c6b9716d5c5dba@NIT-VS11.noldusbv.local> Message-ID: <96D9A718-61D3-4AE3-B2C2-C2B3FCDE01E4@live555.com> > I am working on a direct show filter, which can stream multiple types of video/audio streams. It works well, if I use only one instance. My basic test scenario is to stream a video and view it in VLC. But if I use 4 instances of the filter in same graph I have problems. If I try to open streams in my computer, I can open all four streams, but after a while strange things happen: streams stop to play and I loose my net connection for a while (after I kill my streaming test scenario, my network will be restored in 1 minute). If I try to open the streams on another computer, I can open only 1 or 2 in VLC, 3rd instance can't connect. Problems like this are usually caused by underlying network capacity problems, rather than problems with our software. I.e., it appears that your network simply does not have the capacity to carry the number of streams that you are attempting to send. (In particular, if your network is WiFi, note that multicast generally performs very poorly over WiFi networks.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Jun 5 03:17:46 2014 From: warren at etr-usa.com (Warren Young) Date: Thu, 05 Jun 2014 04:17:46 -0600 Subject: [Live-devel] streaming multiple videos with multiple streams In-Reply-To: <96D9A718-61D3-4AE3-B2C2-C2B3FCDE01E4@live555.com> References: <3ce11cf6b0ec4a5e94c6b9716d5c5dba@NIT-VS11.noldusbv.local> <96D9A718-61D3-4AE3-B2C2-C2B3FCDE01E4@live555.com> Message-ID: <539043CA.1090309@etr-usa.com> On 6/5/2014 04:04, Ross Finlayson wrote: > > (In particular, if your network is WiFi, note that multicast generally > performs very poorly over WiFi networks.) Yes, wifi is a problem for all real-time systems. First, the speeds claimed for wifi are basically marketing BS. A "54 Mbit/s" wireless network standard will give you 54 Mbit/s only when the two radios are sitting right next to each other inside an anechoic RF chamber sitting inside a Faraday cage. Second, let's say you're really lucky and are getting 20 Mbit/s and your streams require "only" 10 Mbit/s. Now along comes a burst of RF noise -- neighbor turned on the microwave or something -- and you get a short blip that knocks your average data rate down to 1 Mbit/s for a few hundred milliseconds. That's a bullet to the heart of your communication stream. You probably just destroyed an I or P frame the decoder requires in order to make sense of the B frames that did get through. Even IP telephony over wifi can be an iffy thing. Video requires much more bandwidth. From dekarl at spaetfruehstuecken.org Thu Jun 5 03:32:39 2014 From: dekarl at spaetfruehstuecken.org (Karl Dietz) Date: Thu, 05 Jun 2014 12:32:39 +0200 Subject: [Live-devel] streaming multiple videos with multiple streams In-Reply-To: <539043CA.1090309@etr-usa.com> References: <3ce11cf6b0ec4a5e94c6b9716d5c5dba@NIT-VS11.noldusbv.local> <96D9A718-61D3-4AE3-B2C2-C2B3FCDE01E4@live555.com> <539043CA.1090309@etr-usa.com> Message-ID: <53904747.6040005@spaetfruehstuecken.org> On 05.06.2014 12:17, Warren Young wrote: > On 6/5/2014 04:04, Ross Finlayson wrote: >> >> (In particular, if your network is WiFi, note that multicast generally >> performs very poorly over WiFi networks.) > > Yes, wifi is a problem for all real-time systems. > > First, the speeds claimed for wifi are basically marketing BS. A "54 > Mbit/s" wireless network standard will give you 54 Mbit/s only when the > two radios are sitting right next to each other inside an anechoic RF > chamber sitting inside a Faraday cage. I think that was in reference to WiFi transmitting multicast even slower then unicast. http://en.wikipedia.org/wiki/IP_multicast#Wireless_.28802.11.29_considerations "and the transmit rate is either 1 Mbit/s or 6 Mbit/s, depending on the operating band and protection mode." Regards, Karl From A.Kovacs at Noldus.NL Thu Jun 5 04:06:26 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Thu, 5 Jun 2014 11:06:26 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <3cbf26d6ddc847038739ca9598e4b234@NIT-VS11.noldusbv.local> I use 1Gbit LAN, I know that WiFi is not good enough for video technology. Technical details: I develop in Win7 SP1 64-bit. Currently I use a 1280 x 800 AVC video 25 frame/sec, which I stream on 2 different RTSPServer. Resource monitor shows 1000-1200 KB/sec receiving for each VLC and 2000-2400 KB/sec sending and also receiving for the RTSPServer application (graphstudio). This amount shouldn't be problem for the LAN, and the problem also happens, if I stream it only to my computer. To reproduce the problem, 2 streams are enough. I also tested to stream one bigger HD video, but that went without problem, so the problem is not the absolute bandwidth. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Jun 5 05:33:42 2014 From: warren at etr-usa.com (Warren Young) Date: Thu, 05 Jun 2014 06:33:42 -0600 Subject: [Live-devel] streaming multiple videos with multiple streams In-Reply-To: <3cbf26d6ddc847038739ca9598e4b234@NIT-VS11.noldusbv.local> References: <3cbf26d6ddc847038739ca9598e4b234@NIT-VS11.noldusbv.local> Message-ID: <539063A6.2070601@etr-usa.com> On 6/5/2014 05:06, Adrian Kovacs wrote: > > Currently I use a 1280 x 800 AVC video 25 frame/sec, Are you encoding that video on the same system in real time? 2-4 streams of 1 megapixel @ 25 fps AVC is pretty aggressive. If you're streaming preencoded files, are you doing intelligent disk reads? Nonblocking reads into large buffers, etc? From A.Kovacs at Noldus.NL Thu Jun 5 06:02:11 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Thu, 5 Jun 2014 13:02:11 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <32c345c5ef4f41308a2a03fbbb54ff6f@NIT-VS11.noldusbv.local> > Are you encoding that video on the same system in real time? 2-4 streams of 1 megapixel @ 25 fps AVC is pretty aggressive. No I don't do any encoding, my DirectShow filter only sends same type of video, that it gets (and live555 supports). When I do the 2 streams test case and I receives the streams also in my computer with VLC, my processor usage is below 20%, so that's also shouldn't be problem. > If you're streaming preencoded files, are you doing intelligent disk reads? Nonblocking reads into large buffers, etc? No I use DirectShow FileSource filter for file reading. My primary goal is not only streaming video files but rather camera streams live. In fact the files, that I use, were recorded from a test camera without changing the encoding. We can't allow more than 200ms delay in LAN, so no really buffering is possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 5 06:58:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Jun 2014 07:58:02 -0600 Subject: [Live-devel] streaming multiple videos with multiple streams In-Reply-To: <32c345c5ef4f41308a2a03fbbb54ff6f@NIT-VS11.noldusbv.local> References: <32c345c5ef4f41308a2a03fbbb54ff6f@NIT-VS11.noldusbv.local> Message-ID: <37BE0052-0E5C-455A-8E9F-23B321A9110D@live555.com> It wasn't clear to me - from your original message - what port numbers you are choosing. For each stream, you *must* use an even numbered port number for RTCP, and that port number +1 (i.e., odd-numbered) for RTCP. Also, you *should* use different port numbers for each stream. E.g., for stream 1, you could use 8000 for RTP, and 8001 for RTCP. For stream 2, you could use 8002 for RTP, and 8003 for RTCP. Etc. Because you are (correctly) using a different IP multicast address for each stream, it shouldn't matter, in principle, if you use different port numbers for each stream. In practice, however, it might matter (and it does matter in some versions of Linux), so that's what I recommend. But apart from that, I don't see anything in our software that could be causing your problem. But you clearly are running into a resource limit somewhere. Is your CPU usage at (or close to) 100% when you start having problems with multiple streams? If so, then you should be able to figure out - using profiling software - where most of the CPU usage is occurring. If, however, the resource limit that you're hitting is *not* your CPU, and it's not your network, then it has to be file I/O, or something else in your OS. Finally, I assume that you're not trying to run multiple copies of *VLC" on the same computer. (Someone reported a similar issue about a month ago, but it turned out that their real problem was that they were trying to run multiple copies of VLC on the same computer.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith at cognitec.com Thu Jun 5 07:47:56 2014 From: smith at cognitec.com (=?utf-8?Q?Robert_Smith?=) Date: Thu, 5 Jun 2014 16:47:56 +0200 Subject: [Live-devel] resuming a live stream with (old) buffered frames in pipeline Message-ID: Hi, I am capturing video from a live camera, encoding to H264 and streaming via the live555 RTSP server. The problem I have is that multiple frames are buffered in the pipeline between the camera and the server which means that when a unicast client connects, the first frames that they get are usually very old, followed by recent frames. VLC drops a lot of frames when I play the stream, resulting in either a frozen image or very choppy video. I get the following messages: "VLC: picture is too late to be displayed" and "more than 5 seconds of late video -> dropping frame (computer too slow ?)" I suppose that the proper way to deal with this would be to pause the pipeline when there are no unicast clients and flush the buffered frames but I before I do this I wanted to get your advice in case there is a simpler alternative that doesn't require modifications to our legacy code. Shouldn't RTCP automatically re-synchronise this anyway? Regards, Robert Smith. -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.Kovacs at Noldus.NL Thu Jun 5 07:55:30 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Thu, 5 Jun 2014 14:55:30 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <7d6ddea635c5408d8e7f4756d43c4d9f@NIT-VS11.noldusbv.local> >It wasn't clear to me - from your original message - what port numbers you are choosing. For each stream, you *must* use an even numbered port number for RTCP, and that port number +1 (i.e., odd-numbered) for RTCP. Also, you *should* use different port numbers for each stream. >E.g., for stream 1, you could use 8000 for RTP, and 8001 for RTCP. For stream 2, you could use 8002 for RTP, and 8003 for RTCP. Etc. >Because you are (correctly) using a different IP multicast address for each stream, it shouldn't matter, in principle, if you use different port numbers for each stream. In practice, however, it might matter (and it does matter in some versions of Linux), so that's what I recommend. Currently I use 8552, 8554, 8556, 8558 for RTSP ports. At my first implementation all RTP port was 18888 and RTCP was 18887, but after I found the problem, I changed this first, as a temporally solution not I calculate RTP port = RTSP port - 1000 and RTCP port = RTSP - 999. >But apart from that, I don't see anything in our software that could be causing your problem. But you clearly are running into a resource limit somewhere. Is your CPU usage at (or close to) 100% when you start having problems with multiple streams? If so, then you should be able to figure out - using profiling software - where most of the CPU usage is occurring. If, however, the resource limit that you're hitting is *not* your CPU, and it's not your network, then it has to be file I/O, or something else in your OS. >Finally, I assume that you're not trying to run multiple copies of *VLC" on the same computer. (Someone reported a similar issue about a month ago, but it turned out that their real problem was that they were trying to run multiple copies of VLC on the same computer.) Yes, I also think, that I use too much resource somewhere, but I don't know which. Network bandwidth shouldn't be problem (2500KB/s). CPU usage is lower than 20% (together with receiving part) also shouldn't be problem. For file I/O I use the general FileSource DirectShow filter, which has to work well. (I also use different video files to surly prevent this problem.) Until now in my test I used VLC, because I thought, that is stable. But we also have a RTSP Source filter which also using live555 solution, and I repeated my test using that to accept the stream, but I experienced the same problem. Note that if I receive the stream on another computer, the same problem happens on the streaming computer. Also note that after I seemingly lost my network connection (Skype disconnect and I can't open anything in browser), streaming doesn't stop immediately. This suggests some king of network resource problem, but not the bandwidth, because resource monitor shows under 10% usage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.pis.langlois at transport.alstom.com Thu Jun 5 11:58:59 2014 From: olivier.pis.langlois at transport.alstom.com (LANGLOIS Olivier PIS -EXT) Date: Thu, 5 Jun 2014 18:58:59 +0000 Subject: [Live-devel] redundant RTP stream setup question Message-ID: <89F8E4011FD7234ABFE48744E300CBC20BD6FC79@041-DB3MPN1-093.041d.mgd.msft.net> Hi, I am working on a system having 2 redundant streamers. The slave streamer starts streaming when a failure is detected on the primary streamer. Players (VLC using live555 (v2014.05.27)) are notified of the change with SAP. The problem is that for a very short period of time, there can be 2 different streams sent to the same multicast destination and this seems to make live555 to just close the stream instead of persisting trying to process RTP packets until the stream becomes clean. I have quickly consulted rfc3550 and it appears to say that you should never have different streams sent at the same address. We will probably make sure that master and slave streams have different destinations even if most of the time there should not be both present simultaneously. I am reaching out the list just for seeking comments on my situation and also to check if it could be possible that live555 rtp client could eventually become more robust against this type of issue or if it is considered such a big misuse of RTP that is unlikely that this will never be looked at. Here are VLC traces: [0x8227190] main input debug: `sdp://v=0 o=- 22857 1 IN IP4 10.130.3.112 s=Stream Id 1 i=vspStreamer c=IN IP4 239.10.10.50/255 t=0 0 a=type:broadcast a=recvonly m=video 6000 RTP/AVP 96 b=RR:0 a=rtpmap:96 H264/90000' successfully opened [0x82da030] packetizer_h264 packetizer warning: waiting for SPS/PPS [0x82da030] packetizer_h264 packetizer debug: found NAL_SPS (sps_id=0) [0x82da030] packetizer_h264 packetizer debug: found NAL_PPS (pps_id=0 sps_id=0) ... [0x821eb40] live555 demux debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP() [0x8227190] main input error: ES_OUT_RESET_PCR called [0x8227190] main input warning: clock gap, unexpected stream discontinuity [0x8227190] main input warning: feeding synchro with a new reference point trying to recover from clock gap [0x821eb40] live555 demux debug: StreamClose [0x8227190] main input debug: EOF reached [0x8227190] main input debug: waiting decoder fifos to empty Please ignore the confidentiality notice below. It is automatically added without my consent. ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. From laimaoli at 126.com Wed Jun 4 04:30:52 2014 From: laimaoli at 126.com (laimaoli at 126.com) Date: Wed, 4 Jun 2014 19:30:52 +0800 Subject: [Live-devel] Question About live555MediaServer Message-ID: <201406041930504092865@126.com> Conditions?live555 both in -Debug mode? Result?live555MediaServer1 which data come from camera send out by rtsp, the vlc only see screem time run ,but no picture in screem. live555MediaServer2 which data come from file send out by rtsp,the vlc is ok,can see picture.(this file is come from the live555MediaServer1 program,date come from the camera.) as i know ,when live555MediaServer2 read from file , first read 15000 bytes, and then parse the Nalu,last sent RTP. why? and i ask some friends,they told me that maybe RTP time stamp is not correct here. I paste a part of output data below.could you help me ,or give me some advices. //=====================live555 from camera ====================// accept()ed connection from 192.168.1.151 RTSPClientConnection[0x924f0]::handleRequestBytes() read 124 new bytes:OPTIONS rtsp://192.168.1.200:8554/h264 RTSP/1.0M CSeq: 2M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M M parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "h264", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OKM CSeq: 2M Date: Wed, Jun 04 2014 18:52:47 GMTM Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETERM M RTSPClientConnection[0x924f0]::handleRequestBytes() read 150 new bytes:DESCRIBE rtsp://192.168.1.200:8554/h264 RTSP/1.0M CSeq: 3M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Accept: application/sdpM M parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "h264", CSeq "3", Content-Length 0, with 0 bytes following the message. H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write, ---13 H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write?? ---9 Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401907967.491473 9 bytes @1401907967.491473, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) irst frame write?? ---1092 file.264 begin: 6655389 test.264 file size = 22 file.264 end: 6656481 2 fFrameSize 1092-- -fMaxSize 149978 fNumTruncatedBytes:0 Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401907967.491473 5 bytes @1401907967.491473, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write?? ---6562 file.264 begin: 6656481 test.264 file size = 1114 file.264 end: 6663043 3 fFrameSize 6562-- -fMaxSize 148886 fNumTruncatedBytes:0 Parsed 1088-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 5 ("Coded slice of an IDR picture")) Presentation time: 1401907967.491473 *****This NAL unit ends the current access unit***** 1088 bytes @1401907967.491473, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write?? ---23267 file.264 begin: 6663043 test.264 file size = 7676 file.264 end: 6686310 4 fFrameSize 23267-- -fMaxSize 142324 fNumTruncatedBytes:0 Parsed 6558-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.524806 *****This NAL unit ends the current access unit***** 6558 bytes @1401907967.524806, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write?? ---11025 file.264 begin: 6686310 test.264 file size = 30943 file.264 end: 6697335 5 fFrameSize 11025-- -fMaxSize 119057 fNumTruncatedBytes:0 Parsed 23263-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.558139 *****This NAL unit ends the current access unit***** 23263 bytes @1401907967.558139, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) close fp1. sending response: RTSP/1.0 200 OKM CSeq: 3M Date: Wed, Jun 04 2014 18:52:47 GMTM Content-Base: rtsp://192.168.1.200:8554/h264/M Content-Type: application/sdpM Content-Length: 482M M v=0M o=- 1401907933976002 1 IN IP4 127.0.1.1M s=Session streamed by "testOnDemandRTSPServer"M i=h264M t=0 0M a=tool:LIVE555 Streaming Media v2014.05.25M a=type:broadcastM a=control:*M a=range:npt=0-M a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"M a=x-qt-text-inf:h264M m=video 0 RTP/AVP 96M c=IN IP4 0.0.0.0M b=AS:1806007888M a=rtpmap:96 H264/90000M a=fmtp:96 packetization-mode=1;profile-level-id=42401E;sprop-parameter-sets=Z0JAHqaAtD2Q,aM4wpIA=M a=control:track1M RTSPClientConnection[0x924f0]::handleRequestBytes() read 181 new bytes:SETUP rtsp://192.168.1.200:8554/h264/track1 RTSP/1.0M CSeq: 4M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Transport: RTP/AVP;unicast;client_port=34338-34339M M parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "h264", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 bytes following the message. file.264 open :6697335! sending response: RTSP/1.0 200 OKM CSeq: 4M Date: Wed, Jun 04 2014 18:52:47 GMTM Transport: RTP/AVP;unicast;destination=192.168.1.151;source=192.168.1.200;client_port=34338-34339;server_port=6970-6971M Session: A5467749;timeout=65M M RTSPClientConnection[0x924f0]::handleRequestBytes() read 160 new bytes:PLAY rtsp://192.168.1.200:8554/h264/ RTSP/1.0M CSeq: 5M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Session: A5467749M Range: npt=0.000-M M parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "h264", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. RTCPInstance[0xefc40]::RTCPInstance() schedule(2.773338->1401907970.574620) sending REPORT sending RTCP packet 80c80006 a200c74f d739e97f cd322f27 f69e8991 00000000 00000000 81ca0004 a200c74f 01085461 6c6f6e2e 42520000 H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) sending response: RTSP/1.0 200 OKM CSeq: 5M Date: Wed, Jun 04 2014 18:52:47 GMTM Range: npt=0.000-M Session: A5467749M RTP-Info: url=rtsp://192.168.1.200:8554/h264/track1;seq=15622;rtptime=4137585282M M first frame write, ---13 H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) first frame write?? ---9 Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401907967.798012 9 bytes @1401907967.798012, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) 2 fFrameSize 3237-- -fMaxSize 149978 fNumTruncatedBytes:0 Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401907967.798012 5 bytes @1401907967.798012, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) 3 fFrameSize 4066-- -fMaxSize 146741 fNumTruncatedBytes:0 Parsed 3233-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.798012 *****This NAL unit ends the current access unit***** 3233 bytes @1401907967.798012, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) 4 fFrameSize 2994-- -fMaxSize 142675 fNumTruncatedBytes:0 Parsed 4062-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.831345 *****This NAL unit ends the current access unit***** 4062 bytes @1401907967.831345, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) 5 fFrameSize 11106-- -fMaxSize 139681 fNumTruncatedBytes:0 Parsed 2990-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.864678 *****This NAL unit ends the current access unit***** 2990 bytes @1401907967.864678, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) 6 fFrameSize 3356-- -fMaxSize 128575 fNumTruncatedBytes:0 Parsed 11102-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401907967.898011 ................................................................. //========================================== //=============================live555 from file.264=================================== accept()ed connection from 192.168.1.151 RTSPClientConnection[0x924f0]::handleRequestBytes() read 124 new bytes:OPTIONS rtsp://192.168.1.200:8554/h264 RTSP/1.0M CSeq: 2M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M M parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "h264", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OKM CSeq: 2M Date: Wed, Jun 04 2014 19:00:39 GMTM Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETERM M RTSPClientConnection[0x924f0]::handleRequestBytes() read 150 new bytes:DESCRIBE rtsp://192.168.1.200:8554/h264 RTSP/1.0M CSeq: 3M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Accept: application/sdpM M parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "h264", CSeq "3", Content-Length 0, with 0 bytes following the message. file.264 open :8486043! H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) length 1368380 Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 9-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 66 constraint_setN_flag: 64 level_idc: 30 seq_parameter_set_id: 0 log2_max_frame_num_minus4: 1 pic_order_cnt_type: 2 max_num_ref_frames: 1 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 29 frame_mbs_only_flag: 1 frame_cropping_flag: 0 vui_parameters_present_flag: 0 This "Sequence Parameter Set" NAL unit contained no frame rate information, so we use a default frame rate of 30.000000 fps Presentation time: 1401908439.432431 9 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 5-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 8 ("Picture parameter set")) Presentation time: 1401908439.432431 5 bytes @1401908439.432431, fDurationInMicroseconds: 0 ((0*1000000)/30.000000) Parsed 1088-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 5 ("Coded slice of an IDR picture")) Presentation time: 1401908439.432431 *****This NAL unit ends the current access unit***** 1088 bytes @1401908439.432431, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) Parsed 211-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401908439.465764 *****This NAL unit ends the current access unit***** 211 bytes @1401908439.465764, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) Parsed 9835-byte NAL-unit (nal_ref_idc: 2, nal_unit_type: 1 ("Coded slice of a non-IDR picture")) Presentation time: 1401908439.499097 : *****This NAL unit ends the current access unit***** 9835 bytes @1401908439.499097, fDurationInMicroseconds: 33333 ((1*1000000)/30.000000) close fp1. sending response: RTSP/1.0 200 OKM CSeq: 3M Date: Wed, Jun 04 2014 19:00:39 GMTM Content-Base: rtsp://192.168.1.200:8554/h264/M Content-Type: application/sdpM Content-Length: 475M M v=0M o=- 1401908425575659 1 IN IP4 127.0.1.1M s=Session streamed by "testOnDemandRTSPServer"M i=h264M t=0 0M a=tool:LIVE555 Streaming Media v2014.05.25M a=type:broadcastM a=control:*M a=range:npt=0-M a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"M a=x-qt-text-inf:h264M m=video 0 RTP/AVP 96M c=IN IP4 0.0.0.0M b=AS:500M a=rtpmap:96 H264/90000M a=fmtp:96 packetization-mode=1;profile-level-id=42401E;sprop-parameter-sets=Z0JAHqaAtD2Q,aM4wpIA=M a=control:track1M RTSPClientConnection[0x924f0]::handleRequestBytes() read 181 new bytes:SETUP rtsp://192.168.1.200:8554/h264/track1 RTSP/1.0M CSeq: 4M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Transport: RTP/AVP;unicast;client_port=44542-44543M M parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "h264", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 bytes following the message. file.264 open :8486043! sending response: RTSP/1.0 200 OKM CSeq: 4M Date: Wed, Jun 04 2014 19:00:39 GMTM Transport: RTP/AVP;unicast;destination=192.168.1.151;source=192.168.1.200;client_port=44542-44543;server_port=6970-6971M Session: EF66CCEB;timeout=65M M RTSPClientConnection[0x924f0]::handleRequestBytes() read 160 new bytes:PLAY rtsp://192.168.1.200:8554/h264/ RTSP/1.0M CSeq: 5M User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)M Session: EF66CCEBM Range: npt=0.000-M M parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "h264", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message. RTCPInstance[0xefc88]::RTCPInstance() schedule(1.117119->1401908440.823485) sending REPORT sending RTCP packet 80c80006 39771c18 d739eb57 b4e618ce f0405a8f 00000000 00000000 81ca0004 39771c18 01085461 6c6f6e2e 42520000 H264or5VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) //===================================== ================================================================== laimaoli at 126.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From audric.bilb at gmail.com Wed Jun 4 08:49:38 2014 From: audric.bilb at gmail.com (Audric Ackermann) Date: Wed, 4 Jun 2014 17:49:38 +0200 Subject: [Live-devel] android audio rtsp server drop frames Message-ID: Hi, I am currently working on a project which needs a RTSP server running under android and iOS. I am able to play an audio file, but the audio is jerky. It's a simple mp3 file. I didn't find a lot of documentation about live555, and if there is a way to improve performances. I don't think android is in fault because I built it in iOS too, and got some lags too. I've attached my code, I hope you will see what I am missing. It's based on the example from live555 for RTSP streaming. Audric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live555_wrapper.cpp Type: text/x-c++src Size: 6862 bytes Desc: not available URL: From finlayson at live555.com Mon Jun 9 05:57:48 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Jun 2014 06:57:48 -0600 Subject: [Live-devel] Logging for analytics In-Reply-To: References: Message-ID: <4DA2B966-C054-4FC2-AD7C-794773204DF8@live555.com> > I'm looking to log information about connections for analytics. I've written a proxy style RTSP server on top of the RTSPServer class, which is very loosely based on the proxy example with the library. Logging new connection information is easy, but what I would like to do create a single line log entry containing the streamName and bytes sent ??at connection teardown time. It would be nice to have the connection's starting time and ending time in that line too. > > I ?don't see any easy to use hooks, ?while OnDemandServerMediaSubsession::deleteStream? is called when a client connection ends, I'd hate to make custom implementations ?of the entire tree just to implement the equivalent of a callback with logging info, not to mention getting the specific data I'm interested in there. You don't need to "make custom implementations of the entire tree" (whatever that means :-) What you can probably do is - in your "OnDemandServerMediaSubsession" subclass, redefine the virtual function virtual void deleteStream(unsigned clientSessionId, void*& streamToken); Have it use the "clientSessionId" as a key for whatever extra information you want to keep about this session. (I.e., you could maintain your own hash table, indexed by "clientSessionId".) The last thing that your custom "deleteStream()" implementation would be to call the original - i.e., call OnDemandServerMediaSubsession::deleteStream(clientSessionId, streamToken); > We're likely to push? ??any? changes in the library level back to the live555 project. Note that if - as described here - you make changes only to your own subclassed code, then you are under no obligation to share it. If, however, you make changes to the supplied "LIVE555 Streaming Media" code (i.e., without subclassing), then it will be subject to the LGPL; see http://www.live555.com/liveMedia/faq.html#copyright-and-license Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.Kovacs at Noldus.NL Tue Jun 10 03:36:34 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Tue, 10 Jun 2014 10:36:34 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <8cb0745a34174155b8157c8439625773@NIT-VS11.noldusbv.local> I did a WireShark test to see what happens on the network. I did the test with one stream, which worked ok, and then I did it with 2 streams, which caused the problem. I didn't noticed any difference during streaming, but when I stopped streaming I found a difference: in two streams cases STP continues to sending pause messages for a while: Spanning-tree-(for-bridges)_01 Spanning-tree-(for-bridges)_01 MAC CTRL 60 MAC PAUSE: pause_time: 65535 quanta I did another test with 2 streams, but I didn't start a receiver for it (so no one received it). The log was looked similar, but at stop streaming I didn't get those pause messages. Note that some pause message was also sent periodically during streaming in all cases. I read that this can block network traffic, which happens in my case. Do you have idea how to prevent this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.Kovacs at Noldus.NL Tue Jun 10 07:19:16 2014 From: A.Kovacs at Noldus.NL (Adrian Kovacs) Date: Tue, 10 Jun 2014 14:19:16 +0000 Subject: [Live-devel] streaming multiple videos with multiple streams Message-ID: <58e450c4dc094334ab31ec9a480f2aac@NIT-VS11.noldusbv.local> Finally the solution was to disable Flow Control in switch/router, which generated these STP PAUSE messages. I don't know if there is possibility to improve on code side to be able to stream multiple streams without disable Flow Control/STP. Unfortunately I don't have much knowledge about socket programing, so I leave it for you, but at least there is a workaround. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 10 08:33:17 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Jun 2014 09:33:17 -0600 Subject: [Live-devel] resuming a live stream with (old) buffered frames in pipeline In-Reply-To: References: Message-ID: <398216F3-4FA9-4D03-94BC-C5E5E4AE98C4@live555.com> > I suppose that the proper way to deal with this would be to pause the pipeline when there are no unicast clients and flush the buffered frames Yes, that's clearly the right thing to do. (Note, BTW, that when we do this when we seek within a file; note line 77 of "InputFile.cpp".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 10 21:15:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Jun 2014 22:15:02 -0600 Subject: [Live-devel] redundant RTP stream setup question In-Reply-To: <89F8E4011FD7234ABFE48744E300CBC20BD6FC79@041-DB3MPN1-093.041d.mgd.msft.net> References: <89F8E4011FD7234ABFE48744E300CBC20BD6FC79@041-DB3MPN1-093.041d.mgd.msft.net> Message-ID: > I am working on a system having 2 redundant streamers. The slave streamer starts streaming when a failure is detected on the primary streamer. Unfortunately, the problem with what you're trying to do is that separate RTP multicast streams - even if sent to the same multicast address+port, using the same RTP payload format (i.e., codec) - are independent. They have different "SSRC" fields, and, more importantly, different (initially randomized) RTP timestamp values. A receiver that was previously receiving the 'primary' stream won't be able to properly handle the 'backup' stream, even if there's no overlap between the two streams, UNLESS it explicitly knows about the fact that it needs to stop receiving the 'primary' stream, and start receiving the 'backup' stream: > Players (VLC using live555 (v2014.05.27)) are notified of the change with SAP. OK, this gives you the opportunity to do the right thing. Your player - once it learns about the new stream - can stop receiving the existing stream (i.e., by closing "RTPSource" and "groupsock" objects, etc.), and then start receiving the new stream (by creating new "groupsock" and "RTPSource" objects, etc.). If you do this, then I suggest using a completely different multicast address+port for the 'backup' stream (you can do this because you're announcing it via SAP). Then you won't have any problem with overlap between the two streams. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanluc.bonnet at barco.com Tue Jun 10 23:30:21 2014 From: jeanluc.bonnet at barco.com (Bonnet, Jean-Luc) Date: Wed, 11 Jun 2014 06:30:21 +0000 Subject: [Live-devel] MP4-ES missing frames Message-ID: <75C4803536D10B4EB6FA0743F98B6A0A1ECCA291@KUUMEX10.barco.com> Hi Ross, * I receive MP4-ES video stream at 2 fps and I'm using MPEG4ESVideoRTPSource. * It's works fine with low CPU load but when this load is about 50%, some frames are lost. * If I use VLC with the same CPU load, it's works fine without missing frames. * I try to increase taskScheduler thread priority without success. Do you know which parameter I need to modify in order that it works? Thanks for your help, best regards. Jean-Luc Bonnet This message is subject to the following terms and conditions: MAIL DISCLAIMER -------------- next part -------------- An HTML attachment was scrubbed... URL: From nambirajan.manickam at i-velozity.com Thu Jun 12 04:52:07 2014 From: nambirajan.manickam at i-velozity.com (Nambirajan) Date: Thu, 12 Jun 2014 17:22:07 +0530 Subject: [Live-devel] FFW and REW play of encrypted files Message-ID: <001101cf8634$c0ac6a60$42053f20$@manickam@i-velozity.com> Hi Ross, We are using the Live555 Media Server for streaming the content to the Set Top Box. Encrypted a video content with a third party DRM and generated the .tsx file from the encrypted file. Then we created Multiple speed files ( x4, x8 files ) using testMPEG2TransportStreamTrickPlay utility from the encrypted file also the .tsx file from the Same encrypted file. We have a peculiar problem. 1. When we stream the encrypted file and receive in the STB ( The STB has the DRM client ), it is playing fine 2. When we tried to do FFW or REW the same content, the STB was not playing, we are getting a frozen picture 3. When we try to stream the x4 or x8 speed file in the normal play mode for testing also, the STB is not playing We checked the encrypted file in a TS Analyzer Software => the TS Header, PAT and PMT packets are in clear form. Can you please give us suggestion. It will be very helpful. Thanks and regards, M. Nambirajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 12 05:53:03 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Jun 2014 06:53:03 -0600 Subject: [Live-devel] FFW and REW play of encrypted files In-Reply-To: <001101cf8634$c0ac6a60$42053f20$@manickam@i-velozity.com> References: <001101cf8634$c0ac6a60$42053f20$@manickam@i-velozity.com> Message-ID: As I explained to you clearly back in April: Because (as you verified at the time) this is a problem with your STB, only the manufacturer of your STB can do help you with it. I would be happy, however, to work with the manufacturer of your STB to address this problem - but they will need to contact us directly about this. Please DO NOT post about this problem to this mailing list again - until I have heard from your STB manufacturer. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 14 10:48:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 14 Jun 2014 10:48:46 -0700 Subject: [Live-devel] android audio rtsp server drop frames In-Reply-To: References: Message-ID: > I am currently working on a project which needs a RTSP server running under android and iOS. > I am able to play an audio file, but the audio is jerky. It's a simple mp3 file. What happens when you use our (unmodified) "LIVE555 Media Server" or "testOnDemandRTSPServer" applications to stream this same file? If our server application works OK, but your application does not, then you know where to look :-) If, however, "LIVE555 Media Server" (or "testOnDemandRTSPServer") also fails to stream this file smoothly, then please let us know: 1/ Which RTSP media player client you are using to play the stream, and 2/ The (publicly accessible) URL that we can use to download your MP3 file, so we can test this for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Mon Jun 9 06:02:50 2014 From: fantasyvideo at 126.com (Tony) Date: Mon, 9 Jun 2014 21:02:50 +0800 (CST) Subject: [Live-devel] Regarding the FramedSource's stopGettingFrames Message-ID: <1fbc964f.16cce.14680b96067.Coremail.fantasyvideo@126.com> Hi Ross, I have call every framed source's stopgettingframes, then call deleteServerMediaSession, why the "aftergettingframe1" is still be called, and the program would crash at if(!SendRTPorRTCPOverTCP)? Is there any method to stop the serversession before delete them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 16 12:47:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Jun 2014 12:47:12 -0700 Subject: [Live-devel] MP4-ES missing frames In-Reply-To: <75C4803536D10B4EB6FA0743F98B6A0A1ECCA291@KUUMEX10.barco.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECCA291@KUUMEX10.barco.com> Message-ID: <5AC9C617-7BC1-44C8-AB5C-E3D15556F59D@live555.com> > I receive MP4-ES video stream at 2 fps and I'm using MPEG4ESVideoRTPSource. > It's works fine with low CPU load but when this load is about 50%, some frames are lost. > If I use VLC with the same CPU load, it's works fine without missing frames. > I try to increase taskScheduler thread priority without success. Do you know which parameter I need to modify in order that it works? Network packet loss (in environments where your network has sufficient capacity) is usually caused by insufficiently large socket reception buffers in the receiver's operating system. Fortunately, this is something that you can fix in your application. See http://www.live555.com/liveMedia/faq.html#packet-loss Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Tue Jun 17 09:44:35 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Tue, 17 Jun 2014 17:44:35 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs Message-ID: <53A07073.9070008@panogenics.com> Hi Ross, Attached are patches to 4 files (MPEG2TransportStreamFromESSource.cpp/hh & MPEG2TransportStreamMultiplexor.cpp/hh). These changes allow addNewVideoSource and addNewAudioSource to be called with an optional third parameter streamId. If this is set to a value other than -1 the PES ID and Stream ID are set differently. If not, current behaviour (Stream ID = PES ID) remains. I have coded this to take a 16 bit integer to allow for a default value outside the range that would be chosen (-1) and to allow for the code to be extended to accept 12 bit stream IDs in the future. It is currently limited to 8 bit Stream IDs. Please consider this small change for inclusion in your code. I'm happy to clarify / answer any questions / resubmit with changes. Many Thanks, Piers Hawksley -------------- next part -------------- 35c35 < u_int8_t pesId, int mpegVersion, --- > u_int8_t streamId, int mpegVersion, 65c65 < u_int8_t fPESid; --- > u_int8_t fStreamId; 82,84c82,84 < ::addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t streamId) { < u_int8_t pesId = 0xE0 | (fVideoSourceCounter++&0x0F); < addNewInputSource(inputSource, pesId, mpegVersion, streamId); --- > ::addNewVideoSource(FramedSource* inputSource, int mpegVersion) { > u_int8_t streamId = 0xE0 | (fVideoSourceCounter++&0x0F); > addNewInputSource(inputSource, streamId, mpegVersion); 89,91c89,91 < ::addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t streamId) { < u_int8_t pesId = 0xC0 | (fAudioSourceCounter++&0x0F); < addNewInputSource(inputSource, pesId, mpegVersion, streamId); --- > ::addNewAudioSource(FramedSource* inputSource, int mpegVersion) { > u_int8_t streamId = 0xC0 | (fAudioSourceCounter++&0x0F); > addNewInputSource(inputSource, streamId, mpegVersion); 146c146 < u_int8_t pesId, int mpegVersion, int16_t streamId) { --- > u_int8_t streamId, int mpegVersion) { 148,152c148 < if (streamId == -1) < fStreamId = pesId; < else < fStreamId = streamId; < fInputSources = new InputESSourceRecord(*this, inputSource, pesId, --- > fInputSources = new InputESSourceRecord(*this, inputSource, streamId, 162c158 < u_int8_t pesId, int mpegVersion, --- > u_int8_t streamId, int mpegVersion, 165c161 < fPESid(pesId), fMPEGVersion(mpegVersion) { --- > fStreamId(streamId), fMPEGVersion(mpegVersion) { 182c178 < fInputBuffer[3] = fPESid; --- > fInputBuffer[3] = fStreamId; -------------- next part -------------- 62d61 < u_int8_t fStreamId; // Should this be 16 bit signed 74c73 < // Note: We used to map 8-bit stream_ids directly to PIDs --- > // Note: We map 8-bit stream_ids directly to PIDs -------------- next part -------------- 109c109 < fCurrentPID = fStreamId; --- > fCurrentPID = stream_id; -------------- next part -------------- 33c33 < void addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t streamId = -1); --- > void addNewVideoSource(FramedSource* inputSource, int mpegVersion); 35c35 < void addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t streamId = -1); --- > void addNewAudioSource(FramedSource* inputSource, int mpegVersion); 43c43 < u_int8_t pesId, int mpegVersion, int16_t streamId = -1); --- > u_int8_t streamId, int mpegVersion); From vikram at vizexperts.com Tue Jun 17 21:56:47 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Wed, 18 Jun 2014 10:26:47 +0530 Subject: [Live-devel] Starting Frames are corrupted Message-ID: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> Hi, I have implemented RTSP Streaming using Live555 Library. Initially when the streaming starts, the frames are corrupted. But later this clears up and I have smooth rendering of the stream. Has anyone faces such an issue. Initially : https://docs.google.com/file/d/0B9yXmUZbfI7_Q0xsR1FZMUdaekE/edit Later : https://docs.google.com/file/d/0B9yXmUZbfI7_ZFlHZ2FqVnd5UUU/edit Thanks Vikram Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Wed Jun 18 03:37:22 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Wed, 18 Jun 2014 11:37:22 +0100 Subject: [Live-devel] Transport Stream PAT/PMT Program Number Message-ID: <53A16BE2.6050309@panogenics.com> Hi Ross, Attached is a small patch to MPEG2TransportStreamMultiplexor.cpp that allows OUR_PROGRAM_NUMBER to be defined externally. This allows the Program Number used in the program association table and program map table be set to a number other than 1. Can you consider it for inclusion in the next version of Live555 ? Best Regards, Piers -------------- next part -------------- 238,240c238 < #ifndef OUR_PROGRAM_NUMBER < #define OUR_PROGRAM_NUMBER 1 < #endif --- > #define OUR_PROGRAM_NUMBER 1 From rglobisch at csir.co.za Wed Jun 18 03:57:39 2014 From: rglobisch at csir.co.za (Ralf Globisch) Date: Wed, 18 Jun 2014 12:57:39 +0200 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> Message-ID: <53A18CC30200004D000A677A@pta-emo.csir.co.za> What codec are you using? For example, in the case of H.264 you should only start decoding the stream on the client once you've received an IDR frame. In other cases, artifacts typically occur due to packet loss. >>> "Vikram Singh" 06/18/14 7:02 AM >>> Hi, I have implemented RTSP Streaming using Live555 Library. Initially when the streaming starts, the frames are corrupted. But later this clears up and I have smooth rendering of the stream. Has anyone faces such an issue. Initially : https://docs.google.com/file/d/0B9yXmUZbfI7_Q0xsR1FZMUdaekE/edit Later : https://docs.google.com/file/d/0B9yXmUZbfI7_ZFlHZ2FqVnd5UUU/edit Thanks Vikram Singh -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From vikram at vizexperts.com Wed Jun 18 04:13:04 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Wed, 18 Jun 2014 16:43:04 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <53A18CC30200004D000A677A@pta-emo.csir.co.za> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> Message-ID: <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> I am testing the testH264VideoStreamer.cpp provided in the testprogs of live555 library folder. This file will stream a h264 file. My h264 file is not corrupted. I am viewing the stream using vlc player. -----Original Message----- From: Ralf Globisch [mailto:rglobisch at csir.co.za] Sent: Wednesday, June 18, 2014 4:28 PM To: live-devel at ns.live555.com; vikram at vizexperts.com Subject: Re: [Live-devel] Starting Frames are corrupted What codec are you using? For example, in the case of H.264 you should only start decoding the stream on the client once you've received an IDR frame. In other cases, artifacts typically occur due to packet loss. >>> "Vikram Singh" 06/18/14 7:02 AM >>> Hi, I have implemented RTSP Streaming using Live555 Library. Initially when the streaming starts, the frames are corrupted. But later this clears up and I have smooth rendering of the stream. Has anyone faces such an issue. Initially : https://docs.google.com/file/d/0B9yXmUZbfI7_Q0xsR1FZMUdaekE/edit Later : https://docs.google.com/file/d/0B9yXmUZbfI7_ZFlHZ2FqVnd5UUU/edit Thanks Vikram Singh -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From finlayson at live555.com Wed Jun 18 06:22:04 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jun 2014 06:22:04 -0700 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> Message-ID: <01429499-58EE-45D9-A65B-B870FB4D1CEA@live555.com> > I have implemented RTSP Streaming using Live555 Library. Have you used the "LIVE555 Streaming Media" code to implement a RTSP server, a RTSP client (i.e., media player), or both? If you have implemented only a RTSP server, then what are you using as your RTSP client (i.e., media player)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 18 06:32:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jun 2014 06:32:58 -0700 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> Message-ID: <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> > I am testing the testH264VideoStreamer.cpp provided in the testprogs of > live555 library folder. > This file will stream a h264 file. > My h264 file is not corrupted. > I am viewing the stream using vlc player. (Sorry, I sent my previous email before I read your last email, in which you explained what you're doing.) Your problem is that your stream contains extremely large 'I- frames' (also known as 'key frames'), and your encoder is encoding each I-frame so that it takes up a single H.264 NAL unit. If you're using VLC as a client, then be aware that - if your I-frame NAL units are excessively large - the first few received frames *will* be truncated. VLC notices this and increases its buffer size, so after a few seconds should have increased its buffer size large enough. That's why you see video corruption only for the first few frames. (There may be an option in VLC to use a larger initial buffer size. However, VLC is not our software, so we can't help you with VLC-related problems.) It's important to understand that each outgoing NAL unit - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame. In other words, if even one of these packets is lost, then the receiver will lose the *entire* NAL unit. That's why the NAL units - generated by your encoder - should be as small as is reasonable. The best solution here - for streaming - is to to not send extremely large NAL units. I-frames should be encoded as multiple 'slice' NAL units. Reconfigure your encoder to break up 'key frames' into multiple (therefore much smaller) 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikram at vizexperts.com Wed Jun 18 07:05:38 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Wed, 18 Jun 2014 19:35:38 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <01429499-58EE-45D9-A65B-B870FB4D1CEA@live555.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <01429499-58EE-45D9-A65B-B870FB4D1CEA@live555.com> Message-ID: <001601cf8afe$62f89be0$28e9d3a0$@vizexperts.com> I am using testH264VideoStreamer.cpp example program provided with live555 as my rtsp server and vlc as my client. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 6:52 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I have implemented RTSP Streaming using Live555 Library. Have you used the "LIVE555 Streaming Media" code to implement a RTSP server, a RTSP client (i.e., media player), or both? If you have implemented only a RTSP server, then what are you using as your RTSP client (i.e., media player)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikram at vizexperts.com Wed Jun 18 07:19:59 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Wed, 18 Jun 2014 19:49:59 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> Message-ID: <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Hi ross, I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp If I decrease the maxSize then the frames I get are truncated. Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. Thanks Vikram Singh From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 7:03 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I am testing the testH264VideoStreamer.cpp provided in the testprogs of live555 library folder. This file will stream a h264 file. My h264 file is not corrupted. I am viewing the stream using vlc player. (Sorry, I sent my previous email before I read your last email, in which you explained what you're doing.) Your problem is that your stream contains extremely large 'I- frames' (also known as 'key frames'), and your encoder is encoding each I-frame so that it takes up a single H.264 NAL unit. If you're using VLC as a client, then be aware that - if your I-frame NAL units are excessively large - the first few received frames *will* be truncated. VLC notices this and increases its buffer size, so after a few seconds should have increased its buffer size large enough. That's why you see video corruption only for the first few frames. (There may be an option in VLC to use a larger initial buffer size. However, VLC is not our software, so we can't help you with VLC-related problems.) It's important to understand that each outgoing NAL unit - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame. In other words, if even one of these packets is lost, then the receiver will lose the *entire* NAL unit. That's why the NAL units - generated by your encoder - should be as small as is reasonable. The best solution here - for streaming - is to to not send extremely large NAL units. I-frames should be encoded as multiple 'slice' NAL units. Reconfigure your encoder to break up 'key frames' into multiple (therefore much smaller) 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Wed Jun 18 08:54:15 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Wed, 18 Jun 2014 16:54:15 +0100 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp Message-ID: <53A1B627.6030400@panogenics.com> Hi Ross, We have been using live 555 reliably for a couple of years to provide the RTSP streams from a CCTV camera we have developed. When testing RTSP over HTTP streams (using VLC 2.1.3 as a client) we have found we get one of the following error messages after ~65-100 minutes: *** glibc detected *** /program/name: free(): invalid next size (fast): or: *** glibc detected *** /program/name: malloc(): memory corruption: Running a debug build of live 555 and a debug build of our code through gdb (using the Eclipse IDE) we find no stack trace (only disassembly code - we are building live 555 with -g3 -O0 -DDEBUG), but the same error message. Adding some debug prints to liveMedia/RTSPServer.cpp and liveMedia/Base64.cpp we've tracked it down to: delete[] out; in base64Decode (line 80) when we get a free(): invalid next size (fast): error and: new unsigned char[resultSize]; in base64Decode (line 78) when we get a malloc(): memory corruption: error. Attached are two difference files showing the debug I have added. Also attached is the debug output I get (all from live 555, save a timestamp / frames per second line our code reports every 75 frames). Can you suggest what else we can try to pinpoint what is going wrong ? I can send more of the debug output if that will help (the 3 bytes left from the previous decode drew my attention, this is not unique in the debug output, it happened after the previous call to RTSPServer::RTSPClientConnection::handleRequestBytes() ). Many Thanks, Piers Hawksley -------------- next part -------------- 46,48d45 < #ifdef DEBUG < #include < #endif 59,61d55 < #ifdef DEBUG < fprintf(stderr, "out=%p\n", out); < #endif 79,81d72 < #ifdef DEBUG < fprintf(stderr, "k=%d, paddingCount=%d, inSize=%d\n", k, paddingCount, inSize); < #endif 84,86d74 < #ifdef DEBUG < fprintf(stderr, "trimTrailingZeros=1\n"); < #endif 90,92d77 < #ifdef DEBUG < fprintf(stderr, "resultSize=%d\n", resultSize); < #endif 94,96d78 < #ifdef DEBUG < fprintf(stderr, "new result=%p\n", result); < #endif 98,100d79 < #ifdef DEBUG < fprintf(stderr, "Moved out to result\n"); < #endif 102,104d80 < #ifdef DEBUG < fprintf(stderr, "deleted out\n"); < #endif -------------- next part -------------- 895,897d894 < #ifdef DEBUG < fprintf(stderr, "numBytesToDecode=%d, newBase64RemainderCount=%d\n", numBytesToDecode, newBase64RemainderCount); < #endif 903d899 < fprintf(stderr, "decodedBytes=%p\n", decodedBytes); 918,920d913 < #ifdef DEBUG < fprintf(stderr, "Deletedd decodedBytes\n"); < #endif 922,924d914 < #ifdef DEBUG < fprintf(stderr, "fBase64RemainderCount=%d\n", newBase64RemainderCount); < #endif -------------- next part -------------- RTSPClientConnection[0x43200588]::handleRequestBytes() read 443 new bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy44MC9zdHJlYW0xLyBSVFNQLzEuMA0KQ1NlcTogNzQNCkF1dGhvcml6YXRpb246IERpZ2VzdCB1c2VybmFtZT0iQWRtaW4iLCByZWFsbT0iTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEiLCBub25jZT0iOWM1MzhhYmE0Y2MxZDAwOWY0YWRkMjc3ZDljODYwYzUiLCB1cmk9InJ0c3A6Ly8xMC4yNi43LjgwL3N0cmVhbTEvIiwgcmVzcG9uc2U9IjhiNjljYmEyZDc0N2Q4ODYwMTNiYmEyMjJjZDhlYTYxIg0KVXNlci1BZ2VudDogTGliVkxDLzIuMS4zIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMS4yMSkNClNlc3Npb246IDMwRTY numBytesToDecode=440, newBase64RemainderCount=3 out=0x27cd60 k=330, paddingCount=0, inSize=440 trimTrailingZeros=1 resultSize=330 new result=0x27cf20 Moved out to result deleted out decodedBytes=0x27cf20 Base64-decoded 440 input bytes into 330 new bytes:GET_PARAMETER rtsp://10.26.7.80/stream1/ RTSP/1.0 CSeq: 74 Authorization: Digest username="Admin", realm="LIVE555 Streaming Media", nonce="9c538aba4cc1d009f4add277d9c860c5", uri="rtsp://10.26.7.80/stream1/", response="8b69cba2d747d886013bba222cd8ea61" User-Agent: LibVLC/2.1.3 (LIVE555 Streaming Media v2014.01.21) Session: 30 Deletedd decodedBytes fBase64RemainderCount=3 RTSPClientConnection[0x43200588]::handleRequestBytes() read 13 new bytes:zM0M2DQoNCg== numBytesToDecode=16, newBase64RemainderCount=0 out=0x183790 k=12, paddingCount=2, inSize=16 trimTrailingZeros=1 resultSize=10 new result=0x1837f0 Moved out to result deleted out decodedBytes=0x1837f0 Base64-decoded 16 input bytes into 10 new bytes:33C6 Deletedd decodedBytes fBase64RemainderCount=0 parseRTSPRequestString() failed; checking now for HTTP commands (for RTSP-over-HTTP tunneling)... parseHTTPRequestString() failed! sending response: RTSP/1.0 400 Bad Request Date: Wed, Jun 18 2014 14:16:13 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x43200588]::handleRequestBytes() processing 3 new bytes:oNC numBytesToDecode=0, newBase64RemainderCount=3 fBase64RemainderCount=3 [18/06/14-14:16:14][003995.819]:#099854:FPS = 24.79 FPS = 25.21 FPS = 24.92 FPS = 25.08 FPS = 25.00 MaxTimes: Frame=55ms, Loop=41ms, Grab=11ms, Check=1ms schedule(0.574857->1403100975.316782) sending REPORT sending RTCP packet 80c80006 d8c5f75c d74c1daf 3c925786 7b637937 00097977 2dbffcd3 81ca0005 d8c5f75c 010a414d 47373130 302d5645 00000000 schedule(3.593662->1403100978.845060) sending REPORT sending RTCP packet 80c80006 2c617b15 d74c1daf 517fc760 5b40ea9a 0006d150 1e99ec21 81ca0005 2c617b15 010a414d 47373130 302d5645 00000000 reap: checking SSRC 0x7c51cba0: 764 (threshold 760) schedule(5.363281->1403100980.684468) [0x21bd50]saw incoming RTCP packet 81c90007 334a8ed0 d8c5f75c 00ffffff 000b47ad 000003c7 1daf3c92 000027e7 81ca0005 334a8ed0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "70967B5D", stream name "stream0"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x334a8ed0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x334a8ed0 validated entire RTCP packet [0x43205d70]saw incoming RTCP packet 81c90007 7c51cba0 2c617b15 00ffffff 0008be55 0000009b 1daf517f 00015410 81ca0005 7c51cba0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "30E633C6", stream name "stream1"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x7c51cba0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x7c51cba0 validated entire RTCP packet [18/06/14-14:16:17][003998.822]:#099929:FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 24.88 MaxTimes: Frame=68ms, Loop=55ms, Grab=29ms, Check=2ms sending REPORT sending RTCP packet 80c80006 d8c5f75c d74c1db2 d91c2a02 7b686ee0 00097bcc 2dcb57db 81ca0005 d8c5f75c 010a414d 47373130 302d5645 00000000 schedule(5.660181->1403100984.512551) [18/06/14-14:16:20][004001.819]:#100004:FPS = 25.13 FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 MaxTimes: Frame=58ms, Loop=45ms, Grab=11ms, Check=16ms [0x21bd50]saw incoming RTCP packet 81c90007 334a8ed0 d8c5f75c 00ffffff 000b4aa2 000000a1 1db2d91c 0001282e 81ca0005 334a8ed0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "70967B5D", stream name "stream0"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x334a8ed0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x334a8ed0 validated entire RTCP packet sending REPORT sending RTCP packet 80c80006 2c617b15 d74c1db4 af6805a3 5b484960 0006d3bd 1ea488b6 81ca0005 2c617b15 010a414d 47373130 302d5645 00000000 schedule(6.056709->1403100986.744148) [0x43205d70]saw incoming RTCP packet 81c90007 7c51cba0 2c617b15 00ffffff 0008c115 00000242 1db4af68 000217b8 81ca0005 7c51cba0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "30E633C6", stream name "stream1"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x7c51cba0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x7c51cba0 validated entire RTCP packet [18/06/14-14:16:23][004004.819]:#100079:FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 MaxTimes: Frame=70ms, Loop=43ms, Grab=16ms, Check=2ms sending REPORT sending RTCP packet 80c80006 d8c5f75c d74c1db8 835ff60a 7b703682 00097f84 2ddda4d1 81ca0005 d8c5f75c 010a414d 47373130 302d5645 00000000 schedule(4.551251->1403100989.066624) [0x21bd50]saw incoming RTCP packet 81c90007 334a8ed0 d8c5f75c 00ffffff 000b4d99 00000144 1db8835f 0000087c 81ca0005 334a8ed0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "70967B5D", stream name "stream0"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x334a8ed0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x334a8ed0 validated entire RTCP packet [18/06/14-14:16:26][004007.819]:#100154:FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 FPS = 25.00 MaxTimes: Frame=67ms, Loop=55ms, Grab=11ms, Check=3ms sending REPORT sending RTCP packet 80c80006 2c617b15 d74c1dba bedd377e 5b509bfb 0006d675 1eb07c21 81ca0005 2c617b15 010a414d 47373130 302d5645 00000000 schedule(6.012983->1403100992.764981) [0x43205d70]saw incoming RTCP packet 81c90007 7c51cba0 2c617b15 00ffffff 0008c30d 0000009c 1dbabedd 00006eb2 81ca0005 7c51cba0 010a5041 4e4f3130 312d5043 00000000 RR RTSP client session (id "30E633C6", stream name "stream1"): Liveness indication validated RTCP subpacket (type 2): 1, 201, 0, 0x7c51cba0 UNSUPPORTED TYPE(0xca) validated RTCP subpacket (type 2): 1, 202, 16, 0x7c51cba0 validated entire RTCP packet [18/06/14-14:16:29][004010.818]:#100229:FPS = 25.00 FPS = 24.19 FPS = 25.86 FPS = 25.00 FPS = 25.00 MaxTimes: Frame=60ms, Loop=45ms, Grab=10ms, Check=2ms schedule(0.131993->1403100989.199001) schedule(0.002769->1403100989.203301) sending REPORT sending RTCP packet 80c80006 d8c5f75c d74c1dbd 34a86d72 7b76a839 0009829e 2dece3e3 81ca0005 d8c5f75c 010a414d 47373130 302d5645 00000000 schedule(3.590446->1403100992.812293) RTSPClientConnection[0x1b64b8]::handleRequestBytes() read 456 new bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy44MC9zdHJlYW0wLyBSVFNQLzEuMA0KQ1NlcTogNzUNCkF1dGhvcml6YXRpb246IERpZ2VzdCB1c2VybmFtZT0iQWRtaW4iLCByZWFsbT0iTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEiLCBub25jZT0iYTlmMDA1ODBlYTA2ZDMxYmIxNWI1ZTU4OTk1ZGFmNmIiLCB1cmk9InJ0c3A6Ly8xMC4yNi43LjgwL3N0cmVhbTAvIiwgcmVzcG9uc2U9ImMwZDgzNGQyNGY4NjE5ZjdiOTU3NmNmZjE4YjRjN2UyIg0KVXNlci1BZ2VudDogTGliVkxDLzIuMS4zIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMS4yMSkNClNlc3Npb246IDcwOTY3QjVEDQoNCg== numBytesToDecode=456, newBase64RemainderCount=3 out=0x183830 k=342, paddingCount=0, inSize=456 trimTrailingZeros=1 resultSize=342 new result=0x27cd48 Moved out to result *** glibc detected *** /program/name: free(): invalid next size (fast): 0x00183830 *** From raimondo at ismb.it Wed Jun 18 07:57:18 2014 From: raimondo at ismb.it (Nadir Raimondo) Date: Wed, 18 Jun 2014 16:57:18 +0200 Subject: [Live-devel] MPEG2TransportStreamIndexer problem Message-ID: <53A1A8CE.4050406@ismb.it> Dear all, I've a question about transport stream indexing with MPEG2TransportStreamIndexer (for media server trick play). It generates a lot of errors: Bad "adaptation_field_length": 183 Those errors are generated by MPEG2IndexFromTransportStream liveMedia class. Here the code: if (totalHeaderSize >= TRANSPORT_PACKET_SIZE) { envir() << "Bad \"adaptation_field_length\": " << fInputBuffer[4] << "\n"; doGetNextFrame(); return; } When "adaptation_field_control" field value = 2 (that it means "adaptation field only") the totalHeaderSize is equals to 188 byte. E.g. packet header = 4 byte adaptation_field_length field = 1 byte (value = 183) adaptation field = 183 byte The result = 4 + 1 + 183 = 188. This is the correct value but it generates an error. Should the check be "if (totalHeaderSize > TRANSPORT_PACKET_SIZE)"? Cheers, Nadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Wed Jun 18 08:21:41 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Wed, 18 Jun 2014 11:21:41 -0400 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: A related technical question. Can we split a large Iframe nal frame into slices after the fact? Sometimes the encoder is a closed piece of hardware/firmware. Is it possible to split it into slices at a macroblock boundary? On Wed, Jun 18, 2014 at 10:19 AM, Vikram Singh wrote: > Hi ross, > > > > I am having -- unsigned OutPacketBuffer::maxSize = 900000; in > mediaSink.cpp > > If I decrease the maxSize then the frames I get are truncated. > > > > Can you please specify how to decrease the nal unit size without > decreasing the value of maxSize. > > > > Thanks > > Vikram Singh > > > > *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf > Of *Ross Finlayson > *Sent:* Wednesday, June 18, 2014 7:03 PM > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] Starting Frames are corrupted > > > > I am testing the testH264VideoStreamer.cpp provided in the testprogs of > live555 library folder. > This file will stream a h264 file. > My h264 file is not corrupted. > I am viewing the stream using vlc player. > > > > (Sorry, I sent my previous email before I read your last email, in which > you explained what you're doing.) > > > > Your problem is that your stream contains extremely large 'I- frames' > (also known as 'key frames'), and your encoder is encoding each I-frame so > that it takes up a single H.264 NAL unit. > > > > If you're using VLC as a client, then be aware that - if your I-frame NAL > units are excessively large - the first few received frames *will* be > truncated. VLC notices this and increases its buffer size, so after a few > seconds should have increased its buffer size large enough. That's why you > see video corruption only for the first few frames. (There may be an > option in VLC to use a larger initial buffer size. However, VLC is not our > software, so we can't help you with VLC-related problems.) > > > > It's important to understand that each outgoing NAL unit - if it is larger > than the RTP/UDP packet size (about 1500 bytes on most networks) - will be > broken up into multiple outgoing RTP packets, and the receiver must receive > *all* of these packets in order to be able to reconstruct the frame. In > other words, if even one of these packets is lost, then the receiver will > lose the *entire* NAL unit. That's why the NAL units - generated by your > encoder - should be as small as is reasonable. > > > > The best solution here - for streaming - is to to not send extremely large > NAL units. I-frames should be encoded as multiple 'slice' NAL units. > Reconfigure your encoder to break up 'key frames' into multiple (therefore > much smaller) 'slice' NAL units. > > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 18 10:43:10 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jun 2014 10:43:10 -0700 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: > I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp > If I decrease the maxSize then the frames I get are truncated. OK, there are two separate buffer sizes that you need to concern yourself with. "OutPacketBuffer::maxSize" is the buffer size that is used - by your server - when *transmitting* NAL units. You must set it to be at least as large as your largest NAL unit. Otherwise you will see (in 'stderr') error messages about needing to increase "OutPacketBuffer::maxSize". The receiving application - in your case VLC - must also have sufficient buffer space to be able to reassemble the incoming RTP packets into a complete NAL unit. That is what I referred to in my previous email message. In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets, and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. > Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. You mean "how to decrease the nal unit size without *increasing* the value of maxSize"? Once again, you need to reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 18 10:48:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jun 2014 10:48:12 -0700 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: <6B207E48-EA80-4323-85CE-52FD4726B53E@live555.com> > In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets Correction: 600 packets! > and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. Please, everybody. If you can't reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units, then please put pressure on your encoder manufacturer to get them to make this possible. They need to understand that excessively large NAL units are bad for (datagram) streaming. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 18 11:02:10 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Jun 2014 11:02:10 -0700 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: <48B585D3-5EFB-49FF-B949-58507B27D236@live555.com> > A related technical question. Can we split a large Iframe nal frame into slices after the fact? Sometimes the encoder is a closed piece of hardware/firmware. Is it possible to split it into slices at a macroblock boundary? I suppose it might be technically possible, but it would require (at least partially) decoding the NAL unit, then reencoding the new slice NAL units. An encoder might be a piece of hardware, but YOU HAVE PAID MONEY FOR IT. Therefore the encoder's manufacturer must surely be sensitive to feedback/criticism?! I find it baffling (and, quite frankly, rather insulting) that people repeatedly refuse to contact the manufacturer of hardware that THEY HAVE PAID FOR (whether it be an encoder, or a set-top box) asking them to fix problems, but instead insist that all of these problems be (somehow, magically) worked around in the "LIVE555 Streaming Media" software - software that they HAVE PAID NOTHING FOR! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Wed Jun 18 14:06:39 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Wed, 18 Jun 2014 17:06:39 -0400 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <48B585D3-5EFB-49FF-B949-58507B27D236@live555.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> <48B585D3-5EFB-49FF-B949-58507B27D236@live555.com> Message-ID: I am lucky with most encoders, I deal with about 23 brands. At least 6 major brands I communicate with and we have a healthy relationship in which we get changes in their FW on request. Inded sometimes it seems we are debugging their firmware for them. It rolls both ways. (A lot of them use live555 as there server BTW) I would like to see Periodic-Intra-refresh become popular. I am pretty sure Live555 can stream it but I think it is like getting rid of Querty, Drive letters, and Kleenex in one commit. But it would greatly improve the Security camera industry on both bandwidth shape and minimize video loss in poor networks. On Wed, Jun 18, 2014 at 2:02 PM, Ross Finlayson wrote: > A related technical question. Can we split a large Iframe nal frame into > slices after the fact? Sometimes the encoder is a closed piece of > hardware/firmware. Is it possible to split it into slices at a macroblock > boundary? > > > I suppose it might be technically possible, but it would require (at least > partially) decoding the NAL unit, then reencoding the new slice NAL units. > > An encoder might be a piece of hardware, but YOU HAVE PAID MONEY FOR IT. > Therefore the encoder's manufacturer must surely be sensitive to > feedback/criticism?! > > I find it baffling (and, quite frankly, rather insulting) that people > repeatedly refuse to contact the manufacturer of hardware that THEY HAVE > PAID FOR (whether it be an encoder, or a set-top box) asking them to fix > problems, but instead insist that all of these problems be (somehow, > magically) worked around in the "LIVE555 Streaming Media" software - > software that they HAVE PAID NOTHING FOR! > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heikifm at gmail.com Fri Jun 13 01:45:25 2014 From: heikifm at gmail.com (SingHa Winter) Date: Fri, 13 Jun 2014 17:45:25 +0900 Subject: [Live-devel] RTSP server taking MPEG2 TS as input using TCP Message-ID: Hi, I know live555 can server taking UDP TS as input using MPEG2TransportUDPServerMediaSubsession. I'd like to build a RTSP server that can takes a "TCP" Transport Stream as input. My relay server will stream TS file using TCP to my live555 streaming server. I made "MPEG2TransportStreamLiveSource" subclass of FramedSource and "MPEG2TransportStreamLiveServerMediaSubsession" subclass of OnDemandServerMediaSubsession. MPEG2TransportStreamLiveSource is copy of ByteStreamFileSource. And MPEG2TransportStreamLiveServerMediaSubsession is copy of MPEG2TransportFileServerMediaSubsession. Am I doing right? Please any advice for my starting point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoyuxqx at gmail.com Fri Jun 13 04:31:48 2014 From: xiaoyuxqx at gmail.com (Sandy) Date: Fri, 13 Jun 2014 19:31:48 +0800 Subject: [Live-devel] Too much bandwidth consumption, how to reduce it Message-ID: <5364C81C-7118-4399-9CF6-CA4B711CABE8@gmail.com> Hello, I'd like to use live555MediaServer to send my H.264 file to another PC which implemented VLC player. The server runs well but the bandwidth consumption is intolerable due to my network condition which could not offer 3Mbps bandwidth. Can you tell me some solution to reduce the bandwidth consumption of live555MediaServer. Thanks. Waiting for your early reply. Best, Yu -- ????????????? ????????? Schools of Information Science and Technology, Fudan ?? Xiao Yu Have a nice day? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Jun 19 03:05:56 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 19 Jun 2014 12:05:56 +0200 Subject: [Live-devel] Problem releasing Matroska demuxer Message-ID: <19353_1403172366_53A2B60D_19353_4771_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A652C@THSONEA01CMS01P.one.grp> Hi Ross, Thanks a lot for your great support. Demuxing a matroska file, I meet problem releasing the memory. Because the medium table is not empty, the reclaim of UsageEnvironment doesnot delete it. I made investigations with valgrind running on the following code that extract the first stream from test.mkv: #include "liveMedia.hh" #include "BasicUsageEnvironment.hh" static char watchVariable = 0; static MatroskaFile* matroskaFile = NULL; static void onMatroskaFileCreation(MatroskaFile* newFile, void* /*clientData*/) { matroskaFile = newFile; watchVariable = 1; } static void afterPlaying(void* clientData) { watchVariable = 1; } int main(int argc, char** argv) { TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // Open a Matroska file: char const* inputFileName = "test.mkv"; MatroskaFile::createNew(*env, inputFileName, onMatroskaFileCreation, NULL); env->taskScheduler().doEventLoop(&watchVariable); // Create a demultiplexor from the file: MatroskaDemux* demux = matroskaFile->newDemux(); // And start copying each track: unsigned trackNumber = 0; FramedSource* source = demux->newDemuxedTrack(trackNumber); MediaSink* sink = FileSink::createNew(*env, "track", 300000, False); sink->startPlaying(*source,afterPlaying,NULL); // Print medium names fprintf(stderr, "Medium name MkvFile:%s Demux:%s Source:%s Sink:%s\n", matroskaFile->name(), demux->name(), source->name(), sink->name()); watchVariable = 0; env->taskScheduler().doEventLoop(&watchVariable); // Clean up Medium::close(source); Medium::close(sink); // Released in MatroskaDemux::removeTrack Medium::close(demux); Medium::close(matroskaFile); // Check Media table _Tables* ourTables = _Tables::getOurTables(*env, false); if (ourTables != NULL) { fprintf(stderr, "Private structure are not empty\n"); HashTable::Iterator* iter = HashTable::Iterator::create(ourTables->mediaTable->getTable()); char const* key = NULL; Medium * medium = NULL; while ((medium = (Medium*)(iter->next(key))) != NULL) { fprintf(stderr, "Still registered %s\n", medium->name()); } delete iter; } else { fprintf(stderr, "_Tables are empties\n"); } env->reclaim(); delete scheduler; return 0; } It appears that releasing the last source, MatroskaDemux object is deleted, but doesnot remove from the mediaTable, and when the program print demux name, it use memory that is no more allocated. I made a try modifying MatroskaDemux::removeTrack : void MatroskaDemux::removeTrack(unsigned trackNumber) { fDemuxedTracksTable->Remove((char const*)trackNumber); if (fDemuxedTracksTable->numEntries() == 0) { // We no longer have any demuxed tracks, so delete ourselves now: - delete this; + Medium::close(this); } } With this modification, reclaim on UsageEnvironment delete it and valgrind do not report memory leakage or corruption. Do you think it could be a way to solve my problem ? Another way, I find more explicit, could be to not delete the demuxer and let the caller to close it, but this has an impact upgrading library used by legacy code. This will avoid to manage in a different way when there is no track parsed. Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Thu Jun 19 03:42:58 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Thu, 19 Jun 2014 06:42:58 -0400 Subject: [Live-devel] Too much bandwidth consumption, how to reduce it In-Reply-To: <5364C81C-7118-4399-9CF6-CA4B711CABE8@gmail.com> References: <5364C81C-7118-4399-9CF6-CA4B711CABE8@gmail.com> Message-ID: Bandwidth is not determined by live555. The bandwidth of H264 video is determined by resolution, quality, gopsize and frames per second used during encoding. Pretty much in that order. The file would need to be transcoded into a new file with another tool like ffmpeg to change it's band width. While Frames per second would seem to be a good place to start, the lower the framerate, the more time there is for pixels to change. From 6 to 30 fps actually has a very small percentage change. Gopsize and quality are the two best places to start to reduce file size and hince bandwidth when streaming. On Fri, Jun 13, 2014 at 7:31 AM, Sandy wrote: > Hello, > I'd like to use live555MediaServer to send my H.264 file to another PC > which implemented VLC player. The server runs well but the bandwidth > consumption is intolerable due to my network condition which could not > offer 3Mbps bandwidth. > Can you tell me some solution to reduce the bandwidth consumption of > live555MediaServer. Thanks. Waiting for your early reply. > Best, > > Yu > > > -- > ????????????? > ????????? > Schools of Information Science and Technology, Fudan > ?? > Xiao Yu > Have a nice day? > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miladin.sajic at citysync.co.uk Fri Jun 20 02:42:35 2014 From: miladin.sajic at citysync.co.uk (Miladin Sajic) Date: Fri, 20 Jun 2014 09:42:35 +0000 Subject: [Live-devel] Decoding H264 non-IDR picture Message-ID: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> Hi, I am trying to implement decoding of H264 NAL units that are received from the camera (using live555 rtsp streaming). Everything works fine if received NAL unit is IDR (see part of the code in PS) but it does not work for SLICE NAL unit (nal_unit_type == 1). To decode image this NAL unit is not enough on its own and reference needs to be made to all the units since last IDR unit (key frame with nal_unit_type == 5). I do not know how to implement this. How to combine last IDR unit with the following SLICE NAL units to produce H264 frame before sending it to the decoder? [cid:image003.png at 01CF8C74.58C38FA0] Can you give me any advice or point me to the right direction? Any help is greatly appreciated. Regards, Miladin PS. Content of the buffer sent to the H264 decoder that gets decoded properly. [cid:image001.png at 01CF8C73.13092D90] unsigned char strTmp[4] = { 0, 0, 0, 1 }; // getting SPS config info memcpy(acSPS, strTmp, 4); memcpy(&acSPS[4], m_pcRtspStream->m_ustrSPS, m_pcRtspStream->m_iSPSLen); nSPSLength = m_pcRtspStream->m_iSPSLen + 4; // getting PPS config info memcpy(acPPS, strTmp, 4); memcpy(&acPPS[4], m_pcRtspStream->m_ustrPPS, m_pcRtspStream->m_iPPSLen); nPPSLength = m_pcRtspStream->m_iPPSLen + 4; // before passing data to be decoder add SPS, PPS and 4 byte of strTmp to the IDR NAL unit (pcbCompressedData) iStrTmpImageSize = nSPSLength + nPPSLength + 4 + nCompressedLength; p = strTmpImage; // strTmpImage is empty allocated memory memcpy(p, acSPS, nSPSLength); p += nSPSLength; memcpy(p, acPPS, nPPSLength); p += nPPSLength; memcpy(p, strTmp, 4); p += 4; memcpy(p, pcbCompressedData, nCompressedLength); pHdr->nLength = iStrTmpImageSize; pcbCompressedData = strTmpImage; nCompressedLength = iStrTmpImageSize; // Pass pcbCompressedData and nCompressedLength to the decoder -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2279 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1728 bytes Desc: image003.png URL: From finlayson at live555.com Fri Jun 20 06:45:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Jun 2014 06:45:38 -0700 Subject: [Live-devel] Decoding H264 non-IDR picture In-Reply-To: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> References: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> Message-ID: <8BFEC696-0093-4B26-A7C5-3DFD07597A1C@live555.com> > I am trying to implement decoding of H264 NAL units that are received from the camera (using live555 rtsp streaming). Everything works fine if received NAL unit is IDR (see part of the code in PS) but it does not work for SLICE NAL unit (nal_unit_type == 1). To decode image this NAL unit is not enough on its own and reference needs to be made to all the units since last IDR unit (key frame with nal_unit_type == 5). I do not know how to implement this. Our software does not do any decoding or other processing on the H.264 NAL units that it transmits/receives via RTP (except that it automatically fragments/defragments large NAL units so that they will fit in RTP packets). It just delivers a sequence of NAL units - the same as if it came directly from the encoder. > How to combine last IDR unit with the following SLICE NAL units to produce H264 frame before sending it to the decoder? Someone on this mailing list might know the answer to your question, but, generally speaking, questions about how to implement the decoding of received NAL units are outside the scope of this mailing list (because the "LIVE555 Streaming Media" software doesn't do any decoding). What happens, however, when you try playing your stream using a media player, such as VLC? If VLC is able to play the stream OK, then you could look at its source code (though ti probably just uses FFMPEG or something for decoding). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkordani at lsa2.com Fri Jun 20 07:05:05 2014 From: jkordani at lsa2.com (Joshua Kordani) Date: Fri, 20 Jun 2014 10:05:05 -0400 Subject: [Live-devel] Decoding H264 non-IDR picture In-Reply-To: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> References: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> Message-ID: <53A43F91.3090000@lsa2.com> On 6/20/14 5:42 AM, Miladin Sajic wrote: > > Hi, > > I am trying to implement decoding of H264 NAL units that are received > from the camera (using live555 rtsp streaming). Everything works fine > if received NAL unit is IDR (see part of the code in PS) but it does > not work for SLICE NAL unit (nal_unit_type == 1). To decode image this > NAL unit is not enough on its own and reference needs to be made to > all the units since last IDR unit (key frame with nal_unit_type == 5). > I do not know how to implement this. > > How to combine last IDR unit with the following SLICE NAL units to > produce H264 frame before sending it to the decoder? > > Can you give me any advice or point me to the right direction?Any help > is greatly appreciated. > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel Sorry Ross for continuing the OT discussion, but just real quick. The answer to your decoding question lies in the question itself, you said that non idr slices can reference any prior nal up to the last idr. So in order to decode, you need to pass all prior nals up to the last idr. How exactly you do this depends on the decoder library you're using, ie ffmpeg requires that you provide the full bitstream each call to the decoder, hence (sc = startcode) sps sc pps sc idr frame 1 sps sc pps sc idr sc slice frame 2 sps sc pps sc idr sc slice sc slice frame 3 and so on. I can imagine a decoding library frontend that keeps track of the unchanging parts of the bitstream for you, and I wonder why it doesn't already exist, ie you pass nals in receive order to the decoder library and then ask the library to give you a frame. Eventually, once it has enough info, you get a frame back each call, while only having to briefly store the latest nal on behalf of the library. I know this is OT, but if I'm mistaken someone please speak up. -- Joshua Kordani LSA Autonomy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1728 bytes Desc: not available URL: From vikram at vizexperts.com Fri Jun 20 07:11:33 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Fri, 20 Jun 2014 19:41:33 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: <000f01cf8c91$8b8eeca0$a2acc5e0$@vizexperts.com> Hi ross, Just for testing purpose, I have reduced my streaming video size to 100*100 px size. By reducing the size I want to avoid the scenario where on the client side there is truncation of data, due to buffer overflow in the starting. This buffer overflow was assumed because the client had no idea about server frame size and initialized a default size to the buffer that receives data. Even then I have the problem of corrupt frames in the starting. Can there be any other case because of which this initial corruption of frames is happening. An another observation is when I had incorrect OutPacketBuffer::maxSize initialized to it, the frame rendered were like this https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharin g From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 11:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp If I decrease the maxSize then the frames I get are truncated. OK, there are two separate buffer sizes that you need to concern yourself with. "OutPacketBuffer::maxSize" is the buffer size that is used - by your server - when *transmitting* NAL units. You must set it to be at least as large as your largest NAL unit. Otherwise you will see (in 'stderr') error messages about needing to increase "OutPacketBuffer::maxSize". The receiving application - in your case VLC - must also have sufficient buffer space to be able to reassemble the incoming RTP packets into a complete NAL unit. That is what I referred to in my previous email message. In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets, and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. You mean "how to decrease the nal unit size without *increasing* the value of maxSize"? Once again, you need to reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miladin.sajic at citysync.co.uk Fri Jun 20 07:12:48 2014 From: miladin.sajic at citysync.co.uk (Miladin Sajic) Date: Fri, 20 Jun 2014 14:12:48 +0000 Subject: [Live-devel] Decoding H264 non-IDR picture In-Reply-To: <53A43F91.3090000@lsa2.com> References: <31FCA5CD5EB3584289781A8B65502BF11EB79E1E@SCS002.citysyncnet.local> <53A43F91.3090000@lsa2.com> Message-ID: <31FCA5CD5EB3584289781A8B65502BF11EB79F51@SCS002.citysyncnet.local> Thank you for your answers and suggestions. Regards, Miladin From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Joshua Kordani Sent: 20 June 2014 15:05 To: live-devel at ns.live555.com Subject: Re: [Live-devel] Decoding H264 non-IDR picture On 6/20/14 5:42 AM, Miladin Sajic wrote: Hi, I am trying to implement decoding of H264 NAL units that are received from the camera (using live555 rtsp streaming). Everything works fine if received NAL unit is IDR (see part of the code in PS) but it does not work for SLICE NAL unit (nal_unit_type == 1). To decode image this NAL unit is not enough on its own and reference needs to be made to all the units since last IDR unit (key frame with nal_unit_type == 5). I do not know how to implement this. How to combine last IDR unit with the following SLICE NAL units to produce H264 frame before sending it to the decoder? [cid:image001.png at 01CF8C9A.19734270] Can you give me any advice or point me to the right direction? Any help is greatly appreciated. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel Sorry Ross for continuing the OT discussion, but just real quick. The answer to your decoding question lies in the question itself, you said that non idr slices can reference any prior nal up to the last idr. So in order to decode, you need to pass all prior nals up to the last idr. How exactly you do this depends on the decoder library you're using, ie ffmpeg requires that you provide the full bitstream each call to the decoder, hence (sc = startcode) sps sc pps sc idr frame 1 sps sc pps sc idr sc slice frame 2 sps sc pps sc idr sc slice sc slice frame 3 and so on. I can imagine a decoding library frontend that keeps track of the unchanging parts of the bitstream for you, and I wonder why it doesn't already exist, ie you pass nals in receive order to the decoder library and then ask the library to give you a frame. Eventually, once it has enough info, you get a frame back each call, while only having to briefly store the latest nal on behalf of the library. I know this is OT, but if I'm mistaken someone please speak up. -- Joshua Kordani LSA Autonomy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1728 bytes Desc: image001.png URL: From vikram at vizexperts.com Fri Jun 20 07:27:40 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Fri, 20 Jun 2014 19:57:40 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> Message-ID: <001401cf8c93$cc0981d0$641c8570$@vizexperts.com> Hi ross, Please ignore my previous mail. I was sent accidently. Just for testing purpose, I have reduced my streaming video size to 100*100 px size. By reducing the size I want to avoid the scenario where on the client side there is truncation of data, due to buffer overflow in the starting. This buffer overflow was assumed because the client had no idea about server frame size and initialized a default size to the buffer that receives data. Even then I have the problem of corrupt frames in the starting. Can there be any other case because of which this initial corruption of frames is happening. An another observation is when I had incorrect OutPacketBuffer::maxSize initialized to it, the frame rendered were like this https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharin g i.e the frame would bleed to the bottom and that symbolizes the truncation of frame. Instead the corruption was something like this https://docs.google.com/file/d/0B9yXmUZbfI7_YUxEb1ltZ2pwa3M/edit and after some time it would clear up like this https://docs.google.com/file/d/0B9yXmUZbfI7_VW9uU2NWU041SkE/edit So can there be any other issue that is causing this problem. -vikram From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 11:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp If I decrease the maxSize then the frames I get are truncated. OK, there are two separate buffer sizes that you need to concern yourself with. "OutPacketBuffer::maxSize" is the buffer size that is used - by your server - when *transmitting* NAL units. You must set it to be at least as large as your largest NAL unit. Otherwise you will see (in 'stderr') error messages about needing to increase "OutPacketBuffer::maxSize". The receiving application - in your case VLC - must also have sufficient buffer space to be able to reassemble the incoming RTP packets into a complete NAL unit. That is what I referred to in my previous email message. In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets, and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. You mean "how to decrease the nal unit size without *increasing* the value of maxSize"? Once again, you need to reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ma at Remsdaq.com Fri Jun 20 08:06:36 2014 From: ma at Remsdaq.com (Manish Agarwal) Date: Fri, 20 Jun 2014 16:06:36 +0100 Subject: [Live-devel] API's unavailable after version update Message-ID: <74CE1D9764EDBF4989C259DC7E8FF2624BFD2C6E71@exch-svr.Remsdaq.co.uk> An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 20 09:43:53 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Jun 2014 09:43:53 -0700 Subject: [Live-devel] API's unavailable after version update In-Reply-To: <74CE1D9764EDBF4989C259DC7E8FF2624BFD2C6E71@exch-svr.Remsdaq.co.uk> References: <74CE1D9764EDBF4989C259DC7E8FF2624BFD2C6E71@exch-svr.Remsdaq.co.uk> Message-ID: <909366BA-4147-453A-B17E-13FABCCD0F3B@live555.com> > I have inherited legacy code and have been tasked with fixing the bugs after the Live555 version update to May 2014 release. I downloaded the source code and compiled it to work with the existing code. Expectedly our code is breaking where it is calling the methods on Live555. For example one of the error is ?'playMediaSession' : is not a member of 'RTSPClient'?. It seems that your application code is using the old 'synchronous' RTSP client interface, which has been obsolete for more than 4 years (and completely unavailable for more than 1 year). This change was announced numerous times on this mailing list, so it's unfortunate that it has taken you this long to join this mailing list. > Is there any documentation available which can help me in firstly understanding what a particular method is doing and secondly with which new method the older one is replaced with. The Doxygen web page for the "RTSPClient" interface is http://www.live555.com/liveMedia/doxygen/html/classRTSPClient.html Note also the "RTSPClient.hh" file itself - especially the comments in the file: http://www.live555.com/liveMedia/doxygen/html/RTSPClient_8hh-source.html I suggest also that you look at the code for the "testRTSPClient" demo application (in the "testProgs" directory). > Also, since I am not a C++ guy and the existing application creates a C++ wrapper so that the assembly is available for .net, are there any samples anywhere which can help me with creating/understanding the .net wrapper Sorry, but that's not our code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_q61 at yahoo.com Mon Jun 16 23:54:17 2014 From: john_q61 at yahoo.com (John Q) Date: Mon, 16 Jun 2014 23:54:17 -0700 Subject: stream webcam using ffmpeg and live555 Message-ID: <1402988057.43487.YahooMailNeo@web122102.mail.ne1.yahoo.com> I am new to live555. I want to stream my webcam from a windows 7 (64-bit) machine behind home LAN using ffmpeg as the encoder to a live555 server running on a Debian 64-bit linux machine in a data center over the WAN. I want to send a H.264 RTP/UDP stream from ffmpeg and the "testOnDemandRTSPServer" should send out RTSP streams to clients that connect to it. I am using the following ffmpeg command which sends UDP data to port 1234, IP address AA.BB.CC.DD .\ffmpeg.exe -f dshow -i video="Webcam C170":audio="Microphone (3- Webcam C170)" -an -vcodec libx264 -f mpegts udp://AA.BB.CC.DD:1234 On the linux server I am running the testOnDemandRTSPServer on port 5555 which expects raw UDP data from from AA:BB:CC:DD:1234. I try to open the rtsp stream in VLC using?rtsp://AA.BB.CC.DD:5555/mpeg2TransportStreamFromUDPSourceTest But I get nothing in VLC. What am I doing wrong? How can I fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 20 14:17:51 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Jun 2014 14:17:51 -0700 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: <53A07073.9070008@panogenics.com> References: <53A07073.9070008@panogenics.com> Message-ID: This patch won't work, because it defines a member variable "fStreamId" in the abstract base class ("MPEG2TransportStreamMultiplexor"), but that member variable is never assigned - except in the implementation of *one particular* subclass: "MPEG2TransportStreamFromESSource". Note that other subclasses of "MPEG2TransportStreamMultiplexor" are possible, and in fact the supplied code includes another subclass - "MPEG2TransportStreamFromPESSource" - which you haven't changed at all. I also have a problem with your use of the term "PES ID". Note that "MPEG2TransportStreamMultiplexor" works by taking as input 'PES_packets' (as defined in ISO+IEC+13818-1). Each 'PES_packet' (again, according to the definition) includes (as its 4th byte; i.e., byte[3]) a "stream_id". That's what it's called in the specification: A "stream_id", not a "PES ID", and so that's what our code should continue to call it. What we do, however, is choose to use this "stream_id" value to be the Transport Stream's 'Program ID' (i.e., PID) - called "fCurrentPID" in our code. It sounds like *that's* what you want to make it possible to change - i.e., you want to be able to make it possible to change the 'Program ID', not the 'stream_id'. So, you should change your proposed modifications (and consequent patch files) accordingly (and also be sure that it works for all possible subclasses of "MPEG2TransportStreamMultiplexor" - not just "MPEG2TransportStreamFromESSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 20 14:21:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 20 Jun 2014 14:21:38 -0700 Subject: [Live-devel] Transport Stream PAT/PMT Program Number In-Reply-To: <53A16BE2.6050309@panogenics.com> References: <53A16BE2.6050309@panogenics.com> Message-ID: > Attached is a small patch to MPEG2TransportStreamMultiplexor.cpp that allows OUR_PROGRAM_NUMBER to be defined externally. This allows the Program Number used in the program association table and program map table be set to a number other than 1. > > Can you consider it for inclusion in the next version of Live555 ? OK, this will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Fri Jun 20 17:56:51 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Sat, 21 Jun 2014 01:56:51 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: References: <53A07073.9070008@panogenics.com> Message-ID: Thanks Ross, I will try to change this as you've suggested on Monday when I have access to a pc ... I think you are correct that it is the transport stream program ID that I want to set. Many thanks, Piers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------- Original Message -------- From: Ross Finlayson Sent: 20 June 2014 22:17:51 GMT+01:00 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Separating Transport Stream IDs from PES IDs This patch won't work, because it defines a member variable "fStreamId" in the abstract base class ("MPEG2TransportStreamMultiplexor"), but that member variable is never assigned - except in the implementation of *one particular* subclass: "MPEG2TransportStreamFromESSource". Note that other subclasses of "MPEG2TransportStreamMultiplexor" are possible, and in fact the supplied code includes another subclass - "MPEG2TransportStreamFromPESSource" - which you haven't changed at all. I also have a problem with your use of the term "PES ID". Note that "MPEG2TransportStreamMultiplexor" works by taking as input 'PES_packets' (as defined in ISO+IEC+13818-1). Each 'PES_packet' (again, according to the definition) includes (as its 4th byte; i.e., byte[3]) a "stream_id". That's what it's called in the specification: A "stream_id", not a "PES ID", and so that's what our code should continue to call it. What we do, however, is choose to use this "stream_id" value to be the Transport Stream's 'Program ID' (i.e., PID) - called "fCurrentPID" in our code. It sounds like *that's* what you want to make it possible to change - i.e., you want to be able to make it possible to change the 'Program ID', not the 'stream_id'. So, you should change your proposed modifications (and consequent patch files) accordingly (and also be sure that it works for all possible subclasses of "MPEG2TransportStreamMultiplexor" - not just "MPEG2TransportStreamFromESSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Fri Jun 20 17:58:57 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Sat, 21 Jun 2014 01:58:57 +0100 Subject: [Live-devel] Transport Stream PAT/PMT Program Number In-Reply-To: References: <53A16BE2.6050309@panogenics.com> Message-ID: Great, thanks Ross -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------- Original Message -------- From: Ross Finlayson Sent: 20 June 2014 22:21:38 GMT+01:00 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Transport Stream PAT/PMT Program Number > Attached is a small patch to MPEG2TransportStreamMultiplexor.cpp that allows OUR_PROGRAM_NUMBER to be defined externally. This allows the Program Number used in the program association table and program map table be set to a number other than 1. > > Can you consider it for inclusion in the next version of Live555 ? OK, this will be included in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 21 17:15:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Jun 2014 17:15:44 -0700 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <53A1B627.6030400@panogenics.com> References: <53A1B627.6030400@panogenics.com> Message-ID: <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> > We have been using live 555 reliably for a couple of years to provide the RTSP streams from a CCTV camera we have developed. When testing RTSP over HTTP streams (using VLC 2.1.3 as a client) we have found we get one of the following error messages after ~65-100 minutes: > > *** glibc detected *** /program/name: free(): invalid next size (fast): > or: > *** glibc detected *** /program/name: malloc(): memory corruption: Unfortunately there's usually not much I can do to help track down problems like this, unless I'm able to reproduce the problem myself (e.g., using an unmodified "LIVE555 Media Server", and "openRTSP -T "). I assume that you're using the latest version of the "LIVE555 Streaming Media" code (as several bugs related to RTP/RTCP-over-TCP (including RTSP-over-HTTP) streaming were fixed over the past few months). > Running a debug build of live 555 and a debug build of our code through gdb (using the Eclipse IDE) we find no stack trace (only disassembly code - we are building live 555 with -g3 -O0 -DDEBUG) Try "-g", without any "-O". Then "gdb" should work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 21 18:05:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 21 Jun 2014 18:05:06 -0700 Subject: [Live-devel] MPEG2TransportStreamIndexer problem In-Reply-To: <53A1A8CE.4050406@ismb.it> References: <53A1A8CE.4050406@ismb.it> Message-ID: > I've a question about transport stream indexing with MPEG2TransportStreamIndexer (for media server trick play). > It generates a lot of errors: Bad "adaptation_field_length": 183 > > Those errors are generated by MPEG2IndexFromTransportStream liveMedia class. Here the code: > > if (totalHeaderSize >= TRANSPORT_PACKET_SIZE) { > envir() << "Bad \"adaptation_field_length\": " << fInputBuffer[4] << "\n"; > doGetNextFrame(); > return; > } > > When "adaptation_field_control" field value = 2 (that it means "adaptation field only") the totalHeaderSize is equals to 188 byte. > > E.g. > packet header = 4 byte > adaptation_field_length field = 1 byte (value = 183) > adaptation field = 183 byte > > The result = 4 + 1 + 183 = 188. This is the correct value but it generates an error. Yes, this is a bug (though the code will still work OK, despite printing the bogus 'error' message). This will be fixed in the next release of the software. Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 22 00:04:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Jun 2014 00:04:47 -0700 Subject: [Live-devel] RTSP server taking MPEG2 TS as input using TCP In-Reply-To: References: Message-ID: <3AEAA263-2999-439B-A6D6-95E640280377@live555.com> > I know live555 can server taking UDP TS as input using MPEG2TransportUDPServerMediaSubsession. > I'd like to build a RTSP server that can takes a "TCP" Transport Stream as input. That's easy to do. Just use the code for the "testOnDemandRTSPServer" demo application. At line 239-240 of "testProgs/testOnDemandRTSPServer.cpp", change char const* inputFileName = "test.ts"; char const* indexFileName = "test.tsx"; to char const* inputFileName = "stdin"; char const* indexFileName = NULL; Then, after building your new "testOnDemandRTSPServer", run your-application-that-generates-a-TCP-stream | testOnDemandRTSPServer I.e., just pipe your TCP connection to (your modified) "testOnDemandRTSPServer". (You may find it useful to use the standard Unix "nc" utility to generate your TCP stream.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 22 00:16:18 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 22 Jun 2014 00:16:18 -0700 Subject: [Live-devel] Problem releasing Matroska demuxer In-Reply-To: <19353_1403172366_53A2B60D_19353_4771_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A652C@THSONEA01CMS01P.one.grp> References: <19353_1403172366_53A2B60D_19353_4771_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A652C@THSONEA01CMS01P.one.grp> Message-ID: > - delete this; > + Medium::close(this); Yes. This will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pirpi.12345 at gmail.com Thu Jun 19 05:55:00 2014 From: pirpi.12345 at gmail.com (srd srdsrd) Date: Thu, 19 Jun 2014 18:25:00 +0530 Subject: [Live-devel] Audio Streaming over network Message-ID: > > I want to stream live audio over network using live 555. I have referred > testprogs from source code. I tried with testMP3Streamer.cpp > and testMP3Receiver.cpp but when I tried these two programs to stream mp3 > file it is just outputting encrypted data on stdout. I want > to play mp3 file on client side. > will you please help me with this? Thanks pirpi -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Jun 19 06:19:24 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 19 Jun 2014 15:19:24 +0200 Subject: [Live-devel] It could be helpful that UsageEnvironment::reclaim return a completion status Message-ID: <6178_1403183968_53A2E360_6178_14612_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A6A13@THSONEA01CMS01P.one.grp> Hi Ross, Thanks again for your support and your help. Since some years I am working with your library, I spend some time to understand when objects are deleted. So I would like to suggest that methods that make "delete this", for instance UsageEnvironement::reclaim, could indicate to the caller that the object was deleted or not. This will allow caller to remove there references (or not). Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Sun Jun 22 00:55:16 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Sun, 22 Jun 2014 08:55:16 +0100 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> Message-ID: Thanks Ross, We are using an unmodified (save for the extra printf's) build of the latest version of live555. I will try a build without -O0 optimizations on Monday to see if I can get a stack trace. I will also try using openRTSP as the client to see if that affects the results. Piers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ma at Remsdaq.com Mon Jun 23 00:43:27 2014 From: ma at Remsdaq.com (Manish Agarwal) Date: Mon, 23 Jun 2014 08:43:27 +0100 Subject: [Live-devel] live-devel Digest, Vol 128, Issue 13 In-Reply-To: References: Message-ID: <74CE1D9764EDBF4989C259DC7E8FF2624BFD2C6EB2@exch-svr.Remsdaq.co.uk> Thanks Ross for the links. As I said I inherited this code so wouldn't have known that it is using obsolete libraries. Are there any samples of c#/VB.net wrappers which can be a starting point. Thanks -----Original Message----- From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com Sent: Friday, June 20, 2014 5:44 PM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 128, Issue 13 Send live-devel mailing list submissions to live-devel at lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to live-devel-request at lists.live555.com You can reach the person managing the list at live-devel-owner at lists.live555.com When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. Re: Starting Frames are corrupted (Vikram Singh) 2. API's unavailable after version update (Manish Agarwal) 3. Re: API's unavailable after version update (Ross Finlayson) ---------------------------------------------------------------------- Message: 1 Date: Fri, 20 Jun 2014 19:57:40 +0530 From: "Vikram Singh" To: "'LIVE555 Streaming Media - development & use'" Subject: Re: [Live-devel] Starting Frames are corrupted Message-ID: <001401cf8c93$cc0981d0$641c8570$@vizexperts.com> Content-Type: text/plain; charset="us-ascii" Hi ross, Please ignore my previous mail. I was sent accidently. Just for testing purpose, I have reduced my streaming video size to 100*100 px size. By reducing the size I want to avoid the scenario where on the client side there is truncation of data, due to buffer overflow in the starting. This buffer overflow was assumed because the client had no idea about server frame size and initialized a default size to the buffer that receives data. Even then I have the problem of corrupt frames in the starting. Can there be any other case because of which this initial corruption of frames is happening. An another observation is when I had incorrect OutPacketBuffer::maxSize initialized to it, the frame rendered were like this https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharin g i.e the frame would bleed to the bottom and that symbolizes the truncation of frame. Instead the corruption was something like this https://docs.google.com/file/d/0B9yXmUZbfI7_YUxEb1ltZ2pwa3M/edit and after some time it would clear up like this https://docs.google.com/file/d/0B9yXmUZbfI7_VW9uU2NWU041SkE/edit So can there be any other issue that is causing this problem. -vikram From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 11:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp If I decrease the maxSize then the frames I get are truncated. OK, there are two separate buffer sizes that you need to concern yourself with. "OutPacketBuffer::maxSize" is the buffer size that is used - by your server - when *transmitting* NAL units. You must set it to be at least as large as your largest NAL unit. Otherwise you will see (in 'stderr') error messages about needing to increase "OutPacketBuffer::maxSize". The receiving application - in your case VLC - must also have sufficient buffer space to be able to reassemble the incoming RTP packets into a complete NAL unit. That is what I referred to in my previous email message. In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets, and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. You mean "how to decrease the nal unit size without *increasing* the value of maxSize"? Once again, you need to reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri, 20 Jun 2014 16:06:36 +0100 From: Manish Agarwal To: "live-devel at lists.live555.com" Subject: [Live-devel] API's unavailable after version update Message-ID: <74CE1D9764EDBF4989C259DC7E8FF2624BFD2C6E71 at exch-svr.Remsdaq.co.uk> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Fri, 20 Jun 2014 09:43:53 -0700 From: Ross Finlayson To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] API's unavailable after version update Message-ID: <909366BA-4147-453A-B17E-13FABCCD0F3B at live555.com> Content-Type: text/plain; charset="windows-1252" > I have inherited legacy code and have been tasked with fixing the bugs after the Live555 version update to May 2014 release. I downloaded the source code and compiled it to work with the existing code. Expectedly our code is breaking where it is calling the methods on Live555. For example one of the error is ?'playMediaSession' : is not a member of 'RTSPClient'?. It seems that your application code is using the old 'synchronous' RTSP client interface, which has been obsolete for more than 4 years (and completely unavailable for more than 1 year). This change was announced numerous times on this mailing list, so it's unfortunate that it has taken you this long to join this mailing list. > Is there any documentation available which can help me in firstly understanding what a particular method is doing and secondly with which new method the older one is replaced with. The Doxygen web page for the "RTSPClient" interface is http://www.live555.com/liveMedia/doxygen/html/classRTSPClient.html Note also the "RTSPClient.hh" file itself - especially the comments in the file: http://www.live555.com/liveMedia/doxygen/html/RTSPClient_8hh-source.html I suggest also that you look at the code for the "testRTSPClient" demo application (in the "testProgs" directory). > Also, since I am not a C++ guy and the existing application creates a > C++ wrapper so that the assembly is available for .net, are there any > samples anywhere which can help me with creating/understanding the > .net wrapper Sorry, but that's not our code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ------------------------------ End of live-devel Digest, Vol 128, Issue 13 ******************************************* Design : Develop : Manufacture | Delivering World-Class Technology Solutions | SCADA : Security : Mobilising Forthcoming Events: Rail Live 18-19 June 2014, Warwickshire UK- visit Remsdaq's Security Business Unit Smart Grids 2-3 December 2014, Thailand - visit Remsdaq's SCADA Business Unit News: Essex Fire and Rescue Service and Bedfordshire Fire and Rescue Service have chosen Remsdaq's Resque 4i for their new control room mobilising system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 23 13:46:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jun 2014 13:46:38 -0700 Subject: [Live-devel] stream webcam using ffmpeg and live555 In-Reply-To: References: Message-ID: <86A56647-7744-42C5-860E-BE227F0EE26A@live555.com> > I want to stream my webcam from a windows 7 (64-bit) machine behind home LAN using ffmpeg as the encoder to a live555 server running on a Debian 64-bit linux machine in a data center over the WAN. I want to send a H.264 RTP/UDP stream from ffmpeg and the "testOnDemandRTSPServer" should send out RTSP streams to clients that connect to it. > I am using the following ffmpeg command which sends UDP data to port 1234, IP address AA.BB.CC.DD > .\ffmpeg.exe -f dshow -i video="Webcam C170":audio="Microphone (3- Webcam C170)" -an > -vcodec libx264 -f mpegts udp://AA.BB.CC.DD:1234 > On the linux server I am running the testOnDemandRTSPServer on port 5555 which expects raw UDP data from from AA:BB:CC:DD:1234. I try to open the rtsp stream in VLC using rtsp://AA.BB.CC.DD:5555/mpeg2TransportStreamFromUDPSourceTest > But I get nothing in VLC. Are you sure that UDP packets from your "ffmpeg" computer are reaching your "testOnDemandRTSPServer" computer? Perhaps there's a firewall somewhere inbetween that's blocking UDP packets? That's the first thing that you should check. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From grom86 at mail.ru Sat Jun 21 19:06:58 2014 From: grom86 at mail.ru (=?UTF-8?B?bWludXM=?=) Date: Sun, 22 Jun 2014 06:06:58 +0400 Subject: [Live-devel] =?utf-8?q?OpenRTSP_test_sample_stops_after_2_minutes?= Message-ID: <1403402818.847119863@f73.i.mail.ru> OpenRTSP test sample always stops after 2 minutes. Why it happens and how to prevent it? -- developer ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Mon Jun 23 16:55:22 2014 From: warren at etr-usa.com (Warren Young) Date: Mon, 23 Jun 2014 17:55:22 -0600 Subject: [Live-devel] OpenRTSP test sample stops after 2 minutes In-Reply-To: <1403402818.847119863@f73.i.mail.ru> References: <1403402818.847119863@f73.i.mail.ru> Message-ID: <53A8BE6A.2060902@etr-usa.com> On 6/21/2014 20:06, minus wrote: > > OpenRTSP test sample always stops after 2 minutes. Why it happens and > how to prevent it? What is the server? Is it unicast or multicast? Is it always exactly 120 seconds, or does it vary somewhat? What is the command line you are passing to openrtsp? Details, man! From finlayson at live555.com Mon Jun 23 21:30:36 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jun 2014 21:30:36 -0700 Subject: [Live-devel] Audio Streaming over network In-Reply-To: References: Message-ID: <4BA9051E-29C2-4E91-A503-DECDDF9EDD03@live555.com> On Jun 19, 2014, at 5:55 AM, srd srdsrd wrote: > I want to stream live audio over network using live 555. I have referred testprogs from source code. I tried with testMP3Streamer.cpp > > and testMP3Receiver.cpp but when I tried these two programs to stream mp3 file it is just outputting encrypted data on stdout. The data that's output to 'stdout' is not 'encrypted'. It's just MP3 audio. You need to feed it to a MP3 decoder. (The "LIVE555 Streaming Media" software doesn't include any media decoders (or encoders).) If you have a MP3 decoder application that reads from 'stdin', you can simply run: testMP3Receiver | your-MP3-decoder-application Alternatively, just run testMP3Receiver > outputFile.mp3 and this will give you a MP3 file that you can play with a media player. > I want > > to play mp3 file on client side. The easiest way to do this is to run the "LIVE555 Media Server": http://www.live555.com/mediaServer/ to stream your file, and then use a RTSP/RTP media player client - such as VLC - to play it at the receiving end. (Note that, in contrast, "testMP3Streamer"/"testMP3Receiver" are *multicast* applications. They will work only on networks in which end-to-end IP multicast routing is implemented.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 23 21:51:17 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Jun 2014 21:51:17 -0700 Subject: [Live-devel] It could be helpful that UsageEnvironment::reclaim return a completion status In-Reply-To: <6178_1403183968_53A2E360_6178_14612_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A6A13@THSONEA01CMS01P.one.grp> References: <6178_1403183968_53A2E360_6178_14612_1_1BE8971B6CFF3A4F97AF4011882AA2550156541A6A13@THSONEA01CMS01P.one.grp> Message-ID: <8A898723-0685-49ED-8E3F-8D784DE96766@live555.com> > Since some years I am working with your library, I spend some time to understand when objects are deleted. At best, this is symptomatic of poor system design (your design, not mine :-) At worst, this is symptomatic of mental illness. > So I would like to suggest that methods that make ?delete this?, for instance UsageEnvironement::reclaim, could indicate to the caller that the object was deleted or not. Yeah, OK, in the latest release of the software, I changed "UsageEnvironment::reclaim()" to return a Boolean. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikram at vizexperts.com Tue Jun 24 03:38:02 2014 From: vikram at vizexperts.com (Vikram Singh) Date: Tue, 24 Jun 2014 16:08:02 +0530 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <001401cf8c93$cc0981d0$641c8570$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> <001401cf8c93$cc0981d0$641c8570$@vizexperts.com> Message-ID: <002901cf8f98$60e9a6c0$22bcf440$@vizexperts.com> On a further note : - I was testing the same file with wowza streaming server and I did not find any glitches at the start. - But the same file when I am streaming with directly downloaded file testH264VideoStreamer.exe provided in the testprogs of live555 library, the stream starting was very noisy as shown in the links from previous emails. - I also found the same starting frame issues with Darwin streaming server when I was streaming with the same file. - And I am sure the files I am testing with are not corrupted. -vikram singh From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Vikram Singh Sent: Friday, June 20, 2014 7:58 PM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Starting Frames are corrupted Hi ross, Please ignore my previous mail. I was sent accidently. Just for testing purpose, I have reduced my streaming video size to 100*100 px size. By reducing the size I want to avoid the scenario where on the client side there is truncation of data, due to buffer overflow in the starting. This buffer overflow was assumed because the client had no idea about server frame size and initialized a default size to the buffer that receives data. Even then I have the problem of corrupt frames in the starting. Can there be any other case because of which this initial corruption of frames is happening. An another observation is when I had incorrect OutPacketBuffer::maxSize initialized to it, the frame rendered were like this https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharin g i.e the frame would bleed to the bottom and that symbolizes the truncation of frame. Instead the corruption was something like this https://docs.google.com/file/d/0B9yXmUZbfI7_YUxEb1ltZ2pwa3M/edit and after some time it would clear up like this https://docs.google.com/file/d/0B9yXmUZbfI7_VW9uU2NWU041SkE/edit So can there be any other issue that is causing this problem. -vikram From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 18, 2014 11:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Starting Frames are corrupted I am having -- unsigned OutPacketBuffer::maxSize = 900000; in mediaSink.cpp If I decrease the maxSize then the frames I get are truncated. OK, there are two separate buffer sizes that you need to concern yourself with. "OutPacketBuffer::maxSize" is the buffer size that is used - by your server - when *transmitting* NAL units. You must set it to be at least as large as your largest NAL unit. Otherwise you will see (in 'stderr') error messages about needing to increase "OutPacketBuffer::maxSize". The receiving application - in your case VLC - must also have sufficient buffer space to be able to reassemble the incoming RTP packets into a complete NAL unit. That is what I referred to in my previous email message. In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! A NAL unit this large will get fragmented into *60* RTP packets, and *all* of these RTP packets must be received by the receiving application, otherwise the entire frame will be unrenderable. This is why it's much better to reconfigure your encoder so that it breaks up large I-frames into smaller 'slice' NAL units. Can you please specify how to decrease the nal unit size without decreasing the value of maxSize. You mean "how to decrease the nal unit size without *increasing* the value of maxSize"? Once again, you need to reconfigure your encoder to break up large I-frames into smaller 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Tue Jun 24 05:13:56 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Tue, 24 Jun 2014 08:13:56 -0400 Subject: [Live-devel] Starting Frames are corrupted In-Reply-To: <002901cf8f98$60e9a6c0$22bcf440$@vizexperts.com> References: <002401cf8ab1$b6de2510$249a6f30$@vizexperts.com> <53A18CC30200004D000A677A@pta-emo.csir.co.za> <000c01cf8ae6$49adecc0$dd09c640$@vizexperts.com> <4483647D-19F7-4D90-B18C-D4EDCCCC50C4@live555.com> <002701cf8b00$63e0c710$2ba25530$@vizexperts.com> <001401cf8c93$cc0981d0$641c8570$@vizexperts.com> <002901cf8f98$60e9a6c0$22bcf440$@vizexperts.com> Message-ID: The first of the 3 images looks like the information has been truncated, at least on the luminence plane but with all grey it is not certain. The first frame in full color pictures from earlier email, the one of a cube and pyrimid is definitely truncated. With the decoders I've used, when the decoder runs out of info it just maintains the same value for the pixels. There is also damage within the image So there is more going on incorrectly here than just truncated information. Have you checked your YUV flavor? they have different layouts and memory usage. Also when I copied my own data in i was re-educated on how types effect copying. SO double check your data moving for "overlap" make sure you are indeed copying bytes in order and not any overlap, byte order, or type promotion to wider types! On Tue, Jun 24, 2014 at 6:38 AM, Vikram Singh wrote: > On a further note : > > > > - I was testing the same file with wowza streaming server and I > did not find any glitches at the start. > > > > - But the same file when I am streaming with directly downloaded > file testH264VideoStreamer.exe provided in the testprogs of live555 library, > > the stream starting was very noisy as shown in the links from previous > emails. > > > > - I also found the same starting frame issues with Darwin > streaming server when I was streaming with the same file. > > > > - And I am sure the files I am testing with are not corrupted. > > > > -vikram singh > > > > *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf > Of *Vikram Singh > *Sent:* Friday, June 20, 2014 7:58 PM > *To:* 'LIVE555 Streaming Media - development & use' > *Subject:* Re: [Live-devel] Starting Frames are corrupted > > > > Hi ross, > > > > Please ignore my previous mail. I was sent accidently. > > > > Just for testing purpose, I have reduced my streaming video size to > 100*100 px size. > > By reducing the size I want to avoid the scenario where on the client side > there is truncation of data, due to buffer overflow in the starting. > > This buffer overflow was assumed because the client had no idea about > server frame size and initialized a default size to the buffer that > receives data. > > Even then I have the problem of corrupt frames in the starting. > > > > Can there be any other case because of which this initial corruption of > frames is happening. > > > > An another observation is when I had incorrect OutPacketBuffer::maxSize initialized > to it, the frame rendered were like this > > > https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharing > > i.e the frame would bleed to the bottom and that symbolizes the truncation > of frame. > > > > Instead the corruption was something like this > > https://docs.google.com/file/d/0B9yXmUZbfI7_YUxEb1ltZ2pwa3M/edit > > > > and after some time it would clear up like this > > https://docs.google.com/file/d/0B9yXmUZbfI7_VW9uU2NWU041SkE/edit > > > > So can there be any other issue that is causing this problem. > > -vikram > > > > *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf > Of *Ross Finlayson > *Sent:* Wednesday, June 18, 2014 11:13 PM > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] Starting Frames are corrupted > > > > I am having -- unsigned OutPacketBuffer::maxSize = 900000; in > mediaSink.cpp > > If I decrease the maxSize then the frames I get are truncated. > > > > OK, there are two separate buffer sizes that you need to concern yourself > with. > > > > "OutPacketBuffer::maxSize" is the buffer size that is used - by your > server - when *transmitting* NAL units. You must set it to be at least as > large as your largest NAL unit. Otherwise you will see (in 'stderr') error > messages about needing to increase "OutPacketBuffer::maxSize". > > > > The receiving application - in your case VLC - must also have sufficient > buffer space to be able to reassemble the incoming RTP packets into a > complete NAL unit. That is what I referred to in my previous email message. > > > > In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!! > A NAL unit this large will get fragmented into *60* RTP packets, and *all* > of these RTP packets must be received by the receiving application, > otherwise the entire frame will be unrenderable. This is why it's much > better to reconfigure your encoder so that it breaks up large I-frames into > smaller 'slice' NAL units. > > > > > > Can you please specify how to decrease the nal unit size without > decreasing the value of maxSize. > > > > You mean "how to decrease the nal unit size without *increasing* the value > of maxSize"? Once again, you need to reconfigure your encoder to break > up large I-frames into smaller 'slice' NAL units. > > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbadhan at interfaceinfosoft.com Tue Jun 24 05:45:24 2014 From: gbadhan at interfaceinfosoft.com (Gaurav Badhan) Date: Tue, 24 Jun 2014 18:15:24 +0530 Subject: [Live-devel] Live555 support for RTSP over TLS Message-ID: At the to do list is task: "Add support for SRTP ('secure' RTP), and perhaps also RTSP-over-TLS." Do you intend to supply this feature any time soon ? Regards, G Badhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 24 08:41:00 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Jun 2014 08:41:00 -0700 Subject: [Live-devel] Live555 support for RTSP over TLS In-Reply-To: References: Message-ID: <579974FF-8F46-4163-8AD9-C47BF05F21A1@live555.com> > Do you intend to supply this feature any time soon ? If you already have a (TCP) TLS socket set up between your client and server, then you can use it now, using existing code. In "RTSPClient::createNew()", note the (optional) "socketNumToServer" parameter. You can set this to specify the (TLS) socket number. At the server end, note the "ourSocket" parameter to the (protected) "RTSPServer" constructor. You can subclass "RTSPServer", and, in your subclass constructor, pass the (TLS) socket number to the "RTSPServer" constructor. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From grom86 at mail.ru Mon Jun 23 22:28:27 2014 From: grom86 at mail.ru (=?UTF-8?B?bWludXM=?=) Date: Tue, 24 Jun 2014 09:28:27 +0400 Subject: [Live-devel] =?utf-8?q?OpenRTSP_test_sample_stops_after_2_minutes?= In-Reply-To: <1403402818.847119863@f73.i.mail.ru> References: <1403402818.847119863@f73.i.mail.ru> Message-ID: <1403587707.322260319@f216.i.mail.ru> 1) The server is IP camera. Details below: Kernel version: Linux 3.0.8 armv5tejl File system version: TH38R2-ONVIF V2.5.0.6 build 2014-01-26 12:39:49 Here is issuer firmware link: http://www.en.tpsee.com/firmware/20140127/firmware_HI3518C-V2-ONVIF-V2.5.0.6_20140126123951.bin Here is the SDK: http://www.en.tpsee.com/uploads/sdkfile/LinuxNetSDK_Release_x86_V22_20140529.zip I have no direct access to the IP camera operating system, so i cannot see more details 2) Transport: RTP/AVP;unicast. 3) Yes it happens always strongly after 2 minutes. Today i have upgraded IP camera to the latest firmware and now it it happens always strongly after every 3 minutes. 4) Here is the commands and logs: This log file was created with old firmware, then media plays only 2 minutes. command line: ./openRTSP rtsp://user:password at ip/mpeg4cif &> ./openRTSP.txt openRTSP.txt: http://pastebin.com/Vv6aGype Next log file contains more details. It was created with new firmware, then media plays only 3 minutes. I cut some log in the middle, because the file size was more than 500K, pastebin.com has size limit. command line: ./testRTSPClient rtsp://user:password at ip/mpeg4cif &> ./testRTSPClient.txt testRTSPClient.txt: http://pastebin.com/pTwtETg4 P.S. One more very important thing: i found that timecode which comes from the server side with frames, are changed chaotically, example of video track timecode sequence: ... 1400294551722.297119 1400294551761.297119 ... 173358852.978000 173358893.978000 ... As you can see: Value 1400294551722 is the date: Sat May 17 2014 05:42:31 GMT+0300 (EEST) Value?173358893 is the date: Sat Jan 03 1970 03:09:18 GMT+0300 (MSK) So, it looks like somehow the datetime is changed on the IP camera side during play mode. It is quite strange... In the IP camera settings i tried to set "Time Settings" to: update time manually - but it did not help. If i'm using issuer SDK to receive the frames, their library does not stop receive the frames, but timecode is changing chaotically during play mode, like i show above. If you will need more information, or remote access to the IP camera, do not hesitate, ask. ???????????, 22 ???? 2014, 6:06 +04:00 ?? minus : > > >OpenRTSP test sample always stops after 2 minutes. Why it happens and how to prevent it? > > >-- >developer >---------------------------------------------------------------------- >_______________________________________________ >live-devel mailing list >live-devel at lists.live555.com >http://lists.live555.com/mailman/listinfo/live-devel > -- Vadim ` -------------- next part -------------- An HTML attachment was scrubbed... URL: From albion_land at hotmail.com Mon Jun 23 22:59:51 2014 From: albion_land at hotmail.com (From Albion) Date: Tue, 24 Jun 2014 07:59:51 +0200 Subject: [Live-devel] Any method to read tsx files? Message-ID: Hello everybody, I'm working in a team where some co-workers are using Live555. They have ts files with associated tsx files, but some of them are empty and many other are not. I'd like to know if there is any method of reading those tsx files in order to know the content and hopefully discover what's going on. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_q61 at yahoo.com Mon Jun 23 09:48:00 2014 From: john_q61 at yahoo.com (John Q) Date: Mon, 23 Jun 2014 09:48:00 -0700 Subject: proxy server timing issues Message-ID: <1403542080.51104.YahooMailNeo@web122104.mail.ne1.yahoo.com> I am streaming a video only back end live rtsp stream (H264 + RTP) to the proxy server. When I kill all clients that are connected to my live555 proxy server and restart them I notice that the clients (VLC for eg.) start at a video position where the displayed video is 1 minute or older. The longer I wait the more severe this problem gets. When I leave one client always connected and kill other clients and restart them there are no issues. How can I fix this? I mean when I restart all my clients any number of times I want the video displayed to be not more than 2-3 seconds old. Regards John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_q61 at yahoo.com Tue Jun 24 03:18:49 2014 From: john_q61 at yahoo.com (John Q) Date: Tue, 24 Jun 2014 03:18:49 -0700 Subject: [Live-devel] stream webcam using ffmpeg and live555 In-Reply-To: <86A56647-7744-42C5-860E-BE227F0EE26A@live555.com> References: <86A56647-7744-42C5-860E-BE227F0EE26A@live555.com> Message-ID: <1403605129.13020.YahooMailNeo@web122104.mail.ne1.yahoo.com> Hi Ross, That's what I thought too. The "testOnDemandRTSPServer" prints "missing sync byte" on the console when I try to grab frames from it using VLC. On Tuesday, 24 June 2014, 2:29, Ross Finlayson wrote: I want to stream my webcam from a windows 7 (64-bit) machine behind home LAN using ffmpeg as the encoder to a live555 server running on a Debian 64-bit linux machine in a data center over the WAN. I want to send a H.264 RTP/UDP stream from ffmpeg and the "testOnDemandRTSPServer" should send out RTSP streams to clients that connect to it. >I am using the following ffmpeg command which sends UDP data to port 1234, IP address AA.BB.CC.DD >.\ffmpeg.exe -f dshow -i video="Webcam C170":audio="Microphone (3- Webcam C170)" -an -vcodec libx264 -f mpegts udp://AA.BB.CC.DD:1234 >On the linux server I am running the testOnDemandRTSPServer on port 5555 which expects raw UDP data from from AA:BB:CC:DD:1234. I try to open the rtsp stream in VLC using?rtsp://AA.BB.CC.DD:5555/mpeg2TransportStreamFromUDPSourceTest >But I get nothing in VLC.Are you sure that UDP packets from your "ffmpeg" computer are reaching your "testOnDemandRTSPServer" computer? ?Perhaps there's a firewall somewhere inbetween that's blocking UDP packets? ?That's the first thing that you should check. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 25 15:24:55 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jun 2014 15:24:55 -0700 Subject: [Live-devel] OpenRTSP test sample stops after 2 minutes In-Reply-To: <1403587707.322260319@f216.i.mail.ru> References: <1403402818.847119863@f73.i.mail.ru> <1403587707.322260319@f216.i.mail.ru> Message-ID: The diagnostic output from "openRTSP" shows that you are using a (very) old version of the "LIVE555 Streaming Media" software. We support only the latest version of the code. Please upgrade to the latest version; see http://www.live555.com/liveMedia/faq.html#latest-version Also, I see that the server (i.e., your IP camera) is also using the "LIVE555 Streaming Media" software - once again, a very old version. This software is licensed under the GNU LGPL. Consequently, your IP camera's manufacturer must, upon request, upgrade it to use the latest version of the "LIVE555 Streaming Media" software, or else provide a way for you to perform the upgrade yourself. Therefore, please contact your IP camera's manufacturer, telling them that - as a consequence of the GNU LGPL - they must upgrade their firmware to use the latest version of the "LIVE555 Streaming Media" software. For further explanation, you could include a the following URL: http://www.live555.com/liveMedia/faq.html#copyright-and-license Please try running your test again once you have upgraded both your client *and* your server (i.e., IP camera) to use the latest version of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 25 15:59:55 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jun 2014 15:59:55 -0700 Subject: [Live-devel] Any method to read tsx files? In-Reply-To: References: Message-ID: <2BFDE911-A07B-4FA6-8321-7F2C6AAB4204@live555.com> > I'm working in a team Does your team not have its own domain name? :-) > where some co-workers are using Live555. They have ts files with associated tsx files, but some of them are empty and many other are not. The "MPEG2TransportStreamIndexer" utility will generate an empty ".tsx" file if the Transport Stream (i.e., ".ts") file is (somehow) inappropriate for indexing - e.g., if it doesn't contain a MPEG-1,2,4 or H.264 or H.265 video track, or if it's encrypted in some way. If you're still unsure why a ".ts" file generates an empty ".tsx" file, then please put an example ".ts" file on a (publically-accessible) web server, and post the URL, so we can download and test it for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.chanteperdrix at xenomai.org Wed Jun 25 16:09:28 2014 From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix) Date: Thu, 26 Jun 2014 01:09:28 +0200 Subject: [Live-devel] Live555 support for RTSP over TLS In-Reply-To: <579974FF-8F46-4163-8AD9-C47BF05F21A1@live555.com> References: <579974FF-8F46-4163-8AD9-C47BF05F21A1@live555.com> Message-ID: <53AB56A8.70101@xenomai.org> On 06/24/2014 05:41 PM, Ross Finlayson wrote: >> Do you intend to supply this feature any time soon ? > If you already have a (TCP) TLS socket set up between your client and > server, then you can use it now, using existing code. > > In "RTSPClient::createNew()", note the (optional) "socketNumToServer" > parameter. You can set this to specify the (TLS) socket number. > > At the server end, note the "ourSocket" parameter to the (protected) > "RTSPServer" constructor. You can subclass "RTSPServer", and, in your > subclass constructor, pass the (TLS) socket number to the "RTSPServer" > constructor. Hi Ross, a related question, if I want to add SRTP, I have found a library which does it (http://srtp.sourceforge.net/srtp.html), I guess I would have to implement the groupsock interface using this library, however, I still guess, because I have not looked in detail that the key(s) used for SRTP would be negotiated during the RTSP dialog, so the question I have is, would it be easy to extend the RTSPServer class by subclassing to add the key negotiation? Regards. -- Gilles. From finlayson at live555.com Wed Jun 25 16:11:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jun 2014 16:11:02 -0700 Subject: [Live-devel] proxy server timing issues In-Reply-To: References: Message-ID: <2CDA589E-EC95-4320-9AA3-B1507742F63A@live555.com> > I am streaming a video only back end live rtsp stream (H264 + RTP) to the proxy server. > > When I kill all clients that are connected to my live555 proxy server and restart them I notice that the clients (VLC for eg.) start at a video position where the displayed video is 1 minute or older. The longer I wait the more severe this problem gets. When I leave one client always connected and kill other clients and restart them there are no issues. When all of the front-end clients of the "LIVE555 Proxy Server" have disconnected, then the proxy server will send a RTSP "PAUSE" command to the back-end server. Then later, when the next front-end client connects, it will send a RTSP "PLAY" command to the back-end server. (You can see this by running the proxy server with the "-V" option; see http://www.live555.com/proxyServer/ ) If the 'back-end' server implements the "PAUSE" command, then this means that there will be no gap in the media between the last front-end client disconnecting, and the next front-end client connecting. However, if the back-end server does not implement "PAUSE" (which it typically won't, if it's a live network camera, for example), then of course you'll see a gap in time. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 25 16:13:54 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Jun 2014 16:13:54 -0700 Subject: [Live-devel] stream webcam using ffmpeg and live555 In-Reply-To: References: <86A56647-7744-42C5-860E-BE227F0EE26A@live555.com> Message-ID: <8A3A09E6-84D6-488E-9D24-C17591FAB4DD@live555.com> > That's what I thought too. The "testOnDemandRTSPServer" prints "missing sync byte" on the console when I try to grab frames from it using VLC. Why didn't you mention this before? That's your problem: The UDP stream that you're generating (using "ffmpeg") does not contain proper MPEG Transport Stream data. That's what you need to fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbadhan at interfaceinfosoft.com Thu Jun 26 06:38:10 2014 From: gbadhan at interfaceinfosoft.com (Gaurav Badhan) Date: Thu, 26 Jun 2014 19:08:10 +0530 Subject: [Live-devel] Live555 support for RTSP over TLS In-Reply-To: <53AB56A8.70101@xenomai.org> References: <579974FF-8F46-4163-8AD9-C47BF05F21A1@live555.com> <53AB56A8.70101@xenomai.org> Message-ID: Is there any change in RTSP url when we stream RTSP over TLS ? Regards, Gaurav Badhan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 26 08:57:17 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 08:57:17 -0700 Subject: [Live-devel] Live555 support for RTSP over TLS In-Reply-To: References: <579974FF-8F46-4163-8AD9-C47BF05F21A1@live555.com> <53AB56A8.70101@xenomai.org> Message-ID: <29C98777-5550-452E-922C-82C876D8094F@live555.com> > Is there any change in RTSP url when we stream RTSP over TLS ? As I noted before, you can do this between an existing LIVE555 RTSP client and an existing LIVE555 RTSP server - with no change to the existing LIVE555 code. If you do things this way, then the answer is no - there's no change in RTSP URL. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Thu Jun 26 09:13:10 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Thu, 26 Jun 2014 17:13:10 +0100 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> Message-ID: <53AC4696.6010304@panogenics.com> Hi Ross, We have rebuilt with -g and without -o0 and get the same result (SIGABRT in disassembled code, no stack trace). We have tried the latest build of OpenRTSP with the -T flag. OpenRTSP does not send GET_PARAMETER requests to the Live555 server, so it will not call the code in base64Decode where the SIGABRT occurs (in the new or delete calls). We are using VLC client which does send the GET_PARAMETER messages. The crash during GET_PARAMETER message processing appears to be related to truncated base 64 encoded GET_PARAMETER requests, so may be triggered by network congestion. Excepts from the live555 debug (with indented lines being debug we have added to try to locate the crash) are attached below. It appears that after sending the RTSP/1.0 400 Bad Request response, RTSPClientConnection::handleRequestBytes is called with 3 bytes, which sets fBase64RemainderCount to 3. Is this causing the pointer passed into base64Decode to go out of range ? Please let me know if there are further tests we can do to find the cause and indicate a fix for this issue. Thanks for the mention in the latest changelog ... Best Regards, Piers Hawksley The following happens twice with many RTCP Liveness indications between. RTSPClientConnection[0x1b64b8]::handleRequestBytes() read 443 new bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy44MC9zdHJlYW0wLyBSVFNQLzEuMA0KQ1NlcTogNzQNCkF1dGhvcml6YXRpb246IERpZ2VzdCB1c2VybmFtZT0iQWRtaW4iLCByZWFsbT0iTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEiLCBub25jZT0iYTlmMDA1ODBlYTA2ZDMxYmIxNWI1ZTU4OTk1ZGFmNmIiLCB1cmk9InJ0c3A6Ly8xMC4yNi43LjgwL3N0cmVhbTAvIiwgcmVzcG9uc2U9ImMwZDgzNGQyNGY4NjE5ZjdiOTU3NmNmZjE4YjRjN2UyIg0KVXNlci1BZ2VudDogTGliVkxDLzIuMS4zIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMS4yMSkNClNlc3Npb246IDcwOTY numBytesToDecode=440, newBase64RemainderCount=3 out=0x27cd80 k=330, paddingCount=0, inSize=440 trimTrailingZeros=1 resultSize=330 new result=0x27cf40 Moved out to result deleted out decodedBytes=0x27cf40 Base64-decoded 440 input bytes into 330 new bytes:GET_PARAMETER rtsp://10.26.7.80/stream0/ RTSP/1.0 CSeq: 74 Authorization: Digest username="Admin", realm="LIVE555 Streaming Media", nonce="a9f00580ea06d31bb15b5e58995daf6b", uri="rtsp://10.26.7.80/stream0/", response="c0d834d24f8619f7b9576cff18b4c7e2" User-Agent: LibVLC/2.1.3 (LIVE555 Streaming Media v2014.01.21) Session: 70 Deletedd decodedBytes fBase64RemainderCount=3 RTSPClientConnection[0x1b64b8]::handleRequestBytes() read 13 new bytes:3QjVEDQoNCg== numBytesToDecode=16, newBase64RemainderCount=0 out=0x183708 k=12, paddingCount=2, inSize=16 trimTrailingZeros=1 resultSize=10 new result=0x183748 Moved out to result deleted out decodedBytes=0x183748 Base64-decoded 16 input bytes into 10 new bytes:7B5D Deletedd decodedBytes fBase64RemainderCount=0 parseRTSPRequestString() failed; checking now for HTTP commands (for RTSP-over-HTTP tunneling)... parseHTTPRequestString() failed! sending response: RTSP/1.0 400 Bad Request Date: Wed, Jun 18 2014 14:15:32 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[0x1b64b8]::handleRequestBytes() processing 3 new bytes:oNC numBytesToDecode=0, newBase64RemainderCount=3 fBase64RemainderCount=3 Then after a few more RTCP Liveness indications we receive a complete base 64 encoded GET_PARAMETER request (with fBase64RemainderCount set to 3) and crash. RTSPClientConnection[0x1b64b8]::handleRequestBytes() read 456 new bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy44MC9zdHJlYW0wLyBSVFNQLzEuMA0KQ1NlcTogNzUNCkF1dGhvcml6YXRpb246IERpZ2VzdCB1c2VybmFtZT0iQWRtaW4iLCByZWFsbT0iTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEiLCBub25jZT0iYTlmMDA1ODBlYTA2ZDMxYmIxNWI1ZTU4OTk1ZGFmNmIiLCB1cmk9InJ0c3A6Ly8xMC4yNi43LjgwL3N0cmVhbTAvIiwgcmVzcG9uc2U9ImMwZDgzNGQyNGY4NjE5ZjdiOTU3NmNmZjE4YjRjN2UyIg0KVXNlci1BZ2VudDogTGliVkxDLzIuMS4zIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMS4yMSkNClNlc3Npb246IDcwOTY3QjVEDQoNCg== numBytesToDecode=456, newBase64RemainderCount=3 out=0x183830 k=342, paddingCount=0, inSize=456 trimTrailingZeros=1 resultSize=342 new result=0x27cd48 Moved out to result *** glibc detected *** /program/name: free(): invalid next size (fast): 0x00183830 *** From Daniel.Labonte at pleora.com Thu Jun 26 10:17:34 2014 From: Daniel.Labonte at pleora.com (Daniel Labonte) Date: Thu, 26 Jun 2014 13:17:34 -0400 Subject: [Live-devel] Errors on client side when using vlc as media player Message-ID: <94E1258436EAB845827EACDADB37210E30A89EE885@pleora-post> Good afternoon, my current project involves sampling video transmitted in real-time (in this case a test pattern) and stream these images to be viewed remotely on a client computer. The environment is a Ubuntu 12.04 64bit machine. Tests were done using a physical server and a virtual machine. For the current prototype, the captured images are put into an .avi container using openCV, the output being a named pipe (pleoraFIFO.avi). This avi file is then converted using avconv to produce a H264 format video. The actual command and arguments used is: avconv -i ./pleoraFIFO.avi -vcodec libx264 -an -f flv test.264 The idea is then to stream the file test.264 using live555. I tried different approaches; live555MediaServer, testONDemandRTSPServer, testH264VideoStreamer and a modified version of testONDemandRTSPServer where only test.264 is streamed. Regardless of the live555 executable used, I am unable to view the video stream on a client. Note that the file test.264.can be viewed using a media player (totem or vlc) on the server. I have attached different stats/log information related to test.264 and information reported by testRTSPCLient and openRTSP on the client side. If vlc is used on the server to stream the video. the following errors are reported: vlc test.264 --sout '#rtp{dst=192.168.0.12,port=1234,sdp=rtsp://192.168.129.102:8080/test.sdp}' VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b) [0x8703f8] logger interface: using logger. [0x792108] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x7f02e00012c8] stream_out_rtp stream out: Consider passing --rtsp-host=IP on the command line instead. [flv @ 0x7f0314c1ebc0] Estimating duration from bitrate, this may be inaccurate [flv @ 0x7f02e00027a0] Estimating duration from bitrate, this may be inaccurate [0x7f02e0c10278] main demux error: option sub-original-fps does not exist [0x7f0304000b78] main input error: no suitable demux module for `file/subtitle:///home/builduer/samples/eppGateway//test264.txt' although the streamed video can be viewed using vlc rtsp on the client side vlc rtsp://192.168.129.102:8080/test.sdp I am confused as to why I experience the reported errors streaming using live555 media server applications and your help/comments are welcome. I downloaded and build live555 version dated May 27, 2014. Regards Daniel _______________________ Daniel Labonte Senior Software Designer Pleora Technologies Inc. Tel: +1-613-270-0625 | Fax: +1-613-270-1425 Daniel.Labonte at pleora.com | www.pleora.com Discover the Next Generation of Video Interfaces We've Moved! Please note our new address: 340 Terry Fox Drive, Suite 300 Kanata, Ontario K2K 3A2 This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test264.txt URL: From finlayson at live555.com Thu Jun 26 11:59:17 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 11:59:17 -0700 Subject: [Live-devel] Errors on client side when using vlc as media player In-Reply-To: <94E1258436EAB845827EACDADB37210E30A89EE885@pleora-post> References: <94E1258436EAB845827EACDADB37210E30A89EE885@pleora-post> Message-ID: <99E79C7B-CEFF-4741-8622-392C2A27C221@live555.com> > The idea is then to stream the file test.264 using live555. I tried different approaches; live555MediaServer, testONDemandRTSPServer, > testH264VideoStreamer and a modified version of testONDemandRTSPServer where only test.264 is streamed. Regardless of the live555 > executable used, I am unable to view the video stream on a client. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your "test.264" file on a publically-accessible web (or FTP) server, and post the URL (not the file itself) to the "live-devel" mailing list, and we'll take a look at it, to see if we can figure out what's wrong. > If vlc is used on the server to stream the video When VLC is used as a RTSP server, it does not use the "LIVE555 Streaming Media" code, so that's not relevant here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xxiao8 at fosiao.com Thu Jun 26 13:45:45 2014 From: xxiao8 at fosiao.com (Xh Xiao) Date: Fri, 27 Jun 2014 04:45:45 +0800 Subject: [Live-devel] live555 sdp issue Message-ID: <53ac867f.83e0440a.492e.0530@mx.google.com> We have a live rtsp streaming that can be played by mplayer,can be saved as file then replayed by vlc or mplayer. strangely,vlc can never play the live rtsp directly,we have been debugging this for two weeks. Below is the sdp captured,we noticed "m" has 0 for port number,don'know if that's the problem. Does anyone have any suggestions on how to further debug this? Thanks, Xxiao Seq: 3 Date: Thu, Jun 26 2014 11:47:49 GMT? Content-Base: rtsp://192.168.1.200:8888/video1/? Content-Type: application/sdpM? Content-Length: 486? v=0 o=- 1403783261801022 1 IN IP4 192.168.1.200? s=Session streamed by "testOnDemandRTSPServer"? i=video1 t=0 0 a=tool:LIVE555 Streaming Media v2014.05.27? a=type:broadcast a=control:*? a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"? a=x-qt-text-inf:video1 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:512000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=42401E;sprop-parameter-sets=Z0JAHqaAtD2Q,aM4wpIA= a=control:track1 From finlayson at live555.com Thu Jun 26 14:04:05 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 14:04:05 -0700 Subject: [Live-devel] live555 sdp issue In-Reply-To: <53ac867f.83e0440a.492e.0530@mx.google.com> References: <53ac867f.83e0440a.492e.0530@mx.google.com> Message-ID: <4BC4C15A-8495-4B15-A06F-2EE55A858B14@live555.com> > We have a live rtsp streaming that can be played by mplayer,can be saved as file then replayed by vlc or mplayer. strangely,vlc can never play the live rtsp directly Before using MPlayer or VLC (which is not our software) to debug your server, you should use "openRTSP": http://www.live555.com/openRTSP Try using "openRTSP" to receive your stream (and output it to a file). Rename the output file to have a ".h264" filename suffix. Can VLC play this file (i.e., directly)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 26 14:08:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 14:08:02 -0700 Subject: [Live-devel] live555 sdp issue In-Reply-To: <53ac867f.83e0440a.492e.0530@mx.google.com> References: <53ac867f.83e0440a.492e.0530@mx.google.com> Message-ID: > Below is the sdp captured,we noticed "m" has 0 for port number,don'know if that's the problem. BTW, that's not a problem. A port number of 0 in the SDP description is normal when streaming a unicast stream using RTSP. (For unicast streams, the port number(s) don't get assigned until later in the RTSP protocol exchange.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 26 14:18:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 14:18:49 -0700 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <53AC4696.6010304@panogenics.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> <53AC4696.6010304@panogenics.com> Message-ID: <22D25135-C4B0-4686-A0AA-76FA166102B5@live555.com> Piers, Thanks for the report. Using it, I was able to identify a bug in the RTSP server code (when an incoming Base-64-encoded request is fragmented over multiple reads, as in your case). A new version of the code - fixing this bug - will be available shortly. (I'll send out another email when it's ready.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xxiao8 at fosiao.com Thu Jun 26 15:31:42 2014 From: xxiao8 at fosiao.com (Xh Xiao) Date: Fri, 27 Jun 2014 06:31:42 +0800 Subject: [Live-devel] live555 sdp issue Message-ID: <53ac9fd6.e4b6440a.644d.10f7@mx.google.com> Ross, We did that,and it plays well. Xxiao 2014?6?27? ??5:04? Ross Finlayson ??? >> >> We have a live rtsp streaming that can be played by mplayer,can be saved as file then replayed by vlc or mplayer. strangely,vlc can never play the live rtsp directly > > > Before using MPlayer or VLC (which is not our software) to debug your server, you should use "openRTSP": > http://www.live555.com/openRTSP > > Try using "openRTSP" to receive your stream (and output it to a file). ?Rename the output file to have a ".h264" filename suffix. > > Can VLC play this file (i.e., directly)? > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > From xxiao8 at fosiao.com Thu Jun 26 15:57:27 2014 From: xxiao8 at fosiao.com (xxiao8) Date: Fri, 27 Jun 2014 06:57:27 +0800 Subject: [Live-devel] live555 sdp issue In-Reply-To: References: <53ac867f.83e0440a.492e.0530@mx.google.com> Message-ID: <53ACA557.1020101@fosiao.com> Thanks! Xxiao On 06/27/2014 05:08 AM, Ross Finlayson wrote: >> Below is the sdp captured,we noticed "m" has 0 for port >> number,don'know if that's the problem. > > BTW, that's not a problem. A port number of 0 in the SDP description > is normal when streaming a unicast stream using RTSP. (For unicast > streams, the port number(s) don't get assigned until later in the RTSP > protocol exchange.) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 26 16:08:54 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 16:08:54 -0700 Subject: [Live-devel] live555 sdp issue In-Reply-To: <53ac9fd6.e4b6440a.644d.10f7@mx.google.com> References: <53ac9fd6.e4b6440a.644d.10f7@mx.google.com> Message-ID: <298A5E8D-B0AC-4EF2-871D-7C953E86A731@live555.com> >> Try using "openRTSP" to receive your stream (and output it to a file). Rename the output file to have a ".h264" filename suffix. >> >> Can VLC play this file (i.e., directly)? > > We did that,and it plays well. OK, so now rename this file to have a ".264" (*not* ".h264") filename, and try streaming it using the "LIVE555 Media Server". When you do this, can VLC play the stream (i.e., from a "rtsp://") URL? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 26 18:24:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Jun 2014 18:24:47 -0700 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <53AC4696.6010304@panogenics.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> <53AC4696.6010304@panogenics.com> Message-ID: <55F3950E-6616-4876-8218-E439EA5C57D8@live555.com> FYI, I've just installed a new version - 2014.06.27 - of the code that, I believe, will fix the RTP/RTCP-over-HTTP server error that you saw. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_q61 at yahoo.com Thu Jun 26 00:50:51 2014 From: john_q61 at yahoo.com (John Q) Date: Thu, 26 Jun 2014 00:50:51 -0700 Subject: [Live-devel] stream webcam using ffmpeg and live555 In-Reply-To: <8A3A09E6-84D6-488E-9D24-C17591FAB4DD@live555.com> References: <86A56647-7744-42C5-860E-BE227F0EE26A@live555.com> <8A3A09E6-84D6-488E-9D24-C17591FAB4DD@live555.com> Message-ID: <1403769051.59867.YahooMailNeo@web122105.mail.ne1.yahoo.com> How can I fix it? I am new here. Any suggestions? Much appreciate your pointing me in the right direction. On Thursday, 26 June 2014, 4:44, Ross Finlayson wrote: That's what I thought too. The "testOnDemandRTSPServer" prints "missing sync byte" on the console when I try to grab frames from it using VLC. Why didn't you mention this before? ?That's your problem: The UDP stream that you're generating (using "ffmpeg") does not contain proper MPEG Transport Stream data. ?That's what you need to fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Fri Jun 27 01:34:32 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Fri, 27 Jun 2014 09:34:32 +0100 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <55F3950E-6616-4876-8218-E439EA5C57D8@live555.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> <53AC4696.6010304@panogenics.com> <55F3950E-6616-4876-8218-E439EA5C57D8@live555.com> Message-ID: <53AD2C98.4060703@panogenics.com> Excellent - thanks Ross, I've downloaded and built the new version and started running it through gdb. I will let you know if it runs for > 2 hours and look out for requests that get split over more than one network read. Many Thanks, Piers From piers.hawksley at panogenics.com Fri Jun 27 04:25:07 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Fri, 27 Jun 2014 12:25:07 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: References: <53A07073.9070008@panogenics.com> Message-ID: <53AD5493.1060605@panogenics.com> Hi Ross, Thanks for you suggestions on the patch I sent in. I have removed the rogue member variable I proposed and made fCurrentPID protected and ensured the MPEG2TransportStreamMultiplexor constructor initialises it. fCurrentPID is now set in MPEG2TransportStreamFromESSource::addNewInputSource to: (by default) the stream ID provided (e.g. the current behaviour, where stream ID may be set in addNewVideoSource or addNewAudioSource); or, the value provided (limited to 0x00 to 0xff). I've used PID as the new variable name (it sets the PCR PID and Elementary ID in the Program Map Table and the Packet ID of the rest of the stream) and kept stream_id as the video / audio stream ID. Please consider this revised patch for inclusion in your next release. It extends the current code to allow the Transport Stream Packet ID to be set explicitly. It is limited to 8 bit values not the 13 bits available due to the value of PID_TABLE_SIZE in MPEG2TransportStreamMultiplexor.hh. Many Thanks, Piers -------------- next part -------------- 34a35 > fCurrentPID(0), 37c38 < fPCR_PID(0), fCurrentPID(0), --- > fPCR_PID(0), 109c110 < fCurrentPID = stream_id; --- > // fCurrentPID now set in MPEG2TransportStreamFromESSource::addNewInputSource -------------- next part -------------- 61a62,64 > // Note: We used to map 8-bit stream_ids directly to PIDs, now we set it > // in MPEG2TransportStreamFromESSource::addNewInputSource > u_int8_t fCurrentPID; 72,73c75 < u_int8_t fPCR_PID, fCurrentPID; < // Note: We map 8-bit stream_ids directly to PIDs --- > u_int8_t fPCR_PID; -------------- next part -------------- 82c82 < ::addNewVideoSource(FramedSource* inputSource, int mpegVersion) { --- > ::addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t PID) { 84c84 < addNewInputSource(inputSource, streamId, mpegVersion); --- > addNewInputSource(inputSource, streamId, mpegVersion, PID); 89c89 < ::addNewAudioSource(FramedSource* inputSource, int mpegVersion) { --- > ::addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t PID) { 91c91 < addNewInputSource(inputSource, streamId, mpegVersion); --- > addNewInputSource(inputSource, streamId, mpegVersion, PID); 146c146 < u_int8_t streamId, int mpegVersion) { --- > u_int8_t streamId, int mpegVersion, int16_t PID) { 147a148,153 > // Note that fCurrentPID is 8 bits not 13 bits as it is limited by > // PID_TABLE_SIZE in MPEG2TransportStreamMultiplexor.hh > if (PID == -1) > fCurrentPID = streamId; > else > fCurrentPID = u_int8_t(PID); -------------- next part -------------- 33c33 < void addNewVideoSource(FramedSource* inputSource, int mpegVersion); --- > void addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t PID = -1); 35c35 < void addNewAudioSource(FramedSource* inputSource, int mpegVersion); --- > void addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t PID = -1); 43c43 < u_int8_t streamId, int mpegVersion); --- > u_int8_t streamId, int mpegVersion, int16_t PID = -1); From piers.hawksley at panogenics.com Fri Jun 27 04:40:31 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Fri, 27 Jun 2014 12:40:31 +0100 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <53AD2C98.4060703@panogenics.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> <53AC4696.6010304@panogenics.com> <55F3950E-6616-4876-8218-E439EA5C57D8@live555.com> <53AD2C98.4060703@panogenics.com> Message-ID: <53AD582F.3050705@panogenics.com> Hi Ross, The new version has been running for over 3 hours and it successfully combines split base 64 encoded GET_PARAMETER requests: RTSPClientConnection[0x1de840]::handleRequestBytes() read 271 new bytes:R0VUX1BBUkFNRVRFUiBydHNwOi8vMTAuMjYuNy4xMjA6ODU1NC9zdHJlYW05LyBSVFNQLzEuMA0KQ1NlcTogNzINCkF1dGhvcml6YXRpb246IERpZ2VzdCB1c2VybmFtZT0iQWRtaW4iLCByZWFsbT0iTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEiLCBub25jZT0iZjYzMjhiZDNhNzE3MDJjYmE1OWVkYzg3NGJlNmU3ZjQiLCB1cmk9InJ0c3A6Ly8xMC4yNi43LjE Base64-decoded 268 input bytes into 201 new bytes:GET_PARAMETER rtsp://10.26.7.120:8554/stream9/ RTSP/1.0 CSeq: 72 Authorization: Digest username="Admin", realm="LIVE555 Streaming Media", nonce="f6328bd3a71702cba59edc874be6e7f4", uri="rtsp://10.26.7 RTSPClientConnection[0x1de840]::handleRequestBytes() read 201 new bytes:yMDo4NTU0L3N0cmVhbTkvIiwgcmVzcG9uc2U9IjdkODkyNjk4MjZiYmQxNjA2ZmVjMTE5MDVlODk1MGIzIg0KVXNlci1BZ2VudDogTGliVkxDLzIuMS4zIChMSVZFNTU1IFN0cmVhbWluZyBNZWRpYSB2MjAxNC4wMS4yMSkNClNlc3Npb246IDZBRkEwQ0Y5DQoNCg== Base64-decoded 204 input bytes into 151 new bytes:.120:8554/stream9/", response="7d89269826bbd1606fec11905e8950b3" User-Agent: LibVLC/2.1.3 (LIVE555 Streaming Media v2014.01.21) Session: 6AFA0CF9 parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "stream9", urlSuffix "", CSeq "72", Content-Length 0, with 3 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 72 Date: Fri, Jun 27 2014 09:38:13 GMT Session: 6AFA0CF9 Content-Length: 10 2014.06.27RTSPClientConnection[0x1de840]::handleRequestBytes() processing 3 new bytes:pYS Is the last line (handleRequestBytes() processing 3 new bytes) expected ? This only occurs (in the debug I have) when the GET_PARAMETER request is split. Many thanks for fixing this, Piers From xxiao8 at fosiao.com Fri Jun 27 07:44:32 2014 From: xxiao8 at fosiao.com (xxiao8) Date: Fri, 27 Jun 2014 22:44:32 +0800 Subject: [Live-devel] live555 sdp issue In-Reply-To: <298A5E8D-B0AC-4EF2-871D-7C953E86A731@live555.com> References: <53ac9fd6.e4b6440a.644d.10f7@mx.google.com> <298A5E8D-B0AC-4EF2-871D-7C953E86A731@live555.com> Message-ID: <53AD8350.8000700@fosiao.com> Sorry I stated wrong. After openRTSP received a file(test.h264), mplayer can play it but vlc can not. mplayer can also play the rtsp stream directly which vlc can not. When VLC is used to play the stream, I can verify "Demux datasize" has valid value, and "Content bitrate" is around 500Kb/second, "Codec" under "Media Information" showed h264 as well, so it seems RTSP is streaming, just that we can never see the video in VLC window. VLC is running under Ubuntu 12.04 64bit, again, mplayer can play the same stream just fine. What's the difference between .264 and .h264? I noticed for the sample 264 files at live555.com, I had to rename it to .h264 before vlc can play that file, for mplayer, it does not care about .264 or .h264 as the file extension. Thanks, xxiao On 06/27/2014 07:08 AM, Ross Finlayson wrote: >>> Try using "openRTSP" to receive your stream (and output it to a >>> file). Rename the output file to have a ".h264" filename suffix. >>> >>> Can VLC play this file (i.e., directly)? >> >> We did that,and it plays well. > > OK, so now rename this file to have a ".264" (*not* ".h264") filename, > and try streaming it using the "LIVE555 Media Server". When you do > this, can VLC play the stream (i.e., from a "rtsp://") URL? > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 27 07:51:23 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jun 2014 07:51:23 -0700 Subject: [Live-devel] live555 sdp issue In-Reply-To: <53AD8350.8000700@fosiao.com> References: <53ac9fd6.e4b6440a.644d.10f7@mx.google.com> <298A5E8D-B0AC-4EF2-871D-7C953E86A731@live555.com> <53AD8350.8000700@fosiao.com> Message-ID: > Sorry I stated wrong. > > After openRTSP received a file(test.h264), mplayer can play it but vlc can not. OK, so that means that there is something wrong with your encoded video that is causing VLC to fail to play it - either directly from a file, or from a RTSP stream. You're going to have to figure out yourself (perhaps with help from a VLC mailing list) why that is. (VLC is not our software.) > What's the difference between .264 and .h264? I noticed for the sample 264 files at live555.com, I had to rename it to .h264 before vlc can play that file, for mplayer, it does not care about .264 or .h264 as the file extension. Our software uses the filename extension ".264". VLC requires the filename extension ".h264". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Labonte at pleora.com Fri Jun 27 09:46:20 2014 From: Daniel.Labonte at pleora.com (Daniel Labonte) Date: Fri, 27 Jun 2014 12:46:20 -0400 Subject: [Live-devel] FW: Errors on client side when using vlc as media player Message-ID: <94E1258436EAB845827EACDADB37210E30A89EEA4A@pleora-post> Hi again, I believe I solved the errors with the streaming. I changed one command line argument for avconv using -f h264 instead of flv, as the comments in testOnDemandRTSPServer mention h.264 video elementary stream. I will review the FAQ to address my next issue; streaming live video, or stream from a pipe. Regards, Daniel From: Daniel Labonte Sent: June-26-14 1:18 PM To: ' Subject: Errors on client side when using vlc as media player Good afternoon, my current project involves sampling video transmitted in real-time (in this case a test pattern) and stream these images to be viewed remotely on a client computer. The environment is a Ubuntu 12.04 64bit machine. Tests were done using a physical server and a virtual machine. For the current prototype, the captured images are put into an .avi container using openCV, the output being a named pipe (pleoraFIFO.avi). This avi file is then converted using avconv to produce a H264 format video. The actual command and arguments used is: avconv -i ./pleoraFIFO.avi -vcodec libx264 -an -f flv test.264 The idea is then to stream the file test.264 using live555. I tried different approaches; live555MediaServer, testONDemandRTSPServer, testH264VideoStreamer and a modified version of testONDemandRTSPServer where only test.264 is streamed. Regardless of the live555 executable used, I am unable to view the video stream on a client. Note that the file test.264.can be viewed using a media player (totem or vlc) on the server. I have attached different stats/log information related to test.264 and information reported by testRTSPCLient and openRTSP on the client side. If vlc is used on the server to stream the video. the following errors are reported: vlc test.264 --sout '#rtp{dst=192.168.0.12,port=1234,sdp=rtsp://192.168.129.102:8080/test.sdp}' VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b) [0x8703f8] logger interface: using logger. [0x792108] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x7f02e00012c8] stream_out_rtp stream out: Consider passing --rtsp-host=IP on the command line instead. [flv @ 0x7f0314c1ebc0] Estimating duration from bitrate, this may be inaccurate [flv @ 0x7f02e00027a0] Estimating duration from bitrate, this may be inaccurate [0x7f02e0c10278] main demux error: option sub-original-fps does not exist [0x7f0304000b78] main input error: no suitable demux module for `file/subtitle:///home/builduer/samples/eppGateway//test264.txt' although the streamed video can be viewed using vlc rtsp on the client side vlc rtsp://192.168.129.102:8080/test.sdp I am confused as to why I experience the reported errors streaming using live555 media server applications and your help/comments are welcome. I downloaded and build live555 version dated May 27, 2014. Regards Daniel _______________________ Daniel Labonte Senior Software Designer Pleora Technologies Inc. Tel: +1-613-270-0625 | Fax: +1-613-270-1425 Daniel.Labonte at pleora.com | www.pleora.com Discover the Next Generation of Video Interfaces We've Moved! Please note our new address: 340 Terry Fox Drive, Suite 300 Kanata, Ontario K2K 3A2 This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test264.txt URL: From finlayson at live555.com Fri Jun 27 13:14:03 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jun 2014 13:14:03 -0700 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: <53AD5493.1060605@panogenics.com> References: <53A07073.9070008@panogenics.com> <53AD5493.1060605@panogenics.com> Message-ID: <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> No, this is still all wrong. First, it (once again) works for only one subclass of "MPEG2TransportStreamMultiplexor" (and, in particular, doesn't work for "MPEG2TransportStreamFromPESSource" at all). But it turns out that there's a more fundamental problem: This won't work if more than one stream is being multiplexed concurrently into a "MPEG2TransportStreamMultiplexor". "fCurrentPID" can't be a single variable, assigned just once. It has to be assigned each time that the multiplexor receives a new 'input packet'. Note that the 'input packets' are PES packets, whose headers contain only 'stream ids', not PIDs. That's why we just reuse the 'stream id' as the PID. So I'm not going to be changing the existing code. You're going to have to live with the generated Transport Stream's PIDs being the same as the 'stream ids', just like everyone else. (Nobody really needs to change these PIDs anyway.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 27 13:15:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Jun 2014 13:15:37 -0700 Subject: [Live-devel] SIGABRT in base64Decode in liveMedia/Base64.cpp In-Reply-To: <53AD582F.3050705@panogenics.com> References: <53A1B627.6030400@panogenics.com> <9E447638-C051-4104-95E1-D4F81DB74586@live555.com> <53AC4696.6010304@panogenics.com> <55F3950E-6616-4876-8218-E439EA5C57D8@live555.com> <53AD2C98.4060703@panogenics.com> <53AD582F.3050705@panogenics.com> Message-ID: <22F9407B-F9DA-4B4E-9884-E89CD28CA3B4@live555.com> > Is the last line (handleRequestBytes() processing 3 new bytes) expected ? No, this is another bug in the code; it'll be fixed in the next release of the software (in a few hours). (Fortunately, it would cause a problem only if a Base-64-encoded request were split into three or more network reads, not just two.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Fri Jun 27 00:27:44 2014 From: fantasyvideo at 126.com (Tony) Date: Fri, 27 Jun 2014 15:27:44 +0800 (CST) Subject: [Live-devel] Regarding the crash when creating RTSPClientSession Message-ID: <23be48e6.6c33.146dc390cba.Coremail.fantasyvideo@126.com> Hi Ross, I get one strange problem sometimes, I get the crash when creating the RTSPClientSession, Could you check it please? I attach the callback screenshot. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.jpg Type: image/jpeg Size: 137096 bytes Desc: not available URL: From piers.hawksley at panogenics.com Fri Jun 27 23:32:12 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Sat, 28 Jun 2014 07:32:12 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> References: <53A07073.9070008@panogenics.com> <53AD5493.1060605@panogenics.com> <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> Message-ID: <04c14a2e-691f-44f6-9553-c602aa722717@email.android.com> Thanks Ross, So MPEG2TransportStreamFromPESSource provides data with the stream_id already set and no methods for setting the packet id ? I'm sorry I didn't understand this before. We have an awkward requirement to work with an installed set of hardware decoders which are set to receive a specific packet id. Thanks for explaining how fCurrentPID is used per packet received. Reusing the stream_id as the packet id makes sense in this context. Best regards, Piers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heikifm at gmail.com Sun Jun 29 19:54:50 2014 From: heikifm at gmail.com (SingHa Winter) Date: Mon, 30 Jun 2014 11:54:50 +0900 Subject: [Live-devel] [Live_devel] mpg file does not finish immediately at EOF Message-ID: Hi Ross, I'm curious about why mpg file does not finish immediately at EOF. At EOF, VLC freezes some seconds showing last image, and live555 RTSP server does TEARDOWN things after that, and VLC finishes play. The other format is ok, VLC finishes immediately after EOF. Why does this happen, is it natural process? Best Regars, -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 29 21:11:01 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Jun 2014 21:11:01 -0700 Subject: [Live-devel] [Live_devel] mpg file does not finish immediately at EOF In-Reply-To: References: Message-ID: <403EA3A9-82EC-4EAD-A29C-DB0A90E384E3@live555.com> > I'm curious about why mpg file does not finish immediately at EOF. Which mpg file? Why is this so hard for people to understand? If you're having trouble streaming a particular file, then please put it on a publically-accessible web (or FTP) server, and post the URL (not the file itself) to the "live-devel" mailing list, and we'll take a look at it, to see if we can figure out what's wrong. See http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 29 21:28:57 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Jun 2014 21:28:57 -0700 Subject: [Live-devel] [Live_devel] mpg file does not finish immediately at EOF In-Reply-To: References: Message-ID: <401F9226-A869-489B-9E39-D35B50D6EBAE@live555.com> But anyway - because your question applies to *any* ".mpg" file, I can answer it without seeing your file. Because ".mpg" files (i.e., MPEG-1 or 2 audio+video Program Stream files) have a known duration, and can be seeked within, our RTSP server does not send a RTCP "BYE" packet when it reaches the end of the file. This allows the RTSP client - if it wishes - to seek backwards within the file, and replay it. I.e., for this type of file, the RTSP session is kept open when the server reaches the end of the file. The RTSP client knows - from the stream's SDP description - the duration of the stream, and therefore may, if it wishes, explicitly close the session itself (by sending a RTSP "TEARDOWN") when it knows that this duration has elapsed. Other types of file for which our server knows the duration (and therefore behaves the same way) are ".mp3" files, ".wav" files, ".dv" files, and ".mkv"/".webm" files. For some other types of file - including ".264" video files - the server does not know the file duration (and does not support 'seeking' within the stream). For these types of files, the server will send a RTCP "BYE" when it reaches the stream. This will tell the RTSP client that the stream has ended. (The RTSP client has no other way of knowing this, because it doesn't know the stream's duration in this case.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heikifm at gmail.com Sun Jun 29 22:07:41 2014 From: heikifm at gmail.com (SingHa Winter) Date: Mon, 30 Jun 2014 14:07:41 +0900 Subject: [Live-devel] [Live_devel] mpg file does not finish immediately at EOF Message-ID: Thanks for the quick reply. My test file is (I downloaded it from here) : https://archive.org/download/ligouHDR-HC1_sample1/Sample.mpg If I have tested with the wrong format, I'm sorry about that. And I read your second reply, I've already check SDP, its "t=" option is "t=0 0". If I set the duration info in SDP, can I solve my problem? Best regars. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 29 22:18:16 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Jun 2014 22:18:16 -0700 Subject: [Live-devel] [Live_devel] mpg file does not finish immediately at EOF In-Reply-To: References: Message-ID: <5674DBA3-918D-488E-81F1-F907567AEE20@live555.com> > can I solve my problem? There is no "problem". Both our RTSP server and VLC (as a RTSP client) are working properly when your file is streamed. As I explained before: Because the server knows the duration of the file, and can seek within it, it does not send a RTCP "BYE" when it reaches the end of the stream. This allows the RTSP client (VLC in your case) to keep the session open. (Notice that VLC lets you seek backwards within the stream to replay part of the file, if you wish.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Mon Jun 30 09:37:40 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Mon, 30 Jun 2014 17:37:40 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> References: <53A07073.9070008@panogenics.com> <53AD5493.1060605@panogenics.com> <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> Message-ID: <53B19254.4030705@panogenics.com> Hi Ross, Now that I more fully understand how Packetized Elementary Streams are fed into the transport stream multiplexor, may I provide one final patch that extends the Elementary Stream interface to the transport stream multiplexor to allow Packet IDs to be set separately from the stream IDs, but preserves the Packetized Elementary Stream interface. This patch extends MPEG2TransportStreamMultiplexor::handleNewBuffer with a default variable, PID (the transport stream Packet ID). If this is not present (e.g when the MPEG2TransportStreamFromPESSource subclass calls it) the current behaviour is maintained. If this is present, the PID is used in place of the stream_id for the Packet ID for the buffer being handled. The patch includes the addition of default variables to InputESSourceRecord::InputESSourceRecord, MPEG2TransportStreamFromESSource::addNewInputSource, MPEG2TransportStreamFromESSource::addNewAudioSource and MPEG2TransportStreamFromESSource::addNewVideoSource in MPEG2TransportStreamFromESSource.cpp/.hh to allow the Packet ID to be set for each Video / Audio source at the time it it added. Again the default behaviour is to use the Elementary Stream stream_id calculated in addNewVideoSource / addNewAudioSource. Each instance of the InputESSourceRecord class maintains its own stream ID (fStreamId) and Packet ID (fPID). I hope you are able to review and accept this patch (I am sorry for not understanding the full picture when sending in earlier patches and thus wasting your time reviewing them) as we have an installed set of hardware decoders that require a specific packet ID in order to function. We are reluctant to modify your code (with a much simpler fix that only works for our specific usage), so hope that this fix is general enough and of potential interest to other Live555 users. Best Regards, Piers AMG Signature -------------- next part -------------- 33c33 < void addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t PID = -1); --- > void addNewVideoSource(FramedSource* inputSource, int mpegVersion); 35c35 < void addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t PID = -1); --- > void addNewAudioSource(FramedSource* inputSource, int mpegVersion); 43c43 < u_int8_t streamId, int mpegVersion, int16_t PID = -1); --- > u_int8_t streamId, int mpegVersion); -------------- next part -------------- 36c36 < InputESSourceRecord* next, int16_t PID = -1); --- > InputESSourceRecord* next); 71d70 < int16_t fPID; 83c82 < ::addNewVideoSource(FramedSource* inputSource, int mpegVersion, int16_t PID) { --- > ::addNewVideoSource(FramedSource* inputSource, int mpegVersion) { 85c84 < addNewInputSource(inputSource, streamId, mpegVersion, PID); --- > addNewInputSource(inputSource, streamId, mpegVersion); 90c89 < ::addNewAudioSource(FramedSource* inputSource, int mpegVersion, int16_t PID) { --- > ::addNewAudioSource(FramedSource* inputSource, int mpegVersion) { 92c91 < addNewInputSource(inputSource, streamId, mpegVersion, PID); --- > addNewInputSource(inputSource, streamId, mpegVersion); 147c146 < u_int8_t streamId, int mpegVersion, int16_t PID) { --- > u_int8_t streamId, int mpegVersion) { 150c149 < mpegVersion, fInputSources, PID); --- > mpegVersion, fInputSources); 160c159 < InputESSourceRecord* next, int16_t PID) --- > InputESSourceRecord* next) 162c161 < fStreamId(streamId), fMPEGVersion(mpegVersion), fPID(PID) { --- > fStreamId(streamId), fMPEGVersion(mpegVersion) { 220c219 < fMPEGVersion, fSCR, fPID); --- > fMPEGVersion, fSCR); -------------- next part -------------- 43c43 < int mpegVersion, MPEG1or2Demux::SCR scr, int16_t PID = -1); --- > int mpegVersion, MPEG1or2Demux::SCR scr); -------------- next part -------------- 94c94 < int mpegVersion, MPEG1or2Demux::SCR scr, int16_t PID) { --- > int mpegVersion, MPEG1or2Demux::SCR scr) { 109,112c109 < if (PID == -1) < fCurrentPID = stream_id; < else < fCurrentPID = (u_int8_t)PID; --- > fCurrentPID = stream_id; From finlayson at live555.com Mon Jun 30 21:11:05 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Jun 2014 21:11:05 -0700 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: <53B19254.4030705@panogenics.com> References: <53A07073.9070008@panogenics.com> <53AD5493.1060605@panogenics.com> <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> <53B19254.4030705@panogenics.com> Message-ID: Yes, this looks good. I'll be including this in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: