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-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of
live-devel-requ...@ns.live555.com
Sent: Wednesday, July 04, 2012 6:04 AM
To: live-de...@ns.live555.com
Subject: live-devel Digest, Vol 105, Issue 4
Send live-devel mailing list submissions to
live-devel@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-requ...@lists.live555.com
You can reach the person managing the list at
live-devel-ow...@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 <finlay...@live555.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>
Subject: Re: [Live-devel] About the H264 over RTP FA
Message-ID: <489abc76-6837-4e98-bc61-4119d4ec2...@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.subrama...@gmail.com>
To: live-de...@ns.live555.com
Subject: Re: [Live-devel] Regarding the build
Message-ID:
<cagbjsjf137nkwwjv9mq1spn3et37qdb47a6bzueahjnb8rd...@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 <ransha...@gmail.com>
To: live-de...@ns.live555.com
Subject: [Live-devel] mpeg-2 transport stream Rate
Message-ID:
<caj2omhljqa2v4o1faavsg4hvkxqmz+aumbgn-we_yivqc+g...@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)" <cerla...@arinc.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>
Subject: Re: [Live-devel] Regarding the build
Message-ID:
<ed766d6cfbfd8243b5285413afcc66f4a44...@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-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of dushyanth
Sent: Tuesday, July 03, 2012 10:04 AM
To: live-de...@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)" <cerla...@arinc.com>
To: "live-devel@lists.live555.com" <live-de...@ns.live555.com>
Subject: [Live-devel] RTSP - Absolute Time
Message-ID:
<ed766d6cfbfd8243b5285413afcc66f4a44...@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 <finlay...@live555.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>
Subject: Re: [Live-devel] RTSP - Absolute Time
Message-ID: <08a2f295-e1a1-4617-9af8-46e66b4ee...@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@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
End of live-devel Digest, Vol 105, Issue 4
******************************************
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
