Ross, Thanks for your reply and sorry for the confusing. Let me clarify. My scenarios is as following, 1) I created a Android based program to capture and encode H264 NAL units; 2) On Android, I seperate the H264 NAL units to Fragmentation Units (FUs-A standard based) and send these FUs-A packages by RTP/UDP via my own RTP wrapper, to Live555 server; 3) While on Live555 server side, I wrote a new H264 Source follow the http://www.live555.com/liveMedia/faq.html#liveInput-unicast. to receive the above H264-FUs-A/RTP; 4) Also on Live555 server side, I had a H264VideoRTPSink;
The problem is on step 2) & 3), when live555 received the FUs-A, it cannot delivery successfully to the H264VideoRTPSink if I use FUs-A. However, if I didn't do the fragmentation on android (send each H264 NAL units by one RTP package), then it works well. Please help. Best Regards Ajax Chai =============================================================================== Message: 4 Date: Mon, 2 Jul 2012 07:47:20 -0700 From: Ross Finlayson <[email protected]> To: LIVE555 Streaming Media - development & use <[email protected]> Subject: Re: [Live-devel] About the H264 over RTP FA Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" I find your message confusing, because here you're talking about transmitting H.264 over RTP: > First thank you give the guide line on how to let Live555 to take input from > a live source (H264 pictures over RTP) > http://www.live555.com/liveMedia/faq.html#liveInput-unicast. But here you're talking about *receiving* H.264 over RTP: > I followed this guideline and made it successfully to receive the H264/RTP > Live Stream from a live source (which sends Single NAL Unit Packet). And here you seem to be talking about both transmitting and receiving, but I'm not sure: > The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A) > then Live555 failed to parse this live stream. But anyway, the important thing to understand is that our software *automatically* handles the fragmentation (when transmitting) and defragmentation (when receiving) H.264 NAL units. Your application software (which uses our software) *should not* deal with FU-A NAL units at all. In particular: - When transmitting H.264 over RTP, you should deliver your (unfragmented!) NAL units - one at a time - to a "H264VideoStreamDiscreteFramer", and then into a "H264VideoRTPSink". - When receiving H.64 over RTP, you use a "H264VideoRTPSource". Any fragmented NAL units in the RTP stream will automatically be defragmented before delivery. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120702/3c99a90d/attachment-0001.html> ------------------------------ Message: 5 Date: Mon, 2 Jul 2012 18:28:00 +0200 From: Jes?s Legan?s <[email protected]> To: "LIVE555 Streaming Media - development & use" <[email protected]> Subject: Re: [Live-devel] Set ProxyServerMediaSession::fProxyRTSPClient as protected Message-ID: <cab3aa2+hakd7kaqxiu7ag9ac_vmnd24jd7ax3yn4lz+cfyn...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 >> Yes, but note that the existing "ProxyServerMediaSession" constructor >> already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient" >> object), so you'll need to delete this (using "Medium::close()") >> first, before assigning your new "ProxyRTSPClient" subclass object. >> > Oh, i didn't thought about it, thanks for the advice... :-) > I have been talking with my boss and we got a better solution to this: instead of set the constructor to protected, redefine it and close the previous connection before create the new one, have this connection created on a protected method so only is needed to be overloaded just this method, so the connection is only done one time and also the constructor gets untouched :-) -- Jes?s Legan?s Combarro Software developer at Vaelsys ------------------------------ Message: 6 Date: Mon, 2 Jul 2012 12:25:49 -0700 From: "Michael L. Boom" <[email protected]> To: <[email protected]> Subject: [Live-devel] Trick Play and the Live 555 Server Message-ID: <FFCE53D6C1494E3BB0F9885FB200444E@Work> Content-Type: text/plain; charset="iso-8859-1" I am writing a proxy for VOD servers. I am using the Live 555 server for testing. The version I have is about 1 year old. How can I tell, from the source code, what version I have? If I say play range npt=30-60 at scale 1 it works. If I say play range npt=30-60 at scale 2 it goes way beyond 60 before it stops. Is (or was) this a bug or am I using it wrong. Also, what player would you suggest to test the rewind. The VLC player doesn't seem to support it (or am I using that wrong also). Can you recommend any other free RTSP servers that I can test with? If I want to play backwards from time 60 to time 30 do I just say Range: npt=60-30 or Range: npt=30-60? What scale should I use for rewind? Any info would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120702/2f94a68b/attachment-0001.html> ------------------------------ Message: 7 Date: Mon, 2 Jul 2012 13:43:20 -0700 From: Ross Finlayson <[email protected]> To: LIVE555 Streaming Media - development & use <[email protected]> Subject: Re: [Live-devel] Trick Play and the Live 555 Server Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" > I am writing a proxy for VOD servers. I am using the Live 555 server for > testing. The version I have is about 1 year old. How can I tell, from the > source code, what version I have? See http://www.live555.com/liveMedia/faq.html#latest-version As noted in the FAQ, only the latest version of the code is supported. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120702/d60f4a09/attachment-0001.html> ------------------------------ Message: 8 Date: Mon, 02 Jul 2012 23:29:29 +0200 From: "Ralf Globisch" <[email protected]> To: <[email protected]> Subject: [Live-devel] RTSP connection management issue Message-ID: <[email protected]> Content-Type: text/plain; charset=US-ASCII Hi Ross, If an RTSP request belonging to an established session is sent over a new TCP connection, the server seems to respond with a "405 Method Not Allowed". According to the RFC, RTSP requests can be transmitted in several different ways including one connection per request/response transaction? This is especially a problem on android devices that experience connection issues. It seems network issues *sometimes* cause subsequent RTSP requests to be sent over a new connection resulting in the 405 response. We've observed this using VLC on android (which uses live555) and replicated it with a python script using the *latest* version of the live555 RTSP server. Output re-using connection: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:20:10 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:20:10 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:20:10 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 269EF060 PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Jul 02 2012 21:20:10 GMT Range: npt=0.000- Session: 269EF060 RTP-Info: url=rtsp://127.0.0.1:8554/test.aac/track1;seq=27747;rtptime=3310178955 TEARDOWN response: RTSP/1.0 200 OK CSeq: 6 Date: Mon, Jul 02 2012 21:20:12 GMT Output with new connections per request: OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jul 02 2012 21:23:20 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jul 02 2012 21:23:20 GMT Content-Base: rtsp://127.0.0.1:8554/test.aac/ Content-Type: application/sdp Content-Length: 518 v=0 o=- 1341255550959061 1 IN IP4 192.168.1.16 s=AAC Audio, streamed by the LIVE555 Media Server i=test.aac t=0 0 a=tool:LIVE555 Streaming Media v2012.06.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AAC Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:test.aac m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 MPEG4-GENERIC/44100/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 a=control:track1 SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jul 02 2012 21:23:20 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=43754-43755;server_port=6970-6971 Session: 4BF1E275 PLAY response: RTSP/1.0 405 Method Not Allowed CSeq: 5 Date: Mon, Jul 02 2012 21:23:20 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER TEARDOWN response: RTSP/1.0 405 Method Not Allowed CSeq: 6 Date: Mon, Jul 02 2012 21:23:22 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER If it helps, I could send you the python script to replicate the issue. Do you consider this to be a bug? Best regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. ------------------------------ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 105, Issue 2 ****************************************** _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
