> Please send us the (publically-accessible) "rtsp://" URL of a server
> that illustrates this problem. (The RTP-over-TCP implementation in
> recent versions should have been *improved*, so I'm a bit suprised to
> hear reports of bugs here.)
Yes I know, I'll try, but it can take a few days.
K
On Tue, 2010-06-29 at 09:25 +0200, Kamil Dobkowski wrote:
> This is strange. I tried it a few times and it didn't work. Of course
> OpenRTSP client connects correctly, invokes PLAY and shows messages
> that is sending/receiving some control packets - everything looks ok
> at first glance, but even
> Kamil : I don't use TCP method but I tried the -t option and it works.
This is strange. I tried it a few times and it didn't work. Of
course OpenRTSP client connects correctly, invokes PLAY and shows
messages that is sending/receiving some control packets - everything
looks ok at first glan
> Kamil : I don't use TCP method but I tried the -t option and it works.
This is strange. I tried it a few times and it didn't work. Of course OpenRTSP
client connects correctly, invokes PLAY and shows messages that is
sending/receiving some control packets - everything looks ok at first glance,
I tried this, but it doesn't work.
I think the issue is because there are two streams but only one
a=control attribute in the sdp description.
The camera sends both video and data in the same stream, and this seems
to be non standard.
Yes, it looks like you're out of luck.
--
Ross Finlayson
Liv
On Mon, 2010-06-28 at 15:17 -0700, Ross Finlayson wrote:
> >m=data 0 RTP/AVP 111
> >a=rtpmap:111 octet-stream/1
> >a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
> >FirmVer=0103; CameraSeries=2;
>
> Yes, this is something totally non-standard. However, I think you
> can r
m=data 0 RTP/AVP 111
a=rtpmap:111 octet-stream/1
a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
FirmVer=0103; CameraSeries=2;
Yes, this is something totally non-standard. However, I think you
can receive this data by adding the command-line option "-S 0" to
"openRTSP".
I used SetAuxReadHandler() for this purpose
No, don't use "setAuxilliaryReadHandler()". That's a hack that
should never have been in the code; it will be going away sometime.
Instead, to receive the data from (otherwise) unknown RTP payload
formats, pass a non-negative "useSpecialRTPoffset"
>I have a network camera which sends rtp packed with payload = 100 (H264).
>But the camera also sends some information in rtp packets with a different
>payload type.
>I believe these packets are discarded by live555, but is there a way to get
>these packet in my application ?
Hi,
I used SetAuxRe
Quoting Ross Finlayson :
> Sebastien,
>
> Perhaps. Does the camera give you a SDP description for the stream?
> (Does the camera support RTSP? If so, please run "openRTSP" on it,
> and send us the (stderr) output.)
Yes I think it does, I can see it in the sdp.
Here is the output :
Opening conn
I have a network camera which sends rtp packed with payload = 100 (H264).
But the camera also sends some information in rtp packets with a different
payload type.
I believe these packets are discarded by live555, but is there a way to get
these packet in my application ?
Sebastien,
Perhaps. Do
11 matches
Mail list logo
