From d.velkin at ids-imaging.de Fri Jul 1 00:47:58 2011 From: d.velkin at ids-imaging.de (Velkin Dmitrij) Date: Fri, 1 Jul 2011 09:47:58 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33801ECABF0@exchsrv.idszentral.local> References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de><58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de><1575D155-0CB3-47F9-BFE9-8E6AC90198AD@ids-imaging.de> <4CB3F3483954BD4ABD0B4DBB35C7E33801ECABF0@exchsrv.idszentral.local> Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33801ECAFC8@exchsrv.idszentral.local> I found my error! If you use TCP you have first send coomand and delete session iterator and than create new session iterator and invoke startPlaying! -----Urspr?ngliche Nachricht----- Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Velkin Dmitrij Gesendet: Donnerstag, 30. Juni 2011 09:40 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] RTP over TCP with iPhone I can't change the code incremental. I have to use a new/ohther sink. And it works fine if I invoke this code without "-t" option! -----Urspr?ngliche Nachricht----- Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson Gesendet: Donnerstag, 30. Juni 2011 09:18 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] RTP over TCP with iPhone >if I implement it in this way i never get into "afterGettingFrame". >What am I doing wrong? I don't know; you're going to have to figure this out for yourself. Remember, you're starting from code that you know works - the "openRTSP" code. By making incremental changes to this code, and testing after each change, you should be able to figure out what's wrong. -- 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 From julian at jusst.de Sun Jul 3 07:00:29 2011 From: julian at jusst.de (Julian Scheel) Date: Sun, 03 Jul 2011 16:00:29 +0200 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating Message-ID: <1309701629.14267.24.camel@juli-workstation.jusst.net> Hi, is anyone else seeing the MPEG2TransportStreamIndexer not terminating at all? When I start it with a path to a ts file it creates a tsx file as expected and for a while it causes some CPU load. A few moments later CPU load reduces to 0%, I guess indexing is completed then, but the program will never terminate. Whenever I interrupt it with gdb it points to this function, which simply seems to wait for anything to happen in an endless loop. BasicTaskScheduler::SingleStep Is this a known issue? -Julian From finlayson at live555.com Sun Jul 3 07:22:18 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Jul 2011 07:22:18 -0700 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: <1309701629.14267.24.camel@juli-workstation.jusst.net> References: <1309701629.14267.24.camel@juli-workstation.jusst.net> Message-ID: >is anyone else seeing the MPEG2TransportStreamIndexer not terminating at >all? When I start it with a path to a ts file it creates a tsx file as >expected and for a while it causes some CPU load. >A few moments later CPU load reduces to 0%, I guess indexing is >completed then, but the program will never terminate. >Whenever I interrupt it with gdb it points to this function, which >simply seems to wait for anything to happen in an endless loop. >BasicTaskScheduler::SingleStep > >Is this a known issue? No. What OS are you running? And are you using the pre-built version of "MPEG2TransportStreamIndexer" for that OS, or one that you built yourself, from source? Also, please put an example ".ts" file - for which "MPEG2TransportStreamIndexer" did not terminate for you - on a publically-accessible web server, and send us the URL, so we can download and test it ourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From julian at jusst.de Sun Jul 3 07:42:27 2011 From: julian at jusst.de (Julian Scheel) Date: Sun, 03 Jul 2011 16:42:27 +0200 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: References: <1309701629.14267.24.camel@juli-workstation.jusst.net> Message-ID: <1309704148.14267.27.camel@juli-workstation.jusst.net> Am Sonntag, den 03.07.2011, 07:22 -0700 schrieb Ross Finlayson: > >is anyone else seeing the MPEG2TransportStreamIndexer not terminating at > >all? When I start it with a path to a ts file it creates a tsx file as > >expected and for a while it causes some CPU load. > >A few moments later CPU load reduces to 0%, I guess indexing is > >completed then, but the program will never terminate. > >Whenever I interrupt it with gdb it points to this function, which > >simply seems to wait for anything to happen in an endless loop. > >BasicTaskScheduler::SingleStep > > > >Is this a known issue? > > No. > > What OS are you running? And are you using the pre-built version of > "MPEG2TransportStreamIndexer" for that OS, or one that you built > yourself, from source? Problem occurs on Debian with recent livemedia-utils package from sid. As well as on archlinux with custom build version from source. > Also, please put an example ".ts" file - for which > "MPEG2TransportStreamIndexer" did not terminate for you - on a > publically-accessible web server, and send us the URL, so we can > download and test it ourself. Actually when preparing a file for upload I just realised, that the problem only occurs when the files are stored on a smb mounted share. If I copy the file to a local disk it works well. Any thoughts on this? -Julian From finlayson at live555.com Sun Jul 3 08:10:43 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Jul 2011 08:10:43 -0700 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: <1309704148.14267.27.camel@juli-workstation.jusst.net> References: <1309701629.14267.24.camel@juli-workstation.jusst.net> <1309704148.14267.27.camel@juli-workstation.jusst.net> Message-ID: >Actually when preparing a file for upload I just realised, that the >problem only occurs when the files are stored on a smb mounted share. If >I copy the file to a local disk it works well. Any thoughts on this? For some reason, you're not getting EOF when you read past the end of the file when it's on SMB. This may be an OS problem. You're going to have to figure this out for yourself (you need to figure out why "handleClosure()" is not getting called in "ByteStreamFileSource.cpp"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From julian at jusst.de Sun Jul 3 09:10:19 2011 From: julian at jusst.de (Julian Scheel) Date: Sun, 03 Jul 2011 18:10:19 +0200 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: References: <1309701629.14267.24.camel@juli-workstation.jusst.net> <1309704148.14267.27.camel@juli-workstation.jusst.net> Message-ID: <1309709419.14267.29.camel@juli-workstation.jusst.net> Am Sonntag, den 03.07.2011, 08:10 -0700 schrieb Ross Finlayson: > >Actually when preparing a file for upload I just realised, that the > >problem only occurs when the files are stored on a smb mounted share. If > >I copy the file to a local disk it works well. Any thoughts on this? > > For some reason, you're not getting EOF when you read past the end of > the file when it's on SMB. This may be an OS problem. You're going > to have to figure this out for yourself (you need to figure out why > "handleClosure()" is not getting called in > "ByteStreamFileSource.cpp"). Ok, I will try to trace this issue. Another thing I am wondering about: Is MPEG2TransportStreamIndexer meant to work with TS-files containing h264-Video as well? For those it won't terminate for me at all. For MPEG2 it works very well now. -Julian From finlayson at live555.com Sun Jul 3 13:35:04 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Jul 2011 13:35:04 -0700 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: <1309709419.14267.29.camel@juli-workstation.jusst.net> References: <1309701629.14267.24.camel@juli-workstation.jusst.net> <1309704148.14267.27.camel@juli-workstation.jusst.net> <1309709419.14267.29.camel@juli-workstation.jusst.net> Message-ID: >Another thing I am wondering about: Is MPEG2TransportStreamIndexer meant >to work with TS-files containing h264-Video as well? Yes. > For those it won't terminate for me at all. Even if the file is on a local file server (not SMB)? If that's the case, then (once again) please put an example ".ts" file - for which "MPEG2TransportStreamIndexer" did not terminate for you - on a publically-accessible web server, and send us the URL, so we can download and test it ourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From exherb at 4leaf.me Sun Jul 3 19:45:02 2011 From: exherb at 4leaf.me (He Lion) Date: Mon, 4 Jul 2011 10:45:02 +0800 Subject: [Live-devel] why live555 as local RTSP server streaming TS file (like a bridge) at android won't work? Message-ID: Because android's media player can't play TS file (1.5 - 2.2), so in oder to play "/sdcard/test.ts", I set up a local RTSP server using live555 at android, then set the data source of android media player as " http://127.0.0.1:8554/test.sdp"(something like that). The rtsp server at android actually started correctly, and I can play the ts stream using VLC player at Mac Desktop (using emulator's redir). But android media play just can't play normally with error code (1, -1). Could someone tell me why this happened? And sorry for my poor english. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 3 21:26:58 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 3 Jul 2011 21:26:58 -0700 Subject: [Live-devel] why live555 as local RTSP server streaming TS file (like a bridge) at android won't work? In-Reply-To: References: Message-ID: >Because android's media player can't play TS file (1.5 - 2.2), so in >oder to play "/sdcard/test.ts", I set up a local RTSP server using >live555 at android, then set the data source of android media player >as >"http://127.0.0.1:8554/test.sdp"(something >like that). > > >The rtsp server at android actually started correctly, and I can >play the ts stream using VLC player at Mac Desktop (using emulator's >redir). But android media play just can't play normally with error >code (1, -1). > >Could someone tell me why this happened? If "Android's media player" can't play a Transport Stream from a local file, then why do you think that it would be able to play a Transport Stream via RTSP/RTP? It probably can't play a Transport Stream, regardless of how it's delivered. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From exherb at 4leaf.me Sun Jul 3 23:03:57 2011 From: exherb at 4leaf.me (He Lion) Date: Mon, 4 Jul 2011 14:03:57 +0800 Subject: [Live-devel] why live555 as local RTSP server streaming TS file (like a bridge) at android won't work? In-Reply-To: References: Message-ID: Thanks for your answer. Why I did that? Because after set up a RTSP server working like a bridge at android, I just need to demux TS, then add video or audio streams to RTSP stream, I don't have to write a JNI media player (very difficult) to display and control every frames. I would like to ask another question. How could I demux TS to RTSP or other stream which could be supported by "Android Media Player" ? Is there a sample code to help me do that? 2011/7/4 Ross Finlayson > ** > > Because android's media player can't play TS file (1.5 - 2.2), so in oder > to play "/sdcard/test.ts", I set up a local RTSP server using live555 at > android, then set the data source of android media player as " > http://127.0.0.1:8554/test.sdp"(something like that). > > > The rtsp server at android actually started correctly, and I can play the > ts stream using VLC player at Mac Desktop (using emulator's redir). But > android media play just can't play normally with error code (1, -1). > > > Could someone tell me why this happened? > > > If "Android's media player" can't play a Transport Stream from a local > file, then why do you think that it would be able to play a Transport Stream > via RTSP/RTP? It probably can't play a Transport Stream, regardless of how > it's delivered. > ** > > -- > > ** > > 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 dekarl at spaetfruehstuecken.org Sun Jul 3 23:47:28 2011 From: dekarl at spaetfruehstuecken.org (Karl Dietz) Date: Mon, 04 Jul 2011 08:47:28 +0200 Subject: [Live-devel] why live555 as local RTSP server streaming TS file (like a bridge) at android won't work? In-Reply-To: References: Message-ID: <4E116200.60708@spaetfruehstuecken.org> On 04.07.2011 08:03, He Lion wrote: > Thanks for your answer. > > Why I did that? > Because after set up a RTSP server working like a bridge at android, I > just need to demux TS, then add video or audio streams to RTSP stream, I > don't have to write a JNI media player (very difficult) to display and > control every frames. Why don't you just encode the media files in a format that your android platform supports? Sounds a lot easier than adding an embedded streaming server just to do live conversion on the fly... http://developer.android.com/guide/appendix/media-formats.html Regards, Karl From exherb at 4leaf.me Mon Jul 4 00:07:57 2011 From: exherb at 4leaf.me (He Lion) Date: Mon, 4 Jul 2011 15:07:57 +0800 Subject: [Live-devel] why live555 as local RTSP server streaming TS file (like a bridge) at android won't work? In-Reply-To: <4E116200.60708@spaetfruehstuecken.org> References: <4E116200.60708@spaetfruehstuecken.org> Message-ID: Because the media files(Apple HTTP ) are coming from a server which I can not control. 2011/7/4 Karl Dietz > On 04.07.2011 08:03, He Lion wrote: > >> Thanks for your answer. >> >> Why I did that? >> Because after set up a RTSP server working like a bridge at android, I >> just need to demux TS, then add video or audio streams to RTSP stream, I >> don't have to write a JNI media player (very difficult) to display and >> control every frames. >> > > Why don't you just encode the media files in a format that your android > platform supports? Sounds a lot easier than adding an embedded streaming > server just to do live conversion on the fly... > http://developer.android.com/**guide/appendix/media-formats.**html > > Regards, > Karl > > ______________________________**_________________ > 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 julian at jusst.de Mon Jul 4 00:24:37 2011 From: julian at jusst.de (Julian Scheel) Date: Mon, 04 Jul 2011 09:24:37 +0200 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: References: <1309701629.14267.24.camel@juli-workstation.jusst.net> <1309704148.14267.27.camel@juli-workstation.jusst.net> <1309709419.14267.29.camel@juli-workstation.jusst.net> Message-ID: <1309764277.14267.37.camel@juli-workstation.jusst.net> Am Sonntag, den 03.07.2011, 13:35 -0700 schrieb Ross Finlayson: > > For those it won't terminate for me at all. > > Even if the file is on a local file server (not SMB)? If that's the > case, then (once again) please put an example ".ts" file - for which > "MPEG2TransportStreamIndexer" did not terminate for you - on a > publically-accessible web server, and send us the URL, so we can > download and test it ourself. Yes, the file is accessed locally. I uploaded a small sample (just cut of the first 10mb of that file) which allows me to reproduce the problem. You can grab it here: http://jusst.de/files/101.ts -Julian From finlayson at live555.com Mon Jul 4 02:31:25 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 4 Jul 2011 02:31:25 -0700 Subject: [Live-devel] MPEG2TransportStreamIndexer not terminating In-Reply-To: <1309764277.14267.37.camel@juli-workstation.jusst.net> References: <1309701629.14267.24.camel@juli-workstation.jusst.net> <1309704148.14267.27.camel@juli-workstation.jusst.net> <1309709419.14267.29.camel@juli-workstation.jusst.net> <1309764277.14267.37.camel@juli-workstation.jusst.net> Message-ID: > > Even if the file is on a local file server (not SMB)? If that's the >> case, then (once again) please put an example ".ts" file - for which >> "MPEG2TransportStreamIndexer" did not terminate for you - on a >> publically-accessible web server, and send us the URL, so we can >> download and test it ourself. > >Yes, the file is accessed locally. I uploaded a small sample (just cut >of the first 10mb of that file) which allows me to reproduce the >problem. You can grab it here: http://jusst.de/files/101.ts OK, thanks. This file helped me identify a bug in our indexing code. It will be fixed in the next release of the software. In the meantime, you can fix the problem yourself by changing line 358 of "liveMedia/MPEG2IndexFromTransportStream.cpp" from return True; to return deliverIndexRecord(); -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From nouri at soroush.net Tue Jul 5 01:27:33 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Tue, 5 Jul 2011 12:57:33 +0430 Subject: [Live-devel] Indexing a recorded stream Message-ID: Hi. I am trying to record and index an h.264/ts stream. The problem is sometimes the recorded file cannot be indexed properly. More precisely, it shows the duration of the indexed stream as a large number. When I try to use it in the streamer it shows the following message: RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! What seems to be the problem? I have uploaded a sample ts file at http://dl.dropbox.com/u/7920298/rango.ts Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From exherb at 4leaf.me Tue Jul 5 01:35:40 2011 From: exherb at 4leaf.me (He Lion) Date: Tue, 5 Jul 2011 16:35:40 +0800 Subject: [Live-devel] how to merge two elementary files? Message-ID: I have two elementary files (H264 video and AAC audio), now I set up a RTSP server, how could I merge them synchronous? -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders_chen at huntelec.com.tw Tue Jul 5 02:59:20 2011 From: anders_chen at huntelec.com.tw (Anders Chen) Date: Tue, 5 Jul 2011 17:59:20 +0800 Subject: [Live-devel] Sending speed is not enough Message-ID: <7FAAEF300EC24BB2B9810421B81CF592@huntelec.com.tw> Dear Sir, LIVE555 will do "select()" before sending every packet of a frame(any task in fact). It spends extra times, especially when the frame size is big. Maybe another reason is that my CPU is not fast enough. On my slow CPU (200MHz), it is difficult to send a real time streaming of JPEG / 20Mbps, even in a local network. (* I aware that JPEG is a bad format for real time streaming.) But it works fine when I stream it via HTTP (sending a frame by select() once and send() once). Is it really necessary to "select()" for every packet? or any advise? Thank you. Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 04:59:21 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 04:59:21 -0700 Subject: [Live-devel] Sending speed is not enough In-Reply-To: <7FAAEF300EC24BB2B9810421B81CF592@huntelec.com.tw> References: <7FAAEF300EC24BB2B9810421B81CF592@huntelec.com.tw> Message-ID: > LIVE555 will do "select()" before sending every packet of a >frame(any task in fact). Correct. > It spends extra times, especially when the frame size is big. No it doesn't. > Maybe another reason is that my CPU is not fast enough. Conceivably, but if that's the case, network streaming is unlikely to be the limiting factor. > On my slow CPU (200MHz), it is difficult to send a real time >streaming of JPEG / 20Mbps, even in a local network. > (* I aware that JPEG is a bad format for real time streaming.) > But it works fine when I stream it via HTTP (sending a frame by >select() once and send() once). > > Is it really necessary to "select()" for every packet? or any advise? The rate at which our server sends packets is determined entirely by the value of "fDurationInMicroseconds" that you set (for each JPEG frame) in the object that feeds into your "JPEGVideoRTPSink". It has nothing to do with the calls to "select()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 05:21:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 05:21:08 -0700 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: >I am trying to record and index an h.264/ts stream. >The problem is sometimes the recorded file cannot be indexed properly. More >precisely, it shows the duration of the indexed stream as a large number. >When I try to use it in the streamer it shows the following message: > >RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! > >What seems to be the problem? >I have uploaded a sample ts file >at http://dl.dropbox.com/u/7920298/rango.ts I have absolutely no problem indexing that file using the (original, unmodified) "MPEG2TransportStreamIndexer" application, nor streaming that file using the (original, unmodified) "live555MediaServer" application. If you're seeing problems only after making modifications to the supplied source code, then I probably can't help you. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nouri at soroush.net Tue Jul 5 05:42:14 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Tue, 5 Jul 2011 17:12:14 +0430 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: Sorry, it appears that I have uploaded a wrong file. Please check this one, I tested it with a fresh compilation of indexer and server. http://dl.dropbox.com/u/7920298/new.ts On Tue, Jul 5, 2011 at 4:51 PM, Ross Finlayson wrote: > ** > > I am trying to record and index an h.264/ts stream. > > The problem is sometimes the recorded file cannot be indexed properly. More > > precisely, it shows the duration of the indexed stream as a large number. > > When I try to use it in the streamer it shows the following message: > > > RTCPInstance::RTCPInstance error: totSessionBW parameter should not be > zero! > > > What seems to be the problem? > > I have uploaded a sample ts file at > http://dl.dropbox.com/u/7920298/rango.ts > > > I have absolutely no problem indexing that file using the (original, > unmodified) "MPEG2TransportStreamIndexer" application, nor streaming that > file using the (original, unmodified) "live555MediaServer" application. > > If you're seeing problems only after making modifications to the supplied > source code, then I probably can't help you. 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 finlayson at live555.com Tue Jul 5 05:52:00 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 05:52:00 -0700 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: >Sorry, it appears that I have uploaded a wrong file. >Please check this one, I tested it with a fresh compilation of >indexer and server. > >http://dl.dropbox.com/u/7920298/new.ts OK, I see the problem with this file. I'll investigate. Stay tuned... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 06:24:51 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 06:24:51 -0700 Subject: [Live-devel] Indexing a recorded stream Message-ID: >Sorry, it appears that I have uploaded a wrong file. >Please check this one, I tested it with a fresh compilation of >indexer and server. > >http://dl.dropbox.com/u/7920298/new.ts The problem with this file is that - at about 9.5 seconds into the file - the PCR timestamp decreases: from 30463.882812 seconds, to 30313.541016 seconds. That shouldn't be happening, and it's confusing the indexing code. I can probably update the indexing code to handle this situation more intelligently, but ideally you should fix your Transport Stream file (or whatever encoder is producing your Transport Stream files) so that it doesn't generate bogus PCR timestamps like this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From developpeur02 at kafemeeting.com Tue Jul 5 08:29:27 2011 From: developpeur02 at kafemeeting.com (Rodolophe Fouquet) Date: Tue, 5 Jul 2011 17:29:27 +0200 Subject: [Live-devel] About SIP server. Message-ID: Hi, I just saw in debian repos that Live 555 may implement the SIP server, but in the doc' I just have info about the client. Is that right? Regards, Rodolphe Fouquet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at awright2009.com Tue Jul 5 11:44:10 2011 From: admin at awright2009.com (admin at awright2009.com) Date: Tue, 05 Jul 2011 11:44:10 -0700 Subject: [Live-devel] wis-streamer RTSP over HTTP Message-ID: <20110705114410.21fdb0f101ed1e75ea8ae5d43a76b79a.568b3aad87.wbe@email11.secureserver.net> An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 12:56:11 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 12:56:11 -0700 Subject: [Live-devel] Indexing a recorded stream Message-ID: FYI, I have now installed a new version (2011.07.05) of the "LIVE555 Streaming Media" code that better handles this situation - indexing a file where the PCR timestamp suddenly decreases in value. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 14:41:26 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 14:41:26 -0700 Subject: [Live-devel] About SIP server. In-Reply-To: References: Message-ID: >I just saw in debian repos that Live 555 may implement the SIP >server, but in the doc' I just have info about the client. > >Is that right? There are no current plans to implement SIP server functionality. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sergey.kosov at project-10.de Tue Jul 5 16:42:36 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Wed, 6 Jul 2011 01:42:36 +0200 Subject: [Live-devel] SVC -> AVC Message-ID: <000001cc3b6d$3803a9e0$a80afda0$@project-10.de> Hi, I wonder how to extract an AVC flow from the SVC file, using live555 library. Should it be a filter? Using Google gave nothing about this question. Test applications and live555 documentation didn't also help. Best, Sergey -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 5 17:08:44 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Jul 2011 17:08:44 -0700 Subject: [Live-devel] SVC -> AVC In-Reply-To: <000001cc3b6d$3803a9e0$a80afda0$@project-10.de> References: <000001cc3b6d$3803a9e0$a80afda0$@project-10.de> Message-ID: >I wonder how to extract an AVC flow from the SVC file, using live555 >library. Should it be a filter? I'm not sure what a "SVC file" is, but it it's the same as a ".264" file - i.e., a sequence of H.264 NAL units, each preceded by 0x00000001 - then you may be able to use "H264VideoStreamFramer" (or perhaps a slight modification of this). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sergey.kosov at project-10.de Tue Jul 5 17:25:57 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Wed, 6 Jul 2011 02:25:57 +0200 Subject: [Live-devel] SVC -> AVC Message-ID: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> >>I wonder how to extract an AVC flow from the SVC file, using live555 >>library. Should it be a filter? > I'm not sure what a "SVC file" is, but it it's the same as a ".264" file > - i.e., a sequence of H.264 NAL units, each preceded by 0x00000001 - > then you may be able to use "H264VideoStreamFramer" (or perhaps a slight > modification of this). > > -- Ross FinlaysonLive Networks, Inc. > http://www.live555.com/ Thats right. I mean that SVC stream is a container with up to 9 layers (3 temporal and 3 spacial), where each layer could be represented as an AVC stream. It is possible to extract the needed layer with i.e. "svcext library". But I want to do that with the help of live555. Processing SVC stream with "H264VideoStreamFramer" produces a .ts file with spacial layer equal to 0 and temporal layer also equal to 0. And my question was about extracting a user-defined layer to save it in a .ts file. I use as an example testH264VideoStreamer application from the original library package. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.timenkov at itv.ru Tue Jul 5 20:20:16 2011 From: yuri.timenkov at itv.ru (Yuri Timenkov) Date: Wed, 06 Jul 2011 07:20:16 +0400 Subject: [Live-devel] About SIP server. In-Reply-To: References: Message-ID: <4E13D470.4070609@itv.ru> You can use separate library for session management stuff and live555 for streaming. I had good experience with sofia-sip. It doesn't provide streaming routines so liveMedia & sofia-sip complement each other. The client-side media session doesn't differ much from server-side one, so you should be able to adapt sip client example from liveMedia. Regards, Yuri On 06.07.2011 1:41, Ross Finlayson wrote: >> I just saw in debian repos that Live 555 may implement the SIP >> server, but in the doc' I just have info about the client. >> >> Is that right? > > There are no current plans to implement SIP server functionality. Sorry. > From joao_dealmeida at hotmail.com Wed Jul 6 00:35:32 2011 From: joao_dealmeida at hotmail.com (Joao Almeida) Date: Wed, 6 Jul 2011 07:35:32 +0000 Subject: [Live-devel] SVC -> AVC In-Reply-To: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> Message-ID: I belive live555 don' t support yet h264/SVC :( look from openSVC with there modified MP4box for SVC, you can hint the SVC.264 in a standard MP4 cointainer wich "H264VideoStreamFarmer" can use. From: sergey.kosov at project-10.de To: live-devel at ns.live555.com Date: Wed, 6 Jul 2011 02:25:57 +0200 Subject: Re: [Live-devel] SVC -> AVC >>I wonder how to extract an AVC flow from the SVC file, using live555 >>library. Should it be a filter? > I'm not sure what a "SVC file" is, but it it's the same as a ".264" file > - i.e., a sequence of H.264 NAL units, each preceded by 0x00000001 - > then you may be able to use "H264VideoStreamFramer" (or perhaps a slight > modification of this). > > -- Ross FinlaysonLive Networks, Inc. > http://www.live555.com/ Thats right. I mean that SVC stream is a container with up to 9 layers (3 temporal and 3 spacial), where each layer could be represented as an AVC stream. It is possible to extract the needed layer with i.e. ?svcext library?. But I want to do that with the help of live555. Processing SVC stream with "H264VideoStreamFramer" produces a .ts file with spacial layer equal to 0 and temporal layer also equal to 0. And my question was about extracting a user-defined layer to save it in a .ts file. I use as an example testH264VideoStreamer application from the original library package. _______________________________________________ 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 nouri at soroush.net Wed Jul 6 01:45:55 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Wed, 6 Jul 2011 13:15:55 +0430 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: Thank you. But I think there is a bug in this version, I can't use trick play on any of the previously indexed files. I have three different version, live.2011.03.14.tar.gz works fine, but live.2011.06.16.tar.gz and live.2011.07.05.tar.gz have this problem. Have I missed anything? On Wed, Jul 6, 2011 at 12:26 AM, Ross Finlayson wrote: > ** > FYI, I have now installed a new version (2011.07.05) of the "LIVE555 > Streaming Media" code that better handles this situation - indexing a file > where the PCR timestamp suddenly decreases in value. > ** > > -- > > ** > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 6 02:03:24 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Jul 2011 02:03:24 -0700 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: >Thank you. > >But I think there is a bug in this version, I can't use trick play >on any of the previously indexed files. >I have three different version, live.2011.03.14.tar.gz works fine, >but live.2011.06.16.tar.gz and live.2011.07.05.tar.gz have this >problem. >Have I missed anything? Yes, what you have missed is a description of a specific example of a 'trick play' operation that succeeds for you in version 2011.03.14, but fails in version 2011.07.05. In particular, please point us at an example ".ts" file for which either: 1/ "MPEG2TransportStreamIndexer" produces a different ".tsx" file in each version of the code, or 2/ "testMPEG2TransportStreamTrickPlay" (with appropriate command-line options) generates a different output file in each version of the code. (See for a description of how to use "testMPEG2TransportStreamTrickPlay".) If you can't demonstrate either 1/ or 2/, then I'm not going to be able to help you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 6 02:12:18 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Jul 2011 02:12:18 -0700 Subject: [Live-devel] wis-streamer RTSP over HTTP In-Reply-To: <20110705114410.21fdb0f101ed1e75ea8ae5d43a76b79a.568b3aad87.wbe@email11.se cureserver.net> References: <20110705114410.21fdb0f101ed1e75ea8ae5d43a76b79a.568b3aad87.wbe@email11.se cureserver.net> Message-ID: >Hello, I have a camera with a modified version of wis-streamer and >wanted to know whether wis-streamer supported RTSP over HTTP. I've >tried connecting to the ports it streams on with telnet and it >doesnt seem to respond to HTTP requests. Although it streams fine >and responds to describe requests. How does live implement RTSP over >HTTP? RTSP-over-HTTP is implemented, but is not enabled in our RTSP servers 'by default'. Instead, you have to enable this functionality, by calling RTSPServer::setUpTunnelingOverHTTP() on your RTSP server, specifying a port number for RTSP-over-HTTP (which must be different from the port number used for regular RTSP-over-TCP). See, for example, the code at the end of "mediaServer/live555MediaServer.cpp" You could easily add code like this to "wis-streamer", if you wished. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From nouri at soroush.net Wed Jul 6 02:55:51 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Wed, 6 Jul 2011 14:25:51 +0430 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: I uploaded a sample ts and produced outputs with testMPEG2TransportStreamTrickPlay at http://dl.dropbox.com/u/7920298/sample.tar.gz The index files seem to be identical. I compiled them on two different machines (linux 32b and 64b), with the same results. I ran the command testMPEG2TransportStreamTrickPlay r3.ts 0 2 out.ts On Wed, Jul 6, 2011 at 1:33 PM, Ross Finlayson wrote: > ** > > Thank you. > > But I think there is a bug in this version, I can't use trick play on any > of the previously indexed files. > > I have three different version, live.2011.03.14.tar.gz works fine, > but live.2011.06.16.tar.gz and live.2011.07.05.tar.gz have this problem. > > Have I missed anything? > > > Yes, what you have missed is a description of a specific example of a > 'trick play' operation that succeeds for you in version 2011.03.14, but > fails in version 2011.07.05. > > In particular, please point us at an example ".ts" file for which either: > 1/ "MPEG2TransportStreamIndexer" produces a different ".tsx" file in each > version of the code, or > 2/ "testMPEG2TransportStreamTrickPlay" (with appropriate command-line > options) generates a different output file in each version of the code. > (See > for a description of how to use "testMPEG2TransportStreamTrickPlay".) > > If you can't demonstrate either 1/ or 2/, then I'm not going to be able to > help you. > ** > > -- > > ** > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 6 03:08:57 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Jul 2011 03:08:57 -0700 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: >I uploaded a sample ts and produced outputs >with testMPEG2TransportStreamTrickPlay at > >http://dl.dropbox.com/u/7920298/sample.tar.gz >The index files seem to be identical. >I compiled them on two different machines (linux 32b and 64b), with >the same results. >I ran the command testMPEG2TransportStreamTrickPlay r3.ts 0 2 out.ts OK, thanks. I'm tracking this down now... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at awright2009.com Wed Jul 6 09:02:25 2011 From: admin at awright2009.com (admin at awright2009.com) Date: Wed, 06 Jul 2011 09:02:25 -0700 Subject: [Live-devel] wis-streamer RTSP over HTTP Message-ID: <20110706090225.21fdb0f101ed1e75ea8ae5d43a76b79a.0a9443992c.wbe@email11.secureserver.net> Alright, I've updated to the latest version of live555 and added the function calls, but am running into some odd linking problems. I can see the function definitions in the code, but the linker doesnt. If anyone could give me some insight I'd appreciate it. It's most likely a makefile issue on my end. -Thanks Alex Wright -----------------------------compiler output------------------- /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-g++ -I . -I../BasicUsageEnvironment/include -I../UsageEnvironment/include -I../groupsock/include -I../liveMedia/include -I/home/awright/ipnc_26/ipnc/ipnc_app/interface/inc -D_LINUX -g -Wall -O3 -o wis-streamer wis-streamer.o Err.o APPROInput.o WISServerMediaSubsession.o WISJPEGStreamSource.o WISJPEGVideoServerMediaSubsession.o WISMPEG4VideoServerMediaSubsession.o WISH264VideoServerMediaSubsession.o WISPCMAudioServerMediaSubsession.o /home/awright/ipnc_26/ipnc/ipnc_app/interface/lib/Appro_interface.a /home/awright/ipnc_26/ipnc/dvsdk_2_10_01_18/linuxutils_2_24_03/packages/ti/sdo/linuxutils/cmem/lib/cmem.a470MV -L../BasicUsageEnvironment -lBasicUsageEnvironment -L../UsageEnvironment -lUsageEnvironment -L../groupsock -lgroupsock -L../liveMedia -lliveMedia ../groupsock/libgroupsock.a(Groupsock.o): In function `getSocketTable(UsageEnvironment&)': Groupsock.cpp:(.text+0xf0): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetInterface.o): In function `SocketLookupTable::SocketLookupTable()': NetInterface.cpp:(.text+0x428): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetInterface.o): In function `SocketLookupTable::SocketLookupTable()': NetInterface.cpp:(.text+0x450): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetInterface.o): In function `DirectedNetInterfaceSet::DirectedNetInterfaceSet()': NetInterface.cpp:(.text+0x478): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetInterface.o): In function `DirectedNetInterfaceSet::DirectedNetInterfaceSet()': NetInterface.cpp:(.text+0x4a0): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetInterface.o): In function `DirectedNetInterfaceSet::Iterator::Iterator(DirectedNetInterfaceSet&)': NetInterface.cpp:(.text+0x6e0): undefined reference to `HashTable::Iterator::create(HashTable&)' ../groupsock/libgroupsock.a(NetInterface.o): In function `DirectedNetInterfaceSet::Iterator::Iterator(DirectedNetInterfaceSet&)': NetInterface.cpp:(.text+0x708): undefined reference to `HashTable::Iterator::create(HashTable&)' ../groupsock/libgroupsock.a(NetAddress.o): In function `AddressPortLookupTable::Iterator::Iterator(AddressPortLookupTable&)': NetAddress.cpp:(.text+0x268): undefined reference to `HashTable::Iterator::create(HashTable&)' ../groupsock/libgroupsock.a(NetAddress.o): In function `AddressPortLookupTable::Iterator::Iterator(AddressPortLookupTable&)': NetAddress.cpp:(.text+0x290): undefined reference to `HashTable::Iterator::create(HashTable&)' ../groupsock/libgroupsock.a(NetAddress.o): In function `AddressPortLookupTable::AddressPortLookupTable()': NetAddress.cpp:(.text+0x2b8): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(NetAddress.o): In function `AddressPortLookupTable::AddressPortLookupTable()': NetAddress.cpp:(.text+0x2e0): undefined reference to `HashTable::create(int)' ../groupsock/libgroupsock.a(GroupEId.o): In function `Scope::assign(unsigned char, char const*)': GroupEId.cpp:(.text+0x84): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(Media.o): In function `MediaLookupTable::MediaLookupTable(UsageEnvironment&)': Media.cpp:(.text+0x24c): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(Media.o): In function `MediaLookupTable::MediaLookupTable(UsageEnvironment&)': Media.cpp:(.text+0x280): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(MPEG4GenericRTPSink.o): In function `MPEG4GenericRTPSink::MPEG4GenericRTPSink(UsageEnvironment&, Groupsock*, unsigned char, unsigned int, char const*, char const*, char const*, unsigned int)': MPEG4GenericRTPSink.cpp:(.text+0x220): undefined reference to `strDup(char const*)' MPEG4GenericRTPSink.cpp:(.text+0x22c): undefined reference to `strDup(char const*)' MPEG4GenericRTPSink.cpp:(.text+0x238): undefined reference to `strDup(char const*)' MPEG4GenericRTPSink.cpp:(.text+0x2bc): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(MPEG4GenericRTPSink.o): In function `MPEG4GenericRTPSink::MPEG4GenericRTPSink(UsageEnvironment&, Groupsock*, unsigned char, unsigned int, char const*, char const*, char const*, unsigned int)': MPEG4GenericRTPSink.cpp:(.text+0x418): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(MPEG4GenericRTPSink.o):MPEG4GenericRTPSink.cpp:(.text+0x424): more undefined references to `strDup(char const*)' follow ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::Iterator::Iterator(RTPTransmissionStatsDB&)': RTPSink.cpp:(.text+0x63c): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::Iterator::Iterator(RTPTransmissionStatsDB&)': RTPSink.cpp:(.text+0x664): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::~RTPTransmissionStatsDB()': RTPSink.cpp:(.text+0x72c): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::~RTPTransmissionStatsDB()': RTPSink.cpp:(.text+0x78c): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::~RTPTransmissionStatsDB()': RTPSink.cpp:(.text+0x7e4): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::RTPTransmissionStatsDB(RTPSink&)': RTPSink.cpp:(.text+0x830): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPTransmissionStatsDB::RTPTransmissionStatsDB(RTPSink&)': RTPSink.cpp:(.text+0x864): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPSink::RTPSink(UsageEnvironment&, Groupsock*, unsigned char, unsigned int, char const*, unsigned int)': RTPSink.cpp:(.text+0xa84): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPSink::RTPSink(UsageEnvironment&, Groupsock*, unsigned char, unsigned int, char const*, unsigned int)': RTPSink.cpp:(.text+0xb90): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTPSink.o): In function `RTPSink::rtpmapLine() const': RTPSink.cpp:(.text+0xd48): undefined reference to `strDup(char const*)' RTPSink.cpp:(.text+0xd60): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTPInterface.o): In function `SocketDescriptor::SocketDescriptor(UsageEnvironment&, int)': RTPInterface.cpp:(.text+0x27c): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTPInterface.o): In function `SocketDescriptor::SocketDescriptor(UsageEnvironment&, int)': RTPInterface.cpp:(.text+0x2b8): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTPInterface.o): In function `socketHashTable(UsageEnvironment&, unsigned int)': RTPInterface.cpp:(.text+0x300): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTCP.o): In function `RTCPInstance::RTCPInstance(UsageEnvironment&, Groupsock*, unsigned int, unsigned char const*, RTPSink*, RTPSource const*, unsigned int)': RTCP.cpp:(.text+0x1624): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTCP.o): In function `RTCPMemberDatabase::reapOldMembers(unsigned int)': RTCP.cpp:(.text+0x17ac): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTCP.o): In function `RTCPInstance::RTCPInstance(UsageEnvironment&, Groupsock*, unsigned int, unsigned char const*, RTPSink*, RTPSource const*, unsigned int)': RTCP.cpp:(.text+0x199c): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `UserAuthenticationDatabase::addUserRecord(char const*, char const*)': RTSPServer.cpp:(.text+0x2b4): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `UserAuthenticationDatabase::UserAuthenticationDatabase(char const*, unsigned int)': RTSPServer.cpp:(.text+0x478): undefined reference to `HashTable::create(int)' RTSPServer.cpp:(.text+0x48c): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `UserAuthenticationDatabase::UserAuthenticationDatabase(char const*, unsigned int)': RTSPServer.cpp:(.text+0x4c4): undefined reference to `HashTable::create(int)' RTSPServer.cpp:(.text+0x4d8): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::ServerMediaSessionIterator::ServerMediaSessionIterator(RTSPServer&)': RTSPServer.cpp:(.text+0x518): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::ServerMediaSessionIterator::ServerMediaSessionIterator(RTSPServer&)': RTSPServer.cpp:(.text+0x550): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::RTSPClientSession::handleHTTPCmd_TunnelingGET(char const*)': RTSPServer.cpp:(.text+0x5b4): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::RTSPClientSession::authenticationOK(char const*, char const*, char const*, char const*)': RTSPServer.cpp:(.text+0x6d0): undefined reference to `strDupSize(char const*)' RTSPServer.cpp:(.text+0x6dc): undefined reference to `strDupSize(char const*)' RTSPServer.cpp:(.text+0x74c): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x978): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x9b0): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x9e8): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0xa0c): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTSPServer.o):RTSPServer.cpp:(.text+0x19ec): more undefined references to `strDup(char const*)' follow ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::RTSPClientSession::handleCmd_SETUP(char const*, char const*, char const*, char const*)': RTSPServer.cpp:(.text+0x2a50): undefined reference to `strDupSize(char const*)' RTSPServer.cpp:(.text+0x2cd4): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x2ce4): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x2da0): undefined reference to `strDup(char const*)' RTSPServer.cpp:(.text+0x2f38): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::RTSPServer(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int)': RTSPServer.cpp:(.text+0x35a4): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::RTSPServer(UsageEnvironment&, int, Port, UserAuthenticationDatabase*, unsigned int)': RTSPServer.cpp:(.text+0x36d4): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::~RTSPServer()': RTSPServer.cpp:(.text+0x37d0): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::~RTSPServer()': RTSPServer.cpp:(.text+0x39fc): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTSPServer.o): In function `RTSPServer::~RTSPServer()': RTSPServer.cpp:(.text+0x3c28): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(ServerMediaSession.o): In function `ServerMediaSubsession::rangeSDPLine() const': ServerMediaSession.cpp:(.text+0x35c): undefined reference to `strDup(char const*)' ServerMediaSession.cpp:(.text+0x390): undefined reference to `strDup(char const*)' ServerMediaSession.cpp:(.text+0x3bc): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(ServerMediaSession.o): In function `ServerMediaSubsession::trackId()': ServerMediaSession.cpp:(.text+0x414): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(ServerMediaSession.o): In function `ServerMediaSession::generateSDPDescription()': ServerMediaSession.cpp:(.text+0x7a4): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(ServerMediaSession.o):ServerMediaSession.cpp:(.text+0x8a0): more undefined references to `strDup(char const*)' follow ../liveMedia/libliveMedia.a(OnDemandServerMediaSubsession.o): In function `OnDemandServerMediaSubsession::~OnDemandServerMediaSubsession()': OnDemandServerMediaSubsession.cpp:(.text+0x738): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(OnDemandServerMediaSubsession.o): In function `OnDemandServerMediaSubsession::~OnDemandServerMediaSubsession()': OnDemandServerMediaSubsession.cpp:(.text+0x7c4): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(OnDemandServerMediaSubsession.o): In function `OnDemandServerMediaSubsession::~OnDemandServerMediaSubsession()': OnDemandServerMediaSubsession.cpp:(.text+0x848): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(OnDemandServerMediaSubsession.o): In function `OnDemandServerMediaSubsession::OnDemandServerMediaSubsession(UsageEnvironment&, unsigned int, unsigned short)': OnDemandServerMediaSubsession.cpp:(.text+0x8d0): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(OnDemandServerMediaSubsession.o): In function `OnDemandServerMediaSubsession::OnDemandServerMediaSubsession(UsageEnvironment&, unsigned int, unsigned short)': OnDemandServerMediaSubsession.cpp:(.text+0x940): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(DigestAuthentication.o): In function `Authenticator::assignUsernameAndPassword(char const*, char const*, unsigned int)': DigestAuthentication.cpp:(.text+0x14): undefined reference to `strDup(char const*)' DigestAuthentication.cpp:(.text+0x20): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(DigestAuthentication.o): In function `Authenticator::assignRealmAndNonce(char const*, char const*)': DigestAuthentication.cpp:(.text+0x44): undefined reference to `strDup(char const*)' DigestAuthentication.cpp:(.text+0x50): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(Base64.o): In function `base64Decode(char*, unsigned int&, unsigned int)': Base64.cpp:(.text+0x258): undefined reference to `strDupSize(char const*)' ../liveMedia/libliveMedia.a(Locale.o): In function `Locale::Locale(char const*, int)': Locale.cpp:(.text+0xf0): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(Locale.o): In function `Locale::Locale(char const*, int)': Locale.cpp:(.text+0x138): undefined reference to `strDup(char const*)' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::Iterator::Iterator(RTPReceptionStatsDB&)': RTPSource.cpp:(.text+0x8b0): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::Iterator::Iterator(RTPReceptionStatsDB&)': RTPSource.cpp:(.text+0x8d8): undefined reference to `HashTable::Iterator::create(HashTable&)' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::~RTPReceptionStatsDB()': RTPSource.cpp:(.text+0xa44): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::~RTPReceptionStatsDB()': RTPSource.cpp:(.text+0xaa4): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::~RTPReceptionStatsDB()': RTPSource.cpp:(.text+0xafc): undefined reference to `HashTable::RemoveNext()' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::RTPReceptionStatsDB()': RTPSource.cpp:(.text+0xba4): undefined reference to `HashTable::create(int)' ../liveMedia/libliveMedia.a(RTPSource.o): In function `RTPReceptionStatsDB::RTPReceptionStatsDB()': RTPSource.cpp:(.text+0xbdc): undefined reference to `HashTable::create(int)' collect2: ld returned 1 exit status make: *** [wis-streamer] Error 1 ------------------------------------makefile------------------------------ ROOTDIR = ../../../.. include $(ROOTDIR)/Rules.make LIVE_DIR = .. EXEC = wis-streamer all: $(EXEC) install: $(EXEC) install $(EXEC) $(EXEC_DIR) CC = $(MVTOOL_PREFIX)gcc CPLUSPLUS = $(MVTOOL_PREFIX)g++ INCLUDES = -I . \ -I$(LIVE_DIR)/BasicUsageEnvironment/include \ -I$(LIVE_DIR)/UsageEnvironment/include \ -I$(LIVE_DIR)/groupsock/include \ -I$(LIVE_DIR)/liveMedia/include \ -I$(PUBLIC_INCLUDE_DIR) CFLAGS = $(INCLUDES) -D_LINUX -g -Wall -O3 LIBS = $(CMEM_INSTALL_DIR)/packages/ti/sdo/linuxutils/cmem/lib/cmem.a470MV \ -L$(LIVE_DIR)/BasicUsageEnvironment -lBasicUsageEnvironment \ -L$(LIVE_DIR)/UsageEnvironment -lUsageEnvironment \ -L$(LIVE_DIR)/groupsock -lgroupsock \ -L$(LIVE_DIR)/liveMedia -lliveMedia OBJS = wis-streamer.o Err.o APPROInput.o \ WISServerMediaSubsession.o \ WISJPEGStreamSource.o \ WISJPEGVideoServerMediaSubsession.o \ WISMPEG4VideoServerMediaSubsession.o \ WISH264VideoServerMediaSubsession.o \ WISPCMAudioServerMediaSubsession.o \ $(APP_LIB_DIR)/Appro_interface.a $(EXEC): $(OBJS) $(CPLUSPLUS) $(CFLAGS) -o $(EXEC) $(OBJS) $(LIBS) wis-streamer.cpp: Err.hh Err.cpp: Err.hh APPROInput.cpp: APPROInput.hh Err.hh WISServerMediaSubsession.cpp: WISServerMediaSubsession.hh WISServerMediaSubsession.hh: APPROInput.hh WISMPEG4VideoServerMediaSubsession.hh: WISServerMediaSubsession.hh WISMPEG4VideoServerMediaSubsession.cpp: WISMPEG4VideoServerMediaSubsession.hh WISH264VideoServerMediaSubsession.hh: WISServerMediaSubsession.hh WISH264VideoServerMediaSubsession.cpp: WISH264VideoServerMediaSubsession.hh WISJPEGStreamSource.cpp: WISJPEGStreamSource.hh WISPCMAudioServerMediaSubsession.cpp: WISPCMAudioServerMediaSubsession.hh .c.o: $(CC) -c $(CFLAGS) $< -o $@ .cpp.o: $(CPLUSPLUS) -c $(CFLAGS) $< -o $@ clean: rm -f *.o *~ rm -f $(EXEC) From finlayson at live555.com Wed Jul 6 12:35:59 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Jul 2011 12:35:59 -0700 Subject: [Live-devel] Indexing a recorded stream In-Reply-To: References: Message-ID: OK, I've now found and fixed the problem, and installed a new version (2011.07.06) of the "LIVE555 Streaming Media" code. Transport Stream 'trick play' works once again. The problem was caused by the change that we made to "ByteStreamFileSource" back in version 2011.06.12. Unfortunately, reading from a file using "read()" (rather than "fread()") doesn't work properly if we're also seeking within the file (as we are doing to the index file when doing Transport Stream 'trick play' operations). We now use "read()" only if we know that the underlying file is non-seekable (e.g., a pipe). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Wed Jul 6 23:12:06 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 7 Jul 2011 08:12:06 +0200 Subject: [Live-devel] TCP ZeroWindow openRTSP with RTsP over TCP Message-ID: Hi, I try to get .avi from VIS-streamer-device with openRTSP-Client. My problem is that I get one image and than I see in wireshark that the client send TCP ZeroWindow. If the images are smaller about 15 KB than it works fine.I tried to increase socket-buffer, but it didn't work for me. Additional information: 1. I run openRTSP on Mac OS X Snow Leopard. 2. Here is my command line input: ./openRTSP -i -t rtsp://193.158.57.66:8555/mjpeg > zeroWindow.avi 3. The images are about 60 KB! 4. I am behind WLAN-Router. Has somebody any ideas, how can I get an avi? Regards, Dmitrij From d.velkin at ids-imaging.de Wed Jul 6 23:13:20 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 7 Jul 2011 08:13:20 +0200 Subject: [Live-devel] TCP ZeroWindow openRTSP with RTsP over TCP Message-ID: Hi, I try to get .avi from VIS-streamer-device with openRTSP-Client. My problem is that I get one image and than I see in wireshark that the client send TCP ZeroWindow. If the images are smaller about 15 KB than it works fine.I tried to increase socket-buffer, but it didn't work for me. Additional information: 1. I run openRTSP on Mac OS X Snow Leopard. 2. Here is my command line input: ./openRTSP -i -t rtsp://193.158.57.66:8555/mjpeg > zeroWindow.avi 3. The images are about 60 KB! 4. I am behind WLAN-Router. Has somebody any ideas, how can I get an avi? Regards, Dmitrij From finlayson at live555.com Thu Jul 7 00:10:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Jul 2011 00:10:07 -0700 Subject: [Live-devel] TCP ZeroWindow openRTSP with RTsP over TCP In-Reply-To: References: Message-ID: >I try to get .avi from VIS-streamer-device with openRTSP-Client. >My problem is that I get one image and than I see in wireshark that >the client send TCP ZeroWindow. This is simply the receiver's operating system's way of telling the sender - using the TCP protocol - that it can't handle incoming data at this rate. I.e., you're trying to stream too much data over the network. >If the images are smaller about 15 KB than it works fine. There's your solution. Alternatively, reduce your encoder's frame rate. But even better: Don't use JPEG for streaming video! JPEG is a *terrible* codec for streaming. Instead, use H.264, MPEG-4, or even MPEG-1 or 2. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From exherb at 4leaf.me Thu Jul 7 00:43:25 2011 From: exherb at 4leaf.me (He Lion) Date: Thu, 7 Jul 2011 15:43:25 +0800 Subject: [Live-devel] streaming *.aac or *.h264 using live555 but android media player can't play. Message-ID: Hi, everyone: I am using live555 to stream *.acc and *.264 files to android devices, VLC mac can play those streams normally, but android media player can't play those streams. I can't figure out why... Is there anyone could help me here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 7 01:14:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Jul 2011 01:14:45 -0700 Subject: [Live-devel] streaming *.aac or *.h264 using live555 but android media player can't play. In-Reply-To: References: Message-ID: > I am using live555 to stream *.acc and *.264 files to android >devices, VLC mac can play those streams normally, but android media >player can't play those streams. I can't figure out why... > Is there anyone could help me here? Are you sure that 'Android Media Player' even supports the RTSP/RTP protocol? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ashwani.grps at gmail.com Thu Jul 7 04:47:28 2011 From: ashwani.grps at gmail.com (Ashwani Kathuria) Date: Thu, 7 Jul 2011 17:17:28 +0530 Subject: [Live-devel] how to schedule function using scheduleDelayedTask() Message-ID: Hi, I did some modification in code for live streaming. Now I want the getNextFrame to be scheduled with a delay (of frame duration). So in function, *MultiFramedRTPSink::packFrame()* What modifications I should do in code in order to call *fSource->getNextFrame function()* using *envir().taskScheduler().scheduleDelayedTask()* Regards, Ashwani -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 7 09:49:40 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Jul 2011 09:49:40 -0700 Subject: [Live-devel] how to schedule function using scheduleDelayedTask() In-Reply-To: References: Message-ID: >I did some modification in code for live streaming. Now I want the >getNextFrame to be scheduled with a delay (of frame duration). >So in function, MultiFramedRTPSink::packFrame() >What modifications I should do in code in order to call >fSource->getNextFrame function() >using >envir().taskScheduler().scheduleDelayedTask() Why do you think that you need to modify the supplied library code? You don't modify the code of other source code libraries that you use (e.g., "libc"), do you? (This is explained in the FAQ, which also explains why serious professionals do not use "@gmail.com" email addresses :-) The duration between each outgoing frame is determined by the value of "fDurationInMicroseconds" that you set in whatever upstream object gets fed to your "MultiFramedRTPSink" subclass. (The "MultiFramedRTPSink" class (as is!) then works out the appropriate delay between each outgoing frame.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at awright2009.com Thu Jul 7 12:54:40 2011 From: admin at awright2009.com (admin at awright2009.com) Date: Thu, 07 Jul 2011 12:54:40 -0700 Subject: [Live-devel] wis-streamer RTSP over HTTP Message-ID: <20110707125440.21fdb0f101ed1e75ea8ae5d43a76b79a.0e35575cd9.wbe@email11.secureserver.net> Seemed to be some sort of circular linking dependency. Relinking all of the libraries a second time fixed the issue. Thanks for the help! I was surprised at how easy live555 was to cross compile for arm, everything just worked. -Thanks Alex Wright From ashwani.grps at gmail.com Thu Jul 7 21:13:37 2011 From: ashwani.grps at gmail.com (Ashwani Kathuria) Date: Fri, 8 Jul 2011 09:43:37 +0530 Subject: [Live-devel] how to schedule function using scheduleDelayedTask() In-Reply-To: References: Message-ID: It's true that MultiFramedRTPSink class already provide this feature of adding delay. But what we wanted was the optimization over that. With MultiFramedRTPSink::sendPacketIfNecessary function delay was added before sending packet over the network. As we are working on live(real time) transmission so what we want is: - send the data (media frames) over network as soon as they are available. However scheduleDelayedTask in MultiFramedRTPSink::sendPacketIfNecessary prevents this unless fDurationInMicroseconds = 0 - After sending frame we want RTP to check for new frame (in shared buffer) only when it is expected (else wait in delay queue) i.e. after fDurationInMicroseconds. So we want to shift that scheduleDelayedTask from "sendPacketIfNecessary" to "packFrame" Hence optimization suggested is: Shift the scheduleDelayedTask from "sendPacketIfNecessary" to "packFrame" with taskFunction set to GetNextFrame(). With this optimization packets will reach earlier at peer by fDurationInMicroseconds. Regards, Ashwani Kathuria On Thu, Jul 7, 2011 at 10:19 PM, Ross Finlayson wrote: > ** > > I did some modification in code for live streaming. Now I want the > getNextFrame to be scheduled with a delay (of frame duration). > > So in function,* MultiFramedRTPSink::packFrame()* > > What modifications I should do in code in order to call > > *fSource->getNextFrame function()* > > using > > *envir().taskScheduler().scheduleDelayedTask()* > > > Why do you think that you need to modify the supplied library code? You > don't modify the code of other source code libraries that you use (e.g., > "libc"), do you? > > (This is explained in the FAQ, which also explains why serious > professionals do not use "@gmail.com" email addresses :-) > > The duration between each outgoing frame is determined by the value of > "fDurationInMicroseconds" that you set in whatever upstream object gets fed > to your "MultiFramedRTPSink" subclass. (The "MultiFramedRTPSink" class (as > is!) then works out the appropriate delay between each outgoing frame.) > ** > > -- > > ** > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 7 21:23:30 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Jul 2011 21:23:30 -0700 Subject: [Live-devel] how to schedule function using scheduleDelayedTask() In-Reply-To: References: Message-ID: >It's true that MultiFramedRTPSink class already provide this feature >of adding delay. But what we wanted was the optimization over that. > >With MultiFramedRTPSink::sendPacketIfNecessary function delay was >added before sending packet over the network. >As we are working on live(real time) transmission so what we want is: >- send the data (media frames) over network as soon as they are >available. However scheduleDelayedTask in >MultiFramedRTPSink::sendPacketIfNecessary prevents this unless >fDurationInMicroseconds = 0 Well then, set "fDurationInMicroseconds" to 0 in your upstream object. (Or alternatively, don't set at all in your upstream object, in which case it will retain its default value of 0.) Once again, you don't need to change the "MultiFramedRTPSink" code *at all*. This will be my (and your) last posting on this topic. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 8 01:48:46 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Jul 2011 01:48:46 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: >Yes, the server code needs to be checking for the "Content-length" >header, if present (which it will be for "GET_PARAMETER" and >"SET_PARAMETER"). A fix will be coming... FYI, I have now installed a new version (2011.07.08) of the "LIVE555 Streaming Media" code that should fix this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From hebrew878 at gmail.com Fri Jul 8 02:09:35 2011 From: hebrew878 at gmail.com (Tere Bin) Date: Fri, 8 Jul 2011 14:39:35 +0530 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: can u install live555 on my server? ssh login details i can give you.. or a TeamViewer demonstration that is aprreciated. plz help a nOOb :p On 7/8/11, Ross Finlayson wrote: >>Yes, the server code needs to be checking for the "Content-length" >>header, if present (which it will be for "GET_PARAMETER" and >>"SET_PARAMETER"). A fix will be coming... > > FYI, I have now installed a new version (2011.07.08) of the "LIVE555 > Streaming Media" code that should fix this. > -- > > 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 > From finlayson at live555.com Fri Jul 8 02:25:32 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Jul 2011 02:25:32 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: >can u install live555 on my server? For instructions on how to build our software, see http://www.live555.com/liveMedia/ >plz help a nOOb :p Sorry, but this software is not for "nOOb"s. (And in the future, please use a proper "Subject:" line for your emails.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sergey.kosov at project-10.de Sun Jul 10 16:18:03 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Mon, 11 Jul 2011 01:18:03 +0200 Subject: [Live-devel] SVC -> AVC In-Reply-To: References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> Message-ID: <000001cc3f57$9e7da200$db78e600$@project-10.de> I have tried to rewrite H264VideoStreamFarmer with H264VideoStreamParcer to SVCVideoStreamFarmer with SVCVideoStreamParcer correspondingly. Especially I put attention to the parse() function. The problem I met now is that the parse() function stucks, when some of the input packets should be ignored. I use "svcext" library to analyze the H264 packets. Since there are till 9 AVC flows in one SVC, I have to skip some redundant packets, but when I try to skip them in the parse function it just stucks. Could you, please, help me with explaining how should I process the data in that case. I attach the class files to this letter. Maybe you also find them useful to include in your library in the future to add the support of SVC streams. Thanks in advance. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Joao Almeida Sent: Wednesday, July 06, 2011 9:36 AM To: live-devel at ns.live555.com Subject: Re: [Live-devel] SVC -> AVC I belive live555 don' t support yet h264/SVC :( look from openSVC with there modified MP4box for SVC, you can hint the SVC.264 in a standard MP4 cointainer wich "H264VideoStreamFarmer" can use. _____ From: sergey.kosov at project-10.de To: live-devel at ns.live555.com Date: Wed, 6 Jul 2011 02:25:57 +0200 Subject: Re: [Live-devel] SVC -> AVC >>I wonder how to extract an AVC flow from the SVC file, using live555 >>library. Should it be a filter? > I'm not sure what a "SVC file" is, but it it's the same as a ".264" file > - i.e., a sequence of H.264 NAL units, each preceded by 0x00000001 - > then you may be able to use "H264VideoStreamFramer" (or perhaps a slight > modification of this). > > -- Ross FinlaysonLive Networks, Inc. > http://www.live555.com/ Thats right. I mean that SVC stream is a container with up to 9 layers (3 temporal and 3 spacial), where each layer could be represented as an AVC stream. It is possible to extract the needed layer with i.e. "svcext library". But I want to do that with the help of live555. Processing SVC stream with "H264VideoStreamFramer" produces a .ts file with spacial layer equal to 0 and temporal layer also equal to 0. And my question was about extracting a user-defined layer to save it in a .ts file. I use as an example testH264VideoStreamer application from the original library package. _______________________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SVCVideoStreamFramer.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SVCVideoStreamFramer.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SVCVideoStreamParser.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SVCVideoStreamParser.h URL: From ken at starseedsoft.com Sun Jul 10 20:07:23 2011 From: ken at starseedsoft.com (ken at starseedsoft.com) Date: Sun, 10 Jul 2011 20:07:23 -0700 (PDT) Subject: [Live-devel] H264VideoStreamDiscreteFramer and PPS , SPS Message-ID: <1310353643.32028.YahooMailClassic@web1205.biz.mail.gq1.yahoo.com> Thanks for this wonderful framework, I am very impressed. ?I am new to RTP, please forgive my ignorance. I am following the FAQ item in order to use live555 with an encoder that delivers 'full frames'.I am basing my new app on "testH264VideoStreamer" and have created a "FramedSource" overrides that delivers full frames, per "DeviceSource.cpp/.h"Instead of using an instance of "H264VideoStreamFramer" i am using H264VideoStreamDicreteFramer, since the??"FramedSource" override delivers full frames.I have a single hard-coded frame from my encoder hard-coded inside my?"FramedSource" override, which it is delivering repeatedly. What i see inside "H264VideoStreamDicreteFramer" is that it expects an 8-byte NAL header in order to do its 'aftergetting'. ?I don't think my raw frame will have this NAL header, so i guess that i can eliminate this code in an override that i will implement. ?But, I guess that i would need to provide SPS and PPS into the RTP stream, is there a simple way to construct these? Also, is there a simple (small) H.264 encoded single frame available? ?I tried to strip one out of ?"tc10.264" but I am managing to crash VLC and Apple's quicktime player when i try to stream this single frame repeatedly.... thanks for the assistance. /K -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 10 21:08:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 10 Jul 2011 21:08:08 -0700 Subject: [Live-devel] H264VideoStreamDiscreteFramer and PPS , SPS In-Reply-To: <1310353643.32028.YahooMailClassic@web1205.biz.mail.gq1.yahoo.com> References: <1310353643.32028.YahooMailClassic@web1205.biz.mail.gq1.yahoo.com> Message-ID: >I am following the FAQ item in order to use live555 with an encoder >that delivers 'full frames'. >I am basing my new app on "testH264VideoStreamer" and have created a >"FramedSource" overrides that delivers full frames, per >"DeviceSource.cpp/.h" >Instead of using an instance of "H264VideoStreamFramer" i am using >H264VideoStreamDicreteFramer, since the "FramedSource" override >delivers full frames. Correct. >What i see inside "H264VideoStreamDicreteFramer" is that it expects >an 8-byte NAL header in order to do its 'aftergetting'. No it doesn't. I'm not sure why you would think this. > I don't think my raw frame will have this NAL header, so i guess >that i can eliminate this code in an override that i will implement. No, as long as your NAL units are generated properly (by your encoder), you should not need to modify the "H264VideoStreamDiscreteFramer" code at all. (Note, in particular, that your NAL units - from your encoder - should *not* begin with 0x00000001 or 0x000001.) > But, I guess that i would need to provide SPS and PPS into the RTP >stream, is there a simple way to construct these? They should be generated automatically (and perhaps periodically) by your encoder. Our code automatically notices these special NAL units when they appear. (Note lines 69 and 71 of "H264VideoStreamDiscreteFramer.cpp".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jul 10 22:48:16 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 10 Jul 2011 22:48:16 -0700 Subject: [Live-devel] SVC -> AVC In-Reply-To: <000001cc3f57$9e7da200$db78e600$@project-10.de> References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> Message-ID: >I have tried to rewrite H264VideoStreamFarmer with >H264VideoStreamParcer to SVCVideoStreamFarmer with >SVCVideoStreamParcer correspondingly. Especially I put attention to >the parse() function. The problem I met now is that the parse() >function stucks, when some of the input packets should be ignored. > >I use "svcext" library to analyze the H264 packets. Since there are >till 9 AVC flows in one SVC, I have to skip some redundant packets, >but when I try to skip them in the parse function it just stucks. >Could you, please, help me with explaining how should I process the >data in that case. I haven't yet had time to look at your code in detail, but (if you're not already doing so), you should skip redundant NAL units by calling "skipBytes()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sokratis.barmpounakis at unige.ch Mon Jul 11 01:42:31 2011 From: sokratis.barmpounakis at unige.ch (Sokratis Barmpounakis) Date: Mon, 11 Jul 2011 10:42:31 +0200 Subject: [Live-devel] TestH264VideoStreamer lags in VLC Message-ID: When using TestH264VideoStreamer to stream a h264 raw file of 23 seconds length, the length in the client's VLC side lasts for about 2 mins (really "laggy"), maybe a little bit more. Does this have to do only with the encoding parameters (SPS,PPS etc) , or is there something I can set something also in the streamer? Thanks, Sokratis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 11 02:33:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Jul 2011 02:33:38 -0700 Subject: [Live-devel] TestH264VideoStreamer lags in VLC In-Reply-To: References: Message-ID: >When using TestH264VideoStreamer to stream a h264 raw file of 23 >seconds length, the length in the client's VLC side lasts for about >2 mins (really "laggy"), maybe a little bit more. Does this have to >do only with the encoding parameters (SPS,PPS etc) , or is there >something I can set something also in the streamer? http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ken at starseedsoft.com Mon Jul 11 08:24:54 2011 From: ken at starseedsoft.com (ken at starseedsoft.com) Date: Mon, 11 Jul 2011 08:24:54 -0700 (PDT) Subject: [Live-devel] H264VideoStreamDiscreteFramer and PPS , SPS Message-ID: <1310397894.51067.YahooMailClassic@web1203.biz.mail.gq1.yahoo.com> >> What i see inside "H264VideoStreamDicreteFramer" is that it expects an 8-byte NAL header in order to do its 'aftergetting'. >No it doesn't.? I'm not sure why you would think this. >... >Ross Finlayson I thought this out of ignorance of the H.264 encoding process. From lines 69-71 of H264VideoStreamDiscreteFramer.cpp it appeared from the comment "NAL units that..." that somehow the 'encoded frame' had been packet-ized with an 8 bit header. From your response, i gather that the encoder itself places this 8-bit header at the start of the encoded frame. /Ken From matt at schuckmannacres.com Mon Jul 11 08:59:18 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Mon, 11 Jul 2011 08:59:18 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: <4E1B1DD6.3070202@schuckmannacres.com> Thank you, I will test as soon as I can. Matt S. On 7/8/2011 1:48 AM, Ross Finlayson wrote: >> Yes, the server code needs to be checking for the "Content-length" >> header, if present (which it will be for "GET_PARAMETER" and >> "SET_PARAMETER"). A fix will be coming... > > FYI, I have now installed a new version (2011.07.08) of the "LIVE555 > Streaming Media" code that should fix this. From finlayson at live555.com Mon Jul 11 11:03:29 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Jul 2011 11:03:29 -0700 Subject: [Live-devel] H264VideoStreamDiscreteFramer and PPS , SPS In-Reply-To: <1310397894.51067.YahooMailClassic@web1203.biz.mail.gq1.yahoo.com> References: <1310397894.51067.YahooMailClassic@web1203.biz.mail.gq1.yahoo.com> Message-ID: > >> What i see inside "H264VideoStreamDicreteFramer" is that it >expects an 8-byte NAL header in order to do its 'aftergetting'. > >>No it doesn't. I'm not sure why you would think this. >>... >>Ross Finlayson > > I thought this out of ignorance of the H.264 encoding process. >From lines 69-71 of H264VideoStreamDiscreteFramer.cpp it appeared >from the comment "NAL units that..." that somehow the 'encoded >frame' had been packet-ized with an 8 bit header. From your >response, i gather that the encoder itself places this 8-bit header >at the start of the encoded frame. In your first message, you said "8 byte". Now you say "8 bit", which is correct. Yes, the first byte of each encoded H.264 NAL unit contains a "nal unit type" code (in its last 5 bits) - as described by the H.264 specification. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sergey.kosov at project-10.de Mon Jul 11 13:50:55 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Mon, 11 Jul 2011 22:50:55 +0200 Subject: [Live-devel] SVC -> AVC In-Reply-To: References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> Message-ID: <003001cc400c$3b288c00$b179a400$@project-10.de> As I understand, SkipBytes(pBufer, n) just shifting the pointer to input data flow for n. The problem is I have to read the data first to understand if I have to skip it. So firstly I read one NAL block to the buffer "data" (from sequence 00 00 00 01 till the next sequence 00 00 00 01): // assert that we are on position where the NAL unit starts (0x00000001) u_int8_t *data = new u_int8_t[NAL_MAX_SIZE]; int n = 0; for (int i = 0; i < 4; i++) data[n++] = get1Byte(); while (next4Bytes != 0x00000001) { data[n++] = get1Byte(); next4Bytes = test4Bytes(); } Then I analyse it with one function: st_svcext_preview_info_t preview_info; st_svcext_preview(handle, reinterpret_cast(data), &preview_info); And only then, depending on the "preview_info.action" I can decide if the current NAL unit should be skipped or not. As I understood, if the current NAL block should be skipped and I call SkipBytes(n) - than the next n bytes will be skipped ? Or not ? -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, July 11, 2011 7:48 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] SVC -> AVC >I have tried to rewrite H264VideoStreamFarmer with >H264VideoStreamParcer to SVCVideoStreamFarmer with SVCVideoStreamParcer >correspondingly. Especially I put attention to the parse() function. >The problem I met now is that the parse() function stucks, when some of >the input packets should be ignored. > >I use "svcext" library to analyze the H264 packets. Since there are >till 9 AVC flows in one SVC, I have to skip some redundant packets, but >when I try to skip them in the parse function it just stucks. >Could you, please, help me with explaining how should I process the >data in that case. I haven't yet had time to look at your code in detail, but (if you're not already doing so), you should skip redundant NAL units by calling "skipBytes()". -- 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 From finlayson at live555.com Mon Jul 11 14:12:52 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Jul 2011 14:12:52 -0700 Subject: [Live-devel] SVC -> AVC In-Reply-To: <003001cc400c$3b288c00$b179a400$@project-10.de> References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> <003001cc400c$3b288c00$b179a400$@project-10.de> Message-ID: > // assert that we are on position where the NAL unit starts >(0x00000001) > u_int8_t *data = new u_int8_t[NAL_MAX_SIZE]; > int n = 0; > for (int i = 0; i < 4; i++) data[n++] = get1Byte(); > > while (next4Bytes != 0x00000001) { > data[n++] = get1Byte(); >next4Bytes = test4Bytes(); > } > >Then I analyse it with one function: > > st_svcext_preview_info_t preview_info; > st_svcext_preview(handle, reinterpret_cast(data), >&preview_info); > >And only then, depending on the "preview_info.action" I can decide if the >current NAL unit should be skipped or not. >As I understood, if the current NAL block should be skipped and I call >SkipBytes(n) - than the next n bytes will be skipped ? Or not ? No. Because (in your code) you've already read the entire NAL unit (via the calls to "get1Byte()"), you don't call "skipBytes()" at all. Instead, just continue and read/analyze the next NAL unit. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ken at starseedsoft.com Mon Jul 11 14:28:24 2011 From: ken at starseedsoft.com (ken at starseedsoft.com) Date: Mon, 11 Jul 2011 14:28:24 -0700 (PDT) Subject: [Live-devel] H264VideoStreamDiscreteFramer and PPS , SPS In-Reply-To: Message-ID: <1310419704.67095.YahooMailClassic@web1209.biz.mail.gq1.yahoo.com> > >? >> What i see inside > "H264VideoStreamDicreteFramer" is that it expects an 8-byte > NAL header in order to do its 'aftergetting'. > > > >> No it doesn't.? I'm not sure why you would > think this. > >> ... > >> Ross Finlayson > > > >? ? I thought this out of ignorance of the > H.264 encoding process. From lines 69-71 of > H264VideoStreamDiscreteFramer.cpp it appeared from the > comment "NAL units that..." that somehow the 'encoded frame' > had been packet-ized with an 8 bit header.? From your > response, i gather that the encoder itself places this 8-bit > header at the start of the encoded frame. > > In your first message, you said "8 byte".? Now you say > "8 bit", which is correct.? Yes, the first byte of each > encoded H.264 NAL unit contains a "nal unit type" code (in > its last 5 bits) - as described by the H.264 specification. > -- > Ross Finlayson I do apologize, thanks for the correction and clarification. I was unclear that these leading 8-bits were written by the H.264 encoder, I had thought it was added by some other facility, given the name 'network' abstraction layer... /Ken From socbar at gmail.com Mon Jul 11 15:00:10 2011 From: socbar at gmail.com (Sokratis) Date: Tue, 12 Jul 2011 00:00:10 +0200 Subject: [Live-devel] live-devel Digest, Vol 93, Issue 8 In-Reply-To: References: Message-ID: > > > >When using TestH264VideoStreamer to stream a h264 raw file of 23 > >seconds length, the length in the client's VLC side lasts for about > >2 mins (really "laggy"), maybe a little bit more. Does this have to > >do only with the encoding parameters (SPS,PPS etc) , or is there > >something I can set something also in the streamer? > > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Here is an example file : http://www.mediafire.com/?rm6v38vx15nd9dv When I play it with VLC in my computer it plays normally. So I guess, as a encoder output is fine. But when I use for example TestH264VideoStreamer to stream it, what the client (also with VLC) sees is much more slow. It is like viewing 1 fps, although this sequence's frame rate is much higher. Thanks again, Sokratis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 11 17:29:59 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Jul 2011 17:29:59 -0700 Subject: [Live-devel] TestH264VideoStreamer lags in VLC In-Reply-To: References: Message-ID: >Here is an example file : > >http://www.mediafire.com/?rm6v38vx15nd9dv > >When I play it with VLC in my computer it plays normally. So I >guess, as a encoder output is fine. But when I use for example >TestH264VideoStreamer to stream it, what the client (also with VLC) >sees is much more slow. It is like viewing 1 fps, although this >sequence's frame rate is much higher. Actually, "testH264VideoStreamer" thinks that the frame rate is 4 frames-per-second, and is streaming at that rate. However, VLC seems to stream at about 6 times that rate - i.e., at about 24 frames-per-second. So, my question - for H.264 experts - is the following: What is VLC seeing, in this file, that makes it see a frame rate of 24 frames-per-second, or so? Our code ("H264VideoStreamFramer") is seeing num_units_in_tick: 1 time_scale: 8 fixed_frame_rate_flag: 1 and from this is inferring a frame rate of 4 frames-per-second. So how is VLC inferring a much higher frame rate?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbonneau at miranda.com Mon Jul 11 19:14:16 2011 From: gbonneau at miranda.com (BONNEAU Guy) Date: Tue, 12 Jul 2011 02:14:16 +0000 Subject: [Live-devel] TestH264VideoStreamer lags in VLC In-Reply-To: References: Message-ID: <24665DDC0D7CF047BD6471A56E615EA6318123F1@CA-OPS-MAILBOX.miranda.com> Perhaps a bug in VLC..... I tried with Elecard Stream Eye application and it does see 4 frames per second (progressive) in the H264 header and plays at such rate. GB From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, July 11, 2011 20:30 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] TestH264VideoStreamer lags in VLC Here is an example file : http://www.mediafire.com/?rm6v38vx15nd9dv When I play it with VLC in my computer it plays normally. So I guess, as a encoder output is fine. But when I use for example TestH264VideoStreamer to stream it, what the client (also with VLC) sees is much more slow. It is like viewing 1 fps, although this sequence's frame rate is much higher. Actually, "testH264VideoStreamer" thinks that the frame rate is 4 frames-per-second, and is streaming at that rate. However, VLC seems to stream at about 6 times that rate - i.e., at about 24 frames-per-second. So, my question - for H.264 experts - is the following: What is VLC seeing, in this file, that makes it see a frame rate of 24 frames-per-second, or so? Our code ("H264VideoStreamFramer") is seeing num_units_in_tick: 1 time_scale: 8 fixed_frame_rate_flag: 1 and from this is inferring a frame rate of 4 frames-per-second. So how is VLC inferring a much higher frame rate?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From exherb at 4leaf.me Mon Jul 11 19:53:47 2011 From: exherb at 4leaf.me (He Lion) Date: Tue, 12 Jul 2011 10:53:47 +0800 Subject: [Live-devel] streaming *.aac or *.h264 using live555 but android media player can't play. In-Reply-To: References: Message-ID: I'm sure 2011/7/7 Ross Finlayson > I am using live555 to stream *.acc and *.264 files to android devices, >> VLC mac can play those streams normally, but android media player can't play >> those streams. I can't figure out why... >> Is there anyone could help me here? >> > > Are you sure that 'Android Media Player' even supports the RTSP/RTP > protocol? > -- > > 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 Mon Jul 11 21:30:09 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Jul 2011 21:30:09 -0700 Subject: [Live-devel] streaming *.aac or *.h264 using live555 but android media player can't play. In-Reply-To: References: Message-ID: >2011/7/7 Ross Finlayson <finlayson at live555.com> > > I am using live555 to stream *.acc and *.264 files to android >devices, VLC mac can play those streams normally, but android media >player can't play those streams. I can't figure out why... > Is there anyone could help me here? > > >Are you sure that 'Android Media Player' even supports the RTSP/RTP protocol? >-- > >I'm sure > OK, then you'll have to ask an 'Android' mailing list about this, because the 'Android Media Player' is not our software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sokratis.barmpounakis at unige.ch Tue Jul 12 01:12:18 2011 From: sokratis.barmpounakis at unige.ch (Sokratis Barmpounakis) Date: Tue, 12 Jul 2011 10:12:18 +0200 Subject: [Live-devel] live-devel Digest, Vol 93, Issue 9 In-Reply-To: References: Message-ID: > > Message: 4 > Date: Tue, 12 Jul 2011 02:14:16 +0000 > From: BONNEAU Guy > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] TestH264VideoStreamer lags in VLC > Message-ID: > < > 24665DDC0D7CF047BD6471A56E615EA6318123F1 at CA-OPS-MAILBOX.miranda.com> > Content-Type: text/plain; charset="us-ascii" > > Perhaps a bug in VLC..... > > I tried with Elecard Stream Eye application and it does see 4 frames per > second (progressive) in the H264 header and plays at such rate. > > GB > > From: live-devel-bounces at ns.live555.com [mailto: > live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Monday, July 11, 2011 20:30 > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] TestH264VideoStreamer lags in VLC > > Here is an example file : > http://www.mediafire.com/?rm6v38vx15nd9dv > When I play it with VLC in my computer it plays normally. So I guess, as a > encoder output is fine. But when I use for example TestH264VideoStreamer to > stream it, what the client (also with VLC) sees is much more slow. It is > like viewing 1 fps, although this sequence's frame rate is much higher. > > Actually, "testH264VideoStreamer" thinks that the frame rate is 4 > frames-per-second, and is streaming at that rate. However, VLC seems to > stream at about 6 times that rate - i.e., at about 24 frames-per-second. > > So, my question - for H.264 experts - is the following: What is VLC seeing, > in this file, that makes it see a frame rate of 24 frames-per-second, or so? > > Our code ("H264VideoStreamFramer") is seeing > num_units_in_tick: 1 > time_scale: 8 > fixed_frame_rate_flag: 1 > and from this is inferring a frame rate of 4 frames-per-second. So how is > VLC inferring a much higher frame rate?? > > -- > > Ross Finlayson > Thank you both for your feedback. Actually I am setting FPS=4 in the encoder parameters, so it should be 4. Did you try to stream using live555 lib and view it in VLC or did you just open it a disk file? Because as I mentioned, when I run it just a file from disk, it plays normally, without lags or strange frame rates. But when I use the testH264VideoStreamer or the testOnDemandRTSPServer applications, I get this strange behavior. So I assume, it only has to do with the streaming parameters of the encoding (NAL parameters?). I am not really a h264 expert, just making some thoughts. Maybe someone can explain this strange behavior. Thanks once more, Sokratis -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kosov at project-10.de Tue Jul 12 15:15:01 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Wed, 13 Jul 2011 00:15:01 +0200 Subject: [Live-devel] SVC -> AVC In-Reply-To: References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> <003001cc400c$3b288c00$b179a400$@project-10.de> Message-ID: <000001cc40e1$25127e50$6f377af0$@project-10.de> I tried to do as you advised me. When I just continue to read following block, I get the error: "StreamPaercer internal error (149997 + 4) 150000)" I looked the source codes of the StreamPaercer.cpp and as I understand there is limited block of memory from which I could read. I suspect that I have to quit the parse function before reading, or reset this block somehow. Please help me with a piece of advice. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, July 11, 2011 11:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] SVC -> AVC > // assert that we are on position where the NAL unit starts >(0x00000001) > u_int8_t *data = new u_int8_t[NAL_MAX_SIZE]; > int n = 0; > for (int i = 0; i < 4; i++) data[n++] = get1Byte(); > > while (next4Bytes != 0x00000001) { > data[n++] = get1Byte(); >next4Bytes = test4Bytes(); > } > >Then I analyse it with one function: > > st_svcext_preview_info_t preview_info; > st_svcext_preview(handle, reinterpret_cast(data), >&preview_info); > >And only then, depending on the "preview_info.action" I can decide if >the current NAL unit should be skipped or not. >As I understood, if the current NAL block should be skipped and I call >SkipBytes(n) - than the next n bytes will be skipped ? Or not ? No. Because (in your code) you've already read the entire NAL unit (via the calls to "get1Byte()"), you don't call "skipBytes()" at all. Instead, just continue and read/analyze the next NAL unit. -- 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 From finlayson at live555.com Wed Jul 13 02:25:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Jul 2011 02:25:07 -0700 Subject: [Live-devel] SVC -> AVC In-Reply-To: <000001cc40e1$25127e50$6f377af0$@project-10.de> References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> <003001cc400c$3b288c00$b179a400$@project-10.de> <000001cc40e1$25127e50$6f377af0$@project-10.de> Message-ID: >I tried to do as you advised me. When I just continue to read following >block, I get the error: "StreamPaercer internal error (149997 + 4) 150000)" >I looked the source codes of the StreamPaercer.cpp and as I understand there >is limited block of memory from which I could read. >I suspect that I have to quit the parse function before reading, or reset >this block somehow. > >Please help me with a piece of advice. To help me figure out what's wrong, could you please point me at an example 'SVC file' (that illustrates the problem) that I could download and test for myself? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ankur.tyagi85 at gmail.com Wed Jul 13 06:31:50 2011 From: ankur.tyagi85 at gmail.com (Ankur Tyagi) Date: Wed, 13 Jul 2011 19:01:50 +0530 Subject: [Live-devel] Problem with live555MediaServer when working with two ethernet interface In-Reply-To: References: Message-ID: > Hello,**** > > ** ** > > I am trying to setup RTSP server on my Linux machine which has two network > interfaces eth0 and eth1.**** > > ** ** > > _________________**** > > 10.199.131.56 ---->| eth1 eth0|<------- 192.168.0.1 > > | Linux | > > |_________________| > > ** ** > > I have downloaded latest version of live555 and compiled it. When I run the > ?live555MediaServer?, it only identifies eth1. Here is the log : > > ** ** > > LIVE555 Media Server**** > > version 0.67 (LIVE555 Streaming Media library version 2011.06.16). > **** > > Play streams from this server using the URL**** > > rtsp://10.199.131.101/**** > > where is a file present in the current directory.**** > > Each file's type is inferred from its name suffix:**** > > ".264" => a H.264 Video Elementary Stream file**** > > ".aac" => an AAC Audio (ADTS format) file**** > > ".ac3" => an AC-3 Audio file**** > > ".amr" => an AMR Audio file**** > > ".dv" => a DV Video file**** > > ".m4e" => a MPEG-4 Video Elementary Stream file**** > > ".mp3" => a MPEG-1 or 2 Audio file**** > > ".mpg" => a MPEG-1 or 2 Program Stream (audio+video) file**** > > ".ts" => a MPEG Transport Stream file**** > > (a ".tsx" index file - if present - provides server 'trick > play' support)**** > > ".wav" => a WAV Audio file**** > > See http://www.live555.com/mediaServer/ for additional documentation.**** > > (We use port 80 for optional RTSP-over-HTTP tunneling.)**** > > ** ** > > The log from ?route? command : > > ** ** > > Kernel IP routing table**** > > ---------------------------**** > > Destination Gateway Genmask Flags Metric > Ref Use Iface > > 192.168.0.0 * 255.255.255.0 U > 0 0 0 eth0 > > 10.199.131.0 * 255.255.255.0 U > 0 0 0 eth1 > > default 10.199.131.254 0.0.0.0 UG > 0 0 0 eth1 > > ** ** > > I want to setup RTSP server using eth0 as my client is running on subnet > 192.168.0.X.**** > > ** ** > > Can you please help me with this.**** > > ** ** > > Thanks & Regards,**** > > Ankur**** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at awright2009.com Thu Jul 14 09:36:33 2011 From: admin at awright2009.com (admin at awright2009.com) Date: Thu, 14 Jul 2011 09:36:33 -0700 Subject: [Live-devel] MJPEG stream problems Message-ID: <20110714093633.21fdb0f101ed1e75ea8ae5d43a76b79a.c78fe8ba56.wbe@email11.secureserver.net> Hello, after upgrading to the latest live libraries I noticed that both my H264 stream and mjpeg stream stopped working. I'm not sure what previous version of the live555 libraries I was using, but the only code change I needed to make to get things to compile was this: sinkVideo = H264VideoRTPSink::createNew(*env, rtpGroupSockVideo, 96, 0x64001F, BuffStr); becomes: sinkVideo = H264VideoRTPSink::createNew(*env, rtpGroupSockVideo, 96); This seems to change the sprop-parameter-set string, but I have tried hardcoding the previously generated string directly into the constructor of H264RTPSink in the new version, but nothing changed. The mjpeg stream partially works, it displays the first couple MCU's of the stream and green screens the rest. I've tried saving a frame.jpg directly to disk and I can view that the raw jpeg data is correct. Looking through WISJPEGStreamSource.cpp I see that it pulls out the Q table and restart interval and copies data into an fTo data member. I'm sure the Q table is correct because the other blocks are correctly decoded, however I'm not sure if the memcpy or restart interval are correct. The copy does the following: memmove(fTo, &fBuffer[JPEGHeaderSize], fFrameSize); JPEGHeaderSize is arbitrarily set to 0x265 which if I look with a hex editor into a single frame doesnt seem to align with any JPEG FFXX marker. The restart interval is filled by searching for 0xFFDD and placing the two bytes instead of all four into a four byte table as follows: for(i = 0x251; i < JPEGHeaderSize-8; ++i) { if (fBuffer[i] == 0xFF) { if (fBuffer[i+1] == 0xDD) { fLastRestartIntervalTable[0] = fBuffer[i+4]; fLastRestartIntervalTable[1] = fBuffer[i+5]; fLastRestartIntervalTable[2] = 0xFF; fLastRestartIntervalTable[3] = 0xFF; } } } I'm not sure how the data is expected in terms of endianess etc. Both streams worked fine with an slightly older version of live555. I'd appreciate any help you can give me! -Thanks Alex Wright -------------- next part -------------- A non-text attachment was scrubbed... Name: mjpeg.png Type: image/png Size: 58732 bytes Desc: not available URL: From rotema777 at gmail.com Wed Jul 13 23:33:16 2011 From: rotema777 at gmail.com (rotem a) Date: Thu, 14 Jul 2011 06:33:16 +0000 Subject: [Live-devel] BANK_SIZE overflow Message-ID: Hello, I'm using live555 to stream mpeg2 video. In some videos, the program gets aborted with an error message that the BANK_SIZE (at StreamParser.cpp) isn't big enough. I've increased it's size (it was initially 100,000 and increased to 2,000,000). It hasn't solved the problem. any idea what should I do? Rotem -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kosov at project-10.de Thu Jul 14 18:56:03 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Fri, 15 Jul 2011 03:56:03 +0200 Subject: [Live-devel] SVC -> AVC In-Reply-To: References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> <003001cc400c$3b288c00$b179a400$@project-10.de> <000001cc40e1$25127e50$6f377af0$@project-10.de> Message-ID: <000a01cc4292$5a7d20b0$0f776210$@project-10.de> Here is the link to the example SVC file: http://www.project-10.de/Cam1.svc I think it is possible to use setParseState(); function within the skip loop to prevent the overflowing. But I'm not sure it this way the right way. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, July 13, 2011 11:25 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] SVC -> AVC >I tried to do as you advised me. When I just continue to read following >block, I get the error: "StreamPaercer internal error (149997 + 4) 150000)" >I looked the source codes of the StreamPaercer.cpp and as I understand >there is limited block of memory from which I could read. >I suspect that I have to quit the parse function before reading, or >reset this block somehow. > >Please help me with a piece of advice. To help me figure out what's wrong, could you please point me at an example 'SVC file' (that illustrates the problem) that I could download and test for myself? -- 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 From finlayson at live555.com Thu Jul 14 19:38:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Jul 2011 19:38:50 -0700 Subject: [Live-devel] BANK_SIZE overflow In-Reply-To: References: Message-ID: >I'm using live555 to stream mpeg2 video. >In some videos, the program gets aborted with an error message that >the BANK_SIZE (at StreamParser.cpp) isn't big enough. >I've increased it's size (it was initially 100,000 and increased to >2,000,000). >It hasn't solved the problem. > >any idea what should I do? http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 14 23:51:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 14 Jul 2011 23:51:45 -0700 Subject: [Live-devel] MJPEG stream problems In-Reply-To: <20110714093633.21fdb0f101ed1e75ea8ae5d43a76b79a.c78fe8ba56.wbe@email11.se cureserver.net> References: <20110714093633.21fdb0f101ed1e75ea8ae5d43a76b79a.c78fe8ba56.wbe@email11.se cureserver.net> Message-ID: >Hello, after upgrading to the latest live libraries I noticed that both >my H264 stream and mjpeg stream stopped working. I'm not sure what >previous version of the live555 libraries I was using See http://www.live555.com/liveMedia/faq.html#latest-version >, but the only code >change I needed to make to get things to compile was this: > >sinkVideo = H264VideoRTPSink::createNew(*env, rtpGroupSockVideo, 96, >0x64001F, BuffStr); >becomes: >sinkVideo = H264VideoRTPSink::createNew(*env, rtpGroupSockVideo, 96); > >This seems to change the sprop-parameter-set string, but I have tried >hardcoding the previously generated string directly into the constructor >of H264RTPSink in the new version, but nothing changed. The old signature - which took the 'sprop-parameter-set' string as a parameter - was just a short-term hack. Now, the SPS and PPS NAL units are recognized within the input stream, and the 'sprop-parameter-string' is generated automatically from these. This means, of course, that the input stream needs to include SPS and PPS NAL units. It's OK if these occur only once (if so, they should be at the beginning of the stream), but they need to be present. You should *not* need to modify the current "H264VideoRTPSink" code. As for JPEG - the only recent changes to the JPEG code was to add support for 'restart intervals' in the input stream. To support this, your subclass of "JPEGVideoSource()" needs to redefine the "restartInterval()" virtual function. (See "liveMedia/include/JPEGVideoSource.hh".) Note that the "wis-streamer" code did not do this (because it was written for an encoder that does not generate restart intervals), so that code won't be much help to you here. Note that you no longer need to fill in the 'restart marker header' in the outgoing RTP packet; we do that ourselves (in "JPEGVideoRTPSink", which you should *not* need to modify). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 15 12:44:46 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 15 Jul 2011 12:44:46 -0700 Subject: [Live-devel] New LIVE555 version, with two new classes Message-ID: The latest version of the "LIVE555 Streaming Media" code contains two new classes that developers might find useful: 1/ "TCPStreamSink", which encapsulates a writable TCP socket. Being a "MediaSink", you can call "startPlaying()" on it, to stream from a "FramedSource" to a TCP socket. This class could be used to implement a HTTP server, for example, or simply a "nc"-like utility to stream data to a remote location. 2/ "ByteStreamMemoryBufferSource", which encapsulates a (static) memory buffer that's used as a byte stream data source. I.e., you can use a memory buffer as a data source, as if it were a file. (Note, however, that the memory buffer must be static - i.e., unchanging - so you can't use this class to encapsulate an encoder. For that, you would need to write your own class (perhaps based on the "DeviceSource" code).) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jh1097 at gmail.com Fri Jul 15 01:13:42 2011 From: jh1097 at gmail.com (=?EUC-KR?B?sejB38jx?=) Date: Fri, 15 Jul 2011 17:13:42 +0900 Subject: [Live-devel] About Streaming repeatedly Message-ID: Hello~ I'm learning live555 for understanding how to communicate data streaming. I have a couple of things question. For studying and testing, I tried to send a Video clip(mpg File) repeatedly like test program 'testMPEG4VideoStreamer', but it doesn't work well. I thought if there are code about finding EOF of media file and Termination, it can be transfer termination to making new point(using pointer EOF -> first one payload) so, I found below code. In "ByteStreamFileSource.cpp" void ByteStreamFileSource::doGetNextFrame() { if (feof(fFid) || ferror(fFid) || (fLimitNumBytesToStream && fNumBytesToStream == 0)) { handleClosure(this); return; } above code, I changed like this. void ByteStreamFileSource::doGetNextFrame() { if (feof(fFid) || ferror(fFid) || (fLimitNumBytesToStream && fNumBytesToStream == 0)) { SeekFile64(fFid, 0, SEEK_SET); // handleClosure(this); return; } What should I do make code more to work well? Please be understanding, *In* *this* *field*, I *am* *as good as* *a* * beginner*. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kidjan at gmail.com Fri Jul 15 17:52:40 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Fri, 15 Jul 2011 17:52:40 -0700 Subject: [Live-devel] Media File in testProgs Message-ID: pcr-decreasing-test2.ts (a ~3 MB file) is in live/testProgs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Cui at zoran.com Fri Jul 15 18:04:51 2011 From: Larry.Cui at zoran.com (Larry Cui) Date: Sat, 16 Jul 2011 01:04:51 +0000 Subject: [Live-devel] h264 test application problem Message-ID: <96CB13D3010D8946AF14847B4BC8D99687AB46@zcomb2.Zoran.com> Hi, I downloaded the two H264 video files from http://www.live555.com/liveMedia/public/264/ But when I run the testH264VideoStreamer application, the client side VLC player cannot play them well. Also, OpenRTSP can save the steam to a file. But VLC player cannot play this file. I guess the testH264VideoStreamer application cannot insert enough SPS/PPS information into the stream. Anybody knows how to solve this problem> Regards, -Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 16 02:04:35 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Jul 2011 02:04:35 -0700 Subject: [Live-devel] h264 test application problem In-Reply-To: <96CB13D3010D8946AF14847B4BC8D99687AB46@zcomb2.Zoran.com> References: <96CB13D3010D8946AF14847B4BC8D99687AB46@zcomb2.Zoran.com> Message-ID: >I downloaded the two H264 video files from > >http://www.live555.com/liveMedia/public/264/ There are actually three files there, FWIW... >But when I run the testH264VideoStreamer application, the client >side VLC player cannot play them well. Also, OpenRTSP can save the >steam to a file. But VLC player cannot play this file. I guess the >testH264VideoStreamer application cannot insert enough SPS/PPS >information into the stream. We don't insert any SPS/PPS NAL units into the stream. We recognize them when they appear (so that they can be inserted into the stream's SDP description (for RTSP)), but we don't insert them into the stream; instead, we just transmit the NAL units that were in the input file. >Anybody knows how to solve this problem> VLC seems to have a problem (in particular, with the display window size) when playing the multicast stream, especially when the input file 'wraps around'. I don't know what's causing this (because VLC is not our software); you'd have to ask a VLC mailing list about this. However, you'll have better luck if you stream each file via unicast - e.g., using "testOnDemandRTSPServer" or "live555MediaServer". (In this case, VLC will play the stream just once, until it ends.) That's what I recommend. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 16 02:07:18 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Jul 2011 02:07:18 -0700 Subject: [Live-devel] Media File in testProgs In-Reply-To: References: Message-ID: >pcr-decreasing-test2.ts (a ~3 MB file) is in live/testProgs. Thanks. This was a test file that I used for 2011.07.05 (when I made "testMPEG2TransportStreamIndexer" more robust). It got left there by mistake, and will be removed from the next release. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jul 16 02:12:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Jul 2011 02:12:45 -0700 Subject: [Live-devel] Problem with live555MediaServer when working with two ethernet interface In-Reply-To: References: Message-ID: >I am trying to setup RTSP server on my Linux machine which has two >network interfaces eth0 and eth1. > >_________________ > >10.199.131.56 ---->| eth1 eth0|<------- 192.168.0.1 [...] >Play streams from this server using the URL > >rtsp://10.199.131.101/ [...] >I want to setup RTSP server using eth0 as my client is running on >subnet 192.168.0.X. You might be able to do this just by having your client use 192.168.0.1 in the "rtsp://" URL - i.e., rtsp://192.168.0.1/ If that doesn't work, then I suggest removing the multicast route (i.e., 255.255.255.0) from the eth1 network (i.e., 10.199.131.0). If you do this, but keep the multicast route on the eth0 network, then the server should automatically use eth0 from then on. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kosov at project-10.de Sat Jul 16 06:04:07 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Sat, 16 Jul 2011 15:04:07 +0200 Subject: [Live-devel] testH264VideoStreamer crushes Message-ID: <000001cc43b8$d92759e0$8b760da0$@project-10.de> Hello, I use the "testH264VideoStreamer" application and VLC media player on localhost to transmit AVC flow. After the launching the "testH264VideoStreamer" application, I get: Prompt 1: "Play this stream using the URL "rtsp://192.168.1.101:8554/testStream" Beginning streaming... Beginning to read from file..." Then in approximately 20 seconds (the length of input AVC video) I get: Prompt 2: "...done reading from file Beginning to read from file..." In case I connect to the server with VLC media player after the Prompt 1 but before Prompt 2, and start playing video, it plays OK up to Prompt 2, but after it starts to show garbage, and rapidly change the size of video window. In case I connect to server with VLC media player after the Prompt 2, the the "testH264VideoStreamer" application just crushes. The test File I Use lies here: http://project-10.de/AVC1.264 . I processed it with the "testH264VideoToTransportStream" application to achieve ts file, and it was processed properly, so I assume that the file is valid. Please help me to solve this problem with the "testH264VideoStreamer" application crush. Thanks in advance, Sergey G. Kosov -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 16 12:21:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Jul 2011 12:21:38 -0700 Subject: [Live-devel] testH264VideoStreamer crushes In-Reply-To: <000001cc43b8$d92759e0$8b760da0$@project-10.de> References: <000001cc43b8$d92759e0$8b760da0$@project-10.de> Message-ID: Sergey, Thanks for the bug report. I've identified the problem, which will be fixed in the next release of the software. In the meantime, you can fix it by adding the line: videoSink->stopPlaying(); at line 128 of "testH264VideoStreamer.cpp", just before: Medium::close(videoSource); -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rglobisch at csir.co.za Sun Jul 17 02:19:08 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Sun, 17 Jul 2011 11:19:08 +0200 Subject: [Live-devel] RTP over TCP bugs Message-ID: Hi Ross, We use the LIVE555 Streaming Media library to implement a live streaming server (on Ubuntu) and a windows media player RTSP client streaming RTP over TCP only. We have run into a complicated set of problems recently: 1) When a client with a *bad* internet connection joins the RTSP server, the server becomes unresponsive (to new RTSP connections) and connected clients are dropped. Enabling the DEBUG processor directive showed that many writes fail in RTPInterface::sendRTPOverTCP before the server finally hangs. After searching the mailing list for any similar problems, I came across this post: http://lists.live555.com/pipermail/live-devel/2010-June/012226.html which seems to indicate that using the new asynchronous RTSP client resolves that issue? Could you please clarify this a bit? If I understand correctly, we must therefore upgrade both our server and client code to use the latest live media version to avoid the server hanging? Or would updating the client code to use the new async RTSPClient code suffice? 2) We are aware that you only support the latest version so we recently upgraded the live555 version. We then ran into another issue: while the stream is playing back, CPU usage is negligible. Then, once network problems occur, the CPU usage spikes to 100%. Matt's post (http://lists.live555.com/pipermail/live-devel/2011-June/013521.html) could be related. However commenting out the adding of dummy socket to fWriteSet and fExceptionSet as you advised in your response to Matt didn't solve the problem. Upgrading our WMP client to use the new asynchronous interface didn't help either. Finally, we were able to replicate the problem using only openRTSP. Here's a short summary of the steps taken so far: LiveMedia 2010.04.09 - synchronous - WMP RTSPClient - no problems with CPU usage LiveMedia 2011.03.14 - synchronous - WMP RTSPClient - same CPU usage problem LiveMedia 2011.03.14 - asynchronous - WMP RTSPClient - same CPU usage problem LiveMedia 2011.03.14 - asynchronous - openRTSP - same CPU usage problem LiveMedia 2011.07.15 - asynchronous - openRTSP - same CPU usage problem Ways to replicate the problem: - One method that has worked to trigger the problem is to start running openRTSP and then restarting our ADSL router once the stream is active. Could this have anything to do with "the Windows bug that forced me to add?"dummySocket" in the first place"? We are currently piloting the project and these errors are critical for the success of the pilot. Any pointers/advice would be greatly appreciated. Best regards, Ralf From rglobisch at csir.co.za Sun Jul 17 03:41:08 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Sun, 17 Jul 2011 12:41:08 +0200 Subject: [Live-devel] RTP over TCP bugs Message-ID: In case it helps: profiling shows that the following seems to account for the CPU usage: void SocketDescriptor::tcpReadHandler(SocketDescriptor* socketDescriptor, int mask) { socketDescriptor->tcpReadHandler1(mask); } Commenting out the dummy descriptor on fReadSet didn't help solve the issue. The stack trace seemingly causing the high CPU uage looks somewhat as follows: BasicTaskScheduler::SingleStep SocketDescriptor::tcpReadHandler socketDescriptor->tcpReadHandler1 -> [fTCPReadingState = AWAITING_PACKET_DATA] rtpInterface->fReadHandlerProc -> MultiFramedRTPSource::networkReadHandler MultiFramedRTPSource::networkReadHandler1 -> [packetReadWasIncomplete = false -> fPacketReadInProgress = NULL] .... if (bPacket->dataSize() < 12) break; -> [readSuccess = false] doGetNextFrame1(); Does this help at all in resolving/tracking down the issue? Perhaps offsetting the next read event by some milliseconds? Regards, Ralf From finlayson at live555.com Sun Jul 17 21:23:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Jul 2011 21:23:20 -0700 Subject: [Live-devel] A new server extension for streaming to iPhones and iPads Message-ID: The latest version (2011.07.18) of the "LIVE555 Streaming Media" code includes an experimental server extension that supports streaming media files to iPhones and iPads, using Apple's "HTTP Live Streaming" mechanism. This means that you can use a single server to stream the same file(s) using either RTSP/RTP (to standard RTSP/RTP clients such as VLC), or using HTTP (to "Safari" on iPhones and iPads). (Note though, that for "HTTP Live Streaming" to iPhones and iPads, only one kind of file is supported: MPEG Transport Stream files with H.264 video. (To be streamed using our server, the files must also be indexed - using the same 'index file' mechanism that we use for 'trick play'.)) I have added this support to the "LIVE555 Media Server" application (the "live555MediaServer" application, in the "mediaServer" directory). (As of now, this support is only in the source code; *not* in the pre-built "live555MediaServer" application binaries that you can download from our web site. However, the pre-built binary versions will be updated shortly, perhaps after I get feedback from this mailing list.) To use the "HTTP Live Streaming" feature, using the "LIVE555 Media Server": ====================================== 1/ Download and build the latest version of the "LIVE555 Streaming Media" software. 2/ Go to the "mediaServer" directory. Build "live555MediaServer" (if it hasn't been built already). 3/ Copy the media file(s) that you wish to stream to this directory. (To use "HTTP Live Streaming", these files must be MPEG Transport Stream files with H.264 video.) 4/ Each of these Transport Stream files must be indexed (to create an 'index file'), using the "MPEG2TransportStreamIndexer" utility. (For more information about this utility, see ) The index file (with file name suffix ".tsx") must be put in the "mediaServer" directory, along with its ".ts" file. 4a/ Note: An example Transport Stream file - and its index file - is available at : You can download the files "bipbop-gear1-all.ts" and "bipbop-gear1-all.tsx", and put them in the "mediaServer" directory. 5/ Run the "live555MediaServer" application. Note the port number that it prints out at the end - for use for HTTP Live Streaming. 6/ On your iPhone or iPad, start the "Safari" (web browser) app, and enter the URL http://:/ where is the port number noted in step 5. If the port number is 80 (the default port number for HTTP), then you can omit ":80" from the URL. (In principle, you could also use the RTSP port number (554 or 8554) for HTTP. I don't recommend this, though, because it might confuse firewalls.) To add the "HTTP Live Streaming" feature to your own RTSP server application: ====================================== 1/ Instead of using the "RTSPServer" class, use the "RTSPServerSupportingHTTPStreaming" class. (This is a subclass of "RTSPServer".) 2/ To set up the server to use a specific HTTP port number, call setHTTPPort() and be sure to test the result, to make sure it worked. (On most Unix/Linux systems, you will not be able to use port number 80, unless you're running as "root". However, ports 8000 or 8080 should work.) Additional notes ============= - If your streamed file does not display properly on an iPhone or iPad, then it might be because it was encoded with a version of H.264 that Apple does not support. According to Apple's documentation, at http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html your file must be encoded using H.264 "Baseline profile 3.0, Baseline profile 3.1, or Main profile 3.1", or just "Baseline 3.1" for older iPhones. - The "bipbop-gear1-all.ts" file (available, along with its index file, from is known to work OK. However, I'm looking for more examples of workable files to put in this directory (so people can use them for their own testing). If you have such a working file, and wish to contribute it to this public repository, then please let me know. - Note that Apple's "QuickTime Player" application (for Mac or Windows) *cannot* play these streams, using either "HTTP Live Streaming", or RTSP/RTP. (It can play RTSP/RTP streams that consist of separate Elementary Stream audio/video substreams, but - for some strange reason - cannot play RTSP/RTP streams of Transport Stream data.) Go figure... (If you want to play these streams using RTSP/RTP, use VLC , not "QuickTime Player".) - Unlike some other servers that support "HTTP Live Streaming", we do not actually 'segment' (split up) the Transport Stream files that we're streaming. Instead, we segment the files 'virtually', inside the server, in response to each client request. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 18 01:02:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Jul 2011 01:02:07 -0700 Subject: [Live-devel] RTP over TCP bugs In-Reply-To: References: Message-ID: >Could you please clarify this a bit? If I understand correctly, we >must therefore upgrade >both our server and client code to use the latest live media version >to avoid the server >hanging? Or would updating the client code to use the new async >RTSPClient code suffice? I'm not interested in any alleged server bug, unless the server is running an up-to-date version of our software (in which case it doesn't matter what version of our software the client is running, or whether or not the client is using the synchronous or asynchronous interface). Similarly, I'm not interested in any alleged client bug, unless the client is running an up-to-date version of our software (in which case it doesn't matter what version of our software the server is running). However, if you have control over *both* the client and server software, then it would be best if you upgrade both the client and the server to the latest version. In any case, I can't really help you with a non-specific bug claim (e.g., "CPU usage spikes to 100%") unless you can show how it can be repeated using our supplied, unmodified software and demo applications (the latest version, of course). If, however, you have a problem that arises only with your own, custom code, then you're going to have to track down *specifically* what is happening, and in which part of our code. Sorry (but Remember, You Have Complete Source Code). Referring to old archived email messages usually doesn't help, because the problems referred to in those emails either weren't real, or else should have been fixed in later versions of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rglobisch at csir.co.za Mon Jul 18 01:30:03 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Mon, 18 Jul 2011 10:30:03 +0200 Subject: [Live-devel] RTP over TCP bugs Message-ID: Hi Ross, Thanks for your response. >I'm not interested in any alleged server bug, unless the server is >running an up-to-date version of our software (in which case it >doesn't matter what version of our software the client is running, or >whether or not the client is using the synchronous or asynchronous Ok, thanks, point made. We are in the process of updating our server code base to the latest version of the live555. The term *bug* was perhaps inappropriate in the title. >interface). Similarly, I'm not interested in any alleged client bug, >unless the client is running an up-to-date version of our software >(in which case it doesn't matter what version of our software the >server is running). Since you stated that it doesn't matter what version the server is running: Perhaps I didn't express myself clear enough. It is for that exact reason, that I replicated the client problem using only an *unmodifed* openRTSP client using the *latest* version of LiveMedia. The accompanying stack trace (if you can call it that) was from obtained running the openRTSP client. I was able to (quickly) replicate the problem multiple times by resetting the ADSL router. However, the problem occurs in practice without needing to do this, since the Internet infrastructure in South Africa is unreliable/not as advanced as in the US/Europe. It just takes longer for it to happen (from minutes to hours). FWIW, I will try to replicate this when connecting openRTSP to the standard Live555 RTSP server. >Referring to old archived email messages usually doesn't help, >because the problems referred to in those emails either weren't real, >or else should have been fixed in later versions of the code. Agree. Please accept my apology. (at the time of writing I thought the second reference was valid since it was from a fairly recent discussion) However profiling the code, showed that it clearly wasn't relevant. From nouri at soroush.net Mon Jul 18 05:35:41 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Mon, 18 Jul 2011 17:05:41 +0430 Subject: [Live-devel] Need some members to be protected Message-ID: Hi Ross. I need some private members to be protected in order to use them in my code. I appreciate if you consider applying them to the main code. In class DynamicRTSPServer, I need the constructor, destructor and function lookupServerMediaSessionv to be protected. In ByteStreamFileSource, fFileSize to be protected. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 18 06:35:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Jul 2011 06:35:17 -0700 Subject: [Live-devel] Need some members to be protected In-Reply-To: References: Message-ID: >I need some private members to be protected in order to use them in >my code. I appreciate if you consider applying them to the main code. >In class DynamicRTSPServer, I need >the constructor, destructor and function lookupServerMediaSessionv >to be protected. OK, will do. >In ByteStreamFileSource, fFileSize to be protected. Note that we already have a "public:" member function u_int64_t fileSize() const { return fFileSize; } Do you still want the "fFileSize" member variable to be "protected:" - i.e., do you want to modify its value in a subclass? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nouri at soroush.net Mon Jul 18 06:46:03 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Mon, 18 Jul 2011 18:16:03 +0430 Subject: [Live-devel] Need some members to be protected In-Reply-To: References: Message-ID: > Do you still want the "fFileSize" member variable to be "protected:" - i.e., do you want to modify its value in a subclass? Yes. Actually, I need to store the original fileName, so I created a sublass of it. But to do so, I need to set fFileSize in my constructor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nouri at soroush.net Mon Jul 18 06:48:33 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Mon, 18 Jul 2011 18:18:33 +0430 Subject: [Live-devel] Need some members to be protected In-Reply-To: References: Message-ID: For another reason, my file is changing onlive, so I need to update its size periodically. On Mon, Jul 18, 2011 at 6:16 PM, Mojtaba Nouri wrote: > > Do you still want the "fFileSize" member variable to be "protected:" - > i.e., do you want to modify its value in a subclass? > > Yes. Actually, I need to store the original fileName, so I created a > sublass of it. But to do so, I need to set fFileSize in my constructor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Larry.Cui at zoran.com Mon Jul 18 11:40:49 2011 From: Larry.Cui at zoran.com (Larry Cui) Date: Mon, 18 Jul 2011 18:40:49 +0000 Subject: [Live-devel] testH264VideoStreamer crushes In-Reply-To: References: <000001cc43b8$d92759e0$8b760da0$@project-10.de> Message-ID: <96CB13D3010D8946AF14847B4BC8D99687ABDF@zcomb2.Zoran.com> Works fine. -Larry -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, July 16, 2011 12:22 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] testH264VideoStreamer crushes Sergey, Thanks for the bug report. I've identified the problem, which will be fixed in the next release of the software. In the meantime, you can fix it by adding the line: videoSink->stopPlaying(); at line 128 of "testH264VideoStreamer.cpp", just before: Medium::close(videoSource); -- 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 From Brad.Lackey at schneider-electric.com Mon Jul 18 17:50:52 2011 From: Brad.Lackey at schneider-electric.com (Lackey, Brad) Date: Mon, 18 Jul 2011 17:50:52 -0700 Subject: [Live-devel] RTSP Url Parameters And Live Vs Playback Message-ID: <4BBAF403456ED74981E7164ED3A4C22402E18EA9@CA-EVS02.pelco.org> Hello, I would like to pass some parameters via the rtsp url (rtsp://x.x.x.x/?id=x&startTime=x&endTime=x), I have overridden the RTSPServer::RTSPClientSession::handleCmd_DESCRIBE method so that I can copy what I want out of the urlSuffix and then trim before calling the base's handleCmd_DESCRIBE method. The problem I'm having is I want to be able to access these varaibles from my framed source, so I know if I should be playing back a recorded source, or a live source. You see, in the base's describe method it ends up creating my framed source to get the sdp details in order to return them to the user, but I'm not sure how to tell my framed source if it's a live stream or playback. Seems like there should be a straightforward way to determine this, I'm just not seeing it. Any insight to my issue would be much appreciated. ______________________________________________________________________ Bradley Lackey ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kidjan at gmail.com Mon Jul 18 08:54:13 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Mon, 18 Jul 2011 08:54:13 -0700 Subject: [Live-devel] A new server extension for streaming to iPhones and iPads In-Reply-To: References: Message-ID: On Sun, Jul 17, 2011 at 9:23 PM, Ross Finlayson wrote: > The latest version (2011.07.18) of the "LIVE555 Streaming Media" code > includes an experimental server extension that supports streaming media > files to iPhones and iPads, using Apple's "HTTP Live Streaming" mechanism. > Very nice feature. Question: if I wanted to extend this to use a different source (say, and MP4 file with H.264 and AAC), where would be the best place to start? And would it be possible to use it with a live source somehow? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbzbz at yahoo.com Mon Jul 18 01:10:46 2011 From: gbzbz at yahoo.com (gather bzbz) Date: Mon, 18 Jul 2011 01:10:46 -0700 (PDT) Subject: [Live-devel] AAC live streaming Message-ID: <1310976646.93840.YahooMailClassic@web121007.mail.ne1.yahoo.com> Hi, Trying to use live555 to stream AAC audio. Our source is a TI dsp that does the compression from PCM source. So the output from the TI chip is the AAC pieces. I saved the AAC output from the chip to a file, test.aac, then used the testOndemandServer to stream it, I could receive and decode it very well with VLC. Then I tried to stream it directly without saving it first. I know the streaming part will use MPEG4GenericRTPSink(), what about audioSource? How to calculate the timestamps based of input configs like sampleRate, bitRate, etc? Thanks! From finlayson at live555.com Mon Jul 18 22:26:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Jul 2011 22:26:22 -0700 Subject: [Live-devel] A new server extension for streaming to iPhones and iPads In-Reply-To: References: Message-ID: >Very nice feature. > >Question: if I wanted to extend this to use a different source (say, >and MP4 file with H.264 and AAC), where would be the best place to >start? The only kind of stream that will play on iPhones and iPads are MPEG Transport Streams that contain H.264 video, and AAC or MP3 audio. So, you won't be able to stream a MP4 file to them. You'd first need to convert the file to a Transport Stream (and then index it). > And would it be possible to use it with a live source somehow? Not with this implementation, because it uses the server 'trick play' mechanism for streaming Transport Stream files, and that requires that the files already exist (and be indexed). Right now the best solution for streaming from a live source to iPhones/iPads is probably to use Apple's own "MediaStreamSegmenter" tool (which breaks an input Transport Stream into multiple files, and generates a playlist). You can then stream these using a regular HTTP server. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 18 22:41:25 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Jul 2011 22:41:25 -0700 Subject: [Live-devel] AAC live streaming In-Reply-To: <1310976646.93840.YahooMailClassic@web121007.mail.ne1.yahoo.com> References: <1310976646.93840.YahooMailClassic@web121007.mail.ne1.yahoo.com> Message-ID: >Trying to use live555 to stream AAC audio. Our source Do "we" not have our own domain name? :-) > is a TI dsp that does the compression from PCM source. So the >output from the TI chip is the AAC pieces. I saved the AAC output >from the chip to a file, test.aac, then used the testOndemandServer >to stream it, I could receive and decode it very well with VLC. Then >I tried to stream it directly without saving it first. I know the >streaming part will use MPEG4GenericRTPSink(), what about >audioSource? How to calculate the timestamps based of input configs >like sampleRate, bitRate, etc? See http://www.live555.com/liveMedia/faq.html#liveInput-unicast You will need to write an "OnDemandServerMediaSubsession" subclass that's similar to the existing "ADTSAudioFileServerMediaSubsession" class, except that the "createNewStreamSource()" virtual function - instead of returning a "ADTSAudioFileSource " - will return an instance of a new class - that you will write - that encapsulates your AAC encoder. This encoder class would need to return three parameters that are needed by the RTP sink created by "createNewRTPSink()": the sampling frequency, the 'config string', and the number of channels. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 18 22:47:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 18 Jul 2011 22:47:38 -0700 Subject: [Live-devel] Need some members to be protected In-Reply-To: References: Message-ID: > > Do you still want the "fFileSize" member variable to be >"protected:" - i.e., do you want to modify its value in a subclass? > >Yes. Actually, I need to store the original fileName, so I created a >sublass of it. But to do so, I need to set fFileSize in >my constructor. OK, I'll make that change too. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstafford at ampltd.com Tue Jul 19 02:58:15 2011 From: jstafford at ampltd.com (James Stafford) Date: Tue, 19 Jul 2011 10:58:15 +0100 Subject: [Live-devel] Need some members to be protected In-Reply-To: References: Message-ID: <4E255537.2050707@ampltd.com> Hi Ross, >> > Do you still want the "fFileSize" member variable to be >> "protected:" - i.e., do you want to modify its value in a subclass? >> >> Yes. Actually, I need to store the original fileName, so I created a >> sublass of it. But to do so, I need to set fFileSize in my constructor. > > OK, I'll make that change too. While making these changes, could you also make the constructor, destructor and processSpecialHeader() of H264VideoRTPSource protected. I need access to the marker bit to determine end of frame (not just end of NAL which the fCurrentPacketCompletesFrame seems to indicate for my stream) so have subclassed H264VideoRTPSource. Thanks -- James Stafford Advanced Micro Peripherals Ltd Unit 1 Harrier House Sedgeway Business Park Witchford Cambridge CB6 2HY From finlayson at live555.com Tue Jul 19 06:27:12 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Jul 2011 06:27:12 -0700 Subject: [Live-devel] Need some members to be protected In-Reply-To: <4E255537.2050707@ampltd.com> References: <4E255537.2050707@ampltd.com> Message-ID: >While making these changes, could you also make the constructor, >destructor and processSpecialHeader() of H264VideoRTPSource >protected. OK, will do. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From admin at awright2009.com Tue Jul 19 07:36:37 2011 From: admin at awright2009.com (admin at awright2009.com) Date: Tue, 19 Jul 2011 07:36:37 -0700 Subject: [Live-devel] H264 StreamParser.cpp thrown exception Message-ID: <20110719073637.21fdb0f101ed1e75ea8ae5d43a76b79a.029a4935e9.wbe@email11.secureserver.net> I just noticed that my forked h264 process is dying on startup due to a thrown integer exception in StreamParser.cpp NO_MORE_BUFFERED_INPUT. Looking into H264VideoStreamParser::parse() method as an example I see that this is caught and treated as non fatal. However, the code I'm working on doesnt attempt to catch this exception. I'm assuming the previously working version of live I had: 2010.07.29 simply didnt throw this exception on startup. I get encoded h264 data from another process and do a little parsing of the raw stream before copying it to the fTo pointer in a method called VideoOpenFileSource::readFromFile(). There is also a little state machine that ensures an SPS and PPS are sent at the begining of each stream within this class. Where would be the best place to put the try/catch blocks to correctly handle this exception? I'm not sure which function call in my code triggers the exception. (Again, this code was originally based on the wis-streamer code and most of the structure is the same) Defining the MJPEG restartInterval() function fixed the MJPEG streaming issue I had before, thanks for the help! And sorry if I'm asking too many questions -Thanks Alex Wright From matt at schuckmannacres.com Tue Jul 19 10:43:49 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Tue, 19 Jul 2011 10:43:49 -0700 Subject: [Live-devel] RTSP Url Parameters And Live Vs Playback In-Reply-To: <4BBAF403456ED74981E7164ED3A4C22402E18EA9@CA-EVS02.pelco.org> References: <4BBAF403456ED74981E7164ED3A4C22402E18EA9@CA-EVS02.pelco.org> Message-ID: <4E25C255.50800@schuckmannacres.com> Checkout this thread http://lists.live555.com/pipermail/live-devel/2011-June/013470.html I was trying to do something similar to what you are doing and I think I also started down the path you are headed and ultimately Ross showed me a much much easier way to do what i wanted. Matt S. On Monday, July 18, 2011 5:50:52 PM, Lackey, Brad wrote: > Hello, > > I would like to pass some parameters via the rtsp url > (rtsp://x.x.x.x/?id=x&startTime=x&endTime=x), I have overridden the > RTSPServer::RTSPClientSession::handleCmd_DESCRIBE method so that I can > copy what I want out of the urlSuffix and then trim before calling the > base's handleCmd_DESCRIBE method. > > The problem I'm having is I want to be able to access these varaibles > from my framed source, so I know if I should be playing back a recorded > source, or a live source. > > You see, in the base's describe method it ends up creating my framed > source to get the sdp details in order to return them to th e user, but > I'm not sure how to tell my framed source if it's a live stream or playback. > > Seems like there should be a straightforward way to determine this, I'm > just not seeing it. > > Any insight to my issue would be much appreciated. > > ______________________________________________________________________ > *Bradley Lackey* > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From volker.marks at outstanding-solutions.de Tue Jul 19 08:07:51 2011 From: volker.marks at outstanding-solutions.de (Volker Marks) Date: Tue, 19 Jul 2011 17:07:51 +0200 Subject: [Live-devel] Problem receiving data on Windows XP Message-ID: <001e01cc4625$a214ace0$e63e06a0$@outstanding-solutions.de> Hi, I'm implementing a RTSP-Sender and -Receiver using liveMedia under Windows XP SP2. (Don't ask...) The current state is that -using VLC I'm able to play the stuff sent by my RTSP-Sender. -my RTSP-Receiver is able to process data streamed by the VLC (sent unicast?). Unfortunately my Receiver won't play with my Sender. :-( Session setup seems to work fine and even "sendPlayCommand" reports no error, but no data is being received. Now I figured out that "openRTSP" (on which I've based my receiver) doesn't work with my RTSP-Server nor with "testMPEG2TransportStreamer" either. Is it possible that the problem is related to the groupsock-error-message "... failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error" printed on the server- and client-side? If so: is there a workaround on Windows XP? If it is not groupsock-error related: any other ideas or "usual suspects"? Regards Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: From kidjan at gmail.com Wed Jul 20 12:43:32 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Wed, 20 Jul 2011 12:43:32 -0700 Subject: [Live-devel] Problem with RTP over TCP In-Reply-To: References: Message-ID: On Wed, Jul 20, 2011 at 11:15 AM, Jeremy Noring wrote: > I updated my RTP client to the most recent version (2011.7.18) and I'm > having trouble with RTP over TCP. Occasionally Live555 will get in a state > where it no longer receives any data from the server, even though the server > is completely alive. > > I narrowed down the problem to RTPInterface.cpp, line 379: > > case AWAITING_STREAM_CHANNEL_ID: { > // The byte that we read is the stream channel id. > fStreamChannelId = c; > fTCPReadingState = AWAITING_SIZE1; > break; > } > > ....fStreamChannelId gets set to some crazy value (e.g. '37') that isn't > valid (for my app, should be 0 or 2). Once it's in that bad state, this > fails repeatedly: > > case AWAITING_PACKET_DATA: { > // Call the appropriate read handler to get the packet data from the > TCP stream: > RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId); > if (rtpInterface != NULL) { > > ...lookupRTPInterface(fStreamChannelId) returns NULL, which causes the > library not to call fReadHandlerProc(). Live555 consumes all the CPU, and > the only communication that still happens are the periodic SR reports (which > do still work). > > I haven't managed to figure out why this is; using a debug build (i.e. > DEBUG is defined, so there are periodic log messages) seems to reproduce the > issue much more immediately--otherwise it can take a while to get in this > bad state. > > Any ideas why this may be happening? > Update: I went through some older versions of the library (prior to the async client rewrite) and I saw code that would ensure the stream channel ID was present. So I did a quick test with the following code: case AWAITING_STREAM_CHANNEL_ID: { // The byte that we read is the stream channel id. RTPInterface* rtpInterface = lookupRTPInterface(c); if (rtpInterface != NULL) { fStreamChannelId = c; fTCPReadingState = AWAITING_SIZE1; } else { // we're not interested in this channel fTCPReadingState = AWAITING_DOLLAR; } ...and that seems to have mostly corrected the issue. That said, I'd really like to know how it's happening in the first place--seems to me like there must be some other bug allowing it to get in this state? Or maybe it's not that simple. Any insight is welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 20 16:41:55 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Jul 2011 16:41:55 -0700 Subject: [Live-devel] Problem with RTP over TCP In-Reply-To: References: Message-ID: >Any ideas why this may be happening? Unfortunately not. >So I did a quick test with the following code: > > case AWAITING_STREAM_CHANNEL_ID: { > // The byte that we read is the stream channel id. > RTPInterface* rtpInterface = lookupRTPInterface(c); > if (rtpInterface != NULL) > { > fStreamChannelId = c; > fTCPReadingState = AWAITING_SIZE1; > } > else > { // we're not interested in this channel > fTCPReadingState = AWAITING_DOLLAR; > } > >...and that seems to have mostly corrected the issue. I'll add this to the next release of the software. I'm not thrilled by this, though, because it means that all subsequent data - up to the next '$' - will get treated as making up a possible RTSP request or response (the "fServerRequestAlternativeByteHandler" code). But at least the code will keep making forward progress (reading one by at a time, up to the next '$'). > That said, I'd really like to know how it's happening in the first >place--seems to me like there must be some other bug allowing it to >get in this state? Agreed. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 20 19:45:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 20 Jul 2011 19:45:33 -0700 Subject: [Live-devel] H264 StreamParser.cpp thrown exception In-Reply-To: <20110719073637.21fdb0f101ed1e75ea8ae5d43a76b79a.029a4935e9.wbe@email11.se cureserver.net> References: <20110719073637.21fdb0f101ed1e75ea8ae5d43a76b79a.029a4935e9.wbe@email11.se cureserver.net> Message-ID: >I just noticed that my forked h264 process is dying on startup due to a >thrown integer exception in StreamParser.cpp NO_MORE_BUFFERED_INPUT. >Looking into H264VideoStreamParser::parse() method as an example I see >that this is caught and treated as non fatal. The "StreamParser" code is somewhat of a 'black art'. The C++ exception occurs if parsing code hits the end of its input buffer, and has to read new input (asynchronously, of course) from its data source. The parsing code (for example, the reimplementation of the "parse()" virtual function in "H264VideoStreamFramer.cpp") needs to catch this exception, and return 0 (as the result of "parse()") if this occurs. >I get encoded h264 data from another process and do a little parsing of >the raw stream before copying it to the fTo pointer in a method called >VideoOpenFileSource::readFromFile(). There is also a little state >machine that ensures an SPS and PPS are sent at the begining of each >stream within this class. If you are delivering discrete H.264 NAL units - i.e., one-at-a-time - then you should probably be feeding your input data into a "H264VideoStreamDiscreteFramer" (rather than into a "H264VideoStreamFramer"). In any case, I'm not convinced that you need to be using the "StreamParser"-derived code yourself, in your own application. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kidjan at gmail.com Wed Jul 20 17:14:57 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Wed, 20 Jul 2011 17:14:57 -0700 Subject: [Live-devel] Problem with RTP over TCP In-Reply-To: References: Message-ID: On Wed, Jul 20, 2011 at 4:41 PM, Ross Finlayson wrote: > ** > > Any ideas why this may be happening? > > > Unfortunately not. > Is it somehow possible that something else could read from the socket between when AWAITING_STREAM_CHANNEL_ID is set and the case statement? And would it be possible to complete the entire operation in tcpReadHandler1, instead of iterating through it repeatedly? (I see that's how it used to function, but maybe that approach isn't feasible with the asynchronous operation) Lastly, I haven't migrated to the new asynchronous interface--is it possible that would have an impact, or is this code shared between the two? Thanks again for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 21 01:06:11 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Jul 2011 01:06:11 -0700 Subject: [Live-devel] Problem with RTP over TCP In-Reply-To: References: Message-ID: >Is it somehow possible that something else could read from the >socket between when AWAITING_STREAM_CHANNEL_ID is set and the case >statement? Now, I don't see how. (I assume you're not doing something dump like trying to use more than one thread.) > And would it be possible to complete the entire operation in >tcpReadHandler1, instead of iterating through it repeatedly? No, because reads from the socket are (now) asynchronous (i.e., non-blocking), so each read from the socket might retrieve only part of the data. >Lastly, I haven't migrated to the new asynchronous interface--is it >possible that would have an impact, or is this code shared between >the two? Yes, the synchronous interface is implemented using the asynchronous interface. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dezso.kancsar at gmail.com Thu Jul 21 01:27:21 2011 From: dezso.kancsar at gmail.com (Dezso Kancsar) Date: Thu, 21 Jul 2011 10:27:21 +0200 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: References: Message-ID: <4E27E2E9.7080805@gmail.com> Hi Ross, I have found some messages about the similar topic as my request, but the latest was published around a year ago and informed that only the client is ready to handle it. So, I want to know if there is any changes in this topic? When do you plan to implement it on the server side as well & to share it with us? Thanks & Best Regards, Dezs? From stathis.voukelatos at aircraftmedical.com Thu Jul 21 01:59:35 2011 From: stathis.voukelatos at aircraftmedical.com (Stathis Voukelatos) Date: Thu, 21 Jul 2011 09:59:35 +0100 Subject: [Live-devel] RTSP server socket bind error Message-ID: Hi, I run the 'testH264VideoStreamer' app and view the video with an RTSP client (eg VLC). If I kill 'testH264VideoStreamer' while the client is connected and then try to run it again straight away I get the following error: Failed to create RTSP server: bind() error (port number: 8554): Address already in use I ran netstat and found that the cause of this error is that the socket is in the TIME_WAIT state. You need to wait until the TIME_WAIT timeout period elapses. I found a way around this by editing the setupStreamSocket() function to set the SO_LINGER option with a timeout of 0 on the socket to force the server to abort the connection. Would that be a useful change to the code (maybe with a linger timeout > 0 ) or would it cause other side effects? Stathis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 21 06:52:21 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Jul 2011 06:52:21 -0700 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: <4E27E2E9.7080805@gmail.com> References: <4E27E2E9.7080805@gmail.com> Message-ID: >I have found some messages about the similar topic as my request, >but the latest was published around a year ago and informed that >only the client is ready to handle it. So, I want to know if there >is any changes in this topic? When do you plan to implement it on >the server side as well & to share it with us? RTP/RTSP-over-HTTP has been supported in our RTSP server implementation since October last year: http://lists.live555.com/pipermail/live-devel/2010-October/012672.html -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 21 07:16:39 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Jul 2011 07:16:39 -0700 Subject: [Live-devel] RTSP server socket bind error In-Reply-To: References: Message-ID: >I run the 'testH264VideoStreamer' app and view the video with an >RTSP client (eg VLC). >If I kill 'testH264VideoStreamer' while the client is connected and >then try to run it again >straight away I get the following error: > > Failed to create RTSP server: bind() error (port number: 8554): >Address already in use > >I ran netstat and found that the cause of this error is that the >socket is in the TIME_WAIT >state. You need to wait until the TIME_WAIT timeout period elapses. >I found a way around this by editing the setupStreamSocket() >function to set the >SO_LINGER option with a timeout of 0 on the socket to force the >server to abort the >connection. Would that be a useful change to the code (maybe with a >linger timeout > 0 ) >or would it cause other side effects? I'm not sure. This web page http://developerweb.net/viewtopic.php?id=2982 suggests that SO_LINGER is not very portable, and might not always do what you want. (Other references (e.g., Stevens' book) also notes the (albeit remote) possibility of data corruption if you were to restart a server before the TIME_WAIT period ends.) So I'd be reluctant to add this to the code just to satisfy people's impatience. Instead, just wait a few seconds, and you'll be able to restart your server. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From volker.marks at outstanding-solutions.de Thu Jul 21 08:14:19 2011 From: volker.marks at outstanding-solutions.de (Volker Marks) Date: Thu, 21 Jul 2011 17:14:19 +0200 Subject: [Live-devel] Problem receiving data on Windows XP (Volker Marks) Message-ID: <000001cc47b8$e1169590$a343c0b0$@outstanding-solutions.de> D'oh! After several days of heavy debugging I've found the reason for all the network/multicast issues: Somehow I had lost the define "WINNT" in my groupsock-project-file. This led to the inclusion of "winsock.h" instead of "ws2ipdef.h" and this led to e.g. a wrong value for "IP_ADD_MEMBERSHIP". Embarrassing... From sergey.kosov at project-10.de Thu Jul 21 15:15:00 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Fri, 22 Jul 2011 00:15:00 +0200 Subject: [Live-devel] Event Triggerring Message-ID: <001b01cc47f3$a24cd0f0$e6e672d0$@project-10.de> Hi, I use the "testH264VideoStreamer" application and VLC media player on localhost to transmit AVC flow. I want to intervene in the transmission process in order to have a possibility to access and change the video stream on the fly. But after the command: env->taskScheduler().doEventLoop(); // does not return I have no possibility to do anything. I thought in the direction of creating a trigger with EventTriggerId myTrigger = env->taskScheduler().createEventTrigger(myProc); To launch my routine within the playing process, but as I understand, I cannot call env->taskScheduler().triggerEvent(myTrigger); within the Event Loop. Could you, please, give me a piece of advice how to launch myProc() in between promts "Beginning to read from file..." and "...done reading from file". Thanks in advance, Sergey G. Kosov From finlayson at live555.com Thu Jul 21 17:12:15 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 21 Jul 2011 17:12:15 -0700 Subject: [Live-devel] Event Triggerring In-Reply-To: <001b01cc47f3$a24cd0f0$e6e672d0$@project-10.de> References: <001b01cc47f3$a24cd0f0$e6e672d0$@project-10.de> Message-ID: >I thought in the direction of creating >a trigger with > >EventTriggerId myTrigger = env->taskScheduler().createEventTrigger(myProc); > >To launch my routine within the playing process, but as I understand, I >cannot call > >env->taskScheduler().triggerEvent(myTrigger); > >within the Event Loop. Yes, of course you can. But if you're already running within the event loop, then you don't need to use the event trigger mechanism (because, if you're running within the event loop, you're already executing code in response to an event). Instead, you can just call "myProc()" directly. > Could you, please, give me a piece of advice how to >launch myProc() in between promts "Beginning to read from file..." and >"...done reading from file". It depends: When specifically do you want to call "myProc()"? If you want to do it after a certain time has elapsed (or periodically), then you can do this using "TaskScheduler::scheduleDelayedTask()". If, however, you want to do this in response to something that's happening in a separate thread (i.e., one that's *not* running the LIVE555 event loop), then the event trigger mechanism would be perfect for this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kidjan at gmail.com Thu Jul 21 13:36:10 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Thu, 21 Jul 2011 13:36:10 -0700 Subject: [Live-devel] Problem with RTP over TCP In-Reply-To: References: Message-ID: On Thu, Jul 21, 2011 at 1:06 AM, Ross Finlayson wrote: > Now, I don't see how. (I assume you're not doing something dump like > trying to use more than one thread.) I'm using a dedicated thread for each Live555 instance. Could it have to do with the session having multiple subsessions? The session I'm pulling from has both AAC and H.264 subsessions, so I'm wondering if somehow the parsing code isn't accounting for that correctly? Any other ideas I could look into? I really need to solve this issue, so any pointers or suggestions are more than welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dezso.kancsar at gmail.com Fri Jul 22 02:00:44 2011 From: dezso.kancsar at gmail.com (Dezso Kancsar) Date: Fri, 22 Jul 2011 11:00:44 +0200 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: <4E27E2E9.7080805@gmail.com> References: <4E27E2E9.7080805@gmail.com> Message-ID: <4E293C3C.5020507@gmail.com> > > RTP/RTSP-over-HTTP has been supported in our RTSP server > implementation since October last year: > http://lists.live555.com/pipermail/live-devel/2010-October/012672.html > The release note of the version 2010 October said only RTSP-over-HTTP nor RTP. Am I right? I have compiled and tested the live555MediaServer version 0.70 from sources. Started the given binary as root and closed all other ports except 80 via tcp on my machine. The startup log said the port 80 was used for "...optional RTSP-over-HTTP tunneling, or for HTTP live streaming...". Next I have started a VLC client on another PC with the settings of the RTP/RTSP over HTTP tunneling on port 80. The VLC just do nothing :-( If udp ports are reopened on server and the HTTP tunneling on the client is disabled, the VLC works fine. In the other hand a dss (Darwin Streaming Server from Apple) on the same server what I tried for live55MediaServer works fine from the VLC client with the same settings even if only the port 80 is open on server side and the HTTP tunneling is enabled on client side. Sum: I was not able to setup live555MediaServer to handle streaming only via HTTP port. What do I have to change in the config or source to make the live555MediaServer also able to work only as "HTTP tunneled streaming server"? Should I get back to the version of 2010 October? Do we talk about the same: "RTP/RTSP over HTTP server implementation"? Do you plan to implement that kind of "HTTP tunneled streaming server" implementation, as well? Thanks for helping! Best Regards, Dezs?. From finlayson at live555.com Fri Jul 22 02:17:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Jul 2011 02:17:22 -0700 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: <4E293C3C.5020507@gmail.com> References: <4E27E2E9.7080805@gmail.com> <4E293C3C.5020507@gmail.com> Message-ID: >>RTP/RTSP-over-HTTP has been supported in our RTSP server >>implementation since October last year: >>http://lists.live555.com/pipermail/live-devel/2010-October/012672.html >> >The release note of the version 2010 October said only >RTSP-over-HTTP nor RTP. Am I right? No. The protocol tunnels RTSP over HTTP, but RTP (and RTCP) packets are also tunneled over the RTSP channel. So, strictly speaking, it's (RTP/RTCP-over-RTSP)-over-HTTP. >I have compiled and tested the live555MediaServer version 0.70 from >sources. Started the given binary as root and closed all other ports >except 80 via tcp on my machine. The startup log said the port 80 >was used for "...optional RTSP-over-HTTP tunneling, or for HTTP live >streaming...". Next I have started a VLC client on another PC with >the settings of the RTP/RTSP over HTTP tunneling on port 80. The VLC >just do nothing :-( If udp ports are reopened on server and the HTTP >tunneling on the client is disabled, the VLC works fine. I can't help you with this, because VLC is not our software, and this is not a VLC mailing list. (However, I've heard reports that RTSP-over-HTTP is not working properly in at least some versions of VLC; you should make sure you have an up-to-date version.) In any case, if you run "openRTSP" as a client, and give it the "-T 80" option, you'll see that RTSP-over-HTTP works properly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 22 02:32:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Jul 2011 02:32:38 -0700 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: References: <4E27E2E9.7080805@gmail.com> <4E293C3C.5020507@gmail.com> Message-ID: >I can't help you with this, because VLC is not our software, and >this is not a VLC mailing list. (However, I've heard reports that >RTSP-over-HTTP is not working properly in at least some versions of >VLC; you should make sure you have an up-to-date version.) Hmm, I've just confirmed that RTSP-over-HTTP is not working even in the latest version (1.1.11) of VLC. I'll ask the VLC developers about this now... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dezso.kancsar at gmail.com Fri Jul 22 05:51:21 2011 From: dezso.kancsar at gmail.com (Dezso Kancsar) Date: Fri, 22 Jul 2011 14:51:21 +0200 Subject: [Live-devel] RTP/RTSP over HTTP server implementation In-Reply-To: <4E293C3C.5020507@gmail.com> References: <4E27E2E9.7080805@gmail.com> <4E293C3C.5020507@gmail.com> Message-ID: <4E297249.8090001@gmail.com> > > In any case, if you run "openRTSP" as a client, and give it the "-T > 80" option, you'll see that RTSP-over-HTTP works properly. > Yes, the openRTSP seems to work fine even if only the port 80 is open on server side. The only "missing" is the visible view of the stream :-) > Hmm, I've just confirmed that RTSP-over-HTTP is not working even in > the latest version (1.1.11) of VLC. I'll ask the VLC developers > about this now... > Thanks for your extra effort. BR, Dezs?. From finlayson at live555.com Fri Jul 22 16:53:40 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Jul 2011 16:53:40 -0700 Subject: [Live-devel] RTSP Url Parameters And Live Vs Playback In-Reply-To: <4E25C255.50800@schuckmannacres.com> References: <4BBAF403456ED74981E7164ED3A4C22402E18EA9@CA-EVS02.pelco.org> <4E25C255.50800@schuckmannacres.com> Message-ID: >Checkout this thread >http://lists.live555.com/pipermail/live-devel/2011-June/013470.html > >I was trying to do something similar to what you are doing and I >think I also started down the path you are headed and ultimately >Ross showed me a much much easier way to do what i wanted. Yes, the solution that I proposed then was that rather than overriding "RTSPServer::RTSPClientSession::handleCmd_DESCRIBE()", you override "RTSPServer:: lookupServerMediaSession()". You would parse the URL suffix (the "streamName" parameter) to get the "startTime" and "endTime" parameters that you want, and then create a new "ServerMediaSession" (with appropriate "ServerMediaSubsession"s) object, passing it the "startTime" and "endTime" parameters, which it would remember. Then, for each new "ServerMediaSubsession" subclass that you're defining, you redefine the "createNewStreamSource()" virtual function to pass the "startTime" and "endTime" parameters to your source object, when you create it. (Alternatively, you could redefine the "seekStream()" virtual function in your "ServerMediaSubsession" subclasses, and call that.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sergey.kosov at project-10.de Sat Jul 23 08:50:56 2011 From: sergey.kosov at project-10.de (Sergey G. Kosov) Date: Sat, 23 Jul 2011 17:50:56 +0200 Subject: [Live-devel] Event Triggerring In-Reply-To: References: <001b01cc47f3$a24cd0f0$e6e672d0$@project-10.de> Message-ID: <000001cc4950$4fe71f60$efb55e20$@project-10.de> Hi Ross, Thanks for the advice. I have created a new Thread and call the env->taskScheduler().triggerEvent(myTrigger); function from there. It works fine. And I would like to ask if it is possible to detect when the client connects to the server. Actually I want to implement 2 features: 1. To start playing the file when the first client connects. In order to do that I think to catch somehow the event of the clients connection and then call: outputSink->startPlaying(*videoSource, afterPlaying, outputSink); 2. To change the speed of the video playing, when the client connects. For this purpose I introduced a positive floating point coefficient in the Parser() for scaling the video play without indexing. Could you please, give me a hint how to detect the clients connections / disconnection. I looked through all the test applications but haven't found any relative information to this question. Thanks in Advance, Sergey. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 22, 2011 2:12 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Event Triggerring >I thought in the direction of creating >a trigger with > >EventTriggerId myTrigger = >env->taskScheduler().createEventTrigger(myProc); > >To launch my routine within the playing process, but as I understand, I >cannot call > >env->taskScheduler().triggerEvent(myTrigger); > >within the Event Loop. Yes, of course you can. But if you're already running within the event loop, then you don't need to use the event trigger mechanism (because, if you're running within the event loop, you're already executing code in response to an event). Instead, you can just call "myProc()" directly. > Could you, please, give me a piece of advice how to launch myProc() >in between promts "Beginning to read from file..." and "...done reading >from file". It depends: When specifically do you want to call "myProc()"? If you want to do it after a certain time has elapsed (or periodically), then you can do this using "TaskScheduler::scheduleDelayedTask()". If, however, you want to do this in response to something that's happening in a separate thread (i.e., one that's *not* running the LIVE555 event loop), then the event trigger mechanism would be perfect for this. -- 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 From finlayson at live555.com Sat Jul 23 12:03:34 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Jul 2011 15:03:34 -0400 Subject: [Live-devel] Event Triggerring In-Reply-To: <000001cc4950$4fe71f60$efb55e20$@project-10.de> References: <001b01cc47f3$a24cd0f0$e6e672d0$@project-10.de> <000001cc4950$4fe71f60$efb55e20$@project-10.de> Message-ID: >And I would like to ask if it is >possible to detect when the client connects to the server. Of course. This is what a server does. >Actually I want to implement 2 features: >1. To start playing the file when the first client connects. In order to do >that I think to catch somehow the event of the clients connection and then >call: outputSink->startPlaying(*videoSource, afterPlaying, outputSink); Our code (the "OnDemandServerMediaSubsession" class) does this automatically. You *do not* need to do this yourself. All you need to do is: Define and implement your own subclass of "OnDemandServerMediaSubsession" that reimplements the two virtual functions "createNewStreamSource()" and "createNewRTPSink()". I suggest that you look at the many existing examples of these functions in our code (along with the "testOnDemandRTSPServer" code, which creates and installs "ServerMediaSession" and "ServerMediaSubsession" objecs into a server), as a model. Also, for more information, see http://www.live555.com/liveMedia/faq.html#liveInput-unicast >2. To change the speed of the video playing, when the client connects. The easiest place to do this is in your implementation of the "createNewStreamSource()" virtual function. I.e., when you create your input source object, you could pass an appropriate 'speed' parameter. To summarize (in case it's not already clear): Our server architecture makes it possible for you to develop your own server - using your own input source(s) - simply by writing new subclasses (of "OnDemandServerMediaSubsession", and, in rare cases, "RTSPServer"). You do not need to modify the supplied code to do this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbzbz at yahoo.com Sun Jul 24 01:39:36 2011 From: gbzbz at yahoo.com (gather bzbz) Date: Sun, 24 Jul 2011 01:39:36 -0700 (PDT) Subject: [Live-devel] H264-ts streaming with Amino STBs Message-ID: <1311496776.97057.YahooMailNeo@web121014.mail.ne1.yahoo.com> When streaming a ts file that contains H.264 video using testOnDemandRTSPServer to an Amino STB (aminet130), the playback had lots of hiccups. Anyone has some hints to share please? Thanks! P.S, yes, I have tried the ts files from live555.com ftp site, same results. From stathis.voukelatos at aircraftmedical.com Mon Jul 25 01:50:33 2011 From: stathis.voukelatos at aircraftmedical.com (Stathis Voukelatos) Date: Mon, 25 Jul 2011 09:50:33 +0100 Subject: [Live-devel] RTSP server socket bind error Message-ID: Hi Ross, Thanks for your reply. I agree that SO_LINGER is not the recommended way of getting round the TIME_WAIT state. I had a closer look at the RTSP server code and realized that the SO_REUSEADDR option is turned off at the server socket in RTSPServer::setUpOurSocket() and that is why the server cannot be restarted. If I set the option by removing the creation of the dummy NoReuse object, then the server can bind again to the same port straight away as expected. Is SO_REUSEADDR turned off just to avoid data corruption (e.g. there is a remote possibility of data that is hanging around from the old dead connection to be inserted to the new TCP stream after the server is restarted)? Stathis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 25 03:10:35 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Jul 2011 06:10:35 -0400 Subject: [Live-devel] RTSP server socket bind error In-Reply-To: References: Message-ID: >Thanks for your reply. I agree that SO_LINGER is not the recommended >way of getting >round the TIME_WAIT state. I had a closer look at the RTSP server >code and realized that >the SO_REUSEADDR option is turned off at the server socket in >RTSPServer::setUpOurSocket() >and that is why the server cannot be restarted. > >If I set the option by removing the creation of the dummy NoReuse >object, then the server can >bind again to the same port straight away as expected. Is >SO_REUSEADDR turned off just to avoid >data corruption (e.g. there is a remote possibility of data that is >hanging around from the old >dead connection to be inserted to the new TCP stream after the >server is restarted)? No, SO_REUSEADDR (and SO_REUSEPORT) is turned off for the server for a very simple reason: We can't have more than one server on the same host using the same port at the same time! I.e., we don't want to start a RTSP server on port 554 (for example) if the computer already has a server running with that port. Similarly for the HTTP port (for RTSP-over-HTTP tunneling, or HTTP Live Streaming): We can't have the server use a HTTP port if there's already a HTTP server running with that port. (That's why our code tries several different HTTP port numbers in succession: 80, then 8000, then 8080.) So, in conclusion: Don't change the code. If you end up having to -C a server, then just be patient and wait a few seconds before starting it up again. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From carmel.work at gmail.com Sun Jul 24 21:58:02 2011 From: carmel.work at gmail.com (=?UTF-8?B?15vXqNee15wg157Xktef?=) Date: Mon, 25 Jul 2011 07:58:02 +0300 Subject: [Live-devel] latency of mpeg2-ts transmission and reception with the library Message-ID: Hello First of all, I understand your logic about non-professional email addresses, However, I work in a company that does not encourage using its name and domain too freely and so am forced to use a gmail address. As for my question: I'm developping a library that will be used to transmit h.264 video and additional data on Mpeg2-TS stream over UDP. I'm currently using ffmpeg as a base for handling the Mpeg2-ts. (h.264 is handled by a hardware encoder and hardware decoder). I have a problem with ffmpeg and I'm considering other options such as the liveMedia library. The problem is that a delay of 2 frames is caused on reception of video by ffmpeg. I'm not certain why that happens. My question is, does the liveMedia library do any logic or might add any latency to mpeg2-ts transmission and reception except for that caused by network traffic? Carmel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cofol1986 at 126.com Mon Jul 25 04:30:09 2011 From: cofol1986 at 126.com (Tim) Date: Mon, 25 Jul 2011 11:30:09 +0000 (UTC) Subject: [Live-devel] The last silce or frame is not sended out by the media server Message-ID: Hi, when I use live555mediaServer as my rtsp server, I found that it always not send the last frame(mpeg4) or slice(h264). I look into the source code, it seems tha when it come to the last frame, the parser cann't found the next start code, so the server can't handle the last frame's data correctly. I really not familiar with the live555 library, so can anybody tell me some usefull information to handle out this bug? I will very appreciate this, thank you. From johannes.ebersold at dfki.de Mon Jul 25 07:46:37 2011 From: johannes.ebersold at dfki.de (Johannes Ebersold) Date: Mon, 25 Jul 2011 16:46:37 +0200 Subject: [Live-devel] Streaming H264 using Transport Stream Message-ID: <4E2D81CD.1090902@dfki.de> Hi, I am trying to generate a transport stream, streaming H.264. I've read a lot of postings in the mailing list and studied the examples (testH264VideoToTransportStream and testMPEG2TransportStreamer), but as a matter of fact my software won't work. First, i implemented a stream via rtp using a rtsp server and feeding single, raw H264 NAL units to it, this works fine, when streaming to VLC on another PC. But i tested this stream and it did not work with iOS and Android. So i used the streaming functionality of VLC to test which stream is okay for iOS and Android and decided to use a transport stream. And at this point I'm stuck ... My application provides a stream, i can connect to that stream with VLC, VLC fills it buffer but do not display anything, also no errors or warning. I got a source, which provides discrete NALunits, without the startcode, but i can eassily change this. And I use the following setup of live555: MySource -> H264VideoStreamDiscreteFramer -> MPEG2TransportStreamFromESSource -> MPEG2TransportStreamFramer -> SimpleRTPSink I configured the SimpleRTPSink and the Server as shown in the example (testMPEG2TransportStreamer). I think, that i missed something or missunderstood something in the usage of the Transport Stream. However, i would be thankful for any hints or help about this issue. Johannes From dekarl at spaetfruehstuecken.org Mon Jul 25 12:03:40 2011 From: dekarl at spaetfruehstuecken.org (Karl Dietz) Date: Mon, 25 Jul 2011 21:03:40 +0200 Subject: [Live-devel] Streaming H264 using Transport Stream In-Reply-To: <4E2D81CD.1090902@dfki.de> References: <4E2D81CD.1090902@dfki.de> Message-ID: <4E2DBE0C.5030309@spaetfruehstuecken.org> Hello, > I am trying to generate a transport stream, streaming H.264. I've read a > lot of postings in the mailing list and studied the examples > (testH264VideoToTransportStream and testMPEG2TransportStreamer), but as > a matter of fact my software won't work. > First, i implemented a stream via rtp using a rtsp server and feeding > single, raw H264 NAL units to it, this works fine, when streaming to VLC > on another PC. But i tested this stream and it did not work with iOS and > Android. So i used the streaming functionality of VLC to test which > stream is okay for iOS and Android and decided to use a transport stream. According to http://developer.android.com/guide/appendix/media-formats.html Android only supports transport streams in version 3.x or newer. So just must write your own demuxer. Regards, Karl From finlayson at live555.com Mon Jul 25 12:06:05 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Jul 2011 15:06:05 -0400 Subject: [Live-devel] latency of mpeg2-ts transmission and reception with the library In-Reply-To: References: Message-ID: >My question is, does the liveMedia library do any logic or might add >any latency to mpeg2-ts transmission and reception except for that >caused by network traffic? No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 25 13:50:11 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Jul 2011 16:50:11 -0400 Subject: [Live-devel] Streaming H264 using Transport Stream In-Reply-To: <4E2D81CD.1090902@dfki.de> References: <4E2D81CD.1090902@dfki.de> Message-ID: >I am trying to generate a transport stream, streaming H.264. I've >read a lot of postings in the mailing list and studied the examples >(testH264VideoToTransportStream and testMPEG2TransportStreamer), but >as a matter of fact my software won't work. >First, i implemented a stream via rtp using a rtsp server and >feeding single, raw H264 NAL units to it, this works fine, when >streaming to VLC on another PC. Good. >But i tested this stream and it did not work with iOS and Android. That's the fault of those systems. First, iOS does not support RTSP (at least, not with "Safari" or any other standard, preinstalled app). And although Android allegedly supports RTSP (according to the link that Karl Dietz noted), people have noted on this mailing list that it doesn't seem to work (at least not with our servers). (Note: If anyone can identify a specific interoperability issue that prevents Android's RTSP/RTP client from working with our server software, then please let us know.) > So i used the streaming functionality of VLC to test which stream >is okay for iOS and Android and decided to use a transport stream. Note that these systems can play Transport Streams using the "HTTP Live Streaming" protocol. Our server software support this protocol, but *only* for pre-recorded (and pre-indexed) Transport Stream *files*. Our server software *cannot* stream Transport Stream data - using "HTTP Live Streaming" - from a *live source*. So if that's what you're trying to do, then you're out of luck. Sorry. But if you still want to generate and stream Transport Stream data: >And at this point I'm stuck ... My application provides a stream, i >can connect to that stream with VLC, VLC fills it buffer but do not >display anything, also no errors or warning. I suggest that you first make sure that your generated Transport Stream data is OK, and then (and only then) worry about how to stream it. I.e., I suggest that you first generate a Transport Stream *file*, and make sure that media players can play that file OK. >I got a source, which provides discrete NALunits, without the >startcode, but i can eassily change this. NO! The NAL units that you input to "H264VideoStreamDiscreteFramer" *must not* begin with the 0x00000001 start code. > And I use the following setup of live555: > >MySource -> H264VideoStreamDiscreteFramer -> >MPEG2TransportStreamFromESSource -> MPEG2TransportStreamFramer -> >SimpleRTPSink I suggest that you first try MySource -> H264VideoStreamDiscreteFramer -> MPEG2TransportStreamFromESSource -> FileSink and make sure that your generated Transport Stream file is OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 25 17:55:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 25 Jul 2011 20:55:08 -0400 Subject: [Live-devel] SVC -> AVC In-Reply-To: <000a01cc4292$5a7d20b0$0f776210$@project-10.de> References: <000601cc3b73$4696fd80$d3c4f880$@project-10.de> <000001cc3f57$9e7da200$db78e600$@project-10.de> <003001cc400c$3b288c00$b179a400$@project-10.de> <000001cc40e1$25127e50$6f377af0$@project-10.de> <000a01cc4292$5a7d20b0$0f776210$@project-10.de> Message-ID: >I think it is possible to use setParseState(); function within the skip loop >to prevent the overflowing. But I'm not sure it this way the right way. Yes, actually this is the right thing to do. You should call "setParseState()" just after you've finished parsing (or skipping) each complete NAL unit. If you do this, and a C++ exception occurs (because more input data needs to be read), then later on - when "parse()" gets called again to re-parse the data, the parsing will resume from this same point (and the input buffer won't fill up with unparsed data). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From live-devel at lists.lammerts.org Mon Jul 25 19:23:37 2011 From: live-devel at lists.lammerts.org (Eric Lammerts) Date: Mon, 25 Jul 2011 22:23:37 -0400 Subject: [Live-devel] RTSP server socket bind error In-Reply-To: References: Message-ID: <4E2E2529.6040409@lists.lammerts.org> On 07/25/11 06:10, Ross Finlayson wrote: > No, SO_REUSEADDR (and SO_REUSEPORT) is turned off for the server for a > very simple reason: We can't have more than one server on the same host > using the same port at the same time! On Linux you can't bind twice even with SO_REUSEADDR, so it might make sense to make it a platform-dependent option. Eric From djonker88 at gmail.com Tue Jul 26 01:25:19 2011 From: djonker88 at gmail.com (Danie Jonker) Date: Tue, 26 Jul 2011 10:25:19 +0200 Subject: [Live-devel] BasicUsageEnvironment.hh linking error Message-ID: Hi all I have compiled all the libraries using Visual Studio 2010. Additionally I compiled the test programs to test everything and it worked fine. Now I'm trying to use the libraries in Qt creator (which has been configured to work with the Visual Studio compiler) to create my own streaming server. The libraries were linked in Qt as follows: > LIBS += -L"C:\Qt\2010.05\qt\lib\live\UsageEnvironment\" -libUsageEnvironment LIBS += -L"C:\Qt\2010.05\qt\lib\live\BasicUsageEnvironment\" -libBasicUsageEnvironment LIBS += -L"C:\Qt\2010.05\qt\lib\live\groupsock\" -libgroupsock LIBS += -L"C:\Qt\2010.05\qt\lib\live\liveMedia\" -libliveMedia INCLUDEPATH += C:\Qt\2010.05\qt\lib\live\liveMedia\include INCLUDEPATH += C:\Qt\2010.05\qt\lib\live\groupsock\include INCLUDEPATH += C:\Qt\2010.05\qt\lib\live\BasicUsageEnvironment\include INCLUDEPATH += C:\Qt\2010.05\qt\lib\live\UsageEnvironment\include The problem however is when I try to include the BasicUsageEnvironment.hh file in my Qt program I get the following errors: > main.obj:: error: unresolved external symbol "class DelayInterval __cdecl operator*(short,class DelayInterval const &)" (??D at YA?AVDelayInterval@@FABV0@@Z) referenced in function "void __cdecl `dynamic initializer for 'DELAY_MINUTE''(void)" (??__EDELAY_MINUTE@@YAXXZ) main.obj:: error: unresolved external symbol "class DelayInterval const DELAY_SECOND" (?DELAY_SECOND@@3VDelayInterval@@B) debug\test.exe:: error: 2 unresolved externals Does anyone know what the problem might be? Any help would be greatly appreciated. Regards Danie -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.ebersold at dfki.de Wed Jul 27 03:21:31 2011 From: johannes.ebersold at dfki.de (Johannes Ebersold) Date: Wed, 27 Jul 2011 12:21:31 +0200 Subject: [Live-devel] Streaming H264 using Transport Stream In-Reply-To: References: <4E2D81CD.1090902@dfki.de> Message-ID: <4E2FE6AB.6030600@dfki.de> Hi, thanks for your advice :) I managed to produce a TransportStream, but to do so, i had to use the following setup: MySource -> MPEG2TransportStreamFromESSource -> MPEG2TransportStreamFramer -> SimpleRTPSink without the H264VideoStreamDiscreteFramer. The Framer wants the NAL units without the startcodes, but without the startcodes the bytestream is no longer an valid ElementaryStream, so the output of the Framer is no valid ElementaryStream and the result is, of course, no valid TransportStream. The output of the encoder including the startcodes is an valid ElementaryStream (see Annex B of H.264 Standard), so all i needed to do is to get rid of the H264Framer and get the data (discrete NAL units with the startcodes) directly to the MPEG2TransportStreamFromESSource. As a matter of fact, the transport stream is not playable on iOS and Android devices. Although we managed to create a rtsp connection between an Android 2.3 and VLC streaming a mp4-File. Maybe this is all just a problem of the container, but this is out of scope of this live555 mailing list... Thanks again for your time and help, Johannes On 07/25/2011 10:50 PM, Ross Finlayson wrote: >> I am trying to generate a transport stream, streaming H.264. I've >> read a lot of postings in the mailing list and studied the examples >> (testH264VideoToTransportStream and testMPEG2TransportStreamer), but >> as a matter of fact my software won't work. >> First, i implemented a stream via rtp using a rtsp server and feeding >> single, raw H264 NAL units to it, this works fine, when streaming to >> VLC on another PC. > > Good. > > >> But i tested this stream and it did not work with iOS and Android. > > That's the fault of those systems. First, iOS does not support RTSP > (at least, not with "Safari" or any other standard, preinstalled > app). And although Android allegedly supports RTSP (according to the > link that Karl Dietz noted), people have noted on this mailing list > that it doesn't seem to work (at least not with our servers). > > (Note: If anyone can identify a specific interoperability issue that > prevents Android's RTSP/RTP client from working with our server > software, then please let us know.) > > >> So i used the streaming functionality of VLC to test which stream is >> okay for iOS and Android and decided to use a transport stream. > > Note that these systems can play Transport Streams using the "HTTP > Live Streaming" protocol. Our server software support this protocol, > but *only* for pre-recorded (and pre-indexed) Transport Stream > *files*. Our server software *cannot* stream Transport Stream data - > using "HTTP Live Streaming" - from a *live source*. So if that's what > you're trying to do, then you're out of luck. Sorry. > > > But if you still want to generate and stream Transport Stream data: > >> And at this point I'm stuck ... My application provides a stream, i >> can connect to that stream with VLC, VLC fills it buffer but do not >> display anything, also no errors or warning. > > I suggest that you first make sure that your generated Transport > Stream data is OK, and then (and only then) worry about how to stream > it. I.e., I suggest that you first generate a Transport Stream > *file*, and make sure that media players can play that file OK. > > >> I got a source, which provides discrete NALunits, without the >> startcode, but i can eassily change this. > > NO! The NAL units that you input to "H264VideoStreamDiscreteFramer" > *must not* begin with the 0x00000001 start code. > > >> And I use the following setup of live555: >> >> MySource -> H264VideoStreamDiscreteFramer -> >> MPEG2TransportStreamFromESSource -> MPEG2TransportStreamFramer -> >> SimpleRTPSink > > I suggest that you first try > MySource -> H264VideoStreamDiscreteFramer -> > MPEG2TransportStreamFromESSource -> FileSink > and make sure that your generated Transport Stream file is OK. From mike at mikebwilliams.com Wed Jul 27 07:44:29 2011 From: mike at mikebwilliams.com (Mike Williams) Date: Wed, 27 Jul 2011 10:44:29 -0400 Subject: [Live-devel] [PATCH] Allow streaming from subdirectories Message-ID: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> This patch modifies the parseRTSPRequestString section to return the entire string between the first / after the host:port and the urlSuffix section. It then conditionally pieces these together based on the request type to handle the fact that SETUP requests have track information appended. Signed-off-by: Mike Williams --- liveMedia/RTSPCommon.cpp | 11 +++-------- liveMedia/RTSPServer.cpp | 40 ++++++++++++++++++++++++++-------------- 2 files changed, 29 insertions(+), 22 deletions(-) diff --git a/liveMedia/RTSPCommon.cpp b/liveMedia/RTSPCommon.cpp index dbc16fc..f872d2e 100644 --- a/liveMedia/RTSPCommon.cpp +++ b/liveMedia/RTSPCommon.cpp @@ -92,15 +92,10 @@ Boolean parseRTSPRequestString(char const* reqStr, while (k2 <= k) resultURLSuffix[n++] = reqStr[k2++]; resultURLSuffix[n] = '\0'; - // Also look for the URL 'pre-suffix' before this: - unsigned k3 = (k1 == 0) ? 0 : --k1; - while (k3 > i && reqStr[k3] != '/') --k3; - // the URL pre-suffix comes from [k3+1,k1] - // Copy "resultURLPreSuffix": - if (k1 - k3 + 1 > resultURLPreSuffixMaxSize) return False; // there's no room - n = 0; k2 = k3+1; - while (k2 <= k1) resultURLPreSuffix[n++] = reqStr[k2++]; + if (k1 - i + 1> resultURLPreSuffixMaxSize) return False; // there's no room + n = 0; k2 = i + 1; + while (k2 <= k1 - 1) resultURLPreSuffix[n++] = reqStr[k2++]; resultURLPreSuffix[n] = '\0'; i = k + 7; // to go past " RTSP/" diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp index dcb2086..4b4650f 100644 --- a/liveMedia/RTSPServer.cpp +++ b/liveMedia/RTSPServer.cpp @@ -449,21 +449,33 @@ void RTSPServer::RTSPClientSession::handleRequestBytes(int newBytesRead) { // If there was a "Content-Length:" header, then make sure we've received all of the data that it specified: if (ptr + newBytesRead < tmpPtr + 2 + contentLength) return; // we still need more data; subsequent reads will give it to us - if (strcmp(cmdName, "OPTIONS") == 0) { - handleCmd_OPTIONS(cseq); - } else if (strcmp(cmdName, "DESCRIBE") == 0) { - handleCmd_DESCRIBE(cseq, urlSuffix, (char const*)fRequestBuffer); - } else if (strcmp(cmdName, "SETUP") == 0) { - handleCmd_SETUP(cseq, urlPreSuffix, urlSuffix, (char const*)fRequestBuffer); - } else if (strcmp(cmdName, "TEARDOWN") == 0 - || strcmp(cmdName, "PLAY") == 0 - || strcmp(cmdName, "PAUSE") == 0 - || strcmp(cmdName, "GET_PARAMETER") == 0 - || strcmp(cmdName, "SET_PARAMETER") == 0) { - handleCmd_withinSession(cmdName, urlPreSuffix, urlSuffix, cseq, - (char const*)fRequestBuffer); + char urlTotalSuffix[RTSP_PARAM_STRING_MAX] = {0}; + if (strlen(urlPreSuffix) + strlen(urlSuffix) + 2 > RTSP_PARAM_STRING_MAX) { + handleCmd_bad(cseq); } else { - handleCmd_notSupported(cseq); + + if (urlPreSuffix[0] != '\0') { + strcat(urlTotalSuffix, urlPreSuffix); + strcat(urlTotalSuffix, "/"); + } + strcat(urlTotalSuffix, urlSuffix); + + if (strcmp(cmdName, "OPTIONS") == 0) { + handleCmd_OPTIONS(cseq); + } else if (strcmp(cmdName, "DESCRIBE") == 0) { + handleCmd_DESCRIBE(cseq, urlTotalSuffix, (char const*)fRequestBuffer); + } else if (strcmp(cmdName, "SETUP") == 0) { + handleCmd_SETUP(cseq, urlPreSuffix, urlSuffix, (char const*)fRequestBuffer); + } else if (strcmp(cmdName, "TEARDOWN") == 0 + || strcmp(cmdName, "PLAY") == 0 + || strcmp(cmdName, "PAUSE") == 0 + || strcmp(cmdName, "GET_PARAMETER") == 0 + || strcmp(cmdName, "SET_PARAMETER") == 0) { + handleCmd_withinSession(cmdName, urlPreSuffix, urlSuffix, cseq, + (char const*)fRequestBuffer); + } else { + handleCmd_notSupported(cseq); + } } } else { #ifdef DEBUG -- 1.7.3.4 From finlayson at live555.com Wed Jul 27 08:30:43 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Jul 2011 11:30:43 -0400 Subject: [Live-devel] [PATCH] Allow streaming from subdirectories In-Reply-To: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> References: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> Message-ID: Thanks for the note. However, could you say some more about what specific problem you're trying to solve here? Is your intention to allow the "LIVE555 Media Server" (for example) to have its files in subdirectories (below the directory in which the media server resides), and have the (subdirectory) path in the "rtsp://" URL - e.g. rtsp://server.example.com:8554/dir1/dir2/foo.ts ??? If so, then what name do you give to the corresponding "ServerMediaSession" object in the server? "dir1/dir2/foo.ts"? Or "foo.ts"? Note that the former approach is the only one that would work (otherwise, for example, you wouldn't be able to have two separate files named "foo.ts", in separate subdirectories). The reason I bring all this up is that this request - to allow intermediate "/" characters in "rtsp://" URLs - is one that comes up often, but the issue is not quite a simple as it first appears. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mike at mikebwilliams.com Wed Jul 27 09:02:32 2011 From: mike at mikebwilliams.com (Mike Williams) Date: Wed, 27 Jul 2011 12:02:32 -0400 Subject: [Live-devel] [PATCH] Allow streaming from subdirectories In-Reply-To: References: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> Message-ID: Ross, > If so, then what name do you give to the corresponding "ServerMediaSession" > object in the server? ?"dir1/dir2/foo.ts"? ?Or "foo.ts"? ? Note that the > former approach is the only one that would work (otherwise, for example, you > wouldn't be able to have two separate files named "foo.ts", in separate > subdirectories). I pass the whole file path to the DESCRIBE command handler, so it works with the same file name in two separate sub directories, e.g. I was testing with test5.ts and testdir/test5.ts and could switch back and forth from VLC fine without restarting live555MediaServer. > > The reason I bring all this up is that this request - to allow intermediate > "/" characters in "rtsp://" URLs - is one that comes up often, but the issue > is not quite a simple as it first appears. Yes, I read the past mails on the list and your responses with links to the corresponding RFC sections. This patch may need a bit more testing for odd client corner-cases, but I posted it because it is fairly unintrusive and "works for me". Thanks, Mike From finlayson at live555.com Wed Jul 27 09:55:16 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Jul 2011 12:55:16 -0400 Subject: [Live-devel] [PATCH] Allow streaming from subdirectories In-Reply-To: References: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> Message-ID: OK, although I haven't considered this a high priority, enough people have been asking for this, that I'll probably upgrade the server code soon to support it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mike at mikebwilliams.com Wed Jul 27 10:55:49 2011 From: mike at mikebwilliams.com (Mike Williams) Date: Wed, 27 Jul 2011 13:55:49 -0400 Subject: [Live-devel] [PATCH] Allow streaming from subdirectories In-Reply-To: References: <1311777869-13206-1-git-send-email-mike@mikebwilliams.com> Message-ID: On Wed, Jul 27, 2011 at 12:55 PM, Ross Finlayson wrote: > OK, although I haven't considered this a high priority, enough people have > been asking for this, that I'll probably upgrade the server code soon to > support it. Thanks! Mike From finlayson at live555.com Wed Jul 27 14:01:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Jul 2011 17:01:22 -0400 Subject: [Live-devel] Streaming H264 using Transport Stream In-Reply-To: <4E2FE6AB.6030600@dfki.de> References: <4E2D81CD.1090902@dfki.de> <4E2FE6AB.6030600@dfki.de> Message-ID: >I managed to produce a TransportStream, but to do so, i had to use >the following setup: > >MySource -> MPEG2TransportStreamFromESSource -> >MPEG2TransportStreamFramer -> SimpleRTPSink > >without the H264VideoStreamDiscreteFramer. The Framer wants the NAL >units without the startcodes, but without the startcodes the >bytestream is no longer an valid ElementaryStream, so the output of >the Framer is no valid ElementaryStream and the result is, of >course, no valid TransportStream. The output of the encoder >including the startcodes is an valid ElementaryStream (see Annex B >of H.264 Standard), so all i needed to do is to get rid of the >H264Framer and get the data (discrete NAL units with the startcodes) >directly to the MPEG2TransportStreamFromESSource. Yes, you're correct. That was an oversight on my part. >As a matter of fact, the transport stream is not playable on iOS and >Android devices. As I noted in my last message, I recommend that you first generate a Transport Stream *file*, and check whether VLC can play that file (i.e., locally; not streamed). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From johannes.ebersold at dfki.de Thu Jul 28 07:55:07 2011 From: johannes.ebersold at dfki.de (Johannes Ebersold) Date: Thu, 28 Jul 2011 16:55:07 +0200 Subject: [Live-devel] Streaming H264 using Transport Stream In-Reply-To: References: <4E2D81CD.1090902@dfki.de> <4E2FE6AB.6030600@dfki.de> Message-ID: <4E31784B.2010806@dfki.de> On 07/27/2011 11:01 PM, Ross Finlayson wrote: > As I noted in my last message, I recommend that you first generate a > Transport Stream *file*, and check whether VLC can play that file > (i.e., locally; not streamed). I did generate a file, which was well playable by VLC and also with an Android 3 tablet. Sorry for not mentioning this. I did some more testing using the testOnDemandRTSPServer and found out, that streaming a file via unicast instead of multicast, works for all my devices: iPhone and Android 2 and 3. Now I will try to stream my live source via unicast. I've already seen the description in the FAQ :) Thank you for providing this software ... Johannes From vnijas at gmail.com Thu Jul 28 06:50:32 2011 From: vnijas at gmail.com (Nijas ec) Date: Thu, 28 Jul 2011 19:20:32 +0530 Subject: [Live-devel] LIVE MEDIA SERVER [Android] Message-ID: Hi, I'm doing my project in Android phone and I need RTSP server,I got the source code but i need to create a dynamic library help me how do i ? From zackxue at 163.com Thu Jul 28 19:19:12 2011 From: zackxue at 163.com (xue) Date: Fri, 29 Jul 2011 10:19:12 +0800 (CST) Subject: [Live-devel] Performance imporved -- SingleStep improved Message-ID: <13e0624.1717.13173b033c4.Coremail.zackxue@163.com> void BasicTaskScheduler::SingleStep(unsigned maxDelayTime) { fd_set readSet = fReadSet; // make a copy for this select() call fd_set writeSet = fWriteSet; // ditto fd_set exceptionSet = fExceptionSet; // ditto DelayInterval const& timeToDelay = fDelayQueue.timeToNextAlarm(); struct timeval tv_timeToDelay; tv_timeToDelay.tv_sec = timeToDelay.seconds(); tv_timeToDelay.tv_usec = timeToDelay.useconds(); // Very large "tv_sec" values cause select() to fail. // Don't make it any larger than 1 million seconds (11.5 days) const long MAX_TV_SEC = MILLION; if (tv_timeToDelay.tv_sec > MAX_TV_SEC) { tv_timeToDelay.tv_sec = MAX_TV_SEC; } // Also check our "maxDelayTime" parameter (if it's > 0): if (maxDelayTime > 0 && (tv_timeToDelay.tv_sec > (long)maxDelayTime/MILLION || (tv_timeToDelay.tv_sec == (long)maxDelayTime/MILLION && tv_timeToDelay.tv_usec > (long)maxDelayTime%MILLION))) { tv_timeToDelay.tv_sec = maxDelayTime/MILLION; tv_timeToDelay.tv_usec = maxDelayTime%MILLION; } /* Here should process the queue data before get new frame from source, this very important for IP net work camera, the video latency will 50ms shorter than before. Zack */ if (tv_timeToDelay.tv_sec == 0 && tv_timeToDelay.tv_usec == 0){ fDelayQueue.handleAlarm(); return ; } int selectResult = select(fMaxNumSockets, &readSet, &writeSet, &exceptionSet, &tv_timeToDelay); if (selectResult < 0) { #if defined(__WIN32__) || defined(_WIN32) int err = WSAGetLastError(); // For some unknown reason, select() in Windoze sometimes fails with WSAEINVAL if // it was called with no entries set in "readSet". If this happens, ignore it: if (err == WSAEINVAL && readSet.fd_count == 0) { err = EINTR; // To stop this from happening again, create a dummy socket: int dummySocketNum = socket(AF_INET, SOCK_DGRAM, 0); FD_SET((unsigned)dummySocketNum, &fReadSet); FD_SET((unsigned)dummySocketNum, &fWriteSet); FD_SET((unsigned)dummySocketNum, &fExceptionSet); } if (err != EINTR) { #else if (errno != EINTR && errno != EAGAIN) { #endif // Unexpected error - treat this as fatal: #if !defined(_WIN32_WCE) perror("BasicTaskScheduler::SingleStep(): select() fails"); #endif abort(); } } // Call the handler function for one readable socket: HandlerIterator iter(*fHandlers); HandlerDescriptor* handler; // To ensure forward progress through the handlers, begin past the last // socket number that we handled: if (fLastHandledSocketNum >= 0) { while ((handler = iter.next()) != NULL) { if (handler->socketNum == fLastHandledSocketNum) break; } if (handler == NULL) { fLastHandledSocketNum = -1; iter.reset(); // start from the beginning instead } } while ((handler = iter.next()) != NULL) { int sock = handler->socketNum; // alias int resultConditionSet = 0; if (FD_ISSET(sock, &readSet) && FD_ISSET(sock, &fReadSet)/*sanity check*/) resultConditionSet |= SOCKET_READABLE; if (FD_ISSET(sock, &writeSet) && FD_ISSET(sock, &fWriteSet)/*sanity check*/) resultConditionSet |= SOCKET_WRITABLE; if (FD_ISSET(sock, &exceptionSet) && FD_ISSET(sock, &fExceptionSet)/*sanity check*/) resultConditionSet |= SOCKET_EXCEPTION; if ((resultConditionSet&handler->conditionSet) != 0 && handler->handlerProc != NULL) { fLastHandledSocketNum = sock; // Note: we set "fLastHandledSocketNum" before calling the handler, // in case the handler calls "doEventLoop()" reentrantly. (*handler->handlerProc)(handler->clientData, resultConditionSet); break; } } if (handler == NULL && fLastHandledSocketNum >= 0) { // We didn't call a handler, but we didn't get to check all of them, // so try again from the beginning: iter.reset(); while ((handler = iter.next()) != NULL) { int sock = handler->socketNum; // alias int resultConditionSet = 0; if (FD_ISSET(sock, &readSet) && FD_ISSET(sock, &fReadSet)/*sanity check*/) resultConditionSet |= SOCKET_READABLE; if (FD_ISSET(sock, &writeSet) && FD_ISSET(sock, &fWriteSet)/*sanity check*/) resultConditionSet |= SOCKET_WRITABLE; if (FD_ISSET(sock, &exceptionSet) && FD_ISSET(sock, &fExceptionSet)/*sanity check*/) resultConditionSet |= SOCKET_EXCEPTION; if ((resultConditionSet&handler->conditionSet) != 0 && handler->handlerProc != NULL) { fLastHandledSocketNum = sock; // Note: we set "fLastHandledSocketNum" before calling the handler, // in case the handler calls "doEventLoop()" reentrantly. (*handler->handlerProc)(handler->clientData, resultConditionSet); break; } } if (handler == NULL) fLastHandledSocketNum = -1;//because we didn't call a handler } // Also handle any delayed event that may have come due. (Note that we do this *after* calling a socket // handler, in case the delayed event handler modifies the set of readable sockets.) fDelayQueue.handleAlarm(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From zackxue at 163.com Thu Jul 28 19:21:27 2011 From: zackxue at 163.com (xue) Date: Fri, 29 Jul 2011 10:21:27 +0800 (CST) Subject: [Live-devel] Performance imporved -- BasicTaskScheduler base linux epoll Message-ID: Linux Epoll patch. Just for reference -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BasicTaskSchedulerEpoll.cpp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BasicTaskSchedulerEpoll.h Type: application/octet-stream Size: 1793 bytes Desc: not available URL: From finlayson at live555.com Thu Jul 28 20:22:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 28 Jul 2011 23:22:07 -0400 Subject: [Live-devel] Performance imporved -- BasicTaskScheduler base linux epoll In-Reply-To: References: Message-ID: <2F219E54-46B3-408A-8850-4DC2A539CEBD@live555.com> On Jul 28, 2011, at 10:21 PM, xue wrote: > Linux Epoll patch. Just for reference Thanks. However, I won't (can't) make such a change to the released code, because "epoll()" - unlike "select()" - is not portable across multiple OSs. It's important to understand that the "BasicTaskScheduler" class is just that - 'basic'. There's no reason why you (or other developers) can't write your own, specialized "TaskScheduler" subclass, and use that - instead of "BasicTaskScheduler" - in your own code. Therefore, if you decide to use this class in your own application, you should give it a name other than "BasicTaskScheduler". That way, you it won't conflict with the released code (which you will be able to continue to update 'in place'). Just use your new class name - rather than "BasicTaskScheduler" - in your application code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 28 20:37:56 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 28 Jul 2011 23:37:56 -0400 Subject: [Live-devel] Performance imporved -- SingleStep improved In-Reply-To: <13e0624.1717.13173b033c4.Coremail.zackxue@163.com> References: <13e0624.1717.13173b033c4.Coremail.zackxue@163.com> Message-ID: <5A9BB9D9-425E-4565-A43D-1B9C353779AB@live555.com> On Jul 28, 2011, at 10:19 PM, xue wrote: > /* Here should process the queue data before get new frame from source, this very important for IP net work camera, the video latency will 50ms shorter than before. Zack */ > if (tv_timeToDelay.tv_sec == 0 && tv_timeToDelay.tv_usec == 0){ > fDelayQueue.handleAlarm(); > return ; > } I don't understand how this could make any difference, because - within the event loop - "SingleStep()" is called over and over again. Therefore, in the current code, the event loop consists of select() socket handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) ? Your proposed change merely changes this to: delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) delay queue handler (if any) select() socket handler (if any) delay queue handler (if any) ? Calling up to two delay queue handlers for each call to "select()" shouldn't make a difference (except perhaps in weird circumstances). In any case: 1/ Your proposed code change is wrong, because of the possibility that your new delay queue handler will cause "fReadSet" to be modified. (Note the comment at the end of the "SingleStep()" code. 2/ As I noted in my previous message, you are welcome (of course) to make this change in your own code, but if you do, you should change the name of the class, so that it doesn't clash with the name "BasicTaskScheduler" used by the released code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Jul 29 07:09:12 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Jul 2011 14:09:12 +0000 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() Message-ID: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> While I thought this was working before for me it is definitely always returning false at the moment. I am trying to track this down to see what I may have done to break this but I cannot figure out how the variable it returns ever gets set. It is constructed false and passed on in each MultiFramedRTPSource::doGetNextFrame1(). So how does this get set? In my current scenario it never does :( Rtsp connected to H264 stream from a security camera. Stream plays fine in VLC, recorded video is ok, but never ever syncs and I wanted to use that sync to trigger the beginning of recording . This use to work with the same stream(but there have been firmware upgrades). I am just trying to find out if my setup has caused this TCP/UDP?, etc. How does it work when it is working correctly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 07:56:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Jul 2011 10:56:08 -0400 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> Message-ID: On Jul 29, 2011, at 10:09 AM, Jeff Shanab wrote: > While I thought this was working before for me it is definitely always returning false at the moment. I am trying to track this down to see what I may have done to break this but I cannot figure out how the variable it returns ever gets set. It is constructed false and passed on in each MultiFramedRTPSource::doGetNextFrame1(). > > So how does this get set? It gets set by the RTP receiving code, when it receives RTCP "SR" packets. If, however, the RTP receiving code doesn't receive any RTCP "SR" packets (e.g., because the sender does not implement RTCP), then "hasBeenSynchronizedUsingRTCP()" will never return True. > Rtsp connected to H264 stream from a security camera. Stream plays fine in VLC, recorded video is ok, but never ever syncs and I wanted to use that sync to trigger the beginning of recording . Does your camera stream audio as well as video? If it streams only video, then I'm not sure what 'syncs' could mean. If, however, your camera streams both audio and video, then it must implement RTCP, otherwise receiving client will never be able to synchronize audio and video. So in short: Does your camera send RTCP packets? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dezso.kancsar at gmail.com Fri Jul 29 07:13:49 2011 From: dezso.kancsar at gmail.com (Dezso Kancsar) Date: Fri, 29 Jul 2011 16:13:49 +0200 Subject: [Live-devel] Adding a ServerMediaSession to a running RTSPServer results a 'Bad file descriptor' error in BasicTaskScheduler::SingleStep(): select() Message-ID: <4E32C01D.2050304@gmail.com> Hi Ross, Could you give me directions how to add a ServerMediaSession to a running RTSPServer. I have started the RTSPServer in a pthread and wanted to add a new ServerMediaSession to it from another thread, but I've got only a 'Bad file descriptor' error even if the file was available on the current path. I also want to ask you for directions how to implement on demand streaming based on frames available in the memory instead of reading them from files. Thanks & BR, D. From jshanab at smartwire.com Fri Jul 29 08:15:20 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Jul 2011 15:15:20 +0000 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> Thanks that explains it, the last firmware upgrade allows us to disable audio. The PTS still jumps even for video only, do I need to explicitly request sync of the video stream when I only want video? One last question, does sync offset the PTS and allow it to appear as if it is the same ntp stamp as the receiver? From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 29, 2011 9:56 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] hasBeenSynchronizedUsingRTCP() On Jul 29, 2011, at 10:09 AM, Jeff Shanab wrote: While I thought this was working before for me it is definitely always returning false at the moment. I am trying to track this down to see what I may have done to break this but I cannot figure out how the variable it returns ever gets set. It is constructed false and passed on in each MultiFramedRTPSource::doGetNextFrame1(). So how does this get set? It gets set by the RTP receiving code, when it receives RTCP "SR" packets. If, however, the RTP receiving code doesn't receive any RTCP "SR" packets (e.g., because the sender does not implement RTCP), then "hasBeenSynchronizedUsingRTCP()" will never return True. Rtsp connected to H264 stream from a security camera. Stream plays fine in VLC, recorded video is ok, but never ever syncs and I wanted to use that sync to trigger the beginning of recording . Does your camera stream audio as well as video? If it streams only video, then I'm not sure what 'syncs' could mean. If, however, your camera streams both audio and video, then it must implement RTCP, otherwise receiving client will never be able to synchronize audio and video. So in short: Does your camera send RTCP packets? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 08:27:43 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Jul 2011 11:27:43 -0400 Subject: [Live-devel] Adding a ServerMediaSession to a running RTSPServer results a 'Bad file descriptor' error in BasicTaskScheduler::SingleStep(): select() In-Reply-To: <4E32C01D.2050304@gmail.com> References: <4E32C01D.2050304@gmail.com> Message-ID: > Could you give me directions how to add a ServerMediaSession to a running RTSPServer. Call "RTSPServer::addServerMediaSession()". You can do this at any time. (Ditto for "RTSPServer::removeServerMediaSession()".) > I have started the RTSPServer in a pthread and wanted to add a new ServerMediaSession to it from another thread When you read the FAQ - as you were asked to do before posting to this mailing list - you will have learned that LIVE555 applications run in a single-threaded event loop, and that you should not call LIVE555 code (except perhaps for "triggerEvent()") from a separate thread. Because LIVE555 applications run within an event loop, if you want to add a new "ServerMediaSession" object to your RTSP server, then this must happen in an event handler - i.e., in response to an event that gets handled within the event loop. You can, however, trigger events from a separate thread, using the "event trigger" mechanism (again, described in the FAQ). > I also want to ask you for directions how to implement on demand streaming based on frames available in the memory instead of reading them from files. If your memory buffer is static (i.e., its contents do not change), then you can use the "ByteStreamMemoryBufferSource" class (instead of "ByteStreamFileSource"). Otherwise, you will need to write your own source class - perhaps based on the "DeviceSource" code - as described in the FAQ. Everybody, please read the FAQ! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 08:40:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Jul 2011 11:40:07 -0400 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> Message-ID: On Jul 29, 2011, at 11:15 AM, Jeff Shanab wrote: > Thanks that explains it, the last firmware upgrade allows us to disable audio. > > The PTS still jumps even for video only That suggests that the camera does, indeed, send RTCP "SR" packets. See http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue > , do I need to explicitly request sync of the video stream when I only want video? The "hasBeenSynchronizedUsingRTCP()" function does not 'request' synchronization; synchronization happens automatically off RTCP "SR" packets are received. The "hasBeenSynchronizedUsingRTCP()" function merely tells you whether the received presentation times can be considered accurate. > One last question, does sync offset the PTS and allow it to appear as if it is the same ntp stamp as the receiver? I don't understand this question. But application code should never need to concern itself with RTP timestamps. Just work with "presentation times". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Jul 29 09:18:25 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Jul 2011 16:18:25 +0000 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> OK, I reset the firmware option and did some more stepping through the code and I see the fHasBeenSynchronized being set during the noteincomingSR but then it manages to get set back to 0 before the line resultHasBeenSyncedUsingRTCP = fHasBeenSynchronized in RTPSource::noteincomeingPacket. I am gonna sssume this is a different situation, an non sr packet. But I have not yet figured out the flow to figure out why the call to hasBeenSynchronizedUsingRTCP()" always returns false I see in the code all the offsets are handled, and using just the PTS has been working. I do not know what I have done to break this in my code :( Is there documentation other than the doxygen that gives a bit more info? From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 29, 2011 10:40 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] hasBeenSynchronizedUsingRTCP() On Jul 29, 2011, at 11:15 AM, Jeff Shanab wrote: Thanks that explains it, the last firmware upgrade allows us to disable audio. The PTS still jumps even for video only That suggests that the camera does, indeed, send RTCP "SR" packets. See http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue , do I need to explicitly request sync of the video stream when I only want video? The "hasBeenSynchronizedUsingRTCP()" function does not 'request' synchronization; synchronization happens automatically off RTCP "SR" packets are received. The "hasBeenSynchronizedUsingRTCP()" function merely tells you whether the received presentation times can be considered accurate. One last question, does sync offset the PTS and allow it to appear as if it is the same ntp stamp as the receiver? I don't understand this question. But application code should never need to concern itself with RTP timestamps. Just work with "presentation times". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 11:14:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Jul 2011 14:14:22 -0400 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> Message-ID: <524176C8-046D-4E6F-86BB-9005E0B1EC49@live555.com> If your call to "hasBeenSynchronizedUsingRTCP()" *always* returns False, then that means that you (the receiving code) are never getting any RTCP "SR" packets, which probably means that the server is not sending such packets. That's a problem with your server (but not a serious one, unless it is streaming both video and audio). But if you receive at least one RTCP "SR" packet, then "hasBeenSynchronizedUsingRTCP()" will always return True thereafter. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Jul 29 11:49:57 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Jul 2011 18:49:57 +0000 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <524176C8-046D-4E6F-86BB-9005E0B1EC49@live555.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> <524176C8-046D-4E6F-86BB-9005E0B1EC49@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B148EEF@IL-BOL-EXCH01.smartwire.com> I traced the code and I AM getting the packets.... But every rtp timestamp is 0! MultiFramedRTPSource::networkReadhandler() following the line Unsigned rtpTimestamp = ( ntohl(*u_int32_t*)(bPacket-data())); ADVANCE(4) The PTS stamps are filled in, so I guess I can hack around it. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 29, 2011 1:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] hasBeenSynchronizedUsingRTCP() If your call to "hasBeenSynchronizedUsingRTCP()" *always* returns False, then that means that you (the receiving code) are never getting any RTCP "SR" packets, which probably means that the server is not sending such packets. That's a problem with your server (but not a serious one, unless it is streaming both video and audio). But if you receive at least one RTCP "SR" packet, then "hasBeenSynchronizedUsingRTCP()" will always return True thereafter. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 12:19:26 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Jul 2011 15:19:26 -0400 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B148EEF@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> <524176C8-046D-4E6F-86BB-9005E0B1EC49@live555.com> <615FD77639372542BF647F5EBAA2DBC20B148EEF@IL-BOL-EXCH01.smartwire.com> Message-ID: <51BB62FB-4083-4085-9773-9CEDB9C5A5EB@live555.com> On Jul 29, 2011, at 2:49 PM, Jeff Shanab wrote: > I traced the code and I AM getting the packets?. > > But every rtp timestamp is 0! Arggh, now you're talking about something completely different: RTP timestamps - which I specifically said you don't need to care about!!! So, are you talking about "hasBeenSynchronizedUsingRTCP()", RTP timestamps (which you don't need to care about), or presentation times (which you do need to care about)? But anyway, to summarize (and this will be my last posting on this thread): 1/ If you ever reach the code at line 380 of "liveMedia/RTPSource.cpp", then - You have received a RTCP "SR" packet, and - "hasBeenSynchronizedUsingRTCP()" will always return True from then on, and - the presentation times for video (and audio, if present) should be correctly synchronized from then on. 2/ If "hasBeenSynchronizedUsingRTCP()" always returns False, then that must mean that you're not receiving any RTCP "SR" packets, which is probably because the server does not send any. But that doesn't really matter, unless you're receiving both a video stream and an audio stream (in which case they can never be synchronized). 3/ All you really care about is the presentation times, anyway. 4/ You absolutely do not need to 'hack' the supplied code. Again, this will be my last posting on this thread. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Fri Jul 29 12:45:48 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Fri, 29 Jul 2011 19:45:48 +0000 Subject: [Live-devel] hasBeenSynchronizedUsingRTCP() In-Reply-To: <51BB62FB-4083-4085-9773-9CEDB9C5A5EB@live555.com> References: <615FD77639372542BF647F5EBAA2DBC20B148DBB@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E08@IL-BOL-EXCH01.smartwire.com> <615FD77639372542BF647F5EBAA2DBC20B148E5C@IL-BOL-EXCH01.smartwire.com> <524176C8-046D-4E6F-86BB-9005E0B1EC49@live555.com> <615FD77639372542BF647F5EBAA2DBC20B148EEF@IL-BOL-EXCH01.smartwire.com> <51BB62FB-4083-4085-9773-9CEDB9C5A5EB@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B148F31@IL-BOL-EXCH01.smartwire.com> Well, there is a problem here then.. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 29, 2011 2:19 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] hasBeenSynchronizedUsingRTCP() On Jul 29, 2011, at 2:49 PM, Jeff Shanab wrote: I traced the code and I AM getting the packets.... But every rtp timestamp is 0! Arggh, now you're talking about something completely different: RTP timestamps - which I specifically said you don't need to care about!!! So, are you talking about "hasBeenSynchronizedUsingRTCP()", RTP timestamps (which you don't need to care about), or presentation times (which you do need to care about)? My call to "hasBeenSynchronizedUsingRTCP()" is always returning false. But anyway, to summarize (and this will be my last posting on this thread): 1/ If you ever reach the code at line 380 of "liveMedia/RTPSource.cpp", then - You have received a RTCP "SR" packet, and - "hasBeenSynchronizedUsingRTCP()" will always return True from then on, and - the presentation times for video (and audio, if present) should be correctly synchronized from then on. I am hitting this line and fHasBeenSyncronized is therefore being set to true. (at that moment in time) (Perhaps I need to protect it) 2/ If "hasBeenSynchronizedUsingRTCP()" always returns False, then that must mean that you're not receiving any RTCP "SR" packets, which is probably because the server does not send any. But that doesn't really matter, unless you're receiving both a video stream and an audio stream (in which case they can never be synchronized). But hasBeenSynchronizedUsingRTCP() does not return fHasBeenSyncronized, it returns fCurPacketHasBeenSynchronizedUsingRTCP which I have not yet found where it is set. I see construted to false and I see returned and I see passed in nextPacket->use. Now on 428 in MultiframedRtpSource I see where it would be set as a return argument, but at that breakpoint it is 0. Not sure where that gets reset. But when I manipulate the camera settings and it starts to have a nonzero rtpTimestamp. It starts to work at the higher level ok. So a non-zero or at least changing rtp timestamp does seem to make a difference. 3/ All you really care about is the presentation times, anyway. I was depending on them being syncyed, file split boundries and names are derived from this. 4/ You absolutely do not need to 'hack' the supplied code. AMEN!, (and I agree) Again, this will be my last posting on this thread. Darn :( Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinlijie2011 at 163.com Fri Jul 29 18:05:11 2011 From: yinlijie2011 at 163.com (yinlijie2011) Date: Sat, 30 Jul 2011 09:05:11 +0800 (CST) Subject: [Live-devel] Problem about openRTSP receive MP4 Message-ID: <544bad3e.df61.1317892cc9f.Coremail.yinlijie2011@163.com> Dear, Thank you supply live555, and I use it for a program receive stream media, and save them to a mp4 file. I know live555 can't convert file format(Am I wrong?). So there are h.264 video and aac audio in RTSP's server. Use order "openRTSP -4 rtsp://... > test.mp4" to receive stream media. When the end, the QuickTime can't play the mp4 file, why? What should I do? Thank you! PS: My English is so bad, don't laugh me. Best Wishes! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 29 21:49:02 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 30 Jul 2011 00:49:02 -0400 Subject: [Live-devel] Problem about openRTSP receive MP4 In-Reply-To: <544bad3e.df61.1317892cc9f.Coremail.yinlijie2011@163.com> References: <544bad3e.df61.1317892cc9f.Coremail.yinlijie2011@163.com> Message-ID: <6130FBDE-7357-4769-AA95-C64EDB4A4768@live555.com> > Use order "openRTSP -4 rtsp://... > test.mp4" to receive stream media. When the end, the QuickTime can't play the mp4 file, why? Unfortunately, I don't know. However, it's very important that you specify the correct video frame rate, width and height - using the -f -w and -h options - see http://www.live555.com/openRTSP/#quicktime You might also try playing your file using VLC: http://www.videolan.org/vlc (VLC can often play files that QuickTime Player cannot.) > PS: My English is so bad, don't laugh me. Your English is good (and much better than my Chinese :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: