headers
xujin | 1 Jun 2009 11:28

about SET PARAMETER

I try realplayer and vlc with my RTSP server and find that realplayer will send command 'set parameter' and vlc not.The RTSP server receive UDP unicast stream and listen rtsp request.
 
I rewrite handleCmd_SET_PARAMETER code as following to give  OK answer:
 
void RTSPServer::RTSPClientSession
::handleCmd_SET_PARAMETER(ServerMediaSubsession* /*subsession*/, char const* cseq,
     char const* fullRequestStr) {
  // By default, we don't implement "SET_PARAMETER":
 
 // handleCmd_notSupported(cseq);
 
  // add by xujin to give OK answer 20090531
  snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
    "RTSP/1.0 200 OK\r\nCSeq: %s\r\n%sSession: %d\r\n\r\n",
    cseq, dateHeader(), fOurSessionId);
}
 
but realplayer will not send PLAY command and report 'normal error message'.
 
I don't know why realplayer does not send next command.
 
VLC will send PLAY command,but no stream will be received.
 
 
 
Thank you.
_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Ross Finlayson | 1 Jun 2009 11:54
Favicon

Re: about SET PARAMETER

RealPlayer and VLC are not our products, so this is not the right 
mailing list to report supposed bugs in those clients.

Also, before modifying the existing RTSP server code, you should 
check that your client(s) work OK with the original, unmodified 
server code.
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply | 0 comments |
headers
Ganesh V | 2 Jun 2009 07:14
Picon
Favicon

Re: H.264 RTSP Streaming with QuickTime

Dear Experts,

I have a doubt. When I am trying to debug RTSP streaming with QT (which I am still unable to achieve), I found one difference between QT and VLC setup.

The SDP information when I connected using QT is as follows:

a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=428015;sprop-parameter-sets=J0KAFZZUCg/QgAATiA,KM4ECMg=
a=control:track1
RTSPClientSession[0xab8ff8]::incomingRequestHandler1() read 303 bytes:SETUP rtsp://172.16.1.211:8002/ch2/track1 RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=6970-6971
x-retransmit: our-retransmit
x-dynamic-rate: 1
x-transpo rt-options: late-tolerance=2.900000
User-Agent: QuickTime/7.6 (qtver=7.6;os=Windows NT 5.1Service Pack 3)
Accept-Language: en-US

And when I connected using VLC player, the log is as follows:

a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=428015;sprop-parameter-sets=J0KAFZZUCg/QgAATiA,KM4ECMg=
a=control:track1
RTSPClientSession[0xab8ff8]::incomingRequestHandler1() read 183 bytes:SETUP rtsp://172.16.1.211:8002/ch2/track1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=56630-56631
User-Agent: VLC media player (LIVE555 Streaming Media v2008.07.24)

When I compare, I observed some new parameters like x-retransmit, x-dynamic-rate, x-transport-options. I presume these are client specific options. Where can I find more information about the same? Do they impact the final video display on the screen? Should I tweak any of these parameters?

Many thanks in advance.

Thanks,
Ganesh



_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
siyara nt | 2 Jun 2009 07:24
Picon

Building live555 for WinCE 6.0 based DM355 target

Hi All,
 
I am newbie and trying to build Live555 on windows CE 6.0. I'm using the platform builder toolkit with WinCE. I am facing problems in building live555 for ARM (DM355) target.
I changed the win32config file for the compiler, header files and library settings as per my WinCE toolchain path. When i run the build batch file it throws lot of errors.
Basically i'm not sure if this is the right way to do it, i.e command line compilation? Or i will have to convert each project into VS2005 workspace and build using VS2005 IDE?
Please suggest.
 
thanks
_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Ross Finlayson | 2 Jun 2009 07:44
Favicon

Re: H.264 RTSP Streaming with QuickTime

>I have a doubt. When I am trying to debug RTSP streaming with QT 
>(which I am still unable to achieve), I found one difference between 
>QT and VLC setup.
>
>The SDP information when I connected using QT is as follows:
>
>a=rtpmap:96 H264/90000
>a=fmtp:96 
>packetization-mode=1;profile-level-id=428015;sprop-parameter-sets=J0KAFZZUCg/QgAATiA,KM4ECMg=
>a=control:track1
>RTSPClientSession[0xab8ff8]::incomingRequestHandler1() read 303 
>bytes:SETUP rtsp://172.16.1.211:8002/ch2/track1 RTSP/1.0
>CSeq: 2
>Transport: RTP/AVP;unicast;client_port=6970-6971
>x-retransmit: our-retransmit
>x-dynamic-rate: 1
>x-transport-options: late-tolerance=2.900000
>User-Agent: QuickTime/7.6 (qtver=7.6;os=Windows NT 5.1Service Pack 3)
>Accept-Language: en-US
>
>And when I connected using VLC player, the log is as follows:
>
>a=rtpmap:96 H264/90000
>a=fmtp:96 
>packetization-mode=1;profile-level-id=428015;sprop-parameter-sets=J0KAFZZUCg/QgAATiA,KM4ECMg=
>a=control:track1
>RTSPClientSession[0xab8ff8]::incomingRequestHandler1() read 183 
>bytes:SETUP rtsp://172.16.1.211:8002/ch2/track1 RTSP/1.0
>CSeq: 3
>Transport: RTP/AVP;unicast;client_port=56630-56631
>User-Agent: VLC media player (LIVE555 Streaming Media v2008.07.24)
>
>When I compare, I observed some new parameters like x-retransmit, 
>x-dynamic-rate, x-transport-options. I presume these are client 
>specific options. Where can I find more information about the same? 
>Do they impact the final video display on the screen? Should I tweak 
>any of these parameters?
.
Those are Apple-specific options that are handled only by Apple's 
'Darwin Streaming Server'.  I think they are only optimizations (for 
reliable) delivery, and I doubt they're the reason why QuickTime 
Player doesn't play your stream.  Instead, the reason is probably 
that QuickTime Player doesn't support the particular variant 
('profile') of H.264 that you're using.

However (for the bazillionth time!) QuickTime Player is not our 
product, and this is not the right mailing list for bug reports with 
QuickTime Player.  Instead, use an appropriate QuickTime mailing list.
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply | 0 comments |
headers
Woods | 3 Jun 2009 04:41
Picon

how to multicast using live555 media server

Hi,

I wish to find out how to do multicast using live555 media server. Thanks for your suggestion.

--
Woods

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Ross Finlayson | 3 Jun 2009 10:30
Favicon

Re: how to multicast using live555 media server

>I wish to find out how to do multicast using live555 media server. 
>Thanks for your suggestion.

Although the "LIVE555 Media Server" product does not (currently) 
stream via multicast, there are several demo applications - in the 
"testProgs" directory - that  do.  (These demo applications must be 
built from source code.)  Look at the various demo applications named 
test*Streamer
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply | 0 comments |
headers
siyara nt | 3 Jun 2009 11:43
Picon

Errors building live555 on WinCE 6.0 based DM355 target

Hi all,
 
I am building live555 on WinCE 6.0 for DM355 target. I am getting the following errors while building groupsock code. It is throwing lot of undeclared identifier errors. I'm not sure which header file needs to be included in the project to resolve these symbols? Please suggest.
 
The error log
---------------------------------------------------------------------------------------------------

GroupsockHelper.cpp(115) : error C2065: 'sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA' : undeclared identifier

1>GroupsockHelper.cpp(131) : error C2065: 'IP_MULTICAST_IF' : undeclared identifier

1>GroupsockHelper.cpp(340) : error C2065: 'IP_MULTICAST_TTL' : undeclared identifier

1>GroupsockHelper.cpp(432) : error C2079: 'imr' uses undefined struct 'socketJoinGroup::ip_mreq'

1>GroupsockHelper.cpp(433) : error C2228: left of '.imr_multiaddr' must have class/struct/union

1> type is 'int'

1>GroupsockHelper.cpp(433) : error C2228: left of '.S_un' must have class/struct/union

1>GroupsockHelper.cpp(433) : error C2228: left of '.S_addr' must have class/struct/union

1>GroupsockHelper.cpp(434) : error C2228: left of '.imr_interface' must have class/struct/union

1> type is 'int'

1>GroupsockHelper.cpp(434) : error C2228: left of '.S_un' must have class/struct/union

1>GroupsockHelper.cpp(434) : error C2228: left of '.S_addr' must have class/struct/union

1>GroupsockHelper.cpp(435) : error C2065: 'IP_ADD_MEMBERSHIP' : undeclared identifier

1>GroupsockHelper.cpp(436) : error C2027: use of undefined type 'socketJoinGroup::ip_mreq'

1> GroupsockHelper.cpp(432) : see declaration of 'socketJoinGroup::ip_mreq'

1>GroupsockHelper.cpp(456) : error C2079: 'imr' uses undefined struct 'socketLeaveGroup::ip_mreq'

1>GroupsockHelper.cpp(457) : error C2228: left of '.imr_multiaddr' must have class/struct/union

1> type is 'int'

1>GroupsockHelper.cpp(457) : error C2228: left of '.S_un' must have class/struct/union

1>GroupsockHelper.cpp(457) : error C2228: left of '.S_addr' must have class/struct/union

1>NMAKE : fatal error U1077: 'C:\WINCE600\SDK\BIN\I386\ARM\cl.EXE' : return code '0x2'

1>GroupsockHelper.cpp(458) : error C2228: left of '.imr_interface' must have class/struct/union

1> type is 'int'

1>Stop.

1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"

1>GroupsockHelper.cpp(458) : error C2228: left of '.S_un' must have class/struct/union

1>GroupsockHelper.cpp(458) : error C2228: left of '.S_addr' must have class/struct/union

1>GroupsockHelper.cpp(459) : error C2065: 'IP_DROP_MEMBERSHIP' : undeclared identifier

1>GroupsockHelper.cpp(460) : error C2027: use of undefined type 'socketLeaveGroup::ip_mreq'

1> GroupsockHelper.cpp(456) : see declaration of 'socketLeaveGroup::ip_mreq'

1>GroupsockHelper.cpp(709) : error C3861: 'ctime': identifier not found

1>Build log was saved at "file://f:\Livemedia\live_source_code\winxp\live\groupsock\Debug\BuildLog.htm"

1>groupsock1 - 24 error(s), 4 warning(s)

========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

thanks

 

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |
headers
Derk-Jan Hartman | 3 Jun 2009 17:17
Favicon

Re: Found document about RTP payload format of ASF

On 29 mei 2009, at 10:35, Ross Finlayson wrote:
>> I know that live555 doesn't support X-ASF-PF format. And I 've  
>> found a document (http://go.microsoft.com/fwlink/?LinkId=89814)  
>> here (http://msdn.microsoft.com/en-us/library/cc245257(PROT. 
>> 10).aspx). It mention about ASF file and also RTP payload format of  
>> ASF. I think it will be useful for anyone want to write code to  
>> handle this.
>
> Yes, if anyone were to implement this RTP payload format, I would  
> likely add it to the released code.
>>
>> And one more thing, live555 doesn't support ASF, so why VLC player  
>> use live555 library and it can play ASF ???
>
> Most likely because - in this case - VLC is downloading the file  
> using HTTP, rather than RTSP.

Much like MPEG-TS and MPEG-PS streams, ASF streams 'ASF files'. So VLC  
opens a second demuxer for these streams, decodes the ASF headers  
which are  in the Describe and feed them to this 2nd demuxer, and then  
simply moves the ASF packets into the ASF demux. It's not that hard to  
do, and you can easily get the required information from the VLC  
source. We basically do the same with the packets as we do with the  
packets we receive from MMS.

Our implementation is not complete however, and it might be that we  
are doing some things incorrectly. We basically just made a guess  
about what would be in the packets we got from live555, based on our  
knowledge about the MMS protocol. I'll open a bugticket in vlc with  
this document so we can look at it more closely sometime.

DJ
Permalink | Reply | 0 comments |
headers
Derk-Jan Hartman | 3 Jun 2009 17:35
Favicon

Re: Found document about RTP payload format of ASF

On 3 jun 2009, at 17:17, Derk-Jan Hartman wrote:
> On 29 mei 2009, at 10:35, Ross Finlayson wrote:
>>> I know that live555 doesn't support X-ASF-PF format. And I 've  
>>> found a document (http://go.microsoft.com/fwlink/?LinkId=89814)  
>>> here (http://msdn.microsoft.com/en-us/library/cc245257(PROT. 
>>> 10).aspx). It mention about ASF file and also RTP payload format  
>>> of ASF. I think it will be useful for anyone want to write code to  
>>> handle this.
>>
>> Yes, if anyone were to implement this RTP payload format, I would  
>> likely add it to the released code.
>>>
>>> And one more thing, live555 doesn't support ASF, so why VLC player  
>>> use live555 library and it can play ASF ???
>>
>> Most likely because - in this case - VLC is downloading the file  
>> using HTTP, rather than RTSP.
>
> Much like MPEG-TS and MPEG-PS streams, ASF streams 'ASF files'. So  
> VLC opens a second demuxer for these streams, decodes the ASF  
> headers which are  in the Describe and feed them to this 2nd  
> demuxer, and then simply moves the ASF packets into the ASF demux.  
> It's not that hard to do, and you can easily get the required  
> information from the VLC source. We basically do the same with the  
> packets as we do with the packets we receive from MMS.
>
> Our implementation is not complete however, and it might be that we  
> are doing some things incorrectly. We basically just made a guess  
> about what would be in the packets we got from live555, based on our  
> knowledge about the MMS protocol. I'll open a bugticket in vlc with  
> this document so we can look at it more closely sometime.

I checked, and what VLC is doing is just skipping the first 4 bytes  
and praying it will work :D Which it surprisingly often actually does...
Must mean that the R, D and I bits are not that often set.

DJ
Permalink | Reply | 0 comments |

Gmane