[Live-devel] live-devel Digest, Vol 48, Issue 3
Yousef Hosseini
uozef at opensoftAustralia.com.au
Fri Oct 5 10:29:08 PDT 2007
Hi guys,
I am using Live555 with Amino 110 , I couldn't work it out how can I get rid
of trick play problem and just wonder if anybody has any resolution for
this, problem is when I press FF on remote , then pause then play it takes
few seconds running in slow mode and then come back again into the normal
mode. I already changed the RTSP_SCALE in amino settings file, nothing has
happened.
Regards,
Yousef.
-----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: Thursday, October 04, 2007 7:59 AM
To: live-devel at ns.live555.com
Subject: live-devel Digest, Vol 48, Issue 3
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. speed settings for mpeg4 (Cristaldi Ambra)
2. Re: RTP-over-TCP streaming (Noam Camiel) (Ron McOuat)
3. Re: RTP-over-TCP streaming (Noam Camiel) (Ross Finlayson)
4. Re: speed settings for mpeg4 (Ross Finlayson)
5. Re: RTP-over-TCP streaming (Noam Camiel) (Shaswata Jash)
6. Re: RTP-over-TCP streaming (Noam Camiel) (Ross Finlayson)
7. testMPEG4VideoStreamer - Debug Assertion Failed!
(Christopher Shumway)
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Oct 2007 16:29:46 +0200
From: "Cristaldi Ambra" <Ambra.Cristaldi at elsagdatamat.com>
Subject: [Live-devel] speed settings for mpeg4
To: <live-devel at ns.live555.com>
Message-ID:
<268315E5844A704AB431589863FE8EEFCED085 at els00wmx04.elsag.it>
Content-Type: text/plain; charset="us-ascii"
Dear Ross,
I have some questions for you about streaming of m4e files from a server
at different speed:
- does the "onDemandRTSPServer" already implement this functionality
for m4e? We just wish to stream the test file (test.m4e) at speed x2 (or
more...)
- I read the FAQ and found that we can change the parameter "scale" in
the function "playMediaSession()" of OpenRTSP.cpp to set the speed. Is
it possible doing something similar for streaming?
Thank you in advance.
Best regards,
Ambra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20071003/8eaae4c8/
attachment-0001.html
------------------------------
Message: 2
Date: Wed, 03 Oct 2007 07:44:16 -0700
From: Ron McOuat <rmcouat at smartt.com>
Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel)
To: live-devel at ns.live555.com
Message-ID: <4703AAC0.1080802 at smartt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I have observed a similar sounding situation as follows:
Use openRTSP to receive the video stream from an Axis camera, I have tried
several models
Using RTP over UDP (no -t or -T option) will run for hours
Using RTP over TCP (-t option) will fail somewhere between 600 and 2000
seconds
Using HTTP tunneling (-T 80 option) will run for hours
Compiling the live555 code with debug on reveals the end sequence looks like
this:
~~~~~~~~~~~~~~~ Debug trace ~~~~~~~~~~~~~~~
sendRTPOverTCP: 976 bytes over channel 0 (socket 8)
sendRTPOverTCP: completed
SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 20
SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 21
[0x300be0]saw incoming RTCP packet (from address 136.244.255.191, port 1280)
80c90001 6fc0e531 81cb0001 6fc0e531
RR
validated RTCP subpacket (type 2): 0, 201, 0, 0x6fc0e531
BYE
Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds)
Sending request: TEARDOWN rtsp://69.67.172.61:554/mpeg4/1/media.amp/
RTSP/1.0
CSeq: 8
Session: 2014422318
User-Agent: ./testProgs/openRTSP (LIVE555 Streaming Media v2007.08.03)
RTCPInstance[0x300be0]::~RTCPInstance()
sending BYE
sending RTCP packet
81c90007 af22ce4c 6fc0e531 00000000 00023418 00000388 bfcf8f2c 000127e1
81cb0001 af22ce4c
sendRTPOverTCP: 40 bytes over channel 21 (socket 3)
sendRTPOverTCP: completed
~~~~~~~~~~~~ End of trace ~~~~~~~~~~~~~~~~
What appears to happen that is different when the stream ends is the 2 lines
from
SocketDescriptor::tcpReadHandler() gets a 16 byte read on channel 20 then
another 16 bytes on channel 21. Often there is a REPORT just before this but
not always.
The end of stream does not go through any timeouts, the debug output just
rolls up and stops when I have observed this in real time.
Also the address and port numbers reported for the source for both -t and -T
port reported in the trace are not valid but with UDP they are good. The
correct source IP address is in the TEARDOWN message.
I have not had a chance to dig into why this is happening yet because I have
some other pressing issues to work on and have worked around this for my own
purposes. However, seeing this on the mailing list prompted me to send in my
observations.
The system running the live555 code is OSX 10.4.10 with all patches. I was
also going to verify on Linux in case this is a problem with the system
interface to select().
Ron McOuat
Message: 3
Date: Tue, 2 Oct 2007 17:10:25 -0700 (PDT)
From: Noam Camiel <noamatari at yahoo.com>
Subject: [Live-devel] RTP-over-TCP streaming
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <76628.29785.qm at web53302.mail.re2.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Hello
I have a problem when accessing live server's stream using RTP-over-TCP as
opposed to UDP.
I have used the testOnDemandRTSPServer example to play a stream of of mpeg4
encodered frames (elementary stream) and was successful with both VLC and
Quicktime as well as RealPlayer, using unicast UDP.
But when I try to connect to the server via TCP (RTP over TCP), the video is
played for a short time and then stops (with a reports - due to a network
problem). This short time duration can be anywhere between 30 seconds and
10 minutes.
Which is the right way to stream RTP over TCP? Should I use a different
example from live than testOnDemandRTSPServer?
Thanks,
Noam Camiel
------------------------------
Message: 3
Date: Wed, 3 Oct 2007 08:10:20 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel)
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <f06240800c3295ee8deeb@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds)
The RTCP "BYE" packet (from the server) is your server is explicitly
saying "I'm ending the streaming of the stream now". The client then
(correctly) handles this by shutting down.
So, you will need to figure out why your server has chosen to end the
stream. (You may need to ask Axis about this.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
------------------------------
Message: 4
Date: Wed, 3 Oct 2007 08:15:28 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] speed settings for mpeg4
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <f06240801c32961b887a4@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii"
>I have some questions for you about streaming of m4e files from a
>server at different speed:
>- does the "onDemandRTSPServer" already implement this
>functionality for m4e?
No, our RTSP server implementation currently does not implement
'trick play' operations when streaming MPEG-4 Elementary Stream video
files.
See
http://www.live555.com/liveMedia/faq.html#trick-mode
and
http://www.live555.com/mediaServer/#trick-play
--
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/20071003/44de5163/
attachment-0001.html
------------------------------
Message: 5
Date: Thu, 4 Oct 2007 12:39:59 +0530
From: "Shaswata Jash" <shaswata at alumnux.com>
Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel)
To: "'LIVE555 Streaming Media - development & use'"
<live-devel at ns.live555.com>
Message-ID: <016201c80655$94b16660$2e0aa8c0 at alumnusshas>
Content-Type: text/plain; charset="us-ascii"
>From our previous experience on working with Axis camera, it does not
really
support RTP interleaved packets over TCP (i.e. the specification you can
find under rfc of RTSP). However, it supports RTSP tunneled over HTTP - this
specification is proprietary and defined by Apple. On the configuration
web-page of your Axis camera, you can verify about this.
To best of my knowledge, Live555 does not yet support that RTSP tunneled
over HTTP - probably Ross would be the best person to comment about this.
With regards,
Shaswata
-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 03, 2007 8:40 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel)
>Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds)
The RTCP "BYE" packet (from the server) is your server is explicitly
saying "I'm ending the streaming of the stream now". The client then
(correctly) handles this by shutting down.
So, you will need to figure out why your server has chosen to end the
stream. (You may need to ask Axis about this.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
------------------------------
Message: 6
Date: Thu, 4 Oct 2007 00:21:06 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel)
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <f06240805c32a442f3fa5@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii"
>To best of my knowledge, Live555 does not yet support that RTSP tunneled
>over HTTP
Yes it does - in our *client* implementation. Note, for example, the
"-T <http-port-number>" option to "openRTSP":
<http://www.live555.com/openRTSP/#other-options>
Our RTSP *server* implementation, however, does not yet support
RTSP-over-HTTP tunneling (but may, sometime in the future).
--
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/20071004/7e83256d/
attachment-0001.html
------------------------------
Message: 7
Date: Thu, 4 Oct 2007 10:55:48 -0400
From: "Christopher Shumway" <cshumway at airvisual.com>
Subject: [Live-devel] testMPEG4VideoStreamer - Debug Assertion Failed!
To: <live-devel at ns.live555.com>
Message-ID:
<9A46651B1CC1FF4DB6275ACD19773C6A28B23D at airvisual1.airvisual.net>
Content-Type: text/plain; charset="us-ascii"
Greetings,
I am working with VS 2005 on Windows XP and I can the
testMPEG4VideoStreamer program to compile. However, when I run it from
a command line I receive an error message (in the form of a pop-up)
which reads, "Debug Assertion Failed!". In debugging the code, I
believe I am having difficulty "joining a socket group". I can debug
the code to the following point, at which time it drops into the "failed
to join group" error.
Groupsock::Groupsock(UsageEnvironment& env, struct in_addr const&
groupAddr,
Port port, u_int8_t ttl)
: OutputSocket(env, port),
deleteIfNoMembers(False), isSlave(False),
fIncomingGroupEId(groupAddr, port.num(), ttl), fDests(NULL),
fTTL(ttl) {
addDestination(groupAddr, port);
if (!socketJoinGroup(env, socketNum(), groupAddr.s_addr)) {
if (DebugLevel >= 1) {
env << *this << ": failed to join group: "
<< env.getResultMsg() << "\n";
}
}
BTW - I do have this compiled (along with the 555 Live Media Server) and
working fine on a Linux (Red Hat) box. I can access the test stream
using VLC on my Windows PC which is on the same network as the Linux
box.
Thanx!
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20071004/fca4fb53/
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 48, Issue 3
*****************************************
More information about the live-devel
mailing list