[Live-devel] live-devel Digest, Vol 105, Issue 4
Chai, Zheng (Ajax)
ajax.chai at alcatel-lucent.com
Thu Jul 5 04:41:40 PDT 2012
Ross,
>> 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.
>Remember that - to receive H.264/RTP packets - you must use a "H264VideoRTPSource" object. If you are doing this, and you find that the "H264VideoRTPSource" object is not defragmenting the FU-A fragments >properly, then perhaps the incoming H.264/RTP are not properly formed - i.e., do not properly conform to the H.264 RTP payload format??
>Because you are not using our software to construct and stream the H.264/RTP packets towards our server, then we can't help you here; you're going to have to figure out for yourself why "H264VideoRTPSource" is >not behaving as expected. Sorry. (But Remember, You Have Complete Source Code.)
I debugged the whole day, and I found the strange behavior of Live555 to receive the FU-As. Even I followed the following H264 Over RTP (RFC3984), Live555 still can not receive/parse them correctly.
When I do the H264 video capture and fragmentation, I send as the RTP package as following order.
1) Send the SPS RTP package: {[12bytes - rtp header][NALU Header: 0x67 - 1 byte][8-bytes sps]}; -- note: my video source totally 9 bytes SPS.
2) Send the PPS RTP package: {[12bytes - rtp header][NALU Header: 0x68 - 1 byte][3-bytes pps]}; -- note: my video source totally 4 bytes PPS;
Note: 1) & 2) will be sent on every Iframe is hitting.
Then, if needn't package fragmentation (<1400)
Send Single NAL units: {[12bytes - rtp header][NALU Header 0x65 or 0x61 - 1 byte][00 00 00 01 - 4bytes starter][NALU frame H264 data]};
Else If needs package fragmentation(>=1400)
Send the FU-A RTP start package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x81 - 1byte FU-A header, S bit is set][00 00 00 01 - 4bytes starter][NALU frame H264 data]};
Then send the FU-A RTP middle package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x01 - 1byte FU-A header][NALU frame H264 data]};
Then send the RU-A RTP end package: {[12bytes- rtp header][0x7c - 1byte FU-A indicator][0x41 - 1byte FU-A header, E bit is set][NALU frame H264 data]};
I was confused that why Live555 can not parse above data. from my debugging, seems it can handle the FU-As and merge them togeter, but it can not handle the starter (00 00 00 01) and NALU type correctly.
Please point me out if my data sending is not correct to meet Live555's requirements. Appreciate you help on this.
Best Regards
Ajax Chai
-----Original Message-----
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com
Sent: Wednesday, July 04, 2012 6:04 AM
To: live-devel at ns.live555.com
Subject: live-devel Digest, Vol 105, Issue 4
Send live-devel mailing list submissions to
live-devel at lists.live555.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.live555.com/mailman/listinfo/live-devel
or, via email, send a message with subject or body 'help' to
live-devel-request at lists.live555.com
You can reach the person managing the list at
live-devel-owner at lists.live555.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..."
Today's Topics:
1. Re: About the H264 over RTP FA (Ross Finlayson)
2. Re: Regarding the build (dushyanth)
3. mpeg-2 transport stream Rate (Ran Shalit)
4. Re: Regarding the build (Erlandsson, Claes P (CERLANDS))
5. RTSP - Absolute Time (Erlandsson, Claes P (CERLANDS))
6. Re: RTSP - Absolute Time (Ross Finlayson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 3 Jul 2012 02:12:47 -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: <489ABC76-6837-4E98-BC61-4119D4EC2C4F at live555.com>
Content-Type: text/plain; charset="us-ascii"
> 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.
Remember that - to receive H.264/RTP packets - you must use a "H264VideoRTPSource" object. If you are doing this, and you find that the "H264VideoRTPSource" object is not defragmenting the FU-A fragments properly, then perhaps the incoming H.264/RTP are not properly formed - i.e., do not properly conform to the H.264 RTP payload format??
Because you are not using our software to construct and stream the H.264/RTP packets towards our server, then we can't help you here; you're going to have to figure out for yourself why "H264VideoRTPSource" is not behaving as expected. Sorry. (But Remember, You Have Complete Source Code.)
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/20120703/9e3ae9f6/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 3 Jul 2012 11:04:02 -0400
From: dushyanth <dushyanth.subramanya at gmail.com>
To: live-devel at ns.live555.com
Subject: Re: [Live-devel] Regarding the build
Message-ID:
<CAGbJsJf137NkwWjV9MQ1sPN3eT37qDb47a6BzUeAhJNB8RDKqg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something *other than*"c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks.
--
Dushyanth Subramanya
University of Pennsylvania
Class of 2012
School of Engineering & Applied Science
MSE, MCIT
www.seas.upenn.edu/~dushs <http://www.seas.upenn.edu/%7Edushs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120703/cb872b81/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 3 Jul 2012 22:20:59 +0200
From: Ran Shalit <ranshalit at gmail.com>
To: live-devel at ns.live555.com
Subject: [Live-devel] mpeg-2 transport stream Rate
Message-ID:
<CAJ2oMhLJQA2V4o1fAavsG4hVkXqmZ+auMbGn-We_YiVQC+gp1A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I would like to ask questions regarding mpeg-2 transport stream in live555.
- Is the stream rate constant ? How is the rate determined: externally or internally by transport muxer ?
- How does the mpeg-ts mux decide which input stream to deliver next from the inputs waiting ?
- Is null packets used for keeping a constant rate ?
- Is it possible to create multiple streams ?
Thank you very much!
Ran
------------------------------
Message: 4
Date: Tue, 3 Jul 2012 21:18:10 +0000
From: "Erlandsson, Claes P (CERLANDS)" <CERLANDS at arinc.com>
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Subject: Re: [Live-devel] Regarding the build
Message-ID:
<ED766D6CFBFD8243B5285413AFCC66F4A44414 at EXANPMB1.arinc.com>
Content-Type: text/plain; charset="us-ascii"
Example with a x64 OS:
VS2010:
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
VS2008:
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\
I btw use the short path (that you can see with dir /X) to avoid issue with
space:
c:\PROGRA~2\MICROS~2.0\VC
/C
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of dushyanth
Sent: Tuesday, July 03, 2012 10:04 AM
To: live-devel at ns.live555.com
Subject: Re: [Live-devel] Regarding the build
In the instructions to build and run the libraries for windows, the second point says "If the 'tools' directory on your Windows machine is something other than "c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file "win32config" " where can i expect to find this directory. Is it the tools folder in my visual studio package? Thanks.
--
Dushyanth Subramanya
University of Pennsylvania
Class of 2012
School of Engineering & Applied Science
MSE, MCIT
www.seas.upenn.edu/~dushs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5740 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120703/fe6c9223/attachment-0001.bin>
------------------------------
Message: 5
Date: Tue, 3 Jul 2012 21:30:47 +0000
From: "Erlandsson, Claes P (CERLANDS)" <CERLANDS at arinc.com>
To: "live-devel at lists.live555.com" <live-devel at ns.live555.com>
Subject: [Live-devel] RTSP - Absolute Time
Message-ID:
<ED766D6CFBFD8243B5285413AFCC66F4A4442D at EXANPMB1.arinc.com>
Content-Type: text/plain; charset="us-ascii"
After doing some testing with openRTSP and looking through the code it appears like "Absolute Time" is currently not supported for RTSP streams. I.e. I can't specify a specific time that the stream should seek to, e.g. Range: clock=20120629T070000.00Z, all according to paragraph 3.7 at http://www.ietf.org/rfc/rfc2326.txt.
I see some remarks for "clock" (and "smtpe") in the code at RTSPCommon->parseRangeParam() which sort of confirms that this is still to be done.
I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it?
I find the seek functionality to be an essential part of RTSP, but it's kind of hard to implement anything with just the npt-time (Normal Play Time) to use. For most uses, like Video Management Systems that uses a circular buffer, the start is a moving target, i.e. seeking to 50 minutes might not take you to the same place in 10 minutes as it does now.
Do you know of any reliable workarounds?
Thanks!
/Claes
------------------------------
Message: 6
Date: Tue, 3 Jul 2012 15:04:21 -0700
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Subject: Re: [Live-devel] RTSP - Absolute Time
Message-ID: <08A2F295-E1A1-4617-9AF8-46E66B4EEDBC at live555.com>
Content-Type: text/plain; charset="us-ascii"
> I'm curious if there is a reason that absolute time has been left out, i.e. are there problems implementing it, or is it just that people for some reason haven't been showing any interest in it?
Until recently, there just hasn't been any interest in supporting seeking by 'absolute time'; instead, almost every application that wants to seek within a stream wants to seek using a relative time (from the start of the stream, or from its current position).
However, you're the second person recently who has expressed interest in supporting this, so it's probably something that I'll add to the 'to do' list. (Supporting this might be nontrivial, though, because right now the code assumes - in lots of places - that only streams with a known duration can be 'seekable'.)
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/20120703/7432ce15/attachment.html>
------------------------------
_______________________________________________
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 4
******************************************
More information about the live-devel
mailing list