[Live-devel] live-devel Digest, Vol 105, Issue 2
Chai, Zheng (Ajax)
ajax.chai at alcatel-lucent.com
Tue Jul 3 02:00:14 PDT 2012
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 <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Subject: Re: [Live-devel] About the H264 over RTP FA
Message-ID: <FBBA802B-D3E5-4FEC-8D32-2BE3FDD6718A at live555.com>
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 <jesus.lc at vaelsys.com>
To: "LIVE555 Streaming Media - development & use"
<live-devel at ns.live555.com>
Subject: Re: [Live-devel] Set
ProxyServerMediaSession::fProxyRTSPClient as protected
Message-ID:
<CAB3aA2+hAkd7kAQXiu7Ag9Ac_vmnD24Jd7aX3yN4LZ+cFyNKHw at 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" <mboom at channelislands.com>
To: <live-devel at ns.live555.com>
Subject: [Live-devel] Trick Play and the Live 555 Server
Message-ID: <FFCE53D6C1494E3BB0F9885FB200444E at 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 <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Subject: Re: [Live-devel] Trick Play and the Live 555 Server
Message-ID: <13D9EA45-1A61-4C1B-95F0-D838CD00AD6C at live555.com>
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" <rglobisch at csir.co.za>
To: <live-devel at ns.live555.com>
Subject: [Live-devel] RTSP connection management issue
Message-ID: <4FF22ED90200004D0006EB37 at pta-emo.csir.co.za>
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
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
End of live-devel Digest, Vol 105, Issue 2
******************************************
More information about the live-devel
mailing list