From markuss at sonicfoundry.com Mon Jul 1 08:08:24 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Mon, 1 Jul 2013 15:08:24 +0000 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: <51CFE193.5050509@gmail.com> References: <51CFE193.5050509@gmail.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D01101D12@postal.sonicfoundry.net> Peng, I see that the frame rate is set to 29.97 ( 60000 / 1001 / 2) but I don't see any other timing information. Did you get the file to work? Markus. seq_parameter_set_data() profile_idc = 100 constraint_set0_flag = false constraint_set1_flag = false constraint_set2_flag = false constraint_set3_flag = false level_idc = 40 seq_parameter_set_id = 0 chroma_format_idc = 1 bit_depth_luma_minus8 = 0 bit_depth_chroma_minus8 = 0 qpprime_y_zero_transform_bypass_flag = false seq_scaling_matrix_present_flag = false log2_max_frame_num_minus4 = 1 pic_order_cnt_type = 0 log2_max_pic_order_cnt_lsb_minus4 = 0 num_ref_frames = 4 gaps_in_frame_num_value_allowed_flag = false pic_width_in_mbs_minus1 = 119 pic_height_in_map_units_minus1 = 33 frame_mbs_only_flag = false mb_adaptive_frame_field_flag = true direct_8x8_inference_flag = true frame_cropping_flag = true frame_crop_left_offset = 0 frame_crop_right_offset = 0 frame_crop_top_offset = 0 frame_crop_bottom_offset = 2 vui_parameters_present_flag = true vui_parameters aspect_ratio_info_present_flag = true aspect_ratio_idc = 1 overscan_info_present_flag = true overscan_appropriate_flag = false video_signal_type_present_flag = true video_format = 5 video_full_range_flag = false colour_description_present_flag = true colour_primaries = 1 transfer_characteristics = 1 matrix_coefficients = 1 chroma_loc_info_present_flag = false timing_info_present_flag = true num_units_in_tick = 1001 time_scale = 60000 fixed_frame_rate_flag = true H.264 SEI [offset 0x3B82A] nal_unit() forbidden_zero_bit = '0' nal_ref_idc = 0 nal_unit_type = 6 pic_timing cpb_removal_delay = 2 dpb_output_delay = 0 pic_struct = 3 clock_timestamp[0] clock_timestamp_flag = false clock_timestamp[1] clock_timestamp_flag = false -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Peng Sent: Sunday, June 30, 2013 2:43 AM To: live-devel at ns.live555.com Subject: Re: [Live-devel] Full HD Contents. trickplay question (with VLC) >> Note the file "ChunMyung1.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1 - i.e., by running: >> testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 >> ChunMyung1.ts Because our 'trick play' works by using I-frames only, this file effectively consists just of the i-frames from the original file. If you play this file in VLC, you can see that the I-frames freeze starting at about the 10 second mark, and do not resume until about the 1 minute mark. Does anyone know why? >> >> For another illustration of this, note the file "ChunMyung1-30.ts". This file was created by applying 'trick play' to the original file, with a scale factor of 1, but starting at the 30 second mark - i.e., by running: >> testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 >> ChunMyung1-30.ts If you play this file in VLC, you can see that the video is 'empty' until about the 30 second mark (i.e., corresponding to about 1 minute into the original video). Does anyone know why? Hi, Ross. I just check ChunMyung.ts and ChunMyung1-30.ts. The empty 30 seconds has nothing to do with MPEG-TS container, it is caused by picture timing information carried within SPS and SEI of H.264 encoding. This point is that though testMPEG2TransportStreamTrickPlay picks I frames out, it does not modify the associated timing information accordingly. A feasible method to avoid this is to remove vui_parameters() (possibly together with hrd_parameters()) in SPS and to remove SEI completely. It seems that somebody has already done something very similar: http://forum.doom9.org/showthread.php?t=152419 Regards -- Peng _______________________________________________ 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 howtofly at gmail.com Mon Jul 1 16:58:20 2013 From: howtofly at gmail.com (Peng) Date: Tue, 02 Jul 2013 07:58:20 +0800 Subject: [Live-devel] Full HD Contents. trickplay question (with VLC) In-Reply-To: References: Message-ID: <51D2179C.3050301@gmail.com> Hi, Markus. > > I see that the frame rate is set to 29.97 ( 60000 / 1001 / 2) but I don't see any other timing information. By timing information, I mean all the information affecting playout timing (including VUI, HDR and SEI), not just frame rate. To change frame rate, it will be safe to remove all of them, unless you are a CODEC implementer. 0x00000192 H264 AUD 0x00000198 H264 Sequence Parameter Set profile_idc = 100 (PROFILE_IDC_High) constraint_set0_flag = 0 constraint_set1_flag = 0 constraint_set2_flag = 0 constraint_set3_flag = 0 reserved_zero_4bits = 0 level_idc = 40 ... vui_parameters_present_flag = 1 vui_parameters(): ... num_units_in_tick = 1001 time_scale = 60000 fixed_frame_rate_flag = 1 nal_hrd_parameters_present_flag = 1 hrd_parameters(): cpb_cnt_minus1 = 0 bit_rate_scale = 2 cpb_size_scale = 4 bit_rate_value_minus1[0] = 20956, cpb_size_value_minus1[0] = 20956, cbr_flag[0] = 1 initial_cpb_removal_delay_length_minus1 = 26 cpb_removal_delay_length_minus1 = 30 dpb_output_delay_length_minus1 = 0 time_offset_length = 24 vcl_hrd_parameters_present_flag = 0 low_delay_hrd_flag = 0 pic_struct_present_flag = 1 bitstream_restriction_flag = 1 motion_vectors_over_pic_boundaries_flag = 1 max_bytes_per_pic_denom = 4 max_bits_per_mb_denom = 1 log2_max_mv_length_horizontal = 10 log2_max_mv_length_vertical = 9 num_reorder_frames = 0 max_dec_frame_buffering = 4 0x000001C4 H264 Picture Parameter Set ... 0x000001CC H264 SEI BUFFERING_PERIOD seq_paramater_set_id = 0 nal_initial_cpb_removal_delay[0] = 88780, nal_initial_cpb_removal_delay_offset[0] = 1220 PIC_TIMING cpb_removal_delay = 30, dpb_output_delay = 0 pic_struct = 3 (top field, bottom field), num_clock_ts = 2 > > Did you get the file to work? > Yes, almostly. 1) Use the following FFmpeg command line to remux the TS stream (without transcoding) into QuickTime file format preserving timing info and discarding audio: ffmpeg -debug_ts -i '/home/peng/Desktop/ChunMyung1-30.ts' -f mov -vcodec copy -an '/home/peng/Desktop/ChunMyung1-30.mov' Check the debugging output by -debug_ts, make sure that the PTS and DTS are preserved. By remuxing, you get rid of the annoying complexity of the intrinsic time axis of TS stream. Then play this file with VLC, you see the same 30 seconds black screen. Press ctrl+j, click the Statistics tab and play it again. Note that in the 30-second period, no block is actually decoded. It is also easy to check the first picture appeared is just the first frame in stream. Why? 2) Use MP4Box in GPAC package to analyze the structure of this mov file, you get a xml named ChunMyung1-30_info.xml: MP4Box -diso '/home/peng/Desktop/ChunMyung1-30.mov' Open this xml with firefox (or whatever) and check 'edst' box (EditBox). You will find only one entry with no empty entry preceding it, which simply means the first sample should be played immediately after the playback starts. Now it is clear that the 30-seconds black screen has nothing to do with media container. 3) Transcoding ChunMyung1-30.ts into Motion JPEG in QuickTime container. Play out this file, you will find black screen disappear and the first sample appear immediately. Since H.264 stream consisting of I frames without timing information is essentially the same Motion JPEG stream. I expect the suggested method to work. -- Peng From michel.promonet at thalesgroup.com Tue Jul 2 11:40:28 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 2 Jul 2013 20:40:28 +0200 Subject: [Live-devel] RTCP Sender Report Flooding Message-ID: <24815_1372790430_51D31E9E_24815_728_1_1BE8971B6CFF3A4F97AF4011882AA2550156378BAE3B@THSONEA01CMS01P.one.grp> Hi Ross, Thanks again for your support. We didn't understood deeply what brings the RTCP sender report flooding, but we has such a behavior using multicast stream that share the same multicast port. Wireshark analysis show that an RTCP sender report is forwarded between 2 RTSP servers without ends. We tried to understand the comment in RTCP.cpp that decide to resend a packet when SSM flag is set and packet comes from another host. It could be again a consequence of the multicast problem in linux using ASM. However we notice that RTCPInstance constructor has an argument to say to use SSM, but the RTCPInstance have a reference to the GroupSock that know if it was created for SSM. Setting this flag according to how groupsock was created seems to solve the problem. For instance in testH264VideoStreamer.cpp seems to make a confusion. 00057 Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl); 00058 rtpGroupsock.multicastSendOnly(); // we're a SSM source 00059 Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); 00060 rtcpGroupsock.multicastSendOnly(); // we're a SSM source 00061 00062 // Create a 'H264 Video RTP' sink from the RTP 'groupsock': 00063 OutPacketBuffer::maxSize = 100000; 00064 videoSink = H264VideoRTPSink::createNew(*env, &rtpGroupsock, 96); 00065 00066 // Create (and start) a 'RTCP instance' for this RTP sink: 00067 const unsigned estimatedSessionBandwidth = 500; // in kbps; for RTCP b/w share 00068 const unsigned maxCNAMElen = 100; 00069 unsigned char CNAME[maxCNAMElen+1]; 00070 gethostname((char*)CNAME, maxCNAMElen); 00071 CNAME[maxCNAMElen] = '\0'; // just in case 00072 RTCPInstance* rtcp 00073 = RTCPInstance::createNew(*env, &rtcpGroupsock, 00074 estimatedSessionBandwidth, CNAME, 00075 videoSink, NULL /* we're a server */, 00076 True /* we're a SSM source */); The RTCPIntance is create with SSM flag set but it use the ASM GroupSock, isn't it ? Don't you think it could be more robust to remove the SSM argument in RTCPInstance constructor and get it from RTCPgs->isSSM() ? Thanks & Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jul 2 13:33:56 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 2 Jul 2013 13:33:56 -0700 Subject: [Live-devel] Handle carriage return/line feed in base64Decode In-Reply-To: References: <017101ce6edd$9a006cf0$ce0146d0$@com> <16E86A2D-58E8-43E7-A784-A6672DF8F502@live555.com> Message-ID: <035601ce7763$7a98e070$6fcaa150$@com> Hi Ross, Thank you for implementing this. I have tested your changes and everything is working fine. Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Sunday, June 30, 2013 1:13 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Handle carriage return/line feed in base64Decode On Jun 23, 2013, at 4:37 PM, Ross Finlayson wrote: I recently came across a client who sends our LIVE555 based RTSP server an HTTP message with a base64 encoded RTSP command that contains CR/LF. It seems fairly standard for a base64 decoder to support CR/LF, at least on 4 char boundaries, so I wrote up a patch to base64Decode to allow this. Then I discovered how the fragmented base64 message reading is implemented in RTSPServer and determined that the fix would not be so simple. Rather than put CR/LF (or other whitespace) removal inside the Base-64 decoding routine, we can just add a whitespace-removing pass to the "RTSPServer" code, before we call "base64Decode()". I'll add this change to the next release of the code. FYI, the latest version (2013.06.30) of the code includes this change. I hope it works OK for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jul 2 17:25:24 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 2 Jul 2013 17:25:24 -0700 Subject: [Live-devel] Memory leaks in RTPInterface Message-ID: <036101ce7783$d19d9670$74d8c350$@com> Hi Ross, In testing the most recent version (2013.06.30), I noticed a couple memory leaks. I know your stance on memory leaks, but these two occur during normal play/stop operation (not just at shutdown), and so they will have noticeable effect on long-running devices. In the SocketDescriptor destructor, the HashTable::Iterator* "iter" is never deleted. In SocketDescriptor::deregisterRTPInterface, the fDeleteMyselfNext member is set to "true", but (for me at least), the tcpReadHandler function is never called again, and so the SocketDescriptor deletion never happens. I believe this was changed from "delete this;" in version 2013.04.29 or 2013.04.30 to avoid crashing if the tcpReadHandler is about to execute just after the socket descriptor is deleted. A fix that works here and does not result in a memory leak is to change the fDeleteMyselfNext back to "delete this;", but also change RTPInterface::stopNetworkReading and RTPInterface::removeStreamSocket to set fReadHandlerProc to NULL before calling deregisterSocket. This way the read handler on the about-to-be-deleted RTPInterface is not called in case tcpReadHandler is about to execute. I have attached a patch that fixes both issues for me, but I am definitely not an expert on the inner-workings of RTPInterface. If anybody who was experiencing the prior crashes would test this I would be grateful. Thanks, Chris Richardson WTI -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTPInterface.cpp.patch Type: application/octet-stream Size: 1412 bytes Desc: not available URL: From chris at gotowti.com Tue Jul 2 17:30:50 2013 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Tue, 2 Jul 2013 17:30:50 -0700 Subject: [Live-devel] Memory Leaks in RTPInterface Message-ID: <036701ce7784$92ca4140$b85ec3c0$@com> Hi All, Please ignore the previous patch I sent with the same subject line; I hit Send too soon. My apologies for the spam. Thanks, Chris Richardson -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 2 17:44:40 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jul 2013 17:44:40 -0700 Subject: [Live-devel] RTCP Sender Report Flooding In-Reply-To: <24815_1372790430_51D31E9E_24815_728_1_1BE8971B6CFF3A4F97AF4011882AA2550156378BAE3B@THSONEA01CMS01P.one.grp> References: <24815_1372790430_51D31E9E_24815_728_1_1BE8971B6CFF3A4F97AF4011882AA2550156378BAE3B@THSONEA01CMS01P.one.grp> Message-ID: <064827DC-7AE0-495E-9BE2-D87A1FA592CC@live555.com> > We didn?t understood deeply what brings the RTCP sender report flooding, but we has such a behavior using multicast stream that share the same multicast port. > Wireshark analysis show that an RTCP sender report is forwarded between 2 RTSP servers without ends. > > We tried to understand the comment in RTCP.cpp that decide to resend a packet when SSM flag is set and packet comes from another host. > It could be again a consequence of the multicast problem in linux using ASM. Yes, that's your problem. Because of a bug in the Linux kernel, you should not (if you are running Linux) have two different applications receiving multicast streams that have the same port number (even if the multicast IP addresses are different). > Don?t you think it could be more robust to remove the SSM argument in RTCPInstance constructor and get it from RTCPgs->isSSM() ? No, that would be wrong, because the "isSSM()" function (which, I admit, has a misleading name) tells you whether the "groupsock" object was created to *receive* a SSM stream - i.e., whether it was given an IP source address, in addition to a multicast address. It doesn't tell you whether or not the groupsock was created to *send* a SSM stream. > For instance in testH264VideoStreamer.cpp seems to make a confusion. No, there's no 'confusion' here. > The RTCPIntance is create with SSM flag set but it use the ASM GroupSock, isn?t it ? No it doesn't. The code explicitly choses an IP multicast address from the 'SSM' range, and sends it as a SSM stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 2 18:28:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jul 2013 18:28:05 -0700 Subject: [Live-devel] Memory leaks in RTPInterface In-Reply-To: <036101ce7783$d19d9670$74d8c350$@com> References: <036101ce7783$d19d9670$74d8c350$@com> Message-ID: <00805869-5207-44F4-8AD1-D318934C62D9@live555.com> > I know your stance on memory leaks No you don't :-) > In the SocketDescriptor destructor, the HashTable::Iterator* ?iter? is never deleted. Yes - that was an oversight on my part. It will be fixed in the next release of the software. > In SocketDescriptor::deregisterRTPInterface, the fDeleteMyselfNext member is set to ?true?, but (for me at least), the tcpReadHandler function is never called again, and so the SocketDescriptor deletion never happens. I believe this was changed from ?delete this;? in version 2013.04.29 or 2013.04.30 to avoid crashing if the tcpReadHandler is about to execute just after the socket descriptor is deleted. > > A fix that works here and does not result in a memory leak is to change the fDeleteMyselfNext back to ?delete this;? No, I can't do that, because if that code happens to be called while we're inside "tcpReadHandler1()" - i.e., while we're inside this loop: while (!socketDescriptor->fDeleteMyselfNext && socketDescriptor->tcpReadHandler1(mask) && --count > 0) {} then the code will crash the next time it tries to dereference "socketDescriptor" to test the loop condition. However, do you raise a valid point: If "SocketDescriptor::deregisterRTPInterface()" happens to be called when we're *not* inside "tcpReadHandler1(), then (with the current code) the "SocketDescriptor" object won't get deleted. I'll add a fix for this (different from the one that you suggested) to the next release of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Tue Jul 2 20:54:20 2013 From: chris at gotowti.com (Chris Richardson) Date: Tue, 2 Jul 2013 20:54:20 -0700 Subject: [Live-devel] Memory leaks in RTPInterface In-Reply-To: <00805869-5207-44F4-8AD1-D318934C62D9@live555.com> References: <036101ce7783$d19d9670$74d8c350$@com> <00805869-5207-44F4-8AD1-D318934C62D9@live555.com> Message-ID: Hi Ross > No you don't :-) I?m happy to be wrong on that. > No, I can't do that, because if that code happens to be called while we're inside "tcpReadHandler1()" - i.e., while we're inside this loop: Thanks for taking a look and fixing it. I did notice the crash of course. I sent my message too hastily and will be more careful next time. Thanks, Chris Richardson WTI -------------- next part -------------- An HTML attachment was scrubbed... URL: From Miler.Chan at quantatw.com Tue Jul 2 23:41:28 2013 From: Miler.Chan at quantatw.com (=?big5?B?TWlsZXIgQ2hhbiAouOK0vLJbKQ==?=) Date: Wed, 3 Jul 2013 06:41:28 +0000 Subject: [Live-devel] FW: How to let RTSP server bind to specific IP? In-Reply-To: <1B28713FDE9EA247941CCBA9958BCD36ACDF79B9@MAILBX03.quanta.corp> References: <1B28713FDE9EA247941CCBA9958BCD36ACDF79B9@MAILBX03.quanta.corp> Message-ID: <1B28713FDE9EA247941CCBA9958BCD36ACDF79D5@MAILBX03.quanta.corp> Hello, I try to use liblivemedia to setup RTSP server. But I need to let the server bind to specific IP. As far as I know, we need to invoke the setupStreamSocket function to get socket file description (fd), but the API doesn't support specific IP. It must bind to default route interface. I add a new API to let the server can bind to specific IP, since I have license concern, so can you help me on this feature? Can you provide a API to let the server can bind to specific IP? Or I provide the modified one. I add the API to livemedia/groupsock/GroupsockHelper.cpp [.h]. Thank you in advance. Original API: int setupStreamSocket(UsageEnvironment& env, Port port, Boolean makeNonBlocking) Add a new API to support specific IP: int setupStreamSocketWithIP(UsageEnvironment& env, string ip, Port port, Boolean makeNonBlocking) Many thanks, Miller -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 3 01:28:31 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Jul 2013 01:28:31 -0700 Subject: [Live-devel] How to let RTSP server bind to specific IP? In-Reply-To: <1B28713FDE9EA247941CCBA9958BCD36ACDF79D5@MAILBX03.quanta.corp> References: <1B28713FDE9EA247941CCBA9958BCD36ACDF79B9@MAILBX03.quanta.corp> <1B28713FDE9EA247941CCBA9958BCD36ACDF79D5@MAILBX03.quanta.corp> Message-ID: <73EBBD6B-AD6D-4FDA-8463-102715546C2F@live555.com> There's currently no way to do this in our code that's both reliable and portable. The easiest way to ensure that one particular interface is chosen is to make that interface the one for which multicast routing is enabled - i.e., the interface that has a route for 224.0.0.0/4 Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shail01khare at gmail.com Wed Jul 3 00:01:03 2013 From: shail01khare at gmail.com (shailendra khare) Date: Wed, 3 Jul 2013 12:31:03 +0530 Subject: [Live-devel] Start session at run time.. Message-ID: Hi, I am using testondemandRTSPServer test program.i want to start a session for a file at run time,how can i perform it in event loop. Thanks & Regards, Shailendra Khare -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Jul 3 05:30:13 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 3 Jul 2013 14:30:13 +0200 Subject: [Live-devel] RTCP Sender Report Flooding In-Reply-To: <064827DC-7AE0-495E-9BE2-D87A1FA592CC@live555.com> References: <24815_1372790430_51D31E9E_24815_728_1_1BE8971B6CFF3A4F97AF4011882AA2550156378BAE3B@THSONEA01CMS01P.one.grp> <064827DC-7AE0-495E-9BE2-D87A1FA592CC@live555.com> Message-ID: <5227_1372854615_51D41957_5227_1873_1_1BE8971B6CFF3A4F97AF4011882AA2550156379009B3@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for your support. Actually I try to have some support from a commercial linux in order to see I it's possible to fix this very old problem... Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mercredi 3 juillet 2013 02:45 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTCP Sender Report Flooding We didn't understood deeply what brings the RTCP sender report flooding, but we has such a behavior using multicast stream that share the same multicast port. Wireshark analysis show that an RTCP sender report is forwarded between 2 RTSP servers without ends. We tried to understand the comment in RTCP.cpp that decide to resend a packet when SSM flag is set and packet comes from another host. It could be again a consequence of the multicast problem in linux using ASM. Yes, that's your problem. Because of a bug in the Linux kernel, you should not (if you are running Linux) have two different applications receiving multicast streams that have the same port number (even if the multicast IP addresses are different). Don't you think it could be more robust to remove the SSM argument in RTCPInstance constructor and get it from RTCPgs->isSSM() ? No, that would be wrong, because the "isSSM()" function (which, I admit, has a misleading name) tells you whether the "groupsock" object was created to *receive* a SSM stream - i.e., whether it was given an IP source address, in addition to a multicast address. It doesn't tell you whether or not the groupsock was created to *send* a SSM stream. For instance in testH264VideoStreamer.cpp seems to make a confusion. No, there's no 'confusion' here. The RTCPIntance is create with SSM flag set but it use the ASM GroupSock, isn't it ? No it doesn't. The code explicitly choses an IP multicast address from the 'SSM' range, and sends it as a SSM stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 3 08:40:59 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Jul 2013 08:40:59 -0700 Subject: [Live-devel] RTCP Sender Report Flooding In-Reply-To: <5227_1372854615_51D41957_5227_1873_1_1BE8971B6CFF3A4F97AF4011882AA2550156379009B3@THSONEA01CMS01P.one.grp> References: <24815_1372790430_51D31E9E_24815_728_1_1BE8971B6CFF3A4F97AF4011882AA2550156378BAE3B@THSONEA01CMS01P.one.grp> <064827DC-7AE0-495E-9BE2-D87A1FA592CC@live555.com> <5227_1372854615_51D41957_5227_1873_1_1BE8971B6CFF3A4F97AF4011882AA2550156379009B3@THSONEA01CMS01P.one.grp> Message-ID: <8D0B6DE0-9928-411D-90B1-925FAD7B2E4A@live555.com> > Actually I try to have some support from a commercial linux in order to see I it?s possible to fix this very old problem? Or, alternatively: 1/ Don't transmit to different multicast IP addresses using the same port number from the same host, or 2/ Make your multicast streams ASM rather than SSM (so that the transmitting server won't 'reflect' incoming RTCP "RR" packets back to the multicast group) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Jul 4 03:44:59 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 4 Jul 2013 12:44:59 +0200 Subject: [Live-devel] Is it possible to give access to parseScaleHeader Message-ID: <4527_1372934702_51D5522E_4527_1859_1_1BE8971B6CFF3A4F97AF4011882AA255015637939292@THSONEA01CMS01P.one.grp> Hi Ross, In our customization of RTSPServer, we already access to parseRangeHeader that is defined in RTSPCommon.h, but I also need to parse the Scale Header. Do you think it will be possible in a future release to give access to parseScaleHeader. Thanks & Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 4 20:57:03 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Jul 2013 20:57:03 -0700 Subject: [Live-devel] Is it possible to give access to parseScaleHeader In-Reply-To: <4527_1372934702_51D5522E_4527_1859_1_1BE8971B6CFF3A4F97AF4011882AA255015637939292@THSONEA01CMS01P.one.grp> References: <4527_1372934702_51D5522E_4527_1859_1_1BE8971B6CFF3A4F97AF4011882AA255015637939292@THSONEA01CMS01P.one.grp> Message-ID: > Do you think it will be possible in a future release to give access to parseScaleHeader. OK, this will be done 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 lijing0010 at gmail.com Thu Jul 4 21:04:25 2013 From: lijing0010 at gmail.com (jing li) Date: Fri, 5 Jul 2013 12:04:25 +0800 Subject: [Live-devel] How to build a transcode proxy VOD server? Message-ID: Hi I want to build a rtsp VOD server combined with transcode(ffmpeg). The application acts as a VOD server, when the client asks for some video through RTSP, it will establish a rtsp request to remote VOD server and acquire the data. Then do a demux/transcode/mux, and finally stream it to the client. I note that the proxyServer link the remote rtpsource to the rtpsink, there are no place for me to place the demux/transcoder/muxer. I tried to create the pipeline like rtspclient-->memorysink-->(demux)transcode(mux)-->memorysource-->RtpSource. But I don't find a proper place to start the rtspclient. If I override the RTSPServer::lookupServerMediaSession(), then I can't distinguish the 1st playback's SETUP and the -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aashish.Kaushik at hcl.com Fri Jul 5 06:19:07 2013 From: Aashish.Kaushik at hcl.com (Aashish Kaushik) Date: Fri, 5 Jul 2013 13:19:07 +0000 Subject: [Live-devel] Adding SRTP encryption to RTP input streams [Live555ProxyServer] Message-ID: Hi Ross, I am using live555ProxyServer for proxying RTSP streams coming from IP Cameras. Now I am trying to evaluate if we can add SRTP encryption to RTP streams coming from camera. Could you please let me know if there is a mechanism by which I could achieve this using any of the below approaches 1. Using some options in live555ProxyServer, or 2. Using any other external components/applications along with live555proxyServer. Any help would be greatly appreciated. Thanks & Regards, Aashish Kaushik HCL Technologies Ltd. www.hcltech.com www.hcl.com ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aashish.Kaushik at hcl.com Fri Jul 5 06:22:14 2013 From: Aashish.Kaushik at hcl.com (Aashish Kaushik) Date: Fri, 5 Jul 2013 13:22:14 +0000 Subject: [Live-devel] Adding SRTP encryption to RTP input streams [Live555ProxyServer] Message-ID: Hi Ross, I am using live555ProxyServer for proxying RTSP streams coming from IP Cameras. Now I am trying to evaluate if we can add SRTP encryption to RTP streams coming from camera. Could you please let me know if there is a mechanism by which I could achieve this using any of the below approaches 1. Using some options in live555ProxyServer, or 2. Using any other external components/applications along with live555proxyServer. Any help would be greatly appreciated. Thanks & Regards, Aashish Kaushik HCL Technologies Ltd. www.hcltech.com www.hcl.com ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 5 06:24:38 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jul 2013 06:24:38 -0700 Subject: [Live-devel] Adding SRTP encryption to RTP input streams [Live555ProxyServer] In-Reply-To: References: Message-ID: <72B4E19F-37BC-47B9-B7A0-F4731B2E543C@live555.com> > I am using live555ProxyServer for proxying RTSP streams coming from IP Cameras. > > Now I am trying to evaluate if we can add SRTP encryption to RTP streams coming from camera. > > Could you please let me know if there is a mechanism by which I could achieve this using any of the below approaches > 1. Using some options in live555ProxyServer, or > 2. Using any other external components/applications along with live555proxyServer. No. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lczyz at man.poznan.pl Mon Jul 8 06:00:10 2013 From: lczyz at man.poznan.pl (=?UTF-8?B?xYF1a2FzeiBDennFvA==?=) Date: Mon, 08 Jul 2013 15:00:10 +0200 Subject: [Live-devel] Application-specific RTCP packets Message-ID: <51DAB7DA.9010705@man.poznan.pl> Dear liveMedia development team Can you tell me whether current version of library provides some interface to handle application-specific RTCP packets (as described in )? I need to use such functionality with a "on-demand h246 RTSP server" scenario. If such functionality is not available, could you provide some general guidelines what is the most straightforward way to implement it? Best regards ?ukasz From piers.hawksley at panogenics.com Tue Jul 9 07:21:26 2013 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Tue, 09 Jul 2013 15:21:26 +0100 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming Message-ID: <51DC1C66.7090507@panogenics.com> When running live.2013.07.03 I get a sigsegv when closing the RTSPServer whilst streaming. When running live 555 with debug turned on, if I get: RTSPClientConnection[0x1c5c80]::handleRequestBytes() read -1 new bytes (of 10000); terminating connection! I then get the following and the program closes cleanly: RTCPInstance[0x1cb318]::~RTCPInstance() sending BYE sending RTCP packet 80c80006 a4bb467b d5867269 ccbc382a 75e402cc 0000044a 00175eb0 81cb0001 a4bb467b If I do not get the '::handleRequestBytes() read -1' debug line I get a sigsegv as soon as: rtspServer->close(rtspServer); is called. For info, rtspServer is created with: RTSPServer *rtspServer = RTSPServer::createNew(*env, rtspport, AuthDB, 65); This sigsegv also occurs with live.2013.06.18 and live.2013.04.05, but not the previous version we were using (live.2012.04.04). Sorry there's such a large gap between the versions we have tested. The RTSPServer constructor / destructor now have fClientConnections and fClientSessions members, does help locate the issue. Should I be calling something to close streams prior to calling rtspServer->close(rtspServer) ? Best Regards, Piers Hawksley From finlayson at live555.com Tue Jul 9 14:18:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Jul 2013 23:18:18 +0200 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming In-Reply-To: <51DC1C66.7090507@panogenics.com> References: <51DC1C66.7090507@panogenics.com> Message-ID: <9A135F14-3A71-4988-9F80-0E74B39407B3@live555.com> Thanks for the report. I'll look into this. But if possible (to help me track this down), please send a stack trace (at the point of the crash). Also, does the error occur only if you delete the server while it's in the middle of streaming? If so, does this happen only with RTP-over-TCP streaming, or also with RTP-over-UDP streaming? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 10 00:40:58 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Jul 2013 09:40:58 +0200 Subject: [Live-devel] Application-specific RTCP packets In-Reply-To: <51DAB7DA.9010705@man.poznan.pl> References: <51DAB7DA.9010705@man.poznan.pl> Message-ID: > Can you tell me whether current version of library provides some > interface to handle application-specific RTCP packets (as described in > )? No, unfortunately there's not. In the future, I hope to update the RTCP more easily support these (and the many 'extended' RTCP packet types recently defined by the IETF). (There's no ETA for this, however.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Wed Jul 10 05:54:09 2013 From: piers.hawksley at panogenics.com (Piers Hawksley - Panogenics) Date: Wed, 10 Jul 2013 13:54:09 +0100 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming Message-ID: <51DD5971.80508@panogenics.com> Thanks Ross, The stack trace is below. This crash occurs when closing the application whilst it is streaming. It does not occur when closing the application if streaming is stopped first. It only occurs when streaming RTP over TCP; it doesn't occur when streaming RTP over UDP. Please let me know if you need further debug. Best Regards, Piers Thread [2] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 18 RTSPServer::RTSPClientConnection::handleAlternativeRequestByte1() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:761 0x000ce974 17 RTSPServer::RTSPClientConnection::handleAlternativeRequestByte() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:751 0x000cea48 16 SocketDescriptor::~SocketDescriptor() /mnt/hgfs/workspaces/live555/liveMedia/RTPInterface.cpp:356 0x000c353c 15 SocketDescriptor::deregisterRTPInterface() /mnt/hgfs/workspaces/live555/liveMedia/RTPInterface.cpp:416 0x000c1e1c 14 deregisterSocket() /mnt/hgfs/workspaces/live555/liveMedia/RTPInterface.cpp:163 0x000c32ec 13 RTPInterface::removeStreamSocket() /mnt/hgfs/workspaces/live555/liveMedia/RTPInterface.cpp:175 0x000c340c 12 RTCPInstance::removeStreamSocket() /mnt/hgfs/workspaces/live555/liveMedia/include/RTCP.hh:90 0x000d9060 11 StreamState::endPlaying() /mnt/hgfs/workspaces/live555/liveMedia/OnDemandServerMediaSubsession.cpp:502 0x000d73fc 10 OnDemandServerMediaSubsession::deleteStream() /mnt/hgfs/workspaces/live555/liveMedia/OnDemandServerMediaSubsession.cpp:304 0x000d799c 9 RTSPServer::RTSPClientSession::reclaimStreamStates() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:1294 0x000c91a8 8 RTSPServer::RTSPClientSession::~RTSPClientSession() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:1279 0x000d18b8 7 RTSPServer::~RTSPServer() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:328 0x000d1e10 6 MediaLookupTable::remove() /mnt/hgfs/workspaces/live555/liveMedia/Media.cpp:151 0x000b0a50 5 Medium::close() /mnt/hgfs/workspaces/live555/liveMedia/Media.cpp:53 0x000b0b14 4 Medium::close() /mnt/hgfs/workspaces/live555/liveMedia/Media.cpp:59 0x000b0b5c 3 event_thread() /mnt/hgfs/workspaces/PanoServer/Branches/JPEGoverRTSP/src/RTSPWrapper.cpp:868 0x0007b268 2 0x40435890 1 0x40435890 Once we've seen the head of the stack trace as follows: 19 RTSPServer::RTSPClientSession::handleCmd_PLAY() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:1749 0x000cfeec 18 RTSPServer::RTSPClientConnection::handleAlternativeRequestByte1() /mnt/hgfs/workspaces/live555/liveMedia/RTSPServer.cpp:761 0x000ce99c From westchen at gvdigital.com Wed Jul 10 18:52:10 2013 From: westchen at gvdigital.com (West Chen) Date: Thu, 11 Jul 2013 09:52:10 +0800 Subject: [Live-devel] CPU usage is high when there are 64 concurrent sessions. Message-ID: Hi, I'm building an application to support RTSP over HTTP using live555, and I ran into a situation that the CPU usage (1 core is completely used) is high (25% or above). Here are the information: 1. windows 7 x64, network 1Gbps, CPU i5 4 cores 2.8GHz, 8G RAM 2. building application with VS2010, application is x64, and I assign the live555 thread to a specific core via windows API. Therefore I can observe which thread is eating up the cpu usage. 3. Concurrent session: 64. (all different sources) 4. H264 video source received from my own camera. 5. I subclassed FramedSource to implement method doGetNextFrame and method afterGetting, and let the delay be 100us when try to call scheduleDelayedTask. When there is a frame available, I copy the bitstream into fTo, assign the fFrameSize according to fMaxSize, and then calculate the fNumTruncatedBytes. If there are remaining bitstream of a frame, I would store it for next doGetNextFrame call, so that all frames are not truncated. Is this correct or related to my current situation? 6. I also subclassed OnDemandServerMediaSubsession to implement my own method checkForAuxSDPLine. 7. If I reduce the concurrent session count to 32, the cpu usage is the same as 64, but the thread of live555 can not handle more than 64 sessions. If more information is needed, please let me know, thank you. I'm kinda new to live555 and the mailing list, forgive my poor presentation skill in Engilish. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 10 19:22:31 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jul 2013 04:22:31 +0200 Subject: [Live-devel] CPU usage is high when there are 64 concurrent sessions. In-Reply-To: References: Message-ID: I presume - from your question - that you see high CPU usage *only* when you have a large number of concurrent client connections, but not if you have a small number of concurrent client connections. If this is the case, then the problem is almost certainly caused by you running into an OS-imposed limit on the number of open files (sockets) that can be used by a single process. See http://www.live555.com/liveMedia/faq.html#scalability Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From westchen at gvdigital.com Wed Jul 10 19:33:06 2013 From: westchen at gvdigital.com (West Chen) Date: Thu, 11 Jul 2013 10:33:06 +0800 Subject: [Live-devel] CPU usage is high when there are 64 concurrent sessions. In-Reply-To: References: Message-ID: Dear Ross, I do modify the macro FD_SETSIZE=1024, but the situation is still the same. Or is there any other limitation that might help? Thank you for your quick reply! 2013/7/11 Ross Finlayson > I presume - from your question - that you see high CPU usage *only* when > you have a large number of concurrent client connections, but not if you > have a small number of concurrent client connections. > > If this is the case, then the problem is almost certainly caused by you > running into an OS-imposed limit on the number of open files (sockets) that > can be used by a single process. See > http://www.live555.com/liveMedia/faq.html#scalability > > 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 ccaughie at openeye.net Thu Jul 11 16:38:57 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Thu, 11 Jul 2013 16:38:57 -0700 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: References: Message-ID: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> Are you a) using interleaved mode and b) not processing one or more of the streams in the session (e.g. throwing away an audio stream)? If so, it could be the issue I reported here: http://lists.live555.com/pipermail/live-devel/2013-April/016796.html From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of West Chen Sent: Wednesday, July 10, 2013 7:33 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] CPU usage is high when there are 64 concurrentsessions. Dear Ross, I do modify the macro FD_SETSIZE=1024, but the situation is still the same. Or is there any other limitation that might help? Thank you for your quick reply! 2013/7/11 Ross Finlayson I presume - from your question - that you see high CPU usage *only* when you have a large number of concurrent client connections, but not if you have a small number of concurrent client connections. If this is the case, then the problem is almost certainly caused by you running into an OS-imposed limit on the number of open files (sockets) that can be used by a single process. See http://www.live555.com/liveMedia/faq.html#scalability 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 westchen at gvdigital.com Thu Jul 11 19:09:57 2013 From: westchen at gvdigital.com (West Chen) Date: Fri, 12 Jul 2013 10:09:57 +0800 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> Message-ID: Dear Colin, I'm using RTSP over HTTP, and by looking at the packets dumped by wireshark. I saw something like this: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Jun 27 2013 05:29:16 GMT Transport: RTP/AVP/TCP;unicast;destination=;source=;interleaved=0-1 Session: Hence I think the interleaved mode is used, and the source generated by my camera contains only single video stream (without audio stream). After checking the patch submitted by you in April, I believed that the latest version of live555 contained that patch already. I did try the latest version of live555 (live.2013.07.03.tar.gz), but the result is still the same. Thank your for your kindly response! 2013/7/12 Colin Caughie > Are you a) using interleaved mode and b) not processing one or more of the > streams in the session (e.g. throwing away an audio stream)?**** > > ** ** > > If so, it could be the issue I reported here: > http://lists.live555.com/pipermail/live-devel/2013-April/016796.html**** > > ** ** > > *From:* live-devel-bounces at ns.live555.com [mailto: > live-devel-bounces at ns.live555.com] *On Behalf Of *West Chen > *Sent:* Wednesday, July 10, 2013 7:33 PM > > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] CPU usage is high when there are 64 > concurrentsessions.**** > > ** ** > > Dear Ross,**** > > ** ** > > I do modify the macro FD_SETSIZE=1024, but the situation is still the same. > **** > > Or is there any other limitation that might help?**** > > ** ** > > Thank you for your quick reply!**** > > ** ** > > 2013/7/11 Ross Finlayson **** > > I presume - from your question - that you see high CPU usage *only* when > you have a large number of concurrent client connections, but not if you > have a small number of concurrent client connections.**** > > ** ** > > If this is the case, then the problem is almost certainly caused by you > running into an OS-imposed limit on the number of open files (sockets) that > can be used by a single process. See > http://www.live555.com/liveMedia/faq.html#scalability**** > > ** ** > > 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**** > > ** ** > > _______________________________________________ > 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 Jul 11 22:22:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jul 2013 07:22:18 +0200 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> Message-ID: <360A4429-A91D-4BB7-AD05-96FE82C1F7C0@live555.com> On Jul 12, 2013, at 1:38 AM, Colin Caughie wrote: > Are you a) using interleaved mode and b) not processing one or more of the streams in the session (e.g. throwing away an audio stream)? > > If so, it could be the issue I reported here: http://lists.live555.com/pipermail/live-devel/2013-April/016796.html Huh?? Recent versions of the code include the patch that you suggested (albeit modified a bit to eliminate some bugs). Therefore (assuming, of course, that he's using a recent version of the code) this can't be the cause of West Chen's problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 11 22:26:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jul 2013 07:26:51 +0200 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> Message-ID: <1C6E270F-E819-4187-9425-4D4B9E1AC825@live555.com> > I do modify the macro FD_SETSIZE=1024, but the situation is still the same. Once again, does your problem occur *only* when you have a large number of concurrent client connections (e.g., 32 or more), and *not* when you have a small number of connections (e.g., 5)? If so, then the problem is almost certainly caused by you running into an OS-imposed limit on the number of open files (sockets) that can be used by a single process. I *thought* that changing "FD_SETSIZE" is the way to increase this limit in WIndows, but I'm not a Windows expert, so I could be wrong about the solution. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccaughie at openeye.net Fri Jul 12 09:24:39 2013 From: ccaughie at openeye.net (Colin Caughie) Date: Fri, 12 Jul 2013 09:24:39 -0700 Subject: [Live-devel] CPU usage is high when there are 64concurrentsessions. In-Reply-To: <360A4429-A91D-4BB7-AD05-96FE82C1F7C0@live555.com> References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> <360A4429-A91D-4BB7-AD05-96FE82C1F7C0@live555.com> Message-ID: <853C62832D606043A043BD770304786C0476D457@EDD.pcopen.net> Good to know - I hadn't realized you'd picked up the patch. I should have checked before posting. Colin Caughie Chief Software Architect (509) 232-5261 ext 5914 What is heroic customer service? ** NOTICE ** The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, July 11, 2013 10:22 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] CPU usage is high when there are 64concurrentsessions. On Jul 12, 2013, at 1:38 AM, Colin Caughie wrote: Are you a) using interleaved mode and b) not processing one or more of the streams in the session (e.g. throwing away an audio stream)? If so, it could be the issue I reported here: http://lists.live555.com/pipermail/live-devel/2013-April/016796.html Huh?? Recent versions of the code include the patch that you suggested (albeit modified a bit to eliminate some bugs). Therefore (assuming, of course, that he's using a recent version of the code) this can't be the cause of West Chen's problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jian at sigmaxsecurity.com Fri Jul 12 10:29:24 2013 From: jian at sigmaxsecurity.com (Jianliang Zhang) Date: Fri, 12 Jul 2013 12:29:24 -0500 Subject: [Live-devel] Memory leak detected Message-ID: Memory leak detected at RTSPClient::responseHandlerForHTTP_GET1(int responseCode, char* responseString) for the latest release version (2013-07-03). The repsonseString isn't deleted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 13 23:00:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 14 Jul 2013 08:00:16 +0200 Subject: [Live-devel] Memory leak detected In-Reply-To: References: Message-ID: Jianliang, Thanks for the report. Yes, you're correct - this is a memory leak (because response handlers should be deleting the 'response string'). 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 westchen at gvdigital.com Sun Jul 14 18:58:02 2013 From: westchen at gvdigital.com (West Chen) Date: Mon, 15 Jul 2013 09:58:02 +0800 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: <1C6E270F-E819-4187-9425-4D4B9E1AC825@live555.com> References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> <1C6E270F-E819-4187-9425-4D4B9E1AC825@live555.com> Message-ID: Test results: 1. core usage goes up to 100% when there are 10 concurrent connections, the usage might drop to normal level (about 1% or 2%) after few minutes passed. (sometimes it doesn't drop at all) 2. core usage goes up to 100% when there are 11 concurrent connections, the usage keeps 100% at all time. 3. according to procdump, the core usage is mostly consumed by method BasicTaskScheduler::SingleStep. 2013/7/12 Ross Finlayson > I do modify the macro FD_SETSIZE=1024, but the situation is still the > same. > > > Once again, does your problem occur *only* when you have a large number of > concurrent client connections (e.g., 32 or more), and *not* when you have a > small number of connections (e.g., 5)? If so, then the problem is almost > certainly caused by you running into an OS-imposed limit on the number of > open files (sockets) that can be used by a single process. I *thought* > that changing "FD_SETSIZE" is the way to increase this limit in WIndows, > but I'm not a Windows expert, so I could be wrong about the solution. > > > 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 Sun Jul 14 19:35:11 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jul 2013 04:35:11 +0200 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> <1C6E270F-E819-4187-9425-4D4B9E1AC825@live555.com> Message-ID: > Test results: > 1. core usage goes up to 100% when there are 10 concurrent connections, the usage might drop to normal level (about 1% or 2%) after few minutes passed. (sometimes it doesn't drop at all) > 2. core usage goes up to 100% when there are 11 concurrent connections, the usage keeps 100% at all time. > 3. according to procdump, the core usage is mostly consumed by method BasicTaskScheduler::SingleStep. OK, thank you for *finally* telling us that your problem has *nothing* to do with the fact that you have "64 concurrent sessions". It apparently occurs regardless of the number of clients. You have wasted a lot of our time by using a misleading "Subject:" line! The answer to your problem can be found in your original message: > 5. I subclassed FramedSource to implement method doGetNextFrame and method afterGetting [...] > 6. I also subclassed OnDemandServerMediaSubsession to implement my own method checkForAuxSDPLine. I.e., your problem arises from your own code, and does not seem to be an inherent problem with the supplied LIVE555 code. Because of this (and because you have wasted so much of our time already), I'm not going to help you anymore with your problem. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From westchen at gvdigital.com Sun Jul 14 22:14:45 2013 From: westchen at gvdigital.com (West Chen) Date: Mon, 15 Jul 2013 13:14:45 +0800 Subject: [Live-devel] CPU usage is high when there are 64 concurrentsessions. In-Reply-To: References: <853C62832D606043A043BD770304786C0476D3B1@EDD.pcopen.net> <1C6E270F-E819-4187-9425-4D4B9E1AC825@live555.com> Message-ID: Dear Ross, I'm sorry to make you think that I want to waste anyone's time, although it's never my intention. But still thank you for your reply. 2013/7/15 Ross Finlayson > Test results: > 1. core usage goes up to 100% when there are 10 concurrent connections, > the usage might drop to normal level (about 1% or 2%) after few minutes > passed. (sometimes it doesn't drop at all) > 2. core usage goes up to 100% when there are 11 concurrent connections, > the usage keeps 100% at all time. > 3. according to procdump, the core usage is mostly consumed by method > BasicTaskScheduler::SingleStep. > > > OK, thank you for *finally* telling us that your problem has *nothing* to > do with the fact that you have "64 concurrent sessions". It apparently > occurs regardless of the number of clients. You have wasted a lot of our > time by using a misleading "Subject:" line! > > The answer to your problem can be found in your original message: > > 5. I subclassed FramedSource to implement method doGetNextFrame and method > afterGetting [...] > > 6. I also subclassed OnDemandServerMediaSubsession to implement my own > method checkForAuxSDPLine. > > > I.e., your problem arises from your own code, and does not seem to be an > inherent problem with the supplied LIVE555 code. > > Because of this (and because you have wasted so much of our time already), > I'm not going to help you anymore with your problem. Sorry. > > > 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 xukaijun at hikvision.com Sun Jul 14 23:41:18 2013 From: xukaijun at hikvision.com (=?gb2312?B?0O2/rb78?=) Date: Mon, 15 Jul 2013 06:41:18 +0000 Subject: [Live-devel] 4+ Connections ->Stream Proxy Server High Packet Loss Rate Message-ID: <038C312AE7DA414D8456337AF41CEE78A82F02@Hik-MBX01.hikvision.com> Dear, Ross, My test environment: Rtsp camera ip: 10.64.59.158 Live555 Proxy Server Install at :10.64.62.41 Rtsp Stream Client at: 10.64.59.27 Rtsp Client num Rtsp Server Address Loss Rate 1 10.64.62.41 0.000000 2 10.64.62.41 0.000000 3 10.64.62.41 0.000000 4 10.64.62.41 0.005000 + 9 10.64.62.41 0.040000 + However, If rtsp client and proxy server install in the same computer 10.64.59.27 Rtsp Client num Rtsp Server Address Loss Rate 4 10.64.59.27 0.000000 10 10.64.59.27 0.000000 20 10.64.59.27 0.001000 + rtsp client connect camera directly Rtsp Client num Loss Rate 4 0.000000 10 0.000000 15 0.000000 I cannot fix out the reason why if the proxy server and client run at different computer will lead to high packet loss rate? Kaijun xu hikvision /////////////////////////////////////////////////////////////////////////////// Connect camera direct rtsp command: --------Start Preview:rtsp://10.64.59.158:554/mpeg4 SeesionID:84793256, CommandName:option, ResultCode:0, ResultString:OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER SeesionID:84793256, CommandName:describe, ResultCode:0, ResultString:v=0 o=- 1373008652750951 1 IN IP4 10.64.59.158 s=RTSP/RTP stream from Network Video Server i=mpeg4 t=0 0 a=tool:LIVE555 Streaming Media v2009.09.28 // the camera is also using the live555 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from Network Video Server a=x-qt-text-inf:mpeg4 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:4000 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=1;config=000001b001000001b50900000101000001200084586a294022d0a21f a=x-dimensions: 1280, 720 a=x-framerate: 25 a=control:track1 SeesionID:84793256, CommandName:setup, ResultCode:0, ResultString:(null) SeesionID:84793256, CommandName:play, ResultCode:0, ResultString:(null) Connect Proxy Server? --------Start Preview:rtsp://10.64.59.27:554/rtsp://10.64.59.158:554/mpeg4 SeesionID:6475024, CommandName:option, ResultCode:0, ResultString:OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER SeesionID:6475024, CommandName:describe, ResultCode:0, ResultString:v=0 o=- 1373869536923340 1 IN IP4 192.168.72.1 s=LIVE555 Streaming Media v2013.05.30 i=LIVE555 Streaming Media v2013.05.30 t=0 0 a=tool:LIVE555 Streaming Media v2013.05.30 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2013.05.30 // my proxy server version a=x-qt-text-inf:LIVE555 Streaming Media v2013.05.30 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:4000 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=1;config=000001B001000001B50900000101000001200084586A294022D0A21F a=control:track1 SeesionID:6475024, CommandName:setup, ResultCode:0, ResultString:(null) SeesionID:6475024, CommandName:play, ResultCode:0, ResultString:(null) -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon Jul 15 09:11:44 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 15 Jul 2013 16:11:44 +0000 Subject: [Live-devel] Rare 2s "delay" when viewing live streams Message-ID: We stream lots of live MJPEG streams using a pretty simple client that is based on the testRTSPClient example. In very rare cases we see a delay/lag that I can't explain. When it happens it is like the live video is delayed 2s. If I at the time start the same stream in VLC and specify a cache of 2000ms the videos play in sync. The thing is that we don't buffer anything, and the fact that any other instance of our program, or any other player, shows the video live tells me it's not the server. The instance where the delay can be seen will continue to do show the delay for all following streams (using the same live555 event loop), i.e. if I switch to another stream the delay is still there. It should be noted that the video plays smooth (no visible frame dropping), just that there is a consistent 2s lag. As mentioned, this is very rare and I've only seen it twice in the last four months, so it's not something that I can recreate. I didn't think live555 really buffer anything, but when trying to look for any explanation at all to this "magic delay" I stumbled upon some old posts that mention a buffer used for sorting RTP packages that are received out of order. It also mentions that setPacketReorderingThresholdTime() can be called to minimize this time. I believe we have quite a bit of packet loss and I will try to check this out, but since we can't reproduce the issue it's like a ghost hunt and it would be great to get some feedback on this. - Is there any possibility that a "delay" (>1s) can somehow be introduced in live555 (e.g. during heavy packet loss)? - Has anyone else experienced any delayed live streams like this? /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5739 bytes Desc: not available URL: From piers.hawksley at amgsystems.com Mon Jul 15 09:34:58 2013 From: piers.hawksley at amgsystems.com (Piers Hawksley) Date: Mon, 15 Jul 2013 17:34:58 +0100 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming Message-ID: <7902889F9975EE44A11D94D3D485EA14BF6A96@amgsrv01.AMGSYSTEMS.local> Hi Ross, Does the stack trace provide any clues to what is causing the sigsegv ? I can repeat the crash and provide the value of any of the class variables if that would help pinpoint the issue. I am very keen to help find a resolution to this as I don't want to revert to using an older (unsupported) version. Is there anything I can do to assist ? I've added some fprintf debug and can confirm incomingRequestHandler and envir().taskScheduler() both have non-zero addresses; fClientInputSocket is zero, but I suspect that is a valid number. I'm happy to add more debug or run alternate versions of RTSPServer.cpp if you can't replicate this sigsegv yourself. Many Thanks, Piers From finlayson at live555.com Mon Jul 15 23:23:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jul 2013 08:23:51 +0200 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming In-Reply-To: <7902889F9975EE44A11D94D3D485EA14BF6A96@amgsrv01.AMGSYSTEMS.local> References: <7902889F9975EE44A11D94D3D485EA14BF6A96@amgsrv01.AMGSYSTEMS.local> Message-ID: <9FE5A145-5447-46C5-8259-AB851AA6BEFC@live555.com> Sorry for the delay in responding to this; I've been traveling over the past week. I've just installed a new version (2013.07.16) of the code that should fix this problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 15 23:35:07 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jul 2013 08:35:07 +0200 Subject: [Live-devel] Rare 2s "delay" when viewing live streams In-Reply-To: References: Message-ID: <8C4B08BC-B2C2-419F-9919-3876E1D6A2F6@live555.com> Of course our code doesn't buffer anything for 2 seconds. (The 'packet reordering' queue delays incoming packets for at most the 'packet reordering threshold' - which is, by default, only 100 ms - and only if packet loss occurs.) The delay is obviously caused by the TCP implementation - i.e., in the OSs of your server and client. This is not a bug; this is simply TCP's way of ensuring reliable data delivery, in the face of high data rates and lossy networks. To overcome this, either send less, or stream via UDP instead of TCP. (You should stream RTP-over-TCP *only* if there's a firewall - between the server and client - that blocks UDP packets.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at amgsystems.com Tue Jul 16 05:06:10 2013 From: piers.hawksley at amgsystems.com (Piers Hawksley) Date: Tue, 16 Jul 2013 13:06:10 +0100 Subject: [Live-devel] sigsegv when closing RTSPServer whilst streaming Message-ID: <7902889F9975EE44A11D94D3D485EA14BF6A98@amgsrv01.AMGSYSTEMS.local> > Sorry for the delay in responding to this; I've been traveling over the past week. > I've just installed a new version (2013.07.16) of the code that should fix this problem. Hi Ross, Excellent - I've tested the latest version multiple times and confirm it does fix this problem - many thanks ! Best Regards, Piers From michel.promonet at thalesgroup.com Tue Jul 16 07:37:29 2013 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 16 Jul 2013 16:37:29 +0200 Subject: [Live-devel] openRTSP option to force multicast Message-ID: <9377_1373985478_51E55AC5_9377_1528_1_1BE8971B6CFF3A4F97AF4011882AA255015637BFF787@THSONEA01CMS01P.one.grp> Hi Ross, Using some camera, it is needed to ask for a multicast stream in the RTSP SETUP, but openRTSP always set this flag to False. If this could help others users, you could find attached a modification that add -W to set the forceMulticastFlag to True. I didn't update the usage that is already quite long... Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openRTSP.patch Type: application/octet-stream Size: 3530 bytes Desc: openRTSP.patch URL: From CERLANDS at arinc.com Tue Jul 16 09:03:55 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 16 Jul 2013 16:03:55 +0000 Subject: [Live-devel] Rare 2s "delay" when viewing live streams In-Reply-To: <8C4B08BC-B2C2-419F-9919-3876E1D6A2F6@live555.com> References: <8C4B08BC-B2C2-419F-9919-3876E1D6A2F6@live555.com> Message-ID: Thanks for the confirmation Ross. We do use UDP, i.e. the default, which makes this lag so very strange. I can clearly see all frames being received on the first UDP-port (when viewing ports in use with e.g. TCPView). This 2s lag has been observed three times in total over the last four months, on different workstations. However, each test-workstation cycles through a lot of streams, each typically making around 100,000 connections a day, so it's a very rare occurrence. The fact that it continues to happen once it started, i.e. for every subsequent connection using the same event loop/video pane is even more confusing. /Claes Of course our code doesn't buffer anything for 2 seconds. (The 'packet reordering' queue delays incoming packets for at most the 'packet reordering threshold' - which is, by default, only 100 ms - and only if packet loss occurs.) The delay is obviously caused by the TCP implementation - i.e., in the OSs of your server and client. This is not a bug; this is simply TCP's way of ensuring reliable data delivery, in the face of high data rates and lossy networks. To overcome this, either send less, or stream via UDP instead of TCP. (You should stream RTP-over-TCP *only* if there's a firewall - between the server and client - that blocks UDP packets.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5739 bytes Desc: not available URL: From pratik.panchal at einfochips.com Tue Jul 16 23:51:37 2013 From: pratik.panchal at einfochips.com (pratik) Date: Wed, 17 Jul 2013 12:21:37 +0530 Subject: [Live-devel] Difference in timestamp while receiving data from server Message-ID: <51E63EF9.6030404@einfochips.com> Hi Ross, --> We are building server & client application to record and stream data using live555 library both the side. --> Live555 version we are using is 2013.07.03. --> we have successfully completed building of server which streams data and we also checked it by receiving data through VLC and it played perfectly. --> Now, we want to make client which receives data which is streamed from server --> For that initially we have received frames using built in test program, "openRTSPClient.cpp". --> We have printed timestamps both the sides, i.e. (Server and Client). The problem is that at the server side timestamp being sent is fine, but at the client side there is an abrupt increase in timestamp once compared to previous values of timestamp which was wrong as described in the attached file. "-------------------------------------------------------- Invalid timestamp 1165029457 - 1164089188" here previous one was 1165029457 and after change it was 1164089188. --> So, why timestamp differs this much at the client side? --> Here I have attached two file, one is modified "openRTSPClient.cpp" and the other is Log file. -- Regards, Pratik --------------------------------------------------------------------------------------------- Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean --------------------------------------------------------------------------------------------- -------------- next part -------------- 55/stream0/track65282 RTSP/1.0 CSeq: 4 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2013.07.03) Transport: RTP/AVP;unicast;client_port=34748-34749 Session: 35A7484E Received 203 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Apr 11 2011 16:26:17 GMT Transport: RTP/AVP;unicast;destination=10.99.10.242;source=10.99.11.197;client_port=34748-34749;server_port=6972-6973 Session: 35A7484E [URL:"rtsp://10.99.11.197:555/stream0/"]: Set up the "audio/MPEG4-GENERIC" subsession (client ports 34748-34749) [URL:"rtsp://10.99.11.197:555/stream0/"]: Created a data sink for the "audio/MPEG4-GENERIC" subsession Sending request: PLAY rtsp://10.99.11.197:555/stream0/ RTSP/1.0 CSeq: 5 User-Agent: ./testRTSPClient (LIVE555 Streaming Media v2013.07.03) Session: 35A7484E Range: npt=0.000- Received 266 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Apr 11 2011 16:26:17 GMT Range: npt=0.000- Session: 35A7484E RTP-Info: url=rtsp://10.99.11.197:555/stream0/track65281;seq=63973;rtptime=1489040845,url=rtsp://10.99.11.197:555/stream0/track65282;seq=55505;rtptime=3401927117 [URL:"rtsp://10.99.11.197:555/stream0/"]: Started playing session... 1164086755 ---------- 1 1164086771 ---------- 1 1164086771 ---------- 1 1164086771 ---------- 1 1164086788 ---------- 1 1164086821 ---------- 1 1164086855 ---------- 1 1164086888 ---------- 1 1164086921 ---------- 1 1164086955 ---------- 1 1164086988 ---------- 1 1164087021 ---------- 1 1164087055 ---------- 1 1164087088 ---------- 1 1164087121 ---------- 1 1164087155 ---------- 1 1164087188 ---------- 1 1164087221 ---------- 1 1164087255 ---------- 1 1164087288 ---------- 1 1164087321 ---------- 1 1164087355 ---------- 1 1164087388 ---------- 1 1164087421 ---------- 1 1164087455 ---------- 1 1164087488 ---------- 1 1164087521 ---------- 1 1164087555 ---------- 1 1164087588 ---------- 1 1164087621 ---------- 1 1164087655 ---------- 1 1164087688 ---------- 1 1164087721 ---------- 1 1164087755 ---------- 1 1164087771 ---------- 1 1164087771 ---------- 1 1164087771 ---------- 1 1164087788 ---------- 1 1164087821 ---------- 1 1164087855 ---------- 1 1164087888 ---------- 1 1164087921 ---------- 1 1164087955 ---------- 1 1164087988 ---------- 1 1164088021 ---------- 1 1164088055 ---------- 1 1164088088 ---------- 1 1164088121 ---------- 1 1164088155 ---------- 1 1164088188 ---------- 1 1164088221 ---------- 1 1164088255 ---------- 1 1164088288 ---------- 1 1164088321 ---------- 1 1164088355 ---------- 1 1164088388 ---------- 1 1164088421 ---------- 1 1164088454 ---------- 1 1164088488 ---------- 1 1164088521 ---------- 1 1164088555 ---------- 1 1164088588 ---------- 1 1164088621 ---------- 1 1164088655 ---------- 1 1164088688 ---------- 1 1164088721 ---------- 1 1164088755 ---------- 1 1164088771 ---------- 1 1164088771 ---------- 1 1164088771 ---------- 1 1164088788 ---------- 1 1164088821 ---------- 1 1164088855 ---------- 1 1164088888 ---------- 1 1164088921 ---------- 1 1164088955 ---------- 1 1164088988 ---------- 1 1164089021 ---------- 1 1164089055 ---------- 1 1164089088 ---------- 1 1164089121 ---------- 1 1164089155 ---------- 1 1164089188 ---------- 1 1165029457 -------------------------------------------------------- Invalid timestamp 1165029457 - 1164089188 ---------- 1 1165029491 ---------- 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: testRTSPClient.cpp Type: text/x-c++src Size: 22666 bytes Desc: not available URL: From finlayson at live555.com Wed Jul 17 03:14:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Jul 2013 12:14:51 +0200 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <51E63EF9.6030404@einfochips.com> References: <51E63EF9.6030404@einfochips.com> Message-ID: <15A18B15-306F-4EB4-A864-A74E7D36BE99@live555.com> > --> Now, we want to make client which receives data which is streamed from server > > --> For that initially we have received frames using built in test program, "openRTSPClient.cpp". I recommend that you use "testRTSPClient" as a model for this, rather than "openRTSP". > --> We have printed timestamps both the sides, i.e. (Server and Client). The problem is that at the server side timestamp being sent is fine, > but at the client side there is an abrupt increase in timestamp once compared to previous values of timestamp See http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.curl at gmail.com Thu Jul 11 08:15:32 2013 From: amit.curl at gmail.com (Amit Pal) Date: Thu, 11 Jul 2013 11:15:32 -0400 Subject: [Live-devel] Need urgent help with RTSP client Message-ID: Hi All, I am trying to build my RTSP client using live555. 1) Can I use RTSP just for streaming not for session management. I mean we have different way of establishing the session, and I just want to use commands like play, pause etc. Is it mandatory to associate these commands with session? 2) I do not want to use RTP, so just wana make sure whether I can use curl for just controlling the stream through RTSP. 3) Which library shall I link in my project to use just the RTSP client streaming section? 4) Is there any URL that I can pass to testRTSPClient to check how does it work? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratik.panchal at einfochips.com Wed Jul 17 03:46:43 2013 From: pratik.panchal at einfochips.com (pratik) Date: Wed, 17 Jul 2013 16:16:43 +0530 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <15A18B15-306F-4EB4-A864-A74E7D36BE99@live555.com> References: <51E63EF9.6030404@einfochips.com> <15A18B15-306F-4EB4-A864-A74E7D36BE99@live555.com> Message-ID: <51E67613.9000408@einfochips.com> Hi Ross, We have also checked return value of /hasBeenSynchronizedUsingRTCP/(), and it returns 1 before and after change of timestamp. On 07/17/2013 03:44 PM, Ross Finlayson wrote: >> --> Now, we want to make client which receives data which is streamed >> from server >> >> --> For that initially we have received frames using built in test >> program, "openRTSPClient.cpp". > > I recommend that you use "testRTSPClient" as a model for this, rather > than "openRTSP". > > >> --> We have printed timestamps both the sides, i.e. (Server and >> Client). The problem is that at the server side timestamp being sent >> is fine, >> but at the client side there is an abrupt increase in timestamp >> once compared to previous values of timestamp > > See > http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > ************************************************************************************************************************************************************* > > > *eInfochips Business Disclaimer*: This e-mail message and all > attachments transmitted with it are intended solely for the use of the > addressee and may contain legally privileged and confidential > information. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution, copying, or other use of this message or > its attachments is strictly prohibited. If you have received this > message in error, please notify the sender immediately by replying to > this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the > spr ead of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > > ************************************************************************************************************************************************************* > > --------------------------------------------------------------------------------------------- > Notice: > This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean > --------------------------------------------------------------------------------------------- > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Regards, Pratik --------------------------------------------------------------------------------------------- Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean --------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 17 04:22:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Jul 2013 13:22:08 +0200 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <51E63EF9.6030404@einfochips.com> References: <51E63EF9.6030404@einfochips.com> Message-ID: <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> > "-------------------------------------------------------- Invalid timestamp 1165029457 - 1164089188" > here previous one was 1165029457 and after change it was 1164089188. > I notice that these presentation times correspond to dates in 2006. Assuming that your server is using our software, you should make sure that the presentation times that it generates (for each of its frames) correspond to 'wall clock' time - i.e. the times that you would get by calling "gettimeofday()". There's nothing wrong with having your server's clock think that it's 2006, but you must ensure that it uses its clock when computing frames' presentation times. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratik.panchal at einfochips.com Thu Jul 18 22:42:40 2013 From: pratik.panchal at einfochips.com (pratik) Date: Fri, 19 Jul 2013 11:12:40 +0530 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> References: <51E63EF9.6030404@einfochips.com> <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> Message-ID: <51E8D1D0.6000800@einfochips.com> Hi Ross, -->As per your suggestion we have changed our server & client's time to wall clock time but still there is problem with timestamp. --> we are still getting abrupt change in timestamp once as i had talked about and due to that while writing to file it writes wrong timestamp to file. On 07/17/2013 04:52 PM, Ross Finlayson wrote: >> "-------------------------------------------------------- Invalid >> timestamp 1165029457 - 1164089188" >> here previous one was 1165029457 and after change it was 1164089188. >> > > I notice that these presentation times correspond to dates in 2006. > Assuming that your server is using our software, you should make sure > that the presentation times that it generates (for each of its frames) > correspond to 'wall clock' time - i.e. the times that you would get by > calling "gettimeofday()". > > There's nothing wrong with having your server's clock think that it's > 2006, but you must ensure that it uses its clock when computing > frames' presentation times. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > ************************************************************************************************************************************************************* > > > *eInfochips Business Disclaimer*: This e-mail message and all > attachments transmitted with it are intended solely for the use of the > addressee and may contain legally privileged and confidential > information. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution, copying, or other use of this message or > its attachments is strictly prohibited. If you have received this > message in error, please notify the sender immediately by replying to > this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the > spr ead of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > > ************************************************************************************************************************************************************* > > --------------------------------------------------------------------------------------------- > Notice: > This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean > --------------------------------------------------------------------------------------------- > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Regards, Pratik --------------------------------------------------------------------------------------------- Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean --------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 18 23:16:34 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Jul 2013 08:16:34 +0200 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <51E8D1D0.6000800@einfochips.com> References: <51E63EF9.6030404@einfochips.com> <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> <51E8D1D0.6000800@einfochips.com> Message-ID: <28E80F22-F563-443C-9944-849B225EDD49@live555.com> > -->As per your suggestion we have changed our server & client's time to wall clock time > but still there is problem with timestamp. I don't see how this can be happening with our server and client. Do you see the problem with your server and our original, *unmodified* "testRTSPClient" application? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratik.panchal at einfochips.com Thu Jul 18 23:25:23 2013 From: pratik.panchal at einfochips.com (pratik) Date: Fri, 19 Jul 2013 11:55:23 +0530 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <28E80F22-F563-443C-9944-849B225EDD49@live555.com> References: <51E63EF9.6030404@einfochips.com> <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> <51E8D1D0.6000800@einfochips.com> <28E80F22-F563-443C-9944-849B225EDD49@live555.com> Message-ID: <51E8DBD3.7020906@einfochips.com> Yes, i have just put some prints to check this abrupt change in timestamp in unmodified "testRTSPClient". So, by observing that change in timestamp i conclude that there may be something wrong. On 07/19/2013 11:46 AM, Ross Finlayson wrote: >> -->As per your suggestion we have changed our server & client's time >> to wall clock time >> but still there is problem with timestamp. > > I don't see how this can be happening with our server and client. > > Do you see the problem with your server and our original, *unmodified* > "testRTSPClient" application? > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > ************************************************************************************************************************************************************* > > > *eInfochips Business Disclaimer*: This e-mail message and all > attachments transmitted with it are intended solely for the use of the > addressee and may contain legally privileged and confidential > information. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution, copying, or other use of this message or > its attachments is strictly prohibited. If you have received this > message in error, please notify the sender immediately by replying to > this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the > spr ead of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > > ************************************************************************************************************************************************************* > > --------------------------------------------------------------------------------------------- > Notice: > This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean > --------------------------------------------------------------------------------------------- > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Regards, Pratik --------------------------------------------------------------------------------------------- Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean --------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 19 00:42:06 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Jul 2013 09:42:06 +0200 Subject: [Live-devel] Difference in timestamp while receiving data from server In-Reply-To: <51E8DBD3.7020906@einfochips.com> References: <51E63EF9.6030404@einfochips.com> <96789EC3-2D19-4E3C-A069-09C2AB36A6C1@live555.com> <51E8D1D0.6000800@einfochips.com> <28E80F22-F563-443C-9944-849B225EDD49@live555.com> <51E8DBD3.7020906@einfochips.com> Message-ID: <5DF2B925-7D00-45FB-97D3-C6954A491993@live555.com> > Yes, i have just put some prints to check this abrupt change in timestamp in unmodified "testRTSPClient". OK, so now try the (unmodified) "testRTSPClient" with the (original, unmodified) "testOnDemandRTSPServer" (or "live555MediaServer"). If you see the problem with your server, but not with "testOnDemandRTSPServer", then the problem has to be (somewhere) with your server... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Jul 19 09:19:54 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 19 Jul 2013 16:19:54 +0000 Subject: [Live-devel] Seeing small handle leak when repeatedly starting and stopping event loop Message-ID: When I start and stop the liveMedia event loop I see a small handle leak in my Windows test client. When looking in Process Explorer I can see the amount of file handles with the name "\Device\Afd" growing. I don't have to stream anything for it to occur, i.e. I just start the event loop and then bring it down by setting the flag to 1. It is very possible it's due to some needed cleanup I'm missing. After leaving doEventLoop I delete my trigger(s), call env->reclaim() and delete the TaskScheduler. Is there anything else that should be done? /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5739 bytes Desc: not available URL: From ashvyrkin at gosniias.ru Tue Jul 23 01:24:30 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Tue, 23 Jul 2013 12:24:30 +0400 Subject: [Live-devel] Streaming over TCP crashing Message-ID: <51EE3DBE.7030205@gosniias.ru> Hi, Ross. I rebuilt live555MediaServer from the latest source from 2013.07.16. I have a problem when playing back on stream TCP. Immediately after playing the file until the end is falling and the client and the server. If you set the playing time (that is, not until the end of the file), then everything is fine, like playing on the UDP. In the client, in the fall "RTSPClient::handleAlternativeRequestByte1" on else if (requestByte == 0xFE) { // Another hack: The new handler of the input TCP socket no longer needs it, so take back control: envir().taskScheduler().setBackgroundHandling(fInputSocketNum, SOCKET_READABLE|SOCKET_EXCEPTION, (TaskScheduler::BackgroundHandlerProc*)&incomingDataHandler, this); In the server, in the fall "RTPInterface::removeStreamSocket" on if ((*streamsPtr)->fStreamSocketNum == sockNum && (*streamsPtr)->fStreamChannelId == streamChannelId) { deregisterSocket(envir(), sockNum, streamChannelId); From pawel.miniszewski at mindpower.pl Tue Jul 23 02:09:41 2013 From: pawel.miniszewski at mindpower.pl (=?UTF-8?B?UGF3ZcWCIE1pbmlzemV3c2tp?=) Date: Tue, 23 Jul 2013 11:09:41 +0200 Subject: [Live-devel] Unable to set PPS/SPS headers Message-ID: <51EE4855.8080608@mindpower.pl> Hello, I'm creating a live streaming library and I have problems with setting up h264 video stream. I implemented a MediaSource class to wrap MS Media Foundation H264 encoder and plugged it into my custom subsession, like this: CIMediaSource* source = CIMediaSource::createNew(envir(), FrameProvider); UINT32 cbSpsSize, cbPpsSize; UINT8* pcbSpsBuffer = NULL; UINT8* pcbPpsBuffer = NULL; source->GetSPSandPPS(&cbSpsSize, &pcbSpsBuffer, &cbPpsSize, &pcbPpsBuffer); H264VideoStreamDiscreteFramer* framer = H264VideoStreamDiscreteFramer::createNew(envir(), source); framer->setSPSandPPS(pcbSpsBuffer, cbSpsSize, pcbPpsBuffer, cbPpsSize); The problem is that my SPS/PPS NALs are never used in SDP. After some debugging i reached the place where Session Description is created in H264VideoRTPSink: if (sps == NULL || pps == NULL) { // We need to get SPS and PPS from our framer source: if (fOurFragmenter == NULL) return NULL; // we don't yet have a fragmenter (and therefore not a source) H264VideoStreamFramer* framerSource = (H264VideoStreamFramer*) (fOurFragmenter->inputSource()); if (framerSource == NULL) return NULL; // we don't yet have a source framerSource->getSPSandPPS(sps, spsSize, pps, ppsSize); if (sps == NULL || pps == NULL) return NULL; // our source isn't ready } Here, framerSource->getSPSandPPS() never gets called because at this point fOurFragmenter is NULL. On the other hand, when I create RTSP sink and then pass SPS/PPS, the stream works OK: return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic, SPS, SPSSize, PPS, PPSSize); //THIS ONE WORKS Is there anything I'm missing with the setup? How can I properly set SPS/PPS NALs for the stream? Any help appreciated! Best regards, Pawel From piers.hawksley at amgsystems.com Tue Jul 23 09:36:56 2013 From: piers.hawksley at amgsystems.com (Piers Hawksley) Date: Tue, 23 Jul 2013 17:36:56 +0100 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams Message-ID: <7902889F9975EE44A11D94D3D485EA14BF6AB4@amgsrv01.AMGSYSTEMS.local> Can I test my understanding of the testMPEG4VideoStreamer multicast sample application and ask a question on the server media session reference count ? testMPEG4VideoStreamer creates an RTSP server to stream test.m4e and reports 'Play using this stream using the URL ...'. The URL is of the form RTSP://:8554/testStream, which is a unicast address. When connecting using VLC the RTSP SETUP response provides the multicast address with the line: Transport: RTP/AVP;multicast;destination=;source=;port=1234-1235;ttl=1 Using wireshark I can see the image data is being sent from the source address to the multicast address. The FAQ mentions that the testMPEG4VideoStreamer program incorporates an RTSP server to provide the SDP description - is this why the RTP multicast stream is accessed using the RTSP unicast address ? VLC instructions (http://www.videolan.org/doc/play-howto/en/ch04.html) suggest an RTP multicast stream can be received using rtp://@:1234/, however VLC does not display a video stream when this address is used - is this because it cannot decode the stream as it doesn't have the information required ? I am extending a program (a camera application running on Embedded Linux and using live555 to server the video streams) that we have been using to provide multiple unicast streams (MPEG4, H.264, JPEG (sorry - its for Onvif standard compliance)) at different resolutions. The aim is to allow some of the streams to be multicast streams (either SSM or non-SSM) and the rest unicast. I am testing this on a LAN with simple unmanaged switches and have set ttl to 1 to avoid issues with routers. On start-up the camera joins the multicast group(s) (one for every stream that is set to use multicast) with an IGMP v2 Membership Report (0x16); When each VLC client connects the PC it is running on joins the multicast group for the stream requested (if it is not already a member) with an IGMP v2 Membership Report (0x16); Each connection to RTSP://:8554/streamN produces the RTSP Options, Describe, Setup, Play sequence; Each connection causes that stream's ServerMediaSession reference count to increase; When each connection is closed that stream's ServerMediaSession reference count decreases; When all connections from one PC are closed we get an RTSP Teardown followed by an IGMP v2 Leave Group (0x17) (from the PC); When the program on the camera stops the live555 event thread / closes the RTSP server we get an IGMP v2 Leave Group (0x17) (from the camera). Each stream's ServerMediaSession reference count (from sms->referenceCount(), where sms was created with ServerMediaSession *sms = ServerMediaSession::createNew(...) ) increments with each new multicast connection. Is this a count of the number of clients not a count of the number of streams being sent ? Many thanks, Piers Hawksley From tim.gee at aldiscorp.com Tue Jul 23 14:39:31 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Tue, 23 Jul 2013 21:39:31 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding Message-ID: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com> I have been working with the testRTSPClient example for reading from an MJPEG camera. I understand that when afterGettingFrame() is called, fReceiveBuffer contains the raw RTP packet, and I need to reformat the header to get "standard" JPEG files. What is the recommended method for doing this? It appears that JPEGVideoRTPSource contains a private virtual function called processSpecialHeader() that is meant for this task, but I don't understand the Live555 architecture well enough to know how this should get called. Thanks, Tim Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 23 19:12:22 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jul 2013 04:12:22 +0200 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> > I have been working with the testRTSPClient example for reading from an MJPEG camera. I understand that when afterGettingFrame() is called, fReceiveBuffer contains the raw RTP packet You understand incorrectly. All of the RTP (and RTCP) processing is done by our code; that's why our code is there. When a RTP receiver (in this case, our "testRTSPClient" application) receives data, it will be a complete (audio or video) frame. In the case of a JPEG/RTP stream (served by a RTSP server - such as a network camera), the received data will be a complete JPEG frame. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jul 23 21:57:36 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Wed, 24 Jul 2013 08:57:36 +0400 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <51EE3DBE.7030205@gosniias.ru> References: <51EE3DBE.7030205@gosniias.ru> Message-ID: <51EF5EC0.608@gosniias.ru> I should add that in version 06.04.13 of this problem is not observed. I also have to add that the testRTSPClient crashes when in the "shutdownStream" function instead "exit(exitCode);" of the substitute "eventLoopWatchVariable = 1;". 23.07.2013 12:24, Andrey Shvyrkin ?????: > Hi, Ross. I rebuilt live555MediaServer from the latest source from > 2013.07.16. I have a problem when playing back on stream TCP. > Immediately after playing the file until the end is falling and the > client and the server. If you set the playing time (that is, not until > the end of the file), then everything is fine, like playing on the UDP. > In the client, in the fall "RTSPClient::handleAlternativeRequestByte1" on > > else if (requestByte == 0xFE) { > // Another hack: The new handler of the input TCP socket no longer > needs it, so take back control: > envir().taskScheduler().setBackgroundHandling(fInputSocketNum, > SOCKET_READABLE|SOCKET_EXCEPTION, > (TaskScheduler::BackgroundHandlerProc*)&incomingDataHandler, this); > > In the server, in the fall "RTPInterface::removeStreamSocket" on > > if ((*streamsPtr)->fStreamSocketNum == sockNum > && (*streamsPtr)->fStreamChannelId == streamChannelId) { > deregisterSocket(envir(), sockNum, streamChannelId); > From finlayson at live555.com Tue Jul 23 23:57:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jul 2013 08:57:43 +0200 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <51EE3DBE.7030205@gosniias.ru> References: <51EE3DBE.7030205@gosniias.ru> Message-ID: <6C57FDFC-4ECB-4707-8C43-0948628B3E24@live555.com> Andrey, Thanks for the report. I have reproduced the problem, and am currently working on a solution. Stay tuned... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.khare at samsung.com Tue Jul 23 22:34:32 2013 From: s.khare at samsung.com (Shailendra Khare) Date: Wed, 24 Jul 2013 05:34:32 +0000 (GMT) Subject: [Live-devel] issue in test app testondemantRTSPServer on windows in debug mode. Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201307241104580_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: From tim.gee at aldiscorp.com Wed Jul 24 05:43:30 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Wed, 24 Jul 2013 12:43:30 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> Message-ID: <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com> Thanks for the response. Ok, does that mean the data in the sink will have already been processed by JPEGVideoRTPSource::processSpecialHeader()? I know the source object is correctly set to be JPEGVideoRTPSource, but I don't know if this member function gets called automatically in the RTP processing. I wonder if there is a bug in the JPEG packet processing because I write each JPEG frame to a file, and each appears very corrupted. It's definitely a JPEG because it opens in an image viewer, and it has the right dimensions. However, each image looks like garbage. I put the following code in testRTSPClient. void DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { FrameCount++; char fname[2048]; sprintf(fname, "image_%04d.jpg", FrameCount); FILE *fout = fopen(fname,"w"); fwrite(fReceiveBuffer, frameSize, 1, fout); fclose(fout); // Then continue, to request the next frame of data: continuePlaying(); } Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Tuesday, July 23, 2013 10:12 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding I have been working with the testRTSPClient example for reading from an MJPEG camera. I understand that when afterGettingFrame() is called, fReceiveBuffer contains the raw RTP packet You understand incorrectly. All of the RTP (and RTCP) processing is done by our code; that's why our code is there. When a RTP receiver (in this case, our "testRTSPClient" application) receives data, it will be a complete (audio or video) frame. In the case of a JPEG/RTP stream (served by a RTSP server - such as a network camera), the received data will be a complete JPEG frame. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image_0001.jpg Type: image/jpeg Size: 22202 bytes Desc: image_0001.jpg URL: From finlayson at live555.com Wed Jul 24 13:02:38 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jul 2013 22:02:38 +0200 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> > Thanks for the response. Ok, does that mean the data in the sink will have already been processed by JPEGVideoRTPSource::processSpecialHeader()? Yes, but you don't have to concern yourself with how our code works. As I said before, the data that the application-level client code (in this case "testRTSPClient") receives should be a complete JPEG video frame each time. > I wonder if there is a bug in the JPEG packet processing because I write each JPEG frame to a file, and each appears very corrupted. It's definitely a JPEG because it opens in an image viewer, and it has the right dimensions. However, each image looks like garbage. What happens when you try playing the stream using VLC? (VLC also uses our RTSP/RTP client code.) > > I put the following code in testRTSPClient. > > void DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, > struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { You should also check the value of "numTruncatedBytes" (to make sure that it's zero). If it's non-zero, then that means that your buffer size was too small. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavlo.suikov at globallogic.com Wed Jul 24 08:01:34 2013 From: pavlo.suikov at globallogic.com (Pavlo Suikov) Date: Wed, 24 Jul 2013 18:01:34 +0300 Subject: [Live-devel] Live555 on QNX 6.5.0 Message-ID: Hi, is there a port of Live555 to Neutrino? There are mentions of such a port on the Internet, but it seems that the latest official source tarball has only QNX4 support. Regards, Pavlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 24 13:19:16 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jul 2013 22:19:16 +0200 Subject: [Live-devel] Live555 on QNX 6.5.0 In-Reply-To: References: Message-ID: <612DE089-4C0E-4DC4-A469-148C88519A13@live555.com> > is there a port of Live555 to Neutrino? Well, I had to look up "Neutrino" to figure out what it is - a version of QNX.... > There are mentions of such a port on the Internet, but it seems that the latest official source tarball has only QNX4 support. I suggest that you begin by trying the existing "config.qnx4" file - i.e., by running "./genMakefiles qnx4". If that doesn't work, feel free to make a new "config.qnx-neutrino" (or whatever) file, and send it to us, so we can include it in future releases of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at amgsystems.com Thu Jul 25 08:23:03 2013 From: piers.hawksley at amgsystems.com (Piers Hawksley) Date: Thu, 25 Jul 2013 16:23:03 +0100 Subject: [Live-devel] Multicast addresses for MPEG4 and H.264 streams In-Reply-To: <51EEB128.7020508@amgsystems.com> References: <51EEB128.7020508@amgsystems.com> Message-ID: <7902889F9975EE44A11D94D3D485EA14BF6ABA@amgsrv01.AMGSYSTEMS.local> Can live555 stream H.264 or MPEG4 video to rtp://:1234 without using RTSP to set-up the stream (e.g. the client might be on a different subnet to the live555 server) ? I am extending a program (a camera application running on Embedded Linux and using live555 to serve the video streams) to add multicast streams. Using rtsp://user:pass@:8554/streamname in VLC I can view each multicast stream. Using rtp://: I cannot view a stream (even if another instance of VLC has already started that stream on the same client PC). Is the password authentication causing a problem ? When I connect using RTSP each stream's ServerMediaSession reference count (from sms->referenceCount(), where sms was created with ServerMediaSession *sms = ServerMediaSession::createNew(...) ) increments with each new multicast connection. Is this a count of the number of clients connected to the multicast stream ? Best Regards, Piers Hawksley From tim.gee at aldiscorp.com Sun Jul 28 08:43:20 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Sun, 28 Jul 2013 15:43:20 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> Message-ID: <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com> Thanks. I'm able to view the RTSP stream in VLC and the Onvif device manager, which also uses Live555. The buffer is plenty big enough, and I'm not seeing truncated bytes. Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Wednesday, July 24, 2013 4:02 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding Thanks for the response. Ok, does that mean the data in the sink will have already been processed by JPEGVideoRTPSource::processSpecialHeader()? Yes, but you don't have to concern yourself with how our code works. As I said before, the data that the application-level client code (in this case "testRTSPClient") receives should be a complete JPEG video frame each time. I wonder if there is a bug in the JPEG packet processing because I write each JPEG frame to a file, and each appears very corrupted. It's definitely a JPEG because it opens in an image viewer, and it has the right dimensions. However, each image looks like garbage. What happens when you try playing the stream using VLC? (VLC also uses our RTSP/RTP client code.) I put the following code in testRTSPClient. void DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { You should also check the value of "numTruncatedBytes" (to make sure that it's zero). If it's non-zero, then that means that your buffer size was too small. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 28 09:30:02 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jul 2013 18:30:02 +0200 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com> > I'm able to view the RTSP stream in VLC OK. One thing that VLC is doing that "testRTSPClient" is not is setting an extremely large receive buffer (in the operating system) for the RTP socket. This may be necessary for you, because you're trying to receive a stream that uses such a ridiculously inefficient codec (i.e., JPEG). So, try the following: Add #include to your application, and add the line increaseReceiveBufferTo(env, scs.subsession->rtpSource()->RTPgs()->socketNum(), 2000000); to your "continueAfterSETUP()" function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.gee at aldiscorp.com Sun Jul 28 12:59:50 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Sun, 28 Jul 2013 19:59:50 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com>, <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com> Message-ID: I added the line for increasing the receive buffer, but it didn't make the output images any better. Thanks for the suggestion. Anything else I should try or investigate? Below is the continueAfterSETUP() after the addition of the new line. void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* resultString) { do { UsageEnvironment& env = rtspClient->envir(); // alias StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs; // alias scs.subsession->sink = DummySink::createNew(env, *scs.subsession, rtspClient->url()); env << *rtspClient << "Created a data sink for the \"" << *scs.subsession << "\" subsession\n"; scs.subsession->miscPtr = rtspClient; increaseReceiveBufferTo(env, scs.subsession->rtpSource()->RTPgs()->socketNum(), 2000000); FramedSource *src = scs.subsession->readSource(); scs.subsession->sink->startPlaying(*src, subsessionAfterPlaying, scs.subsession); if (scs.subsession->rtcpInstance() != NULL) { scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler, scs.subsession); } } while (0); delete[] resultString; setupNextSubsession(rtspClient); } Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Sunday, July 28, 2013 12:30 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding I'm able to view the RTSP stream in VLC OK. One thing that VLC is doing that "testRTSPClient" is not is setting an extremely large receive buffer (in the operating system) for the RTP socket. This may be necessary for you, because you're trying to receive a stream that uses such a ridiculously inefficient codec (i.e., JPEG). So, try the following: Add #include to your application, and add the line increaseReceiveBufferTo(env, scs.subsession->rtpSource()->RTPgs()->socketNum(), 2000000); to your "continueAfterSETUP()" function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xieyongda at gmail.com Tue Jul 16 01:15:11 2013 From: xieyongda at gmail.com (=?GB2312?B?0LvTwLTv?=) Date: Tue, 16 Jul 2013 16:15:11 +0800 Subject: [Live-devel] bad file descritor Message-ID: when clients up to FD_SETSIZE, terminal print error string "BasicTaskScheduler::SingleStep(): select() fails" and I add debug printf("%s",strerr(errno)); It print "bad file descritor" quickly, and never remove the bad file descritor; -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.gee at aldiscorp.com Mon Jul 29 15:54:58 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Mon, 29 Jul 2013 22:54:58 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com>, <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com>, Message-ID: <0802e088d254444cbbb4662fadb48268@BY2PR06MB092.namprd06.prod.outlook.com> I've been looking at the JPEG images in JpegSnoop and hex view. It appears that there are 4 extra bytes between the luminance and chrominance quantization tables. I've looked at the code for JPEGVideoRTPSource::processSpecialHeader(), and I don't yet see why the extra bytes would occur. I'll keep looking. Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Tim Gee Sent: Sunday, July 28, 2013 3:59 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding I added the line for increasing the receive buffer, but it didn't make the output images any better. Thanks for the suggestion. Anything else I should try or investigate? Below is the continueAfterSETUP() after the addition of the new line. void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* resultString) { do { UsageEnvironment& env = rtspClient->envir(); // alias StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs; // alias scs.subsession->sink = DummySink::createNew(env, *scs.subsession, rtspClient->url()); env << *rtspClient << "Created a data sink for the \"" << *scs.subsession << "\" subsession\n"; scs.subsession->miscPtr = rtspClient; increaseReceiveBufferTo(env, scs.subsession->rtpSource()->RTPgs()->socketNum(), 2000000); FramedSource *src = scs.subsession->readSource(); scs.subsession->sink->startPlaying(*src, subsessionAfterPlaying, scs.subsession); if (scs.subsession->rtcpInstance() != NULL) { scs.subsession->rtcpInstance()->setByeHandler(subsessionByeHandler, scs.subsession); } } while (0); delete[] resultString; setupNextSubsession(rtspClient); } Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Sunday, July 28, 2013 12:30 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding I'm able to view the RTSP stream in VLC OK. One thing that VLC is doing that "testRTSPClient" is not is setting an extremely large receive buffer (in the operating system) for the RTP socket. This may be necessary for you, because you're trying to receive a stream that uses such a ridiculously inefficient codec (i.e., JPEG). So, try the following: Add #include to your application, and add the line increaseReceiveBufferTo(env, scs.subsession->rtpSource()->RTPgs()->socketNum(), 2000000); to your "continueAfterSETUP()" function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 29 23:10:39 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jul 2013 08:10:39 +0200 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <0802e088d254444cbbb4662fadb48268@BY2PR06MB092.namprd06.prod.outlook.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com>, <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com>, <0802e088d254444cbbb4662fadb48268@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <8FD65B51-77E6-4EC9-9246-15579F4EF8A4@live555.com> > I've been looking at the JPEG images in JpegSnoop and hex view. It appears that there are 4 extra bytes between the luminance and chrominance quantization tables. I've looked at the code for JPEGVideoRTPSource::processSpecialHeader(), and I don't yet see why the extra bytes would occur. > > I'll keep looking. The fact that - by your own admission - the same stream is decoded and rendered OK by VLC (which also uses the LIVE555 library code) suggests that you are on a wild goose chase here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 30 05:11:05 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jul 2013 14:11:05 +0200 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <51EF5EC0.608@gosniias.ru> References: <51EE3DBE.7030205@gosniias.ru> <51EF5EC0.608@gosniias.ru> Message-ID: (Sorry for the delay in dealing with this problem. I've been traveling recently, and am at the IETF meeting in Berlin this week.) I have just installed a new version (2013.07.30) of the "LIVE555 Streaming Media" code that should fix this problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 30 06:20:54 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jul 2013 15:20:54 +0200 Subject: [Live-devel] openRTSP option to force multicast In-Reply-To: <9377_1373985478_51E55AC5_9377_1528_1_1BE8971B6CFF3A4F97AF4011882AA255015637BFF787@THSONEA01CMS01P.one.grp> References: <9377_1373985478_51E55AC5_9377_1528_1_1BE8971B6CFF3A4F97AF4011882AA255015637BFF787@THSONEA01CMS01P.one.grp> Message-ID: <97999EEC-12E1-42E4-B2B3-0DC9AB092DFA@live555.com> > Using some camera, it is needed to ask for a multicast stream in the RTSP SETUP, but openRTSP always set this flag to False. > If this could help others users, you could find attached a modification that add ?W to set the forceMulticastFlag to True. OK, I'll add this to the next release of the software. (However, I'll make the option "-C" rather than "-W" (because the word "multicast" contains the letter C, but not W.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.gee at aldiscorp.com Tue Jul 30 10:37:39 2013 From: tim.gee at aldiscorp.com (Tim Gee) Date: Tue, 30 Jul 2013 17:37:39 +0000 Subject: [Live-devel] testRTSPClient and MJPEG decoding In-Reply-To: <8FD65B51-77E6-4EC9-9246-15579F4EF8A4@live555.com> References: <655d13fe8aac4206975bdaea243795b0@BY2PR06MB092.namprd06.prod.outlook.com>, <40C43D3D-5D18-43E8-9BF8-717DC7FB730D@live555.com> <675e0b95a63147aab000267d81e75283@BY2PR06MB092.namprd06.prod.outlook.com>, <089BDF26-2A5C-44EA-9836-9579A6D65E98@live555.com> <3726b520136a4a65956adaf9368c7a0d@BY2PR06MB092.namprd06.prod.outlook.com>, <24C581AE-87A6-440B-8D68-57ACACF8D307@live555.com>, <0802e088d254444cbbb4662fadb48268@BY2PR06MB092.namprd06.prod.outlook.com>, <8FD65B51-77E6-4EC9-9246-15579F4EF8A4@live555.com> Message-ID: <7a1bd80fdc48420d9ab0c4db42535849@BY2PR06MB092.namprd06.prod.outlook.com> Ok. It was my problem. I should have opened the file as binary. I added the 'b' to file open mode, and it worked. FILE *fout = fopen(fname,"wb"); Thanks for your help. Tim Gee | Senior R&D Engineer Aldis | 10545 Hardin Valley Rd. | Knoxville TN | 37932 o: 865-978-6535 | f: 865-249-6608 ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Tuesday, July 30, 2013 2:10 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testRTSPClient and MJPEG decoding I've been looking at the JPEG images in JpegSnoop and hex view. It appears that there are 4 extra bytes between the luminance and chrominance quantization tables. I've looked at the code for JPEGVideoRTPSource::processSpecialHeader(), and I don't yet see why the extra bytes would occur. I'll keep looking. The fact that - by your own admission - the same stream is decoded and rendered OK by VLC (which also uses the LIVE555 library code) suggests that you are on a wild goose chase here. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremiah.Morrill at econnect.tv Tue Jul 30 13:08:22 2013 From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill) Date: Tue, 30 Jul 2013 20:08:22 +0000 Subject: [Live-devel] LiveMedia in Windows 8 Application Message-ID: <8e732d91b2344db0b0ee10b3f583795f@BLUPR07MB162.namprd07.prod.outlook.com> Hello all, Windows (8) Store application's do not have access to winsock, which is needed to support liveMedia (mostly the BSD socket functions). Win8 applications only have access to Windows Runtime Socket COM classes: http://msdn.microsoft.com/en-us/library/windows/apps/br212061.aspx I've started a project here (http://winrtsock.codeplex.com/) for a windows runtime winsock fa?ade. It's still in the very early stages (read: experimental), but liveMedia currently is able to stream RTSP (UDP/TCP) from a Win Store App with this. The only code change needed was replacing the winsock include to "#include ". I don't have the listen/accept methods finished yet to host an RTSP servers but hope to get that in there soon! Just thought I'd share as others may want to use this great RTSP library on the win8 platform. Thanks, -Jeremiah Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Tue Jul 30 23:01:03 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Wed, 31 Jul 2013 10:01:03 +0400 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <6C57FDFC-4ECB-4707-8C43-0948628B3E24@live555.com> References: <51EE3DBE.7030205@gosniias.ru> <6C57FDFC-4ECB-4707-8C43-0948628B3E24@live555.com> Message-ID: <51F8A81F.9030801@gosniias.ru> 24.07.2013 10:57, Ross Finlayson ?????: > Andrey, > > Thanks for the report. I have reproduced the problem, and am > currently working on a solution. Stay tuned... > > > 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 Hi, Ross. I tried the new version of 7/30/13, but unfortunately the problem persists. The client is crashing after the call "shutdownStream" function. I enclose the call stack: > testRTSPClient.exe!UsageEnvironment::taskScheduler()?????? 58 C++ testRTSPClient.exe!RTSPClient::handleAlternativeRequestByte1(unsigned char requestByte)?????? 1217 C++ testRTSPClient.exe!RTSPClient::handleAlternativeRequestByte(void * rtspClient, unsigned char requestByte)?????? 1208 C++ testRTSPClient.exe!SocketDescriptor::~SocketDescriptor()?????? 357 C++ testRTSPClient.exe!SocketDescriptor::`scalar deleting destructor'(unsigned int) C++ testRTSPClient.exe!SocketDescriptor::tcpReadHandler(SocketDescriptor * socketDescriptor, int mask)?????? 428 C++ testRTSPClient.exe!BasicTaskScheduler::SingleStep(unsigned int maxDelayTime)?????? 163 C++ testRTSPClient.exe!BasicTaskScheduler0::doEventLoop(char * watchVariable)?????? 80 C++ testRTSPClient.exe!main(int argc, char * * argv)?????? 76 C++ testRTSPClient.exe!__tmainCRTStartup()?????? 536 C testRTSPClient.exe!mainCRTStartup()?????? 377 C -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vince.Li at quantatw.com Tue Jul 30 20:27:32 2013 From: Vince.Li at quantatw.com (=?big5?B?VmluY2UgTGkgKKf1q8Ip?=) Date: Wed, 31 Jul 2013 03:27:32 +0000 Subject: [Live-devel] Streaming H.264 with MPEG2TS via BasicUDPSink Message-ID: <1B8CE959541B0C40BEC5966000F63EC6AD9846C5@MAILBX03.quanta.corp> Greetings, I?m a new to live555. I'm trying to use live555 to stream H.264 video which is encoded by x264 and the video source is webcam. I?ve tried - Write my own FramedSource subclass based on DeviceSource - Use my own FramedSource, H264VideoStreamFramer and H264VideoRTPSink to stream by RTP. - Use my own FramedSource, H264VideoStreamFramer, MPEG2TransportStreamFromESSource and BasicUDPSink to MPEG2TS stream by UDP. In the RTP case, it works fine. However, in the UDP case, it got broken image by VLC player often. The VLC player got broken image is appeared usually when the video bitrate up to 1Mbps or a lot of B-frames. I noticed there is a tip in FAQ. ------------------------------ The "test*Streamer" test programs read from a file. Can I modify them so that they take input from a H.264 or MPEG encoder instead, so I can stream live (rather than prerecorded) video and/or audio? ------------------------------ Therefore, I changed my video frame source from H264VideoStreamFramer to H264VideoStreamDiscreteFramer, but got broken image still. Any ideas on how to solve this problem? Kind Regards, Vince -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 31 10:10:55 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 31 Jul 2013 19:10:55 +0200 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <51F8A81F.9030801@gosniias.ru> References: <51EE3DBE.7030205@gosniias.ru> <6C57FDFC-4ECB-4707-8C43-0948628B3E24@live555.com> <51F8A81F.9030801@gosniias.ru> Message-ID: <43F1D9DB-168D-4FA5-B1E9-43C2914AF842@live555.com> > Hi, Ross. I tried the new version of 7/30/13, but unfortunately the problem persists. Oops, it seems that I didn't read your original message well enough. The problem that I fixed yesterday was a problem in the *server* (if it reached the end of an input file while streaming to at least one client via RTP-over-TCP). I could reproduce that problem by running the (unmodified) "live555MediaServer" with the (unmodified) "openRTSP -t". But - on reading your message again - I understand now that you also had a problem with the RTSP *client* in this situation. I was able to reproduce this by modifying "testRTSPClient", as you did. I have now installed a new version - 2013.07.31 - of the code that should fix your problem this time. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashvyrkin at gosniias.ru Wed Jul 31 20:07:01 2013 From: ashvyrkin at gosniias.ru (Andrey Shvyrkin) Date: Thu, 01 Aug 2013 07:07:01 +0400 Subject: [Live-devel] Streaming over TCP crashing In-Reply-To: <43F1D9DB-168D-4FA5-B1E9-43C2914AF842@live555.com> References: <51EE3DBE.7030205@gosniias.ru> <6C57FDFC-4ECB-4707-8C43-0948628B3E24@live555.com> <51F8A81F.9030801@gosniias.ru> <43F1D9DB-168D-4FA5-B1E9-43C2914AF842@live555.com> Message-ID: <51F9D0D5.9000702@gosniias.ru> > I have now installed a new version - 2013.07.31 - of the code that should fix your problem this time. Thank you for your promptness, Ross. Now the error no longer occurs.