From finlayson at live555.com  Sun Jul  1 02:43:16 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 1 Jul 2007 02:43:16 -0700
Subject: [Live-devel] RSTP Server Mods - opening files & transcoding
In-Reply-To: <003501c7bb58$7d134700$0300a8c0@AlexLaptop>
References: <003501c7bb58$7d134700$0300a8c0@AlexLaptop>
Message-ID: <f06240808c2ad27462167@[66.80.62.44]>

>a) How can i stream file names with spaces in them? (e.g. 
>rtsp://<ip>/i am a file.ts instead of rtsp://<ip>/file.ts)

This was a bug in our "RTSPServer" (and "RTSPClient") implementation. 
I have just installed a new version (2007.07.01) of the "LIVE555 
Streaming Media" software (and "live555MediaServer" binaries) that 
fixes this problem.

>b) Is it possible stream file outside the working directory or 
>create virtual paths?

Right now, the only way to do this is by creating symbolic links 
inside the "mediaServer" directory.

>c) Ideally i'd like to be able to drag and drop files into a 
>directory and transcode them on the fly to any format i set, in the 
>same way it can be done with VLC manually. I know this has been 
>covered before but could someone give me an overview how VLC's 
>engine or something like FFMpeg could be integrated with the live 
>RTSP server to achieve this so streams are served and transcoded 
>on-demand?

Sorry, I can't help you with this one.
-- 

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/20070701/092a74dc/attachment.html 

From julian.lamberty at mytum.de  Mon Jul  2 00:36:51 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Mon, 02 Jul 2007 09:36:51 +0200
Subject: [Live-devel] presentationTime and B-Frames
In-Reply-To: <f06240800c2abb687411a@[66.80.62.44]>
References: <468515BE.6090105@mytum.de> <f06240800c2abb687411a@[66.80.62.44]>
Message-ID: <4688AB13.6030209@mytum.de>


> Note that In your original MPEG-2 stream, with B-frames, the frames 
> will be in decoding order, which is different from the display order, 
> and thus different from the order of frames in the resulting MPEG-4 
> stream (because that doesn't have B frames).  In particular, the 
> presentation times in the original MPEG-2 stream, with B-frames, will 
> *not* be monotonically increasing.  You will need to reorder the 
> presentation times accordingly when you convert the stream to MPEG-4 
> (without B-frames).
>   

My source is the vobStreamer application. Examining the packets it looks 
like if they are sent rather in display order (IBBPBBPBBPBBI...). Is 
that true for the vobStreamer?

How is the timeval structure mapped onto the 32bit presentation time in 
the RTP packet, what interval do I have to add to fPresentationTime to 
make RTP timestamp increase by 3600 (i.e. one frame duration @25Hz)?

Thanks
Julian

From zhj.zhao at gmail.com  Mon Jul  2 01:08:01 2007
From: zhj.zhao at gmail.com (jerry zhao)
Date: Mon, 2 Jul 2007 10:08:01 +0200
Subject: [Live-devel] RTCP packet interval
Message-ID: <b9f77bff0707020108w1d95133dw22e89990bca21f87@mail.gmail.com>

Hello,
I have a question about RTCP packet interval. Now the RTCP packet (e.g. RR)
interval is about 5 seconds. Can I change the RR packet interval to one RTT
with Live library?
Thanks.

Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070702/5c52ad1a/attachment.html 

From finlayson at live555.com  Mon Jul  2 01:38:04 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 01:38:04 -0700
Subject: [Live-devel] presentationTime and B-Frames
In-Reply-To: <4688AB13.6030209@mytum.de>
References: <468515BE.6090105@mytum.de>
	<f06240800c2abb687411a@[66.80.62.44]> <4688AB13.6030209@mytum.de>
Message-ID: <f06240815c2ae69180fc0@[66.80.62.44]>

>How is the timeval structure mapped onto the 32bit presentation time in
>the RTP packet, what interval do I have to add to fPresentationTime to
>make RTP timestamp increase by 3600 (i.e. one frame duration @25Hz)?

Receiving code should not need to care about RTP timestamps.  (Only 
the LIVE555 RTP reception code needs to care about RTP timestamps.) 
Instead, just use the presentation time that's given to each piece of 
incoming data (from the "RTPSource" subclass).

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Mon Jul  2 01:38:22 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 01:38:22 -0700
Subject: [Live-devel] RTCP packet interval
In-Reply-To: <b9f77bff0707020108w1d95133dw22e89990bca21f87@mail.gmail.com>
References: <b9f77bff0707020108w1d95133dw22e89990bca21f87@mail.gmail.com>
Message-ID: <f06240814c2ae68e20327@[66.80.62.44]>

>Hello,
>I have a question about RTCP packet interval. Now the RTCP packet 
>(e.g. RR) interval is about 5 seconds. Can I change the RR packet 
>interval to one RTT with Live library?

Our RTCP code implements the standard RTCP retransmission rules - 
defined in RFC 3550.  I don't recommend changing this.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From julian.lamberty at mytum.de  Mon Jul  2 01:55:15 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Mon, 02 Jul 2007 10:55:15 +0200
Subject: [Live-devel] presentationTime and B-Frames
In-Reply-To: <f06240815c2ae69180fc0@[66.80.62.44]>
References: <468515BE.6090105@mytum.de>	<f06240800c2abb687411a@[66.80.62.44]>
	<4688AB13.6030209@mytum.de> <f06240815c2ae69180fc0@[66.80.62.44]>
Message-ID: <4688BD73.4030701@mytum.de>

Ross Finlayson schrieb:
>> How is the timeval structure mapped onto the 32bit presentation time in
>> the RTP packet, what interval do I have to add to fPresentationTime to
>> make RTP timestamp increase by 3600 (i.e. one frame duration @25Hz)?
>>     
>
> Receiving code should not need to care about RTP timestamps.  (Only 
> the LIVE555 RTP reception code needs to care about RTP timestamps.) 
> Instead, just use the presentation time that's given to each piece of 
> incoming data (from the "RTPSource" subclass).
>
>   
Ok, but there's still the problem how to sync an original audio stream 
to the transcoded corresponding video stream because the original 
timestamps are not preserved. Can this be worked around somehow? I know 
the standard requires a "random" offset to be added to the RTP 
timestamps. How can I keep synchronisation at the final receiver?

From armandopoulos at yahoo.fr  Mon Jul  2 03:40:09 2007
From: armandopoulos at yahoo.fr (Armando Ko)
Date: Mon, 2 Jul 2007 12:40:09 +0200 (CEST)
Subject: [Live-devel] implement the RTCP APP Packet
Message-ID: <125402.60045.qm@web25912.mail.ukl.yahoo.com>

hi,

How can i expand the Live555 to implement the rtcp app packet.
Please i need some details for a new user of the live555.

Can the app packet replace the bye packet ?

thank you
Armand 

 	      
---------------------------------
 Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070702/292829a7/attachment.html 

From finlayson at live555.com  Mon Jul  2 04:41:43 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 04:41:43 -0700
Subject: [Live-devel] implement the RTCP APP Packet
In-Reply-To: <125402.60045.qm@web25912.mail.ukl.yahoo.com>
References: <125402.60045.qm@web25912.mail.ukl.yahoo.com>
Message-ID: <f06240818c2ae946a7862@[66.80.62.44]>

>How can i expand the Live555 to implement the rtcp app packet.

You would need to modify the "RTCPInstance" implementation, defined 
in "liveMedia/RTCP.cpp".

>Can the app packet replace the bye packet ?

No.  The "BYE" packet is defined in the RTP/RTCP standard, and should 
continue to be implemented.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Mon Jul  2 04:46:06 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 04:46:06 -0700
Subject: [Live-devel] presentationTime and B-Frames
In-Reply-To: <4688AB13.6030209@mytum.de>
References: <468515BE.6090105@mytum.de>
	<f06240800c2abb687411a@[66.80.62.44]> <4688AB13.6030209@mytum.de>
Message-ID: <f06240819c2ae951ca219@[66.80.62.44]>

>  > Note that In your original MPEG-2 stream, with B-frames, the frames
>>  will be in decoding order, which is different from the display order,
>>  and thus different from the order of frames in the resulting MPEG-4
>>  stream (because that doesn't have B frames).  In particular, the
>>  presentation times in the original MPEG-2 stream, with B-frames, will
>>  *not* be monotonically increasing.  You will need to reorder the
>>  presentation times accordingly when you convert the stream to MPEG-4
>>  (without B-frames).
>>  
>
>My source is the vobStreamer application. Examining the packets it looks
>like if they are sent rather in display order (IBBPBBPBBPBBI...).

I believe you're mistaken on this point.  E.g., the first B-frames 
that you receive after each I-frame are  actually intended to be 
displayed *before* the i-frame.  That's why the B-frames will have a 
lower presentation time than the I-frame.

You need to take this into account when assigning presentation times 
to the transcoded MPEG-4 frames (without B-frames).

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From neo_star2007 at yahoo.es  Mon Jul  2 06:06:03 2007
From: neo_star2007 at yahoo.es (Joan Manuel Zabala)
Date: Mon, 2 Jul 2007 15:06:03 +0200 (CEST)
Subject: [Live-devel] Help with the testMPEG1or2VideoStreamer
In-Reply-To: <e776c1620706260912r7b16d813o50c2890fa69f3040@mail.gmail.com>
Message-ID: <439640.77479.qm@web28103.mail.ukl.yahoo.com>

ok, Russell. thank you very much by the clarifying one now. I have a problem with my programs client and server, because the side server supposedly is transmitting the packages of video to the network by a port RTP (8888) and the client is not receiving anything. in addition I am working of local way in a single machine... but also I have proven with two machines in network point to point, and does not work either.
Another thing, when I connect my 2 machines to the local area network of the institute, the programs say me that the machines do not have valid direction IP which are assigned to the machines by a DHCP server .

  Do you could help me in that, please?

  Joan Zabala - Venezuela


Russell Brennan <rjbrennn at gmail.com> escribi?:
    If I understand your question correctly, you are simply asking if packets are sent when startPlaying() is called. I believe the answer is no, doEventLoop() calls a function called SingleStep() in a while loop.  Each time SingleStep() is executed, a packet is sent.  That's as deep as I understand it. 
   
  Russell

 
  On 6/26/07, Joan Manuel Zabala <neo_star2007 at yahoo.es> wrote:     hello! I wanted that somebody could help me. saying to me, if the testing program to testMPEG1or2VideoStreamer when arriving at the point where startPlaying() is called to the function initiates the transmission of the video through the network. or on the contrary I must make a function so that it initiates the shipment of packages to the network and how I could do it. 
  on the other hand, if I have a receiving program of video by RTP when unloading the data from the network and startPlaying() is called to the function, after that begins the reproduction of the video or I must use a decoder to part? 
  I ask this, because I am making a project for reception of live video using RTP/RTCP/RTSP, and must soon give the results of this development, more or less for half-full of Julio, and I am on the brink of madness, please if somebody could help me would thank for it. because it is my project of graduation and it is very important for my. 
  of before hand, thanks.
  Joan Zabala -  Venezuela
   
    
---------------------------------
  
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m?viles desde 1 c?ntimo por minuto.
http://es.voice.yahoo.com   
  

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com 
http://lists.live555.com/mailman/listinfo/live-devel





-- 
Russell Brennan
RJBrennn at gmail.com
(708) 699-7314 _______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


       
---------------------------------

?Descubre una nueva forma de obtener respuestas a tus preguntas!
Entra en Yahoo! Respuestas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070702/6837ed03/attachment.html 

From tl11305 at salle.url.edu  Mon Jul  2 09:32:16 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Mon, 2 Jul 2007 18:32:16 +0200 (CEST)
Subject: [Live-devel] Close On Demand Session from Server
Message-ID: <1217.172.16.11.128.1183393936.squirrel@webmail.salle.url.edu>

Hi all,
Could I close an on demand session from server side? How will it be the best
way to do that?

I tried "rtspServer->removeServerMediaSession(sms)" and then, this subsession
is not accessible for future RTSP requests, but a client that is playing this
session continues playing the video. I would like to stop sending videos too.

Thanks in advance,

Ramon


From fherna04 at harris.com  Mon Jul  2 13:36:17 2007
From: fherna04 at harris.com (Hernandez, Fernando)
Date: Mon, 2 Jul 2007 16:36:17 -0400
Subject: [Live-devel] Increasing UDP packet sizes for streaming MPEG video?
Message-ID: <4C1EB210CB4D784D89E9B4858CF5DE8B22A2E0@mlbe2k5.cs.myharris.net>

Hello,

I have a question about MPEG video streaming and UDP packet sizes.

I'm working on a server application which does up to two streams of 10
Mbit/sec HD MPEG video, and have been running into performance problems.
The problems occur because the system is already under a moderate load
from a few other things it has to do, and starting a play session of 10
Mbit video will max out at around 6 - 7 Mbit/sec.  The throughput of the
line isn't the problem, as this is run over a GigE interface.  When run
by themselves, the video playback threads reach the full 10 Mb/sec rate.

Grabbing an Ethernet trace of the data as it comes in shows the data in
UDP packets coming across the line with data payloads of 1328 bytes.  I
am interested in increasing this to a few dozen kb at least, in order to
improve performance, but where should I look to find the code that deals
with this?  The way it is structured right now, the server has to push
out around two thousand UDP messages per second to maintain the desired
rate, and reducing the number of messages should help throughput.  Is
this feasible with a little work on my end?

Thanks for any direction that you can provide.


--------------------------
Fernando Hernandez
Software Engineer
Harris Corporation GCSD
321-729-3413


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070702/b8df9a7b/attachment.html 

From finlayson at live555.com  Mon Jul  2 16:11:07 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 16:11:07 -0700
Subject: [Live-devel] Close On Demand Session from Server
In-Reply-To: <1217.172.16.11.128.1183393936.squirrel@webmail.salle.url.edu>
References: <1217.172.16.11.128.1183393936.squirrel@webmail.salle.url.edu>
Message-ID: <f0624081ac2af35da6fcf@[66.80.62.44]>

>Could I close an on demand session from server side?

There is currently no way in the code to do this so that all current 
streams for the session stop immediately.

However, if your intention is to stop streaming to dead clients, then 
remember the "reclamationTestSeconds" parameter to 
"RTSPServer::createNew()" - see "liveMedia/include/RTSPServer.hh".
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Mon Jul  2 16:35:49 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Jul 2007 16:35:49 -0700
Subject: [Live-devel] Increasing UDP packet sizes for streaming MPEG
 video?
In-Reply-To: <4C1EB210CB4D784D89E9B4858CF5DE8B22A2E0@mlbe2k5.cs.myharris.net>
References: <4C1EB210CB4D784D89E9B4858CF5DE8B22A2E0@mlbe2k5.cs.myharris.net>
Message-ID: <f0624081cc2af389f1601@[66.80.62.44]>

>Grabbing an Ethernet trace of the data as it comes in shows the data 
>in UDP packets coming across the line with data payloads of 1328 
>bytes.  I am interested in increasing this to a few dozen kb at 
>least, in order to improve performance, but where should I look to 
>find the code that deals with this?

First, I'm assuming that your network MTU is large enough to 
accommodate larger UDP packets.  (If instead, your network MTU is 
something like the usual 1500 bytes, then you should not try to send 
larger UDP packets, otherwise you'll end up with IP-level 
fragmentation, and bad performance if packets get lost.)

If your network MTU is really large enough to accommodate larger 
packets, then you can do so by making the following two changes:
1/ In "MultiFramedRTPSink.cpp", change the call to "setPacketSizes()" 
on line 46.  (Alternatively, call "setPacketSizes()" with your new 
parameters after each "RTPSink" object is created.)
2/ In "MPEG2TransportFileServerMediaSubsession.cpp", change the 
definition of "TRANSPORT_PACKETS_PER_NETWORK_PACKET", so that
	12 + 188*TRANSPORT_PACKETS_PER_NETWORK_PACKET < your maximum 
UDP packet size
	(12 bytes is the size of the RTP header)
-- 

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/20070702/d77f2203/attachment-0001.html 

From weiyutao36 at 163.com  Mon Jul  2 17:52:47 2007
From: weiyutao36 at 163.com (weiyutao36)
Date: Tue, 3 Jul 2007 08:52:47 +0800 (CST)
Subject: [Live-devel] about using live555 library as a streaming server
Message-ID: <1819047502.1982541183423967675.JavaMail.coremail@bj163app120.163.com>

Hi everyone, I want to use live555 streaming Media library as a streaming server and I
 
have serveral questions: (1) Can the live555 library be used in a practical application, for example, a
 
VoD system, as a streaming server and, can the streaming server run
stably for normal use? (2) I know that currently the server can stream mpeg-4 elementary stream
 
and want to know further:
 
    a) do the company  have the plan to make the library support  streaming
a mpeg-4 file including audio and video;
  
    b) is it possible for myself to modify  the code to make it have this
 
       functionality? If it is possible, what should I do?
 
Thank you very much. ----------------------
Yutao Wei   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070702/247f8696/attachment.html 

From krishnakishore.nakarikanti at gmail.com  Tue Jul  3 00:43:03 2007
From: krishnakishore.nakarikanti at gmail.com (krishnakishore)
Date: Tue, 3 Jul 2007 13:13:03 +0530
Subject: [Live-devel] Problem in RTSP Response
Message-ID: <a9159750707030043v15d746d1o643530749fc73cc0@mail.gmail.com>

Hello All,
                               This is kishore from INDIA. we are developing
an MPEG2 Streaming server on windows. Actually my problem is, After sending
the RTSP SETUP Response to client ( VLC Player ) i am not getting any
further RTSP Request from client. And also the existing connection has been
forcibly closed by the client. I am describing the total Session Details
below. please see, and kindly tell me what exactly the problem is. And one
more problem is the connection between my Server and Client has been
forcibly closed by the Client.I am running my client and server on the same
machine. some one please help me.Thanks in advance.



Request:

OPTIONS rtsp://10.10.10.8:1234/39.mpg RTSP/1.0
CSeq: 7
User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)



Response:

RTSP/1.0 200 OK
CSeq: 7
Server: Mpeg2StreamingServer
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Content-Length: 0


Request:


DESCRIBE rtsp://10.10.10.8:1234/39.mpg RTSP/1.0
CSeq: 8
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)


Response:

RTSP/1.0 200 OK
Server: Mpeg2StreamingServer
CSeq: 8
Cache-Control: no-cache
Content-Length: 250
Content-Type: application/sdp

v=0
o=Mpeg2StreamingServer -902530567 -902530567 IN IP4 10.10.10.8
s=RTSP Session
u=http:///
e=admin@
c=IN IP4 0.0.0.0
i=RTSP test
t=0 0
a=tool:vlc 0.8.6a
a=range:npt=0- 41.00000
m=video 0 RTP/AVP 32
a=rtpmap:32 MPV/90000
a=control:rtsp://10.10.10.8:1234/39.mpg/trackID=1



Request:

SETUP rtsp:/ RTSP/1.0
CSeq: 9
Transport: RTP/AVP;unicast;client_port=1834-1835
User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)



Response:

RTSP/1.0 200 OK
Server: Mpeg2StreamingServer
CSeq: 9
Cache-Control: no-cache
Session: 43069932053063
Transport: RTP/AVP;unicast;destination=10.10.10.8;source=10.10.10.8
;client_port=1834-1835;server_port=2344-2345;ssrc=5AD314
Content-Length: 0



And i am getting the following Messages in VLC player


VLC Messages:

main debug: creating new input thread
main debug: waiting for thread completion
main debug: thread 3936 (input) created at priority 1 (input/input.c:265)
main debug: `rtsp://10.10.10.8:1234/39.mpg' gives access `rtsp' demux `'
path `10.10.10.8:1234/39.mpg'
main debug: creating demux: access='rtsp' demux='' path='
10.10.10.8:1234/39.mpg'
main debug: looking for access_demux module: 1 candidate
live555 debug: RTP subsession 'video/MPV'
live555 error: SETUP of'video/MPV' failed no response code in line:
"/10.10.10.8:1234/39.mpg/trackID=1"
live555 error: Nothing to play for rtsp://10.10.10.8:1234/39.mpg
main warning: no access_demux module matching "rtsp" could be loaded
main debug: creating access 'rtsp' path='10.10.10.8:1234/39.mpg'
main debug: looking for access2 module: 5 candidates
main debug: net: connecting to 10.10.10.8 port 1234
main debug: connection in progress




What should i have to do now?

Please kindly help me.Thank You All.



-- 
Regards ,
Krishna Kishore. N ,
Ph: +91 9848668168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070703/39a40df3/attachment.html 

From lartc at manchotnetworks.net  Tue Jul  3 01:04:23 2007
From: lartc at manchotnetworks.net (lartc)
Date: Tue, 03 Jul 2007 10:04:23 +0200
Subject: [Live-devel] forcing subtitles / merging subtitles into video stream
Message-ID: <1183449863.3998.13.camel@sumatra.radius.fr>

hi all,

i have a dvd in spanish and need to force the english subtitles into the video
stream for rendering clients that cannot pick out the subtitle ES in a TS ...

is this possible ??


thanks :-)


charles
 


From tl11305 at salle.url.edu  Tue Jul  3 01:54:50 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Tue, 3 Jul 2007 10:54:50 +0200 (CEST)
Subject: [Live-devel] Close On Demand Session from Server
Message-ID: <1145.172.16.11.128.1183452890.squirrel@webmail.salle.url.edu>

>However, if your intention is to stop streaming to dead clients, then
>remember the "reclamationTestSeconds" parameter to
>"RTSPServer::createNew()" - see "liveMedia/include/RTSPServer.hh".

Thankyou very much Ross, but it is not exactly what I need. I am offering some
services from my Web Service, and a manager will have to control all services
offered. He can remove and add some broadcast and on-demand services on video
server when he want. Do you know some way to implement a stop function for an
on-demand session? Maybe send some kind of BYE message to client to stop
playing?

If I do "rtspServer->removeServerMediaSession(sms)" client that is playing
continues it, but the worst thing is that if client does a stop and then play
again it breaks down RTSPServer and my application. Is there any sense in it?

Thanks in advence,

Ramon


From finlayson at live555.com  Tue Jul  3 03:25:14 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Jul 2007 03:25:14 -0700
Subject: [Live-devel] forcing subtitles / merging subtitles into video
 stream
In-Reply-To: <1183449863.3998.13.camel@sumatra.radius.fr>
References: <1183449863.3998.13.camel@sumatra.radius.fr>
Message-ID: <f06240801c2afd46f505f@[66.80.62.44]>

>i have a dvd in spanish and need to force the english subtitles into the video
>stream for rendering clients that cannot pick out the subtitle ES in a TS ...
>
>is this possible ??

No, not with the "LIVE555 Streaming Media" software (which is what 
this mailing list is for).
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul  3 03:53:31 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Jul 2007 03:53:31 -0700
Subject: [Live-devel] Problem in RTSP Response
In-Reply-To: <a9159750707030043v15d746d1o643530749fc73cc0@mail.gmail.com>
References: <a9159750707030043v15d746d1o643530749fc73cc0@mail.gmail.com>
Message-ID: <f06240803c2afda8dbf7a@[66.80.62.44]>

>                                This is kishore from INDIA. we are 
>developing an MPEG2 Streaming server on windows.

Did you consider using our RTSP server implementation?  (If you had, 
you probably would have avoided your problem.)

>Response:
>
>RTSP/1.0 200 OK
>Server: Mpeg2StreamingServer
>CSeq: 8
>Cache-Control: no-cache
>Content-Length: 250
>Content-Type: application/sdp
>
>v=0
>o=Mpeg2StreamingServer -902530567 -902530567 IN IP4 
><http://10.10.10.8> 10.10.10.8
>s=RTSP Session
>u=http:///
>e=admin@
>c=IN IP4 <http://0.0.0.0>0.0.0.0
>i=RTSP test
>t=0 0
>a=tool:vlc 0.8.6a
>a=range:npt=0- 41.00000
>m=video 0 RTP/AVP 32
>a=rtpmap:32 MPV/90000
>a=control:rtsp://10.10.10.8:1234/39.mpg/trackID=1

I think the "a=control:" line is the problem.  It should be
	a=control:trackID=1

In any case, I suggest using our "openRTSP" command-line RTSP client 
<http://www.live555.com/openRTSP/> to debug your server.  (You will 
probably find this easier to use than VLC.)
-- 

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/20070703/a20ad0d4/attachment.html 

From rmcouat at smartt.com  Tue Jul  3 19:55:05 2007
From: rmcouat at smartt.com (Ron McOuat)
Date: Tue, 03 Jul 2007 19:55:05 -0700
Subject: [Live-devel] No ability to have directories under live555 Media
	Server
Message-ID: <468B0C09.4050901@smartt.com>

The docs say the file must be in the mediaServer process directory. 
Turning on debug mode and recompiling the package reveals the reason a 
subdirectory for media is not functional. A URL of the form 
rtsp://<ip_address>/content/testx.m4e will result in 404 errors. The 
devil is the URL if it starts out as rtsp://<ip_address>/testx.m4e (no 
content subdirectory) is modified later to include the track number to 
be something of the form 
rtsp://<ip_address>/testx.m4e/track1;seq=29023;rtptime=646689728 so 
initially testx.m4e is parsed out as urlSuffix during DESCRIBE and later 
becomes urlPreSuffix for SETUP and PLAY. If the URL has a subdirectory 
then the subdirectory becomes the preSuffix in the first stage and is 
lost for the file existence tests during session creation resulting in a 
404 error and nothing futher is attempted. Tying to add subdirectories 
would mean a context sensitive parse of the URL would be needed along 
with preservation of the full file path in the session relative to the 
mediaServer directory. Also for Windows and possibly other systems the 
filesystem access would have to have path separator substitution. 
Probably I have missed aspects of this I do not yet understand.

My question - is there any interest in changing this so subdirectories 
are allowed for the mediaServer? I could look at doing this but don't 
really have a desire to support my own fork of the live555 code because 
my belief is there are significant changes and testing required which 
assuming I perform this in an acceptable way could be given back to the 
project. I tested a workaround which would be to take the hierarchical 
name and flatten it by removing the / separator and adding a symlink to 
the mediaServer directory that points to the hierarchical name and then 
use a URL referring to the media using the flattened name. This may be 
an adequate solution in my case.

Thanks for your consideration,
Ron McOuat

From finlayson at live555.com  Tue Jul  3 22:10:26 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Jul 2007 22:10:26 -0700
Subject: [Live-devel] No ability to have directories under live555 Media
 Server
In-Reply-To: <468B0C09.4050901@smartt.com>
References: <468B0C09.4050901@smartt.com>
Message-ID: <f06240803c2b0db67ea6f@[66.80.62.44]>

>My question - is there any interest in changing this so subdirectories
>are allowed for the mediaServer?

This is a possible feature to add sometime in the future, but it's 
low-priority, because it would add nothing more than cosmetic 
functionality.  (There are other far more important features that are 
higher-priority.)

If you really want to keep your media files in a separate directory, 
then you can use symbolic links.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From donghoon.vanuytsel at esaturnus.com  Wed Jul  4 05:15:29 2007
From: donghoon.vanuytsel at esaturnus.com (Dong Hoon Van Uytsel)
Date: Wed, 04 Jul 2007 14:15:29 +0200
Subject: [Live-devel] one stream received on multiple multicast addresses
Message-ID: <1183551329.5967.15.camel@localhost>

Dear list members,

I'm seeing the following strange behaviour using liveMedia: one stream
to a certain multicast group is being received on other multicast
addresses too, if the receiving host is member of the streamer's group
too. 

Not sure whether this is due to configuration error of my linux hosts
(Debian etch) or switch (D-Link DGS-1216T) - or is this even expected
behavior?

For instance, testMPEG1or2VideoReceiver.cpp:56 reads

	= "239.6.42.42";

and testMPEG1or2VideoStreamer.cpp:68 reads

	= "239.7.42.42";

SSM is not used.

In this situation, testMPEG1or2VideoReceiver sees the stream sent by
testMPEG1or2VideoStreamer as long as another process on the same host is
listening on 239.6.42.42 .

Best regards
Dong Hoon


From julian.lamberty at mytum.de  Wed Jul  4 07:57:06 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 04 Jul 2007 16:57:06 +0200
Subject: [Live-devel] RTCP and synchronization
Message-ID: <468BB542.1020905@mytum.de>

Hi!

As RTCP SR packets carry NTP ans RTP timestamps I would like to know how 
they are used to sync to streams. I found out that the RTP timestamp in 
the RTCP SR corresponds to the timevalue which the NTP timestamp indicates.

But why can't I find the RTP timestamp in the packets of my videostream? 
For example I have (taken from wireshark):

RTCP Sender Report:

Arrival Time: Jul  2, 2007 14:34:00.669515000
MSW and LSW as NTP timestamp: Jul  2, 2007 12:27:10.3529 UTC
RTP timestamp: 2965177770

But my video stream has timestamps beginning at higher values.

RTP packet:

Arrival Time: Jul  2, 2007 14:34:00.651933000
Timestamp: 3583401060

How do these times correspond to each other?

What leads me to this problem is the question, how I can keep a video 
stream synchronised to an audio stream when I manipulate the video 
stream on its way to the final recipient (i.e. transcoding it)? When I 
send out the manipulated videoframes, they get a new RTP timestamp 
offset and the receiver will not be able to sync them to the 
unmanipulated audio stream...?

From finlayson at live555.com  Wed Jul  4 08:59:35 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Jul 2007 08:59:35 -0700
Subject: [Live-devel] one stream received on multiple multicast addresses
In-Reply-To: <1183551329.5967.15.camel@localhost>
References: <1183551329.5967.15.camel@localhost>
Message-ID: <f06240806c2b1708e1f2c@[66.80.62.44]>

>For instance, testMPEG1or2VideoReceiver.cpp:56 reads
>
>	= "239.6.42.42";
>
>and testMPEG1or2VideoStreamer.cpp:68 reads
>
>	= "239.7.42.42";
>
>SSM is not used.
>
>In this situation, testMPEG1or2VideoReceiver sees the stream sent by
>testMPEG1or2VideoStreamer as long as another process on the same host is
>listening on 239.6.42.42 .

This is a problem with some operating systems - if two or more 
receivers have joined different multicast groups, but using the same 
port number, then - on some operating systems - all received packets 
will be delivered to all receivers.

To overcome this, use different port numbers as well as different 
multicast groups.  (Remember, though, that for RTP, the port number 
should always be even.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul  4 09:09:38 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Jul 2007 09:09:38 -0700
Subject: [Live-devel] RTCP and synchronization
In-Reply-To: <468BB542.1020905@mytum.de>
References: <468BB542.1020905@mytum.de>
Message-ID: <f06240807c2b1749c126e@[66.80.62.44]>

>As RTCP SR packets carry NTP ans RTP timestamps I would like to know how
>they are used to sync to streams.

As described in RFC 3550.


>  I found out that the RTP timestamp in
>the RTCP SR corresponds to the timevalue which the NTP timestamp indicates.
>
>But why can't I find the RTP timestamp in the packets of my videostream?

Because they're not useful to you.

I'll say this yet again (and hopefully for the last time): Our 
RTP/RTCP implementation automatically computes synchronized 
presentation times using RTP timestamps and RTCP reports.  Code that 
receives a RTP stream (using our library) should never have to look 
at RTP timestamps.  Instead, just use the presentation time.  If you 
are also using RTCP (which you should be), then the presentaton time 
*will* be properly synchronized.


>What leads me to this problem is the question, how I can keep a video
>stream synchronised to an audio stream when I manipulate the video
>stream on its way to the final recipient (i.e. transcoding it)?

Just make sure that frames of the transcoded stream get correct 
presentation times (and that you create a new "RTCPInstance" object 
for the new outgoing stream).
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From donghoon.vanuytsel at esaturnus.com  Wed Jul  4 11:55:24 2007
From: donghoon.vanuytsel at esaturnus.com (Dong Hoon Van Uytsel)
Date: Wed, 4 Jul 2007 20:55:24 +0200
Subject: [Live-devel] one stream received on multiple multicast addresses
In-Reply-To: <f06240806c2b1708e1f2c@[66.80.62.44]>
References: <1183551329.5967.15.camel@localhost>
	<f06240806c2b1708e1f2c@[66.80.62.44]>
Message-ID: <5AA2F0EC-E6CC-4FE8-82D9-EF8D0FEECC21@esaturnus.com>

Op 4-jul-07, om 17:59 heeft Ross Finlayson het volgende geschreven:

>> For instance, testMPEG1or2VideoReceiver.cpp:56 reads
>>
>> 	= "239.6.42.42";
>>
>> and testMPEG1or2VideoStreamer.cpp:68 reads
>>
>> 	= "239.7.42.42";
>>
>> SSM is not used.
>>
>> In this situation, testMPEG1or2VideoReceiver sees the stream sent by
>> testMPEG1or2VideoStreamer as long as another process on the same  
>> host is
>> listening on 239.6.42.42 .
>
> This is a problem with some operating systems - if two or more
> receivers have joined different multicast groups, but using the same
> port number, then - on some operating systems - all received packets
> will be delivered to all receivers.
>
> To overcome this, use different port numbers as well as different
> multicast groups.  (Remember, though, that for RTP, the port number
> should always be even.)

Thank you Ross! I had already found that out by experimentation, but  
it is good to know this is a known work-around for linux.

Best regards
Dong Hoon



From yang-m-h at 126.com  Wed Jul  4 19:44:55 2007
From: yang-m-h at 126.com (yang-m-h at 126.com)
Date: Thu, 5 Jul 2007 10:44:55 +0800 (CST)
Subject: [Live-devel] When I ran "testOnDemandRTSPServer",
 It c annot work. What's wrong?
Message-ID: <468C5B27.0000B5.25112@bj126app17.126.com>

Dear Engineering,
I use the testOnDemandRTSPServer to play the stream from a mpeg4 encoder. So I just modified the input file name to be the device I want to use. But the output is 
 
"open success<BR>Unable to determine our source address: This computer has an invalid IP address:<BR> 0x0<BR>Unable to determine our source address: This computer has an invalid IP address:<BR> 0x0<BR>Command fault!<BR>close success"
 
 It seems that the testOnDemandRTSPServer program call the device ioctl function. But I did not find where the function is called.
 
                                     expecting your letter!
                                     
                                                                                           yours   sincerely
 
 


? ? 150 ? ? ? ? ??? ? ? ? ? ? ? ?  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070704/20143ee4/attachment.html 

From finlayson at live555.com  Wed Jul  4 20:53:48 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Jul 2007 20:53:48 -0700
Subject: [Live-devel] When I ran "testOnDemandRTSPServer",
 It c annot work. What's wrong?
In-Reply-To: <468C5B27.0000B5.25112@bj126app17.126.com>
References: <468C5B27.0000B5.25112@bj126app17.126.com>
Message-ID: <f06240800c2b20ee2e0b9@[66.80.62.44]>

>"open success
>Unable to determine our source address: This computer has an invalid 
>IP address:
>  0x0

This error usually means that you do not have networking configured 
properly on your system.

Does your computer have a network interface?  Are you able to access 
it from other computers?

(If you're on a Unix system, make sure that multicast is configured 
properly - i.e., make sure you have a route for 224.0.0/4.  The code 
uses multicast loop-back as one method of finding your IP address.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From tl11305 at salle.url.edu  Thu Jul  5 02:28:44 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Thu, 5 Jul 2007 11:28:44 +0200 (CEST)
Subject: [Live-devel] MPEG4 Audio
Message-ID: <1277.172.16.11.128.1183627724.squirrel@webmail.salle.url.edu>

Hi,
I saw there are implemented classes to stream MPEG4 Audio based on RFC3016
(MPEG4LATMAudioRTPSink, MPEG4LATMAudioRTPSource). What kind of session may I
use to create an on-demand service of this audio? Using this classes could I
stream a MPEG4 elementary audio stream based on RFC3640?

Thanks in advance,

Ramon


From finlayson at live555.com  Thu Jul  5 02:42:05 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Jul 2007 02:42:05 -0700
Subject: [Live-devel] MPEG4 Audio
In-Reply-To: <1277.172.16.11.128.1183627724.squirrel@webmail.salle.url.edu>
References: <1277.172.16.11.128.1183627724.squirrel@webmail.salle.url.edu>
Message-ID: <f06240801c2b26ca6f262@[66.80.62.44]>

>I saw there are implemented classes to stream MPEG4 Audio based on RFC3016
>(MPEG4LATMAudioRTPSink, MPEG4LATMAudioRTPSource). What kind of session may I
>use to create an on-demand service of this audio?

You would need to write your own 
"MPEG4LATMAudioFileServerMediaSubsession" class.  This should be easy 
to do (just use one of the existing "*FleServerMediaSubsession" 
classes as a model).

>  Using this classes could I
>stream a MPEG4 elementary audio stream based on RFC3640?

No, for RFC3640 audio streaming you would use the existing 
"ADTSAudioFileServerMediaSubsession" (and "ADTSAudioFileSource") 
classes.  Note that the "live555MediaServer" application, and the 
demo "testOnDemandRTSPServer" application already stream ADTS-format 
MPEG-4 audio files using RFC3640.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From rjbrennn at gmail.com  Thu Jul  5 13:55:38 2007
From: rjbrennn at gmail.com (Russell Brennan)
Date: Thu, 5 Jul 2007 16:55:38 -0400
Subject: [Live-devel] MPEG2TransportStreamRTPSource and testMPEG2TSreceiver:
	not quite right...
Message-ID: <e776c1620707051355t414ef1bwbbf542211de5c5d5@mail.gmail.com>

I am trying to make a "testMPEG2TSReceiver" executable that will receive
MPEG2-TS streams, which I am playing using testMPEG2TransportStreamer.  I
think that this would be a solid addition to the test programs included with
the library.  I have started by using "testMPEG1or2VideoReceiver" as a
template to build a TS receiver, and it appears that I will simply need to
create a "MPEG2TransportStreamRTPSource" class to replace
"MPEG1or2VideoRTPSource" with.  Is this correct?  Nothing else seems
format-dependant.

To create "MPEG2TransportStreamRTPSource" I used "MPEG1or2VideoRTPSource" as
a template, but use "rtpPayloadFormat = 33" as the format type.  This is
where I get lost... I don't know what sBit, bBit, or eBit should be and if
they should differ in my new class, or if I need to change anything else for
that matter.  Any help here would be much appreciated!

-- 
Russell Brennan
RJBrennn at gmail.com
(708) 699-7314
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070705/54826cdc/attachment.html 

From xcsmith at rockwellcollins.com  Thu Jul  5 16:31:52 2007
From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com)
Date: Thu, 5 Jul 2007 18:31:52 -0500
Subject: [Live-devel] MPEG2TransportStreamRTPSource and testMPEG2TSreceiver:
 not quite right...
Message-ID: <OFD3908D73.D9446A8E-ON8625730F.0080E7B9-8625730F.00818AE9@rockwellcollins.com>

Do you have a specific reason to not use openRTSP to receive transport 
streams?  testMPEG2TransportStreamer has an optional RTSP server in it.

I think instead of making MPEG2TransportStreamRTPSource, you should set up 
the chain like this:

SimpleRTPSource -> MPEG2TransportStreamFramer -> FileSink

xo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070705/cc350195/attachment-0001.html 

From finlayson at live555.com  Thu Jul  5 17:52:42 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Jul 2007 17:52:42 -0700
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
 testMPEG2TSreceiver: not quite right...
In-Reply-To: <OFD3908D73.D9446A8E-ON8625730F.0080E7B9-8625730F.00818AE9@rockwellcollins
	.com>
References: <OFD3908D73.D9446A8E-ON8625730F.0080E7B9-8625730F.00818AE9@rockwellcollins
	.com>
Message-ID: <f06240802c2b341e6d9bd@[66.80.62.44]>

>Do you have a specific reason to not use openRTSP to receive 
>transport streams?  testMPEG2TransportStreamer has an optional RTSP 
>server in it.
>
>I think instead of making MPEG2TransportStreamRTPSource, you should 
>set up the chain like this:
>
>SimpleRTPSource -> MPEG2TransportStreamFramer -> FileSink

Actually, you won't need to insert a "MPEG2TransportStreamFramer", 
because its main purpose is to extract presentation times from the 
transport stream, and you won't need those if you're just outputting 
to a "FileSink".

You can create a "RTPSource" for receiving a MPEG Transport/RTP 
stream by calling
	SimpleRTPSource::createNew(envir(), rtpGroupsock, 30,
                                                	90000, "video/MP2T", 0, False);
-- 

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/20070705/05495e2d/attachment.html 

From yang-m-h at 126.com  Thu Jul  5 19:02:28 2007
From: yang-m-h at 126.com (yang-m-h at 126.com)
Date: Fri, 6 Jul 2007 10:02:28 +0800 (CST)
Subject: [Live-devel] In the "testOnDemandServer",
 where call th e device iocntl funtion?
Message-ID: <468DA2B4.00001F.31757@bj126app17.126.com>

Dear list menbers.
 
I run the testOnDemandServer program to transfer the mpeg4 video stream from a encoding device.But the program seems to call the ioctl function than close the device.So I cannot see the realtime video. in what case, it will open the file and then call the control function,and then to close it. Thank for your help! Expecting for your letter!
 
                                                                                                      yours sincerely. 
 
 
 


150 ? ? ? ? ? ? ? ? ??? ? ? ? ? ?  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070705/68908560/attachment.html 

From donghoon.vanuytsel at esaturnus.com  Fri Jul  6 01:07:14 2007
From: donghoon.vanuytsel at esaturnus.com (Dong Hoon Van Uytsel)
Date: Fri, 06 Jul 2007 10:07:14 +0200
Subject: [Live-devel] minimum inter-packet delay
Message-ID: <1183709234.25645.26.camel@localhost>

Hello Ross & list,

I have a linux application send uncompressed frames using the liveMedia
library; with wireshark I'm measuring 17 microseconds between successive
packets (sized 1490 bytes, of the same image frame) being sent, which
boils down to instantaneous bandwidth consumption of 700 Mb/s. In this
configuration, several packets are lost at some receivers. I've already
tried increasing the UDP sending and receiving buffers - but this
doesn't solve the packet loss.

A temporary work-around seems to increase the interpacket gap to 30
microseconds by inserting a few fprintf()s in sendPacket() in
RTPInterface.cpp. However, isn't there a cleaner solution to specify the
minimum inter-packet gap in liveMedia?

Best regards
Dong Hoon Van Uytsel


From finlayson at live555.com  Fri Jul  6 01:22:41 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Jul 2007 01:22:41 -0700
Subject: [Live-devel] minimum inter-packet delay
In-Reply-To: <1183709234.25645.26.camel@localhost>
References: <1183709234.25645.26.camel@localhost>
Message-ID: <f06240806c2b3aa278b49@[66.80.62.44]>

>I have a linux application send uncompressed frames using the liveMedia
>library; with wireshark I'm measuring 17 microseconds between successive
>packets (sized 1490 bytes, of the same image frame) being sent, which
>boils down to instantaneous bandwidth consumption of 700 Mb/s. In this
>configuration, several packets are lost at some receivers. I've already
>tried increasing the UDP sending and receiving buffers - but this
>doesn't solve the packet loss.
>
>A temporary work-around seems to increase the interpacket gap to 30
>microseconds by inserting a few fprintf()s in sendPacket() in
>RTPInterface.cpp. However, isn't there a cleaner solution to specify the
>minimum inter-packet gap in liveMedia?

Are you setting the "fDurationInMicroseconds" variable correctly in 
whatever source object(s) feed into your "RTPSink" (or 
"BasicUDPSink") object?  It's that variable that determines the 
(average) inter-packet gap.

However, what is your data's bitrate *supposed* to be?  If it really 
is supposed to be 700 Mbps, then you're not going to be able to 
increase the average inter-packet delay - it is what it is.

Note that becuase the "LIVE555 Streaming Media" code is 
single-threaded code that simply reads sequentially from a socket, 
any packet loss that you see cannot be the fault of this code. 
Instead, it must be either actual network packet loss, or data loss 
(e.g., overflowing buffers) within your OS.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From donghoon.vanuytsel at esaturnus.com  Fri Jul  6 01:50:30 2007
From: donghoon.vanuytsel at esaturnus.com (Dong Hoon Van Uytsel)
Date: Fri, 06 Jul 2007 10:50:30 +0200
Subject: [Live-devel] minimum inter-packet delay
In-Reply-To: <f06240806c2b3aa278b49@[66.80.62.44]>
References: <1183709234.25645.26.camel@localhost>
	<f06240806c2b3aa278b49@[66.80.62.44]>
Message-ID: <1183711830.25645.36.camel@localhost>

On Fri, 2007-07-06 at 01:22 -0700, Ross Finlayson wrote:
> >I have a linux application send uncompressed frames using the liveMedia
> >library; with wireshark I'm measuring 17 microseconds between successive
> >packets (sized 1490 bytes, of the same image frame) being sent, which
> >boils down to instantaneous bandwidth consumption of 700 Mb/s. In this
> >configuration, several packets are lost at some receivers. I've already
> >tried increasing the UDP sending and receiving buffers - but this
> >doesn't solve the packet loss.
> >
> >A temporary work-around seems to increase the interpacket gap to 30
> >microseconds by inserting a few fprintf()s in sendPacket() in
> >RTPInterface.cpp. However, isn't there a cleaner solution to specify the
> >minimum inter-packet gap in liveMedia?
> 
> Are you setting the "fDurationInMicroseconds" variable correctly in 
> whatever source object(s) feed into your "RTPSink" (or 
> "BasicUDPSink") object?  It's that variable that determines the 
> (average) inter-packet gap.

yes, I think so (40000 us ; 25 fps). the _average_ inter-packet gap is
what you would expect, but in effect the packets are not spaced evenly
in time; they are sent in bursts.
> 
> However, what is your data's bitrate *supposed* to be?  If it really 
> is supposed to be 700 Mbps, then you're not going to be able to 
> increase the average inter-packet delay - it is what it is.

the average data's bitrate is supposed to be 130Mbs. but the bitrate
during "bursts" is 700Mbs (and zero in between), as measured with
ethereal. it seems something in the network seems to have difficulties
with this.

> Note that becuase the "LIVE555 Streaming Media" code is 
> single-threaded code that simply reads sequentially from a socket, 
> any packet loss that you see cannot be the fault of this code. 
> Instead, it must be either actual network packet loss, or data loss 
> (e.g., overflowing buffers) within your OS.

yes, it may be due to the switch or its configuration I'm using (D-Link
DGS-1216T). i'll look into it further. thanks for your suggestions!

Dong Hoon


From rjbrennn at gmail.com  Fri Jul  6 09:06:21 2007
From: rjbrennn at gmail.com (Russell Brennan)
Date: Fri, 6 Jul 2007 12:06:21 -0400
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
	testMPEG2TSreceiver: not quite right...
In-Reply-To: <f06240802c2b341e6d9bd@66.80.62.44>
References: <f06240802c2b341e6d9bd@66.80.62.44>
Message-ID: <e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>

On 7/5/07, Ross Finlayson <finlayson at live555.com> wrote:
>
>  Do you have a specific reason to not use openRTSP to receive transport
> streams?  testMPEG2TransportStreamer has an optional RTSP server in it.
>
> I think instead of making MPEG2TransportStreamRTPSource, you should set up
> the chain like this:
>
> SimpleRTPSource -> MPEG2TransportStreamFramer -> FileSink
>
>
>
> Actually, you won't need to insert a "MPEG2TransportStreamFramer", because
> its main purpose is to extract presentation times from the transport stream,
> and you won't need those if you're just outputting to a "FileSink".
>
>
> You can create a "RTPSource" for receiving a MPEG Transport/RTP stream by
> calling
>         SimpleRTPSource::createNew(envir(), rtpGroupsock, 30,
>                                                 90000, "video/MP2T", 0,
> False);
>

xcsmith,  I am not using RTSP because I am actually integrating this into an
existing software framework, and the openRTSP app seems to be much more
functionalty than I want or need.  I actually haven't really looked at the
code though.

Ross, I used a SimpleRTPSource::createNew(envir(), rtpGroupsock, 33, 90000,
"video/MP2T", 0, False);
source as you suggested, but with 33 as my payload type ( I believe this is
what you meant).  This worked right off the bat, but playing my captured
stream back out to RTP and then playing the stream in VLC, I get a lot of
intermittent video freezing, especially when my video (playing on loop)
repeats at the beginning.  However, using VLC to save this stream to file
yields perfect playback when I open it up later in VLC.  Very strange.  This
sounds like a VLC issue to me, do you concur or is there something that I
might need to incorporate in order to get playback working smoothly?  I
can't imagine what data I might be missing that would cause VLC trouble with
playing while capturing, but no trouble while capturing to file.

~Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/d7dc20fb/attachment.html 

From shishir at birmiwal.net  Fri Jul  6 09:19:58 2007
From: shishir at birmiwal.net (Shishir Birmiwal)
Date: Fri, 6 Jul 2007 11:19:58 -0500
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
	testMPEG2TSreceiver: not quite right...
In-Reply-To: <e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
References: <f06240802c2b341e6d9bd@66.80.62.44>
	<e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
Message-ID: <f66b63580707060919k15a6ac73g166869b16a0bb357@mail.gmail.com>

Russell,


> Ross, I used a SimpleRTPSource::createNew(envir(), rtpGroupsock, 33,
> 90000, "video/MP2T", 0, False);
> source as you suggested, but with 33 as my payload type ( I believe this
> is what you meant).  This worked right off the bat, but playing my captured
> stream back out to RTP and then playing the stream in VLC, I get a lot of
> intermittent video freezing, especially when my video (playing on loop)
> repeats at the beginning.  However, using VLC to save this stream to file
> yields perfect playback when I open it up later in VLC.
>


You may want to look at (or share) the debug messages generated by VLC. I
get the picture that you are streaming the TS file out over RTP and then
using VLC as a client. If you play back the captured stream (TS file) as a
"file" in VLC, do you get the same kind of errors? This may help you isolate
the fault. If you do get similar errors, then you may want to share the TS
stream or the errors reported.

Hope that helps.

Cheers
Shishir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/929fde48/attachment-0001.html 

From zmax.linkedin at gmail.com  Fri Jul  6 09:55:18 2007
From: zmax.linkedin at gmail.com (Massimo Zito)
Date: Fri, 6 Jul 2007 18:55:18 +0200
Subject: [Live-devel] Trick play problem ...
Message-ID: <92a42b330707060955i5930ffc9q46bc95d19d0d1dc2@mail.gmail.com>

Hi everyone,

I have a problem in trick play mode to play a TS resource by an RTSP session
...

I have modified openRTSP to send PLAY with scale = 2.0 and I have realized
that timestamps are always the same value ....

After a deep study I have realized that:

When MPEG2TransportFileServerMediaSubsession receive a setStreamScale,
ClientTrickPlayState change framer source in
MPEG2TransportStreamFromESSource.

Doing this, MPEG2TransportStreamFromESSource has InputESSourceRecord that
calculate presentation time and remember it in afterGettingFrame1 function
...

I think that is correct to assign presentationTime to
fParent.fPresentationTime ( related to MPEG2TransportStreamFromESSource )
...

Doing this I can see correct timestamps ...


Is this work correct ?

Regards

Massimo Zito
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/99954ef0/attachment.html 

From rjbrennn at gmail.com  Fri Jul  6 11:20:27 2007
From: rjbrennn at gmail.com (Russell Brennan)
Date: Fri, 6 Jul 2007 14:20:27 -0400
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
	testMPEG2TSreceiver: not quite right...
In-Reply-To: <f66b63580707060919k15a6ac73g166869b16a0bb357@mail.gmail.com>
References: <f06240802c2b341e6d9bd@66.80.62.44>
	<e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
	<f66b63580707060919k15a6ac73g166869b16a0bb357@mail.gmail.com>
Message-ID: <e776c1620707061120l9b687cxadbd04f567efcbe5@mail.gmail.com>

Thanks,

I get the following errors while playing the RTP stream via VLC...
libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 5) for
PID 0
libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 5) for
PID 66

But I think this discontinuity occurs due to my video restarting at the
beginning.  I get no errors or warnings other than those, either playing my
file or playing the RTP stream.  While the video is frozen, I can see that
RTP packets are being sent.  Whether it is the fault of VLC that the video
is freezing or if the RTP packets are malformed is beyond me.  Is there a
way that I can check the RTP packets to verify that their structure and
header info is correct?  Thanks,

Russell




On 7/6/07, Shishir Birmiwal <shishir at birmiwal.net> wrote:
>
> Russell,
>
>
> > Ross, I used a SimpleRTPSource::createNew(envir(), rtpGroupsock, 33,
> > 90000, "video/MP2T", 0, False);
> > source as you suggested, but with 33 as my payload type ( I believe this
> > is what you meant).  This worked right off the bat, but playing my captured
> > stream back out to RTP and then playing the stream in VLC, I get a lot of
> > intermittent video freezing, especially when my video (playing on loop)
> > repeats at the beginning.  However, using VLC to save this stream to file
> > yields perfect playback when I open it up later in VLC.
> >
>
>
> You may want to look at (or share) the debug messages generated by VLC. I
> get the picture that you are streaming the TS file out over RTP and then
> using VLC as a client. If you play back the captured stream (TS file) as a
> "file" in VLC, do you get the same kind of errors? This may help you isolate
> the fault. If you do get similar errors, then you may want to share the TS
> stream or the errors reported.
>
> Hope that helps.
>
> Cheers
> Shishir
>
>
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Russell Brennan
RJBrennn at gmail.com
(708) 699-7314
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/112e89ca/attachment.html 

From shishir at birmiwal.net  Fri Jul  6 11:51:15 2007
From: shishir at birmiwal.net (Shishir Birmiwal)
Date: Sat, 7 Jul 2007 00:21:15 +0530
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
	testMPEG2TSreceiver: not quite right...
In-Reply-To: <e776c1620707061120l9b687cxadbd04f567efcbe5@mail.gmail.com>
References: <f06240802c2b341e6d9bd@66.80.62.44>
	<e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
	<f66b63580707060919k15a6ac73g166869b16a0bb357@mail.gmail.com>
	<e776c1620707061120l9b687cxadbd04f567efcbe5@mail.gmail.com>
Message-ID: <f66b63580707061151h667ca7c0u87fe373cb9b9153c@mail.gmail.com>

Russell,

I get the following errors while playing the RTP stream via VLC...
> libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 5)
> for PID 0
> libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 5)
> for PID 66
>
> But I think this discontinuity occurs due to my video restarting at the
> beginning.  I get no errors or warnings other than those, either playing my
> file or playing the RTP stream.  While the video is frozen, I can see that
> RTP packets are being sent.  Whether it is the fault of VLC that the video
> is freezing or if the RTP packets are malformed is beyond me.  Is there a
> way that I can check the RTP packets to verify that their structure and
> header info is correct?  Thanks,
>
>
Were you able to play the TS file in VLC as "file input"? If the file played
correctly, then the problem is probably in the way they're streamed back
out. If the file doesn't play correctly, then the problem could be with the
way they're captured and written.

You can try capturing the RTP stream using Wireshark (formerly Ethereal) and
see if you can spot out any problems. Wireshark can help you analyze the RTP
stream for missing packets, incorrect timestamps and bit-rates. The bit-rate
analysis (Statistics->IO Graph) can help you identify any issues due to
excessive/bursty transmission. It may be worthwhile to run a similar test on
a working / non-working stream to identify any particular issues due to
streaming.


Cheers
Shishir

PS: Sometimes, you may have do a RightClick on a UDP packet and choose
DecodeAs->RTP  for it to identify packets as RTP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/8cd17191/attachment.html 

From finlayson at live555.com  Fri Jul  6 13:04:05 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Jul 2007 13:04:05 -0700
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
 testMPEG2TSreceiver: not quite right...
In-Reply-To: <e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
References: <f06240802c2b341e6d9bd@66.80.62.44>
	<e776c1620707060906t3489395dsf7c049c2a257221@mail.gmail.com>
Message-ID: <f06240807c2b44f1433b5@[66.80.62.44]>

>Ross, I used a SimpleRTPSource::createNew(envir(), rtpGroupsock, 33, 
>90000, "video/MP2T", 0, False);
>source as you suggested, but with 33 as my payload type ( I believe 
>this is what you meant).

Yes - sorry.


>   This worked right off the bat, but playing my captured stream back 
>out to RTP and then playing the stream in VLC, I get a lot of 
>intermittent video freezing, especially when my video (playing on 
>loop) repeats at the beginning.

Note that when MPEG Transport Stream data is streamed, its contents 
are not modified at all.  Therefore, the data that you receive (using 
either a RTSP client, or your "testMPEG2TransportStreamReceiver" 
application) should be exactly the same as the original, provided 
that you don't encounter packet loss.

Therefore, if you have trouble playing the received video, but not 
the original source video, then you are probably seeing packet loss. 
You may be able to overcome this by increasing your OS's socket 
reception buffer.  (Enter "LIVE555 increaseReceiveBufferTo" into a 
search engine.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Fri Jul  6 13:08:16 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Jul 2007 13:08:16 -0700
Subject: [Live-devel] Trick play problem ...
In-Reply-To: <92a42b330707060955i5930ffc9q46bc95d19d0d1dc2@mail.gmail.com>
References: <92a42b330707060955i5930ffc9q46bc95d19d0d1dc2@mail.gmail.com>
Message-ID: <f06240808c2b45142b6b2@[66.80.62.44]>

>Hi everyone,
>
>I have a problem in trick play mode to play a TS resource by an RTSP 
>session ...
>
>I have modified openRTSP to send PLAY with scale = 2.0

Are you using the latest version of the code (version 2007.07.01)? 
That version fixed a bug specifically related to scale == 2.0


>  and I have realized that timestamps are always the same value ....
>
>After a deep study I have realized that:
>
>When MPEG2TransportFileServerMediaSubsession receive a 
>setStreamScale, ClientTrickPlayState change framer source in 
>MPEG2TransportStreamFromESSource.
>
>Doing this, MPEG2TransportStreamFromESSource has InputESSourceRecord 
>that calculate presentation time and remember it in 
>afterGettingFrame1 function ...
>
>I think that is correct to assign presentationTime to 
>fParent.fPresentationTime ( related to 
>MPEG2TransportStreamFromESSource ) ...
>
>Doing this I can see correct timestamps ...
>
>Is this work correct ?

Could you please submit your proposed change as a patch file (e.g., 
generated with "diff -c"), so I can better understand what you are 
proposing?
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From zmax.linkedin at gmail.com  Fri Jul  6 15:33:47 2007
From: zmax.linkedin at gmail.com (Massimo Zito)
Date: Sat, 7 Jul 2007 00:33:47 +0200
Subject: [Live-devel] Trick play problem ...
In-Reply-To: <f06240808c2b45142b6b2@66.80.62.44>
References: <92a42b330707060955i5930ffc9q46bc95d19d0d1dc2@mail.gmail.com>
	<f06240808c2b45142b6b2@66.80.62.44>
Message-ID: <92a42b330707061533n3e00b127k4ba5d22c4023385f@mail.gmail.com>

2007/7/6, Ross Finlayson <finlayson at live555.com>:
>
> >Hi everyone,
> >
> >I have a problem in trick play mode to play a TS resource by an RTSP
> >session ...
> >
> >I have modified openRTSP to send PLAY with scale = 2.0
>
> Are you using the latest version of the code (version 2007.07.01)?
> That version fixed a bug specifically related to scale == 2.0


Yes .... I'm using the latest version ...

>  and I have realized that timestamps are always the same value ....
> >
> >After a deep study I have realized that:
> >
> >When MPEG2TransportFileServerMediaSubsession receive a
> >setStreamScale, ClientTrickPlayState change framer source in
> >MPEG2TransportStreamFromESSource.
> >
> >Doing this, MPEG2TransportStreamFromESSource has InputESSourceRecord
> >that calculate presentation time and remember it in
> >afterGettingFrame1 function ...
> >
> >I think that is correct to assign presentationTime to
> >fParent.fPresentationTime ( related to
> >MPEG2TransportStreamFromESSource ) ...
> >
> >Doing this I can see correct timestamps ...
> >
> >Is this work correct ?
>
> Could you please submit your proposed change as a patch file (e.g.,
> generated with "diff -c"), so I can better understand what you are
> proposing?
> --



*** MPEG2TransportStreamFromESSource.cpp 2007-07-01 11:16:05.000000000 +0200
--- MPEG2TransportStreamFromESSource.cpp.new  2007-07-06 18:45:01.000000000+0200
***************
*** 251,256 ****
--- 251,258 ----

    fInputBufferBytesAvailable += frameSize;

+   fParent.fPresentationTime = presentationTime;
+
    // Now that we have new input data, check if we can deliver to the
client:
    fParent.awaitNewBuffer(NULL);
  }
what do you think about ?

Massimo

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070706/e460a320/attachment.html 

From finlayson at live555.com  Fri Jul  6 16:33:01 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Jul 2007 16:33:01 -0700
Subject: [Live-devel] Trick play problem ...
In-Reply-To: <92a42b330707061533n3e00b127k4ba5d22c4023385f@mail.gmail.com>
References: <92a42b330707060955i5930ffc9q46bc95d19d0d1dc2@mail.gmail.com>
	<f06240808c2b45142b6b2@66.80.62.44>
	<92a42b330707061533n3e00b127k4ba5d22c4023385f@mail.gmail.com>
Message-ID: <f06240801c2b481314953@[66.80.62.44]>

>*** MPEG2TransportStreamFromESSource.cpp 2007-07-01 11:16:05.000000000 +0200
>--- MPEG2TransportStreamFromESSource.cpp.new  2007-07-06 
>18:45:01.000000000 +0200
>***************
>*** 251,256 ****
>--- 251,258 ----
>
>     fInputBufferBytesAvailable += frameSize;
>
>+   fParent.fPresentationTime = presentationTime;
>+
>     // Now that we have new input data, check if we can deliver to the client:
>     fParent.awaitNewBuffer(NULL);
>   }

Thanks for reporting this.  (I had not noticed this before because 
most clients that receive MPEG Transport Streams don't care about the 
RTP-timestamp-derived presentation time, because the Transport Stream 
has its own embedded timestamps.)

This will get fixed in the next release of the software.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From k.sivareddy at gmail.com  Sat Jul  7 04:11:32 2007
From: k.sivareddy at gmail.com (sivareddy kallam)
Date: Sat, 7 Jul 2007 16:41:32 +0530
Subject: [Live-devel] Need help on Buffer pointer
Message-ID: <f30c5bb30707070411r4bb1e010o435287c28b66203d@mail.gmail.com>

Hi,
I am using live555 to get MPEG2 Transport Streams.
I need help regarding the Buffer pointer.
while i am receiveing MPEG2 Transport Stream, I am issuing
playMediaSubsession & used Filesink to save on to file.
I need the Buffer pointer instead of saving to file.
Please help me regarding this.

Thanks,
Siva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070707/86657060/attachment.html 

From rjbrennn at gmail.com  Sat Jul  7 06:15:34 2007
From: rjbrennn at gmail.com (Russell Brennan)
Date: Sat, 07 Jul 2007 09:15:34 -0400
Subject: [Live-devel] Need help on Buffer pointer
In-Reply-To: <f30c5bb30707070411r4bb1e010o435287c28b66203d@mail.gmail.com>
References: <f30c5bb30707070411r4bb1e010o435287c28b66203d@mail.gmail.com>
Message-ID: <468F91F6.2020008@gmail.com>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070707/9811654f/attachment.html 

From finlayson at live555.com  Sat Jul  7 06:49:32 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 7 Jul 2007 06:49:32 -0700
Subject: [Live-devel] Need help on Buffer pointer
In-Reply-To: <f30c5bb30707070411r4bb1e010o435287c28b66203d@mail.gmail.com>
References: <f30c5bb30707070411r4bb1e010o435287c28b66203d@mail.gmail.com>
Message-ID: <f06240802c2b54a1cf463@[66.80.62.44]>

>Hi,
>I am using live555 to get MPEG2 Transport Streams.
>I need help regarding the Buffer pointer.
>while i am receiveing MPEG2 Transport Stream, I am issuing 
>playMediaSubsession & used Filesink to save on to file.
>I need the Buffer pointer instead of saving to file.

Then you would need to write your own "MediaSink" subclass to use 
instead of "FileSink".  Your new "MediaSink" subclass would 
(presumably) process incoming data instead of writing it to a file.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From pjf at cape.com  Sun Jul  8 06:01:41 2007
From: pjf at cape.com (pjf at cape.com)
Date: Sun, 8 Jul 2007 09:01:41 -0400 (EDT)
Subject: [Live-devel] Getting Status
Message-ID: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>

Hi to all,

Im new to the list, and this may have been answered elsewhere, so I
aplogize if this is a repeat.

I have a streaming server, and some others that I look into (hosted
elsewhere).  I would like to grab the info that is generated from
openRTSP, eg DESCRIBE.  I don't really need the actual stream so something
like :
openRTSP -r rtsp://stream.name:9999/path/to/stream.rm
returns the SDP info that I'm interested in.  As you can see from the
example command above, some of the streams are of the 'Real' type, and
don't actually capture, but the info i'd like to capture does come across
the terminal ....

I'm not concerned with the content, just being able to capture/pipe the
output of the SDP description, so I can determine the streams
activity/status using a script (bash/perl) or grep out a specific line.

I suspect this would be a trivial change to the source, I'm just not a
great c programmer, and need some direction, and pointers ....

I think this would make a good tool, to be able to detect live streams,
and be able to add a 'live' indicator on a web page ...  This way the web
page could list a bunch of live streams that you're interested in, and
toggle an indicator if it actually is up and broadcasting ....


Thanks
-PeteF



From finlayson at live555.com  Sun Jul  8 09:35:40 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 8 Jul 2007 09:35:40 -0700
Subject: [Live-devel] Getting Status
In-Reply-To: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>
References: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>
Message-ID: <f06240800c2b6c24e6755@[66.80.62.44]>

>I have a streaming server, and some others that I look into (hosted
>elsewhere).  I would like to grab the info that is generated from
>openRTSP, eg DESCRIBE.  I don't really need the actual stream so something
>like :
>openRTSP -r rtsp://stream.name:9999/path/to/stream.rm
>returns the SDP info that I'm interested in.  As you can see from the
>example command above, some of the streams are of the 'Real' type, and
>don't actually capture, but the info i'd like to capture does come across
>the terminal ....
>
>I'm not concerned with the content, just being able to capture/pipe the
>output of the SDP description, so I can determine the streams
>activity/status using a script (bash/perl) or grep out a specific line.
>
>I suspect this would be a trivial change to the source, I'm just not a
>great c programmer, and need some direction, and pointers ....

There's currently no option in the "openRTSP" application for just 
doing the "DESCRIBE" operation.  However, you could easily modify the 
code to do this, by adding
	shutdown();
immediately after
	  *env << "Opened URL \"" << url
           << "\", returning a SDP description:\n" << sdpDescription << "\n";
(line 505) in "testProgs/playCommon.cpp".
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From pjf at cape.com  Sun Jul  8 17:41:49 2007
From: pjf at cape.com (pjf at cape.com)
Date: Sun, 8 Jul 2007 20:41:49 -0400 (EDT)
Subject: [Live-devel] Getting Status
In-Reply-To: <f06240800c2b6c24e6755@[66.80.62.44]>
References: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>
	<f06240800c2b6c24e6755@[66.80.62.44]>
Message-ID: <34052.75.67.164.28.1183941709.squirrel@email.cape.com>

Thanks, that is part of the answer, now for the trickier part.

it appears the output is direct to the console, in that I can't pipe it
anywhere. Is this correct ?  is there a way to get the SDP information
optimally to STDOUT? or at least a file ???

Thanks
-Pete


>>I have a streaming server, and some others that I look into (hosted
>>elsewhere).  I would like to grab the info that is generated from
>>openRTSP, eg DESCRIBE.  I don't really need the actual stream so
>> something
>>like :
>>openRTSP -r rtsp://stream.name:9999/path/to/stream.rm
>>returns the SDP info that I'm interested in.  As you can see from the
>>example command above, some of the streams are of the 'Real' type, and
>>don't actually capture, but the info i'd like to capture does come across
>>the terminal ....
>>
>>I'm not concerned with the content, just being able to capture/pipe the
>>output of the SDP description, so I can determine the streams
>>activity/status using a script (bash/perl) or grep out a specific line.
>>
>>I suspect this would be a trivial change to the source, I'm just not a
>>great c programmer, and need some direction, and pointers ....
>
> There's currently no option in the "openRTSP" application for just
> doing the "DESCRIBE" operation.  However, you could easily modify the
> code to do this, by adding
> 	shutdown();
> immediately after
> 	  *env << "Opened URL \"" << url
>            << "\", returning a SDP description:\n" << sdpDescription <<
> "\n";
> (line 505) in "testProgs/playCommon.cpp".
> --
>
> 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
>



From pjf at cape.com  Sun Jul  8 19:35:11 2007
From: pjf at cape.com (pjf at cape.com)
Date: Sun, 8 Jul 2007 22:35:11 -0400 (EDT)
Subject: [Live-devel] Getting Status
In-Reply-To: <34052.75.67.164.28.1183941709.squirrel@email.cape.com>
References: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>
	<f06240800c2b6c24e6755@[66.80.62.44]>
	<34052.75.67.164.28.1183941709.squirrel@email.cape.com>
Message-ID: <32893.75.67.164.28.1183948511.squirrel@email.cape.com>

figured it out needed to add
#include <stdio.h>

and before the shutdown
printf  ( "%s \n" , sdpDescription );

This gets me the description into stdout and I can pipe grep etc ..

Thanks for the pointers

-Pete

> Thanks, that is part of the answer, now for the trickier part.
>
> it appears the output is direct to the console, in that I can't pipe it
> anywhere. Is this correct ?  is there a way to get the SDP information
> optimally to STDOUT? or at least a file ???
>
> Thanks
> -Pete
>
>
>>>I have a streaming server, and some others that I look into (hosted
>>>elsewhere).  I would like to grab the info that is generated from
>>>openRTSP, eg DESCRIBE.  I don't really need the actual stream so
>>> something
>>>like :
>>>openRTSP -r rtsp://stream.name:9999/path/to/stream.rm
>>>returns the SDP info that I'm interested in.  As you can see from the
>>>example command above, some of the streams are of the 'Real' type, and
>>>don't actually capture, but the info i'd like to capture does come
>>> across
>>>the terminal ....
>>>
>>>I'm not concerned with the content, just being able to capture/pipe the
>>>output of the SDP description, so I can determine the streams
>>>activity/status using a script (bash/perl) or grep out a specific line.
>>>
>>>I suspect this would be a trivial change to the source, I'm just not a
>>>great c programmer, and need some direction, and pointers ....
>>
>> There's currently no option in the "openRTSP" application for just
>> doing the "DESCRIBE" operation.  However, you could easily modify the
>> code to do this, by adding
>> 	shutdown();
>> immediately after
>> 	  *env << "Opened URL \"" << url
>>            << "\", returning a SDP description:\n" << sdpDescription <<
>> "\n";
>> (line 505) in "testProgs/playCommon.cpp".
>> --
>>
>> 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
>>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>



From rajeshkumar.r at imimobile.com  Sun Jul  8 23:25:01 2007
From: rajeshkumar.r at imimobile.com (rajesh)
Date: Mon, 9 Jul 2007 11:55:01 +0530
Subject: [Live-devel] unsupported Transport
Message-ID: <008301c7c1f1$e14b8350$6902000a@imidomain.com>



Hi Ross
when I an trying to connect one rtsp server.I am getting the Error "RTSP/1.0 461 Unsupported transport".
SetUp Method is 
SETUP rtsp://10.0.2.105/test.3gp RTSP/1.0
CSeq: 3
Transport:RTP/AVP;unicast;client_port=5050

can u plz suggest me wher am i  wrong
Thanks in Advance.

###########################################################LOGS##########################################
Connecting
57
DESCRIBE rtsp://10.0.2.105/test.3gp RTSP/1.0
CSeq: 1


Bytes Send57
#####################################
RTSP/1.0 200 OK
CSeq: 1
Date: Mon, 09 Jul 2007 06:21:13 GMT
Set-Cookie: cbid=qfdgjmfiijiklldmeooolultrrjrktlufkhjkielhjjkklplmnkrqpnqermsktnuhfhjihji;path=/;expires=Thu,31-Dec-2037 23:59:59 GMT
vsrc: http://10.0.2.105:80/viewsource/template.html?nuyhtgt9uuz6hAhwxg7zDD8gBek4r48j5Ds7Eb7uD6wvyt6c
Last-Modified: Fri, 05 Jan 2007 05:57:20 GMT
Content-base: rtsp://10.0.2.105/test.3gp/
Vary: User-Agent, ClientID
Content-type: application/sdp
x-real-usestrackid: 1
Content-length: 1609

v=0
o=- 1167976640 1167976640 IN IP4 10.0.2.105
s=<No title>
i=<No author> <No copyright>
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=DefaultLicenseValue:integer;0
a=FileType:string;"MPEG4"
a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"
a=range:npt=0-62.400000
a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIrAE////4I/wOBNgABQJhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVlFCS0FVZkF5UUF5UUFFRFNBUkFCSjFBQUNUcUFBQWs2Z0dFQUJFQUFGZmtBQUJYNUFnQUFBQUFBTUJLQ
UtmQXlRQVpRQUVEY2NWQUFBQUFBQUFBQUFBQUFBR0VBQkVBQUFmUUFBQlg1QWdBQUFBQUFNPQQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2kAAkBGZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTZ1RBcUJXMG1FRUg4QUFBQi9BQUFCR
UtDS0NuNAQSAg0AACAAAAAAAAAAAAUDAABABgkBAAAAAAAAAAA="
m=video 0 RTP/AVP 96
b=AS:36
b=RR:1368
b=RS:456
a=control:streamid=65335
a=range:npt=0-62.400000
a=length:npt=62.400000
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=8; config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F
a=mimetype:string;"video/MP4V-ES"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;36493
a=HasOutOfOrderTS:integer;1
a=Height:integer;144
a=Width:integer;176
a=cliprect:0,0,144,176
a=mpeg4-esid:201
a=x-envivio-verid:00035A30
m=audio 0 RTP/AVP 97
b=AS:13
b=RR:481
b=RS:160
a=control:streamid=65435
a=range:npt=0-62
a=length:npt=62
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align=1
a=mimetype:string;"audio/AMR"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;12840
a=HasOutOfOrderTS:integer;1
a=mpeg4-esid:101
a=x-envivio-verid:00035A30

#######################################
OPTIONS rtsp://10.0.2.105/test.3gp RTSP/1.0
CSeq: 2


Bytes Send56
#####################################
RTSP/1.0 200 OK
CSeq: 2
Date: Mon, 09 Jul 2007 06:21:13 GMT
Server: Helix Server Version 11.0.1.1884 (win32) (RealServer compatible)
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN
TurboPlay: 1
RealChallenge1: 2fda22e1d5d961b201fcde5ac730cb8a
StatsMask: 8


#######################################
SETUP rtsp://10.0.2.105/test.3gp RTSP/1.0
CSeq: 3
Transport:RTP/AVP;unicast;client_port=5050


Bytes Send98
#####################################
RTSP/1.0 461 Unsupported transport
CSeq: 3
Date: Mon, 09 Jul 2007 06:21:13 GMT


#######################################
PLAY rtsp://10.0.2.105/test.3gp RTSP/1.0
CSeq: 4
Session: 0


Bytes Send65
#####################################
RTSP/1.0 455 Method Not Valid in This State
CSeq: 4
Date: Mon, 09 Jul 2007 06:21:13 GMT
Allow: OPTIONS, DESCRIBE, SETUP, ANNOUNCE, TEARDOWN, GET_PARAMETER, SET_PARAMETER


#######################################
Sendto function of Socket failed to send the Data
10049

Rajesh Kumar
Software Enginner
Cont-9908400027
NOTE: mobile not in use in office time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070708/e05c0e8a/attachment-0001.html 

From finlayson at live555.com  Mon Jul  9 02:11:03 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 9 Jul 2007 02:11:03 -0700
Subject: [Live-devel] Getting Status
In-Reply-To: <34052.75.67.164.28.1183941709.squirrel@email.cape.com>
References: <33181.75.67.164.28.1183899701.squirrel@email.cape.com>
	<f06240800c2b6c24e6755@[66.80.62.44]>
	<34052.75.67.164.28.1183941709.squirrel@email.cape.com>
Message-ID: <f06240802c2b7abe77214@[66.80.62.44]>

>it appears the output is direct to the console, in that I can't pipe it
>anywhere. Is this correct ?  is there a way to get the SDP information
>optimally to STDOUT? or at least a file ???

The diagnostic information (including the SDP description) is output 
to stderr.  You can redirect/pipe that.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From zmax.linkedin at gmail.com  Mon Jul  9 02:12:35 2007
From: zmax.linkedin at gmail.com (Massimo Zito)
Date: Mon, 9 Jul 2007 11:12:35 +0200
Subject: [Live-devel] MPEG2TransportFileServerMediaSubsession seekStream ...
Message-ID: <92a42b330707090212y9d189c4nf0153daa63645ecf@mail.gmail.com>

Hi Ross,

when I send a seek ( RTSP ) for a TS file ( handled by
MPEG2TransportFileServerMediaSubsession ), MPEG2TransportStreamFramer
doesn't estimate TS packet duration correctly ... I have found a workaround
...

*** live/liveMedia/include/MPEG2TransportStreamFramer.hh        2007-07-01
11:16:05.000000000 +0200
--- live_new/liveMedia/include/MPEG2TransportStreamFramer.hh    2007-07-09
11:38:50.000000000 +0200
***************
*** 40,45 ****
--- 40,47 ----

    void changeInputSource(FramedSource* newInputSource) { fInputSource =
newInputSource; }

+   void clearPidStatusTable();
+
  protected:
    MPEG2TransportStreamFramer(UsageEnvironment& env, FramedSource*
inputSource);
        // called only by createNew()


*** live/liveMedia/MPEG2TransportStreamFramer.cpp       2007-07-01 11:16:
05.000000000 +0200
--- live_new/liveMedia/MPEG2TransportStreamFramer.cpp   2007-07-09 11:43:
09.000000000 +0200
***************
*** 70,75 ****
--- 70,83 ----
    delete fPIDStatusTable;
  }

+ void MPEG2TransportStreamFramer::clearPidStatusTable()
+ {
+   PIDStatus* pidStatus;
+   while ((pidStatus = (PIDStatus*)fPIDStatusTable->RemoveNext()) != NULL)
{
+     delete pidStatus;
+   }
+ }
+
  void MPEG2TransportStreamFramer::doGetNextFrame() {
    // Read directly from our input source into our client's buffer:
    fFrameSize = 0;

*** live/liveMedia/MPEG2TransportFileServerMediaSubsession.cpp  2007-07-01
11:16:05.000000000 +0200
--- live_new/liveMedia/MPEG2TransportFileServerMediaSubsession.cpp
2007-07-09 11:41:48.000000000 +0200
***************
*** 275,280 ****
--- 275,282 ----
      // Note: We assume that we're asked to seek only in normal
      // (i.e., non trick play) mode, so we don't seek within the trick
      // play source (if any).
+
+     fFramer->clearPidStatusTable();
    }
  }



Is this work correct ?

Thank you

Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070709/90c530aa/attachment.html 

From finlayson at live555.com  Mon Jul  9 02:12:19 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 9 Jul 2007 02:12:19 -0700
Subject: [Live-devel] unsupported Transport
In-Reply-To: <008301c7c1f1$e14b8350$6902000a@imidomain.com>
References: <008301c7c1f1$e14b8350$6902000a@imidomain.com>
Message-ID: <f06240803c2b7ac658fae@[66.80.62.44]>

This is a problem with your server, not with our RTSP client code.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From wyt-1981 at 163.com  Mon Jul  9 02:32:52 2007
From: wyt-1981 at 163.com (Wei Yutao)
Date: Mon, 9 Jul 2007 17:32:52 +0800 (CST)
Subject: [Live-devel] using live555 library as a streaming server
Message-ID: <1709334220.799391183973572511.JavaMail.coremail@bj163app106.163.com>

Hi everyone,
 
I want to use live555 streaming Media library as a streaming server and I
 
have serveral questions:
 
(1) Can the live555 library be used in a practical application, for example, a
 
VoD system, as a streaming server? Can the streaming server runstably for normal use?
 
(2) I know that currently the server can stream mpeg-4 elementary stream
 
and want to know further:
 
    a) do the company  have the plan to make the library support  streaminga mpeg-4 file including audio and video;
  
    b) is it possible for myself to modify  the code to make it have this
 
       functionality? If it is possible, what should I do?
 
Thank you very much.
 
--------
Austin   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070709/a7e7c6a3/attachment.html 

From finlayson at live555.com  Mon Jul  9 06:56:08 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 9 Jul 2007 06:56:08 -0700
Subject: [Live-devel] using live555 library as a streaming server
In-Reply-To: <1709334220.799391183973572511.JavaMail.coremail@bj163app106.163.com>
References: <1709334220.799391183973572511.JavaMail.coremail@bj163app106.163.com>
Message-ID: <f06240804c2b7ee575bbc@[66.80.62.44]>

>(1) Can the live555 library be used in a practical application, for example, a
>
>VoD system, as a streaming server? Can the streaming server run
>stably for normal use?

Of course.  For example, our "LIVE555 Media Server" application: 
http://www.live555.com/mediaServer/



>(2) I know that currently the server can stream mpeg-4 elementary stream
>
>and want to know further:
>
>     a) do the company  have the plan to make the library support  streaming
>a mpeg-4 file including audio and video;

Yes, but there I can't estimate when this might be available.

>   
>     b) is it possible for myself to modify  the code

Of course.  This code is Open Source.


ps. Please don't ever send the same email to the mailing list more 
than once.  This is your last warning.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From Chen.Li2 at boeing.com  Mon Jul  9 14:02:26 2007
From: Chen.Li2 at boeing.com (Li, Chen)
Date: Mon, 9 Jul 2007 14:02:26 -0700
Subject: [Live-devel] RTSP Player Client
Message-ID: <FBE587797E2D164EA422C24856583F340200A2B8@XCH-SW-2V1.sw.nos.boeing.com>

Hi,

Does anyone have a recommendation on what to use to test/utilize "trick"
play functionality?  I have tried VLC but that "cheats" by fast
forwaring within its own buffer whereas I am looking for a client that
will actually use rtsp to send and confirm receipt of the trick play
commands such as fast forward and rewind.

I have tried mplayer as well with little success and it seems to sputter
and crash when there are lost packets while playing a transport stream.

Any recommendations would be really appreciated.

Thanks!

From finlayson at live555.com  Mon Jul  9 15:07:43 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 9 Jul 2007 15:07:43 -0700
Subject: [Live-devel] RTSP Player Client
In-Reply-To: <FBE587797E2D164EA422C24856583F340200A2B8@XCH-SW-2V1.sw.nos.boeing.com>
References: <FBE587797E2D164EA422C24856583F340200A2B8@XCH-SW-2V1.sw.nos.boeing.com>
Message-ID: <f06240805c2b861faa001@[66.80.62.44]>

>Does anyone have a recommendation on what to use to test/utilize "trick"
>play functionality?  I have tried VLC but that "cheats" by fast
>forwaring within its own buffer whereas I am looking for a client that
>will actually use rtsp to send and confirm receipt of the trick play
>commands such as fast forward and rewind.

The VLC developers tell me that they are currently working on adding 
proper RTSP 'trick play' support to the VLC client, and that they 
should be releasing this soon.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Mon Jul  9 21:56:49 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 9 Jul 2007 21:56:49 -0700
Subject: [Live-devel] MPEG2TransportFileServerMediaSubsession seekStream
 ...
In-Reply-To: <92a42b330707090212y9d189c4nf0153daa63645ecf@mail.gmail.com>
References: <92a42b330707090212y9d189c4nf0153daa63645ecf@mail.gmail.com>
Message-ID: <f06240802c2b8c1e0ec36@[66.80.62.44]>

Massimo,

Thanks for the suggestion.  I have added this - and your previous 
suggested modification - to a new release (2007.07.10) of the 
"LIVE555 Streaming Media" software, available now.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From hpmail75 at googlemail.com  Tue Jul 10 06:12:29 2007
From: hpmail75 at googlemail.com (Hans Peter)
Date: Tue, 10 Jul 2007 15:12:29 +0200
Subject: [Live-devel] Sample code in LGPL
Message-ID: <fd782ac60707100612h2089f307tfcff074e98e3d978@mail.gmail.com>

Hi Ross,

Your LIVE555 Streaming Media library is LGPL, and that is really
great! Thanks so much. I noticed, however, that the sample code also
has the LGPL note in the source files.

I want to use your library in a project that is not open source, so I
put the whole library into a Mac OS X .framework and link to it
dynamically. This works well, and I could then release the source
code for the framework if anyone asks. The problem is that the code
that calls into the framework is based on the sample code, with some
of the functions (initialization etc.) being really identical to the
sample code; I'm afraid this appears to be against the LGPL
requirement of not directly linking against LGPL code.

I could now write another abstraction layer on top of the sample code
and put the modified sample code into the framework. It would be much
easier, though, if you could release the sample code as public
domain, without the LGPL restrictions. Is there any chance of that
happening?

Thanks,

hp

From gundam at metarete.it  Tue Jul 10 07:10:35 2007
From: gundam at metarete.it (Fabio Zeri)
Date: Tue, 10 Jul 2007 16:10:35 +0200
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get a SDP
	description	from URL
Message-ID: <1184076635.14801.14634.camel@gundam.metarete.lan>

I am trying to connect with mplayer (1.0rc1) compiled with liveMedia
(2007.07.01) support to a rtsp windows server unsuccessfully.

I have already tried to connect to with vlc and with openRTSP but
connection always fails with the same debug error:

==] CUT HERE [==
Failed to get a SDP description from URL
"rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0": Failed to read response: Success
==] CUT HERE [==

The same URL works fine with Windows Media Player 9.

Could this be a mismatch protocol issue from server or from stream
library?

Here a give you a more verbose log from mplayer:
==] CUT HERE [==
...
Playing
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0.
get_path('sub/') -> '/root/.mplayer/sub/'
STREAM_RTSP, URL:
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
Filename for url is now
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
Filename for url is now
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
Resolving aliceliverossoalice1.alice.cdn.interbusiness.it for AF_INET...
Connecting to server
aliceliverossoalice1.alice.cdn.interbusiness.it[80.20.4.72]: 554...
librtsp: server responds: '??'
Filename for url is now
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
Filename for url is now
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
STREAM_LIVE555, URL:
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
STREAM: [RTSP and SIP]
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0
STREAM: Description: standard RTSP and SIP
STREAM: Author: Ross Finlayson
STREAM: Comment: Uses LIVE555 Streaming Media library.
s->pos=0  newpos=0  new_bufpos=0  buflen=0  
Stream not seekable!
 file format detected.
Sending request: DESCRIBE
rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0 RTSP/1.0
CSeq: 1
Accept: application/sdp
User-Agent: MPlayer (LIVE555 Streaming Media v2007.07.01)


Failed to get a SDP description from URL
"rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0": Failed to read response: Success
DEMUXER: freeing demuxer at 0x8902840
==] CUT HERE [==

Many thanks in advance.

Bye
-- 
ing. Fabio Zeri
--
[ Metarete - X Service Provider - Soluzioni in rete ]
  http://www.metarete.it - gundam at metarete.it
  Tel: +39 0372 432228 - Fax: +39 0372 590617


From xcsmith at rockwellcollins.com  Tue Jul 10 11:32:26 2007
From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com)
Date: Tue, 10 Jul 2007 13:32:26 -0500
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
 testMPEG2TSreceiver: not quite right...
Message-ID: <OF6EE10D45.13D9FF7F-ON86257314.0065A6C3-86257314.006620E2@rockwellcollins.com>

Actually, you won't need to insert a "MPEG2TransportStreamFramer", because 
its main purpose is to extract presentation times from the transport 
stream, and you won't need those if you're just outputting to a 
"FileSink".

Re: Doesn't MPEG2TransportStreamFramer also check for sync bytes in the 
data before passing the data forward?  Is it useful in that sense?

xochitl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070710/fa153fba/attachment.html 

From stondage123 at yahoo.com  Tue Jul 10 15:34:28 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Tue, 10 Jul 2007 15:34:28 -0700 (PDT)
Subject: [Live-devel] index files and mpeg2 ts
Message-ID: <20070710223428.85927.qmail@web35909.mail.mud.yahoo.com>

Hi All,

I am currently trying to play a scaled mpeg2 ts stream in
vlc that I got originally from a dvd, and have gotten a multitude of
errors. The original ts stream plays fine. I then scale the ts stream
with index files using some live555 code. I believe this is correct,
but vlc will not play the resulting stream. Any help would be
appreciated. The commands I used and the errors are listed below along
with some comments.

Thanks,
Andrew


//Create a ts file from the dvd
vlc dvdsimple:///media/cdrom0 --sout '#standard{access=file,mux=ts,dst=dvd.ts}}'

//Successful playing
vlc dvd.ts

//generate an index file using live555 code (output dvd.tsx)
live/testProgs/MPEG2TransportStreamIndexer dvd.ts

//create a ts stream that is scaled by a factor of 2 (aka play twice as fast) -- output file dvd2.ts
live/testProgs/testMPEG2TransportStreamTrickPlay dvd.ts 0 2 dvd2.ts

//Errors playing dvd2.ts
$ vlc -vvv dvd2.ts

VLC media player 0.9.0-svn Grishenko
[00000001] main libvlc debug: checking builtin modules
[00000001] main libvlc debug: checking plugin modules
[00000001] main libvlc debug: loading plugins cache file /home/astone/.vlc/cache/plugins-04081e.dat
[00000001] main libvlc debug: recursively browsing `modules'
[00000001] main libvlc debug: recursively browsing `/usr/local/lib/vlc'
[00000001]
main libvlc warning: cannot load module
`/usr/local/lib/vlc/codec/libffmpeg_plugin.so'
(/usr/local/lib/vlc/codec/libffmpeg_plugin.so: undefined symbol:
avcodec_decode_audio2)
[00000001] main libvlc debug: recursively browsing `plugins'
[00000001] main libvlc debug: module bank initialized, found 223 modules
[00000001] main libvlc debug: opening config file (/home/astone/.vlc/vlcrc)
[00000001] main libvlc debug: CPU has capabilities 486 586 MMX MMXEXT SSE SSE2 FPU 
[00000001] main libvlc debug: looking for memcpy module: 3 candidates
[00000001] main libvlc debug: using memcpy module "memcpymmxext"
[00000295] main playlist error: Reloading playlist not implemented.
[00000296] main private debug: waiting for thread completion
[00000296] main private debug: thread 1090525504 (preparser) created at priority 0 (playlist/thread.c:81)
[00000297] main private debug: waiting for thread completion
[00000297] main private debug: thread 1098918208 (fetcher) created at priority 0 (playlist/thread.c:107)
[00000295] main playlist debug: waiting for thread completion
[00000295] main playlist debug: rebuilding array of current - root Playlist
[00000295] main playlist debug: rebuild done - 0 items, index -1
[00000295] main playlist debug: thread 1107310912 (playlist) created at priority 0 (playlist/thread.c:117)
[00000298] main interface debug: looking for interface module: 1 candidate
[00000298] main interface debug: using interface module "hotkeys"
[00000298] main interface debug: thread 1115703616 (interface) created at priority 0 (interface/interface.c:218)
[00000300] main interface debug: looking for interface module: 1 candidate
[00000300] main interface debug: using interface module "screensaver"
[00000300] main interface debug: thread 1124096320 (interface) created at priority 0 (interface/interface.c:218)
[00000295] main playlist debug: adding item `dvd2.ts' ( dvd2.ts )
[00000302] main interface debug: looking for interface module: 3 candidates
[00000302] main interface debug: using interface module "wxwidgets"
[00000302] wxwidgets interface debug: Using last windows config '(-1,0,0,1680,1050)(0,839,248,720,655)(6,0,0,-1,150)'
[00000302] wxwidgets interface debug: id=0 p=(839,248) s=(720,655)
[00000302] wxwidgets interface debug: id=6 p=(0,0) s=(-1,150)
[00000295] main playlist debug: rebuilding array of current - root Playlist
[00000295] main playlist debug: rebuild done - 1 items, index -1
[00000295] main playlist debug: starting new item
[00000295] main playlist debug: changing item without a request (current -1/1)
[00000295] main playlist debug: using item 0
[00000295] main playlist debug: creating new input thread
[00000305] main input debug: waiting for thread completion
[00000305] main input debug: `dvd2.ts' gives access `' demux `' path `dvd2.ts'
[00000305] main input debug: creating demux: access='' demux='' path='dvd2.ts'
[00000306] main demuxer debug: looking for access_demux module: 1 candidate
[00000305] main input debug: creating access '' path='dvd2.ts'
[00000308] main access debug: looking for access2 module: 4 candidates
[00000308] vcd access debug: trying .cue file: dvd2.cue
[00000308] vcd access debug: could not find .cue file
[00000308] access_directory access debug: opening directory `dvd2.ts'
[00000308] access_directory access debug: skipping non-directory `dvd2.ts'
[00000305] main input debug: thread 1132489024 (input) created at priority 0 (input/input.c:332)
[00000295] main playlist debug: requesting art for dvd2.ts
[00000308] access_file access debug: opening file `dvd2.ts'
[00000308] main access debug: using access2 module "access_file"
[00000313] main private debug: pre-buffering...
[00000313] main private debug: received first data for our buffer
[00000313] main private debug: pre-buffering done 1408981 bytes in 0s - 951561 kbytes/s
[00000305] main input debug: creating demux: access='' demux='' path='dvd2.ts'
[00000314] main demuxer debug: looking for demux2 module: 47 candidates
[00000314] main demuxer debug: using demux2 module "ts"
[00000305] main input debug: looking for a subtitle file in /home/astone/live555Wrapper/live/
[00000314] ts demuxer debug: DEMUX_SET_GROUP 0 (nil)
[00000305] main input debug: `dvd2.ts' successfully opened
[00000314] ts demuxer debug: PATCallBack called
[00000314] ts demuxer debug: new PAT ts_id=1 version=1 current_next=1
[00000314] ts demuxer debug:   * number=1 pid=16
[00000314] ts demuxer debug: PMTCallBack called
[00000314] ts demuxer debug: new PMT program number=1 version=1 pid_pcr=224
[00000314] ts demuxer debug:   * es pid=224 type=2 fcc=mpgv
[00000305] main input debug: selecting program id=1
[00000353] main decoder debug: looking for decoder module: 21 candidates
[00000353] main decoder debug: using decoder module "libmpeg2"
[00000353] main decoder debug: thread 1140881728 (decoder) created at priority 0 (input/decoder.c:191)
[00000314] ts demuxer warning: first packet for pid=224 cc=0x1
[00000314] ts demuxer warning: discontinuity indicator (pid=224) 
[00000353] libmpeg2 decoder debug: 720x480 (display 720,480), aspect 576000, sar 8:9, 29.971 fps
[00000353] main decoder debug: no usable vout present, spawning one
[00000357] main video output debug: window size: 720x540
[00000357] main video output debug: looking for video output module: 6 candidates
[00000357] xvideo video output debug: adaptor 0, port 115, format 0x32315659 (YV12) planar
[00000357] xvideo video output debug: Window manager supports NetWM
[00000357] xvideo video output debug: Window manager supports _NET_WM_STATE_FULLSCREEN
[00000357] xvideo video output debug: Window manager supports _NET_WM_STATE_ABOVE
[00000357] xvideo video output debug: Window manager supports _NET_WM_STATE_BELOW
[00000357] main video output debug: using video output module "xvideo"
[00000357] main video output debug: waiting for thread completion
[00000357] main video output debug: got 8 direct buffer(s)
[00000357] main video output debug: picture in 720x480 (0,0,720x480), chroma I420, ar 4:3, sar 8:9
[00000357] main video output debug: picture user 720x480 (0,0,720x480), chroma I420, ar 4:3, sar 8:9
[00000357] main video output debug: picture out 720x480 (0,0,720x480), chroma I420, ar 4:3, sar 8:9
[00000357] main video output debug: direct render, mapping render pictures 0-6 to system pictures 1-7
[00000357] main video output debug: thread 1149274432 (video output) created at priority 0 (video_output/video_output.c:454)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: dts != current_pts (128504)
[00000295] main playlist debug: art not found for dvd2.ts
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (33200)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35166)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (33200)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35167)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] main decoder error: decoder is leaking pictures, resetting the heap
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35155)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000353] libmpeg2 decoder warning: invalid picture encountered
[00000360] main private warning: backward_pts != dts (35156)
[00000360] main private warning: backward_pts != current_pts (33366)
[00000353] libmpeg2 decoder warning: invalid picture encountered





From finlayson at live555.com  Tue Jul 10 16:45:00 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 10 Jul 2007 16:45:00 -0700
Subject: [Live-devel] index files and mpeg2 ts
In-Reply-To: <20070710223428.85927.qmail@web35909.mail.mud.yahoo.com>
References: <20070710223428.85927.qmail@web35909.mail.mud.yahoo.com>
Message-ID: <f06240807c2b9ca49b160@[66.80.62.44]>

>I am currently trying to play a scaled mpeg2 ts stream in
>vlc that I got originally from a dvd, and have gotten a multitude of
>errors. The original ts stream plays fine. I then scale the ts stream
>with index files using some live555 code. I believe this is correct,
>but vlc will not play the resulting stream. Any help would be
>appreciated.

Please put your "dvd.ts" on a web site, and send us the URL, so we 
can download and test this for ourselves.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 10 16:48:27 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 10 Jul 2007 16:48:27 -0700
Subject: [Live-devel] Sample code in LGPL
In-Reply-To: <fd782ac60707100612h2089f307tfcff074e98e3d978@mail.gmail.com>
References: <fd782ac60707100612h2089f307tfcff074e98e3d978@mail.gmail.com>
Message-ID: <f06240808c2b9ca95c30c@[66.80.62.44]>

>I could now write another abstraction layer on top of the sample code
>and put the modified sample code into the framework. It would be much
>easier, though, if you could release the sample code as public
>domain, without the LGPL restrictions. Is there any chance of that
>happening?

There are no plans to change the licensing of any of this source code.

However, it's perfectly OK for you to write your own (non-LGPL) code 
that uses some of the "testProgs" code as a model.  I don't care if 
your own code looks similar to (or even, in places, identical to) the 
"testProgs" code.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 10 16:50:41 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 10 Jul 2007 16:50:41 -0700
Subject: [Live-devel] MPEG2TransportStreamRTPSource and
 testMPEG2TSreceiver: not quite right...
In-Reply-To: <OF6EE10D45.13D9FF7F-ON86257314.0065A6C3-86257314.006620E2@rockwellcollins
	.com>
References: <OF6EE10D45.13D9FF7F-ON86257314.0065A6C3-86257314.006620E2@rockwellcollins
	.com>
Message-ID: <f06240809c2b9cb5bf19e@[66.80.62.44]>

>Actually, you won't need to insert a "MPEG2TransportStreamFramer", 
>because its main purpose is to extract presentation times from the 
>transport stream, and you won't need those if you're just outputting 
>to a "FileSink".
>
>Re: Doesn't MPEG2TransportStreamFramer also check for sync bytes in 
>the data before passing the data forward?  Is it useful in that 
>sense?

Probably not if the input data is coming from a RTP (or even raw UDP) 
source, because in this case the input Transport Stream data is 
supposed to contain an integral number of 188-byte Transport Packets 
(and therefore start with a sync byte).

However, inserting a "MPEG2TransportStreamFramer" wouldn't hurt, I suppose...
-- 

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/20070710/517580bb/attachment-0001.html 

From frahm.c at googlemail.com  Wed Jul 11 02:16:01 2007
From: frahm.c at googlemail.com (Christian Frahm)
Date: Wed, 11 Jul 2007 11:16:01 +0200
Subject: [Live-devel] RTP Sequence number - alternating values
Message-ID: <8039fa140707110216j5263074dhaa8ec79981de1b0c@mail.gmail.com>

Hi to all,

I am trying to stream A / V which are stored in a series of PES packets.

I am using the VOBstreamer code as a start - just changed the source so that
it reads from my source.

Audio works fine - I am encountering a rather peculiar error with video. My
video RTP packets are being send with alternating Sequence Numbers. For
example:

RTP packet 1 Sequence number:54820
RTP packet 2 Sequence number:44758
RTP packet 3 Sequence number:54821
RTP packet 4 Sequence number:44759
RTP packet 5 Sequence number:54822
RTP packet 6 Sequence number:44760
RTP packet 7 Sequence number:54823

It is as if it sees two video streams when in fact there should only be one.

Can anyone tell me how the Sequence Number is calculated?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070711/d2b038b4/attachment.html 

From julian.lamberty at mytum.de  Wed Jul 11 04:29:01 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 11 Jul 2007 13:29:01 +0200
Subject: [Live-devel] RTCP and synchronization
In-Reply-To: <f06240807c2b1749c126e@[66.80.62.44]>
References: <468BB542.1020905@mytum.de> <f06240807c2b1749c126e@[66.80.62.44]>
Message-ID: <4694BEFD.1010807@mytum.de>


> Because they're not useful to you.
>
> I'll say this yet again (and hopefully for the last time): Our 
> RTP/RTCP implementation automatically computes synchronized 
> presentation times using RTP timestamps and RTCP reports.  Code that 
> receives a RTP stream (using our library) should never have to look 
> at RTP timestamps.  Instead, just use the presentation time.  If you 
> are also using RTCP (which you should be), then the presentaton time 
> *will* be properly synchronized.
>   

And if the receiver does NOT use Live555?

> Just make sure that frames of the transcoded stream get correct 
> presentation times (and that you create a new "RTCPInstance" object 
> for the new outgoing stream).
>   


OK, I do use an RTCPInstance.
What does "correct" in this context mean? I record the first incoming 
presentationTime for the first outgoing frame and add a constant value 
(correspoding to one frame duration) to it for every following frame. Is 
that "corrrect"?

From julian.lamberty at mytum.de  Wed Jul 11 05:14:15 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 11 Jul 2007 14:14:15 +0200
Subject: [Live-devel] High peaks in processing times
Message-ID: <4694C997.7050209@mytum.de>

Hi!

I've developed a class to transcode video streams. I measure the time 
between "doGetNextFrame()" and "afterGetting(this)" with the 
gettimeofday() function. The results show that it takes in average 40ms 
to complete one frame (according to the frame rate of 25Hz). But 
irregularily one frame takes more than 120ms which seems to be 
"compensated" in the next frames. The transcoding time is far below 40ms 
for each frame. Sample:

...
39.88ms
39.79ms
39.84ms
40.23ms
40.00ms
39.11ms
124.25ms (peak)
17.79ms (shorter periods)
17.87ms
17.54ms
20.20ms
38.52ms (back to normal)
39.76ms
...

What could this come from? I'm using Fedora Linux, is there maybe a 
kernel/user switch or anything similar involved?

Thanks
Julin

From finlayson at live555.com  Wed Jul 11 05:41:21 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 11 Jul 2007 05:41:21 -0700
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get a
 SDP description	from URL
In-Reply-To: <1184076635.14801.14634.camel@gundam.metarete.lan>
References: <1184076635.14801.14634.camel@gundam.metarete.lan>
Message-ID: <f06240800c2ba7fc561b4@[66.80.62.44]>

>I am trying to connect with mplayer (1.0rc1) compiled with liveMedia
>(2007.07.01) support to a rtsp windows server unsuccessfully.
>
>I have already tried to connect to with vlc and with openRTSP but
>connection always fails with the same debug error:
>
>==] CUT HERE [==
>Failed to get a SDP description from URL
>"rtsp://aliceliverossoalice1.alice.cdn.interbusiness.it/alicelive1?WMThinning=0": 
>Failed to read response: Success
>==] CUT HERE [==
>
>The same URL works fine with Windows Media Player 9.
>
>Could this be a mismatch protocol issue from server

Perhaps.  Perhaps your server supports only a Microsoft-specific 
non-standard variant ot RTSP?

What happens when you run our "openRTSP" command-line client (with 
the "-V" option, to generate verbose output)?  (See 
<http://www.live555.com/openRTSP/>)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul 11 05:43:05 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 11 Jul 2007 05:43:05 -0700
Subject: [Live-devel] RTP Sequence number - alternating values
In-Reply-To: <8039fa140707110216j5263074dhaa8ec79981de1b0c@mail.gmail.com>
References: <8039fa140707110216j5263074dhaa8ec79981de1b0c@mail.gmail.com>
Message-ID: <f06240801c2ba80a0951f@[66.80.62.44]>

>Audio works fine - I am encountering a rather peculiar error with 
>video. My video RTP packets are being send with alternating Sequence 
>Numbers. For example:
>
>RTP packet 1 Sequence number:54820
>RTP packet 2 Sequence number:44758
>RTP packet 3 Sequence number:54821
>RTP packet 4 Sequence number:44759
>RTP packet 5 Sequence number:54822
>RTP packet 6 Sequence number:44760
>RTP packet 7 Sequence number:54823
>
>It is as if it sees two video streams when in fact there should only be one.
>
>Can anyone tell me how the Sequence Number is calculated?

Sequentially for each (video or audio) RTP stream.

Therefore, you must be generating more than one RTP stream.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul 11 05:47:51 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 11 Jul 2007 05:47:51 -0700
Subject: [Live-devel] RTCP and synchronization
In-Reply-To: <4694BEFD.1010807@mytum.de>
References: <468BB542.1020905@mytum.de>
	<f06240807c2b1749c126e@[66.80.62.44]> <4694BEFD.1010807@mytum.de>
Message-ID: <f06240802c2ba80e7a5cd@[66.80.62.44]>

>  > Because they're not useful to you.
>>
>>  I'll say this yet again (and hopefully for the last time): Our
>>  RTP/RTCP implementation automatically computes synchronized
>>  presentation times using RTP timestamps and RTCP reports.  Code that
>>  receives a RTP stream (using our library) should never have to look
>>  at RTP timestamps.  Instead, just use the presentation time.  If you
>>  are also using RTCP (which you should be), then the presentaton time
>>  *will* be properly synchronized.
>>  
>
>And if the receiver does NOT use Live555?

It shouldn't matter, provided that the receiver also follows the 
RTP/RTCP standard.


>  > Just make sure that frames of the transcoded stream get correct
>>  presentation times (and that you create a new "RTCPInstance" object
>>  for the new outgoing stream).
>>  
>
>
>OK, I do use an RTCPInstance.
>What does "correct" in this context mean? I record the first incoming
>presentationTime for the first outgoing frame and add a constant value
>(correspoding to one frame duration) to it for every following frame. Is
>that "corrrect"?

Yes.  It's important, though, that the first presentationTime (that 
you generate for the first frame) is generated by calling 
"gettimeofday()".
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From stondage123 at yahoo.com  Wed Jul 11 06:47:14 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Wed, 11 Jul 2007 06:47:14 -0700 (PDT)
Subject: [Live-devel] index files and mpeg2 ts
Message-ID: <968988.83402.qm@web35913.mail.mud.yahoo.com>

Thanks for the help Ross. The url is:
http://andrewjstone.net/dvd.ts

-Andrew

----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Tuesday, July 10, 2007 7:45:00 PM
Subject: Re: [Live-devel] index files and mpeg2 ts

>I am currently trying to play a scaled mpeg2 ts stream in
>vlc that I got originally from a dvd, and have gotten a multitude of
>errors. The original ts stream plays fine. I then scale the ts stream
>with index files using some live555 code. I believe this is correct,
>but vlc will not play the resulting stream. Any help would be
>appreciated.

Please put your "dvd.ts" on a web site, and send us the URL, so we 
can download and test this for ourselves.

-- 

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




From gundam at metarete.it  Wed Jul 11 08:21:54 2007
From: gundam at metarete.it (Fabio Zeri)
Date: Wed, 11 Jul 2007 17:21:54 +0200
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get
	a	SDP description	from URL
In-Reply-To: <f06240800c2ba7fc561b4@[66.80.62.44]>
References: <1184076635.14801.14634.camel@gundam.metarete.lan>
	<f06240800c2ba7fc561b4@[66.80.62.44]>
Message-ID: <1184167314.14801.18643.camel@gundam.metarete.lan>

Il giorno mer, 11/07/2007 alle 05.41 -0700, Ross Finlayson ha scritto:
[snip]
> >The same URL works fine with Windows Media Player 9.
> >
> >Could this be a mismatch protocol issue from server
> 
> Perhaps.  Perhaps your server supports only a Microsoft-specific 
> non-standard variant ot RTSP?
I really hope it will not be so.

Unfortunately I can't manage the remote server, so I don't know exactly
what kind of streaming server it could be. :-/

> What happens when you run our "openRTSP" command-line client (with 
> the "-V" option, to generate verbose output)?  (See 
> <http://www.live555.com/openRTSP/>)

This is the output of "openRTSP -V"
==] CUT HERE [==
Sending request: OPTIONS
rtsp://aliceliverossoalice.alice.cdn.interbusiness.it/alicelive?WMThinning=0 RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2007.07.01)


Sending request: DESCRIBE
rtsp://aliceliverossoalice.alice.cdn.interbusiness.it/alicelive?WMThinning=0 RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openRTSP (LIVE555 Streaming Media v2007.07.01)


Failed to get a SDP description from URL
"rtsp://aliceliverossoalice.alice.cdn.interbusiness.it/alicelive?WMThinning=0": Failed to read response: Success
==] CUT HERE [==

Bye
-- 
ing. Fabio Zeri
--
[ Metarete - X Service Provider - Soluzioni in rete ]
  http://www.metarete.it - gundam at metarete.it
  Tel: +39 0372 432228 - Fax: +39 0372 590617


From finlayson at live555.com  Wed Jul 11 10:19:02 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 11 Jul 2007 10:19:02 -0700
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get a
 SDP description	from URL
In-Reply-To: <1184167314.14801.18643.camel@gundam.metarete.lan>
References: <1184076635.14801.14634.camel@gundam.metarete.lan>
	<f06240800c2ba7fc561b4@[66.80.62.44]>
	<1184167314.14801.18643.camel@gundam.metarete.lan>
Message-ID: <f06240803c2bac1582b88@[66.80.62.44]>

I did some more testing on this "rtsp://" URL, and the problem 
definitely seems to be at the server end.  For some reason, your 
server is not responding properly (if at all) to RTSP requests.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From julian.lamberty at mytum.de  Wed Jul 11 12:41:55 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 11 Jul 2007 21:41:55 +0200
Subject: [Live-devel] RTCP and synchronization
References: 4694BEFD.1010807@mytum.de
Message-ID: <46953283.4060407@mytum.de>

Ok, but I still don't get how the final recipient gets to know the
*original* presentation time (which correspond to audio) if I generate a
new one in the transcoder... Is this done via RTCP?! If yes, could you
shortly explain it, please?

Julian


From tl11305 at salle.url.edu  Thu Jul 12 00:46:51 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Thu, 12 Jul 2007 09:46:51 +0200 (CEST)
Subject: [Live-devel] SDP file of a multiple destination session
Message-ID: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>

Hi all,
I created a session with its respective rtpGroupsock & rtcpGroupsock and then
I added another destination using:

rtpPort= new Port(newPort);
rtcpPort= new Port(newPort+1);
destinationAddress.s_addr = inet_addr((char*)newIP);
rtpGroupsock->addDestination(destinationAddress,*rtpPort);
rtcpGroupsock->addDestination(destinationAddress,*rtcpPort);

Then, when I generated SDP file and it was created with the first destination
I used to create Groupsock's. There is some way to choose the second
destination appears in SDP file?

Thanks in advance,

Ramon


From gundam at metarete.it  Thu Jul 12 02:32:13 2007
From: gundam at metarete.it (Fabio Zeri)
Date: Thu, 12 Jul 2007 11:32:13 +0200
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get
	a	SDP description	from URL
In-Reply-To: <f06240803c2bac1582b88@[66.80.62.44]>
References: <1184076635.14801.14634.camel@gundam.metarete.lan>
	<f06240800c2ba7fc561b4@[66.80.62.44]>
	<1184167314.14801.18643.camel@gundam.metarete.lan>
	<f06240803c2bac1582b88@[66.80.62.44]>
Message-ID: <1184232733.14801.22120.camel@gundam.metarete.lan>

Il giorno mer, 11/07/2007 alle 10.19 -0700, Ross Finlayson ha scritto:
> I did some more testing on this "rtsp://" URL, and the problem 
> definitely seems to be at the server end.  For some reason, your 
> server is not responding properly (if at all) to RTSP requests.
Thanks for your help.

I will try to sniff WMPlayer traffic to understand what kind of
streaming protocol (except for RTSP) it could be.

Many thanks again.

Bye
-- 
ing. Fabio Zeri
--
[ Metarete - X Service Provider - Soluzioni in rete ]
  http://www.metarete.it - gundam at metarete.it
  Tel: +39 0372 432228 - Fax: +39 0372 590617


From finlayson at live555.com  Thu Jul 12 03:37:54 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Jul 2007 03:37:54 -0700
Subject: [Live-devel] SDP file of a multiple destination session
In-Reply-To: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
References: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
Message-ID: <f06240807c2bbb3dd2917@[66.80.62.44]>

You probably shouldn't be using "addDestination()" - that is a 
specialized function used only to implement on-demend unicast 
streaming to multiple clients from a single source.  (Note that, for 
unicast on-demand streams, the SDP description should contain the 
special address 0.0.0.0, not a specific unicast address.)

I don't really know what you are trying to do, but I suspect that you 
should just leave the existing code as it is, and use it without 
modification.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From tl11305 at salle.url.edu  Thu Jul 12 04:00:44 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Thu, 12 Jul 2007 13:00:44 +0200 (CEST)
Subject: [Live-devel] SDP file of a multiple destination session
In-Reply-To: <f06240807c2bbb3dd2917@[66.80.62.44]>
References: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
	<f06240807c2bbb3dd2917@[66.80.62.44]>
Message-ID: <1995.172.16.11.128.1184238044.squirrel@webmail.salle.url.edu>

> You probably shouldn't be using "addDestination()" - that is a
> specialized function used only to implement on-demend unicast
> streaming to multiple clients from a single source.  (Note that, for
> unicast on-demand streams, the SDP description should contain the
> special address 0.0.0.0, not a specific unicast address.)

It's exactly my case, I create a service that streams on broadcast one
description of H.264 SVC and the second description is streaming on-demand
unicast, but I didn't know that SDP should contain 0.0.0.0 to this address,
thank you very much Ross.

> I don't really know what you are trying to do, but I suspect that you
> should just leave the existing code as it is, and use it without
> modification.
> --


Well, I added some classes like my own class dervated from
H264RTPVideoStreamer and some classes that make similar functions to
testMPEG4VideoStreamer, but using my own H.264 source and using UDP commands
from a web service to add and remove sessions from RTSPServer. I want to use 3
types of services: broadcast H.264 service (all the descriptions), on demand
H.264 AVC service, the last one that I commented above. All the existing code
is not modificated, only my added classes. But if you are interested in it I
could share with you my project. There are some universities of europe
involved and I'm doing the playout part (videoserver) and some partners of my
department the web service to control it.

Thanks again Ross for all your attention,

Ramon


From tl11305 at salle.url.edu  Thu Jul 12 04:12:54 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Thu, 12 Jul 2007 13:12:54 +0200 (CEST)
Subject: [Live-devel] SDP file of a multiple destination session
In-Reply-To: <f06240807c2bbb3dd2917@[66.80.62.44]>
References: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
	<f06240807c2bbb3dd2917@[66.80.62.44]>
Message-ID: <2007.172.16.11.128.1184238774.squirrel@webmail.salle.url.edu>

Sorry, I forgot ask you about SDP file. Now address is correct (0.0.0.0) but
what about port? "m" line of SDP is still using port I specified when I create
groupsock, could I change it? Should I change it? If the first description is
sending broadcast in te same port it will cause a problem.

Thanks again,

Ramon



From finlayson at live555.com  Thu Jul 12 04:54:49 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Jul 2007 04:54:49 -0700
Subject: [Live-devel] SDP file of a multiple destination session
In-Reply-To: <2007.172.16.11.128.1184238774.squirrel@webmail.salle.url.edu>
References: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
	<f06240807c2bbb3dd2917@[66.80.62.44]>
	<2007.172.16.11.128.1184238774.squirrel@webmail.salle.url.edu>
Message-ID: <f06240809c2bbc60930d5@[66.80.62.44]>

Again, it sounds like you're trying to reinvent the wheel.  The 
"OnDemandServerMediaSubsession" class works just fine - you should 
just use it (by defining your own subclass).  Note the several 
examples in the code.  You should be using "testOnDemandRTSPServer" - 
not "testMPEG4VideoStreamer" - as a model for your application.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From frahm.c at googlemail.com  Thu Jul 12 06:46:56 2007
From: frahm.c at googlemail.com (Christian Frahm)
Date: Thu, 12 Jul 2007 15:46:56 +0200
Subject: [Live-devel] RTP Sequence number - alternating values
Message-ID: <8039fa140707120646k49f0f961w3eeb211ed2d74014@mail.gmail.com>

Thanks for the answer Ross. I will make myself a bit more clear to state the
case.

I am streaming a sequence of PES (both audio and video). I use the demux
class to stream audio and video separatelly ( audio to IP port 7777 and
video to 8888). I am using a dedicated network - so all traffic to that port
must  be generated by the LiveMedia server.

At port 7777 - audio can be received and decoded successfully.

At port 8888, video was "jiggy". So ran some network traces with Wireshark.
RTP packets DO get sent in port 8888. However, as I have stated before, the
RTP sequence number is not continuous - and alternates. Secondly - I have
also observed some RTP packets in port 8888 with payload 72!

With video - the Demux is connected to a discrete framer, which is connected
to a RTP Sink (just like the VOB Streamer code...).

Does anyone have any idea why this could happen? Why is my RTP sink
generating bad sequence numbers? What about the RTP packets with payload 72!
They must be coming from the same RTPSink and Framer... but how can that
happen!?

Thanks!



-------- Original Message -------------------
>Audio works fine - I am encountering a rather peculiar error with
>video. My video RTP packets are being send with alternating Sequence
>Numbers. For example:
>
>RTP packet 1 Sequence number:54820
>RTP packet 2 Sequence number:44758
>RTP packet 3 Sequence number:54821
>RTP packet 4 Sequence number:44759
>RTP packet 5 Sequence number:54822
>RTP packet 6 Sequence number:44760
>RTP packet 7 Sequence number:54823
>
>It is as if it sees two video streams when in fact there should only be
one.
>
>Can anyone tell me how the Sequence Number is calculated?

Sequentially for each (video or audio) RTP stream.

Therefore, you must be generating more than one RTP stream.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070712/7f31e991/attachment.html 

From tl11305 at salle.url.edu  Thu Jul 12 07:37:59 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Thu, 12 Jul 2007 16:37:59 +0200 (CEST)
Subject: [Live-devel] SDP file of a multiple destination session
In-Reply-To: <f06240809c2bbc60930d5@[66.80.62.44]>
References: <1228.172.16.11.128.1184226411.squirrel@webmail.salle.url.edu>
	<f06240807c2bbb3dd2917@[66.80.62.44]>
	<2007.172.16.11.128.1184238774.squirrel@webmail.salle.url.edu>
	<f06240809c2bbc60930d5@[66.80.62.44]>
Message-ID: <1066.172.16.11.128.1184251079.squirrel@webmail.salle.url.edu>

> Again, it sounds like you're trying to reinvent the wheel.  The
> "OnDemandServerMediaSubsession" class works just fine - you should
> just use it (by defining your own subclass).  Note the several
> examples in the code.  You should be using "testOnDemandRTSPServer" -
> not "testMPEG4VideoStreamer" - as a model for your application.

I use "testOnDemandRTSPServer" as a model for the video on demand service, but
in this case I am sending broadcast all time and resending the synchronized
source (but description 2) to some unicast address (some kind of Quality On
Demand). Maybe I can use on demand model but I need to start reading
description 2 source at same time I start reading description 1 and sending it
on broadcast, so I thought it was the easiest way (maybe not the most
correct). Now it works fine, and I only have the problem in "m" line creating
automatically SDP file, but thanks for your observation, I will revise it for
a better implementation.

Thanks anyway,

Ramon


From finlayson at live555.com  Thu Jul 12 09:11:59 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Jul 2007 09:11:59 -0700
Subject: [Live-devel] RTP Sequence number - alternating values
In-Reply-To: <8039fa140707120646k49f0f961w3eeb211ed2d74014@mail.gmail.com>
References: <8039fa140707120646k49f0f961w3eeb211ed2d74014@mail.gmail.com>
Message-ID: <f0624080ac2bc01fa42dc@[66.80.62.44]>

>Does anyone have any idea why this could happen? Why is my RTP sink 
>generating bad sequence numbers? What about the RTP packets with 
>payload 72! They must be coming from the same RTPSink

No.  Unless you have modified the existing library code, your 
"alternating sequence numbers" must be coming from two different 
"RTPSink" objects.

You're going to have to figure out for yourself why your application 
code has created two or more "RTPSink" objects that (apparently) use 
the same "groupsock" object.  But Remember, You Have Complete Source 
Code.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Thu Jul 12 09:24:54 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Jul 2007 09:24:54 -0700
Subject: [Live-devel] RTCP and synchronization
In-Reply-To: <46953283.4060407@mytum.de>
References: 4694BEFD.1010807@mytum.de <46953283.4060407@mytum.de>
Message-ID: <f0624080bc2bc039fa58f@[66.80.62.44]>

>Ok, but I still don't get how the final recipient gets to know the
>*original* presentation time (which correspond to audio) if I generate a
>new one in the transcoder...

Each incoming frame (from your "RTPSource" object) has an accurate 
presentation time, which you know (because it's passed as a parameter 
to your "afterGetting...()" function).  If your transcoder works by 
translating each incoming frame into a corresponding new transcoded 
frame, then it should simply assign each transcoded frame the 
presentation time from its corresponding incoming frame.  (Note, 
though, that if the incoming frames contain B-frames, but the 
transcoded frames don't, then the sequence of transcoded frames will 
not exactly match the sequence of incoming frames, and you should 
reorder the presentation times accordingly.)

If, however, your transcoder does *not* work by translating each 
incoming frame into a corresponding new transcoded frame, then things 
are more complicated.

But in any case, you're on your own from now on...
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From jsamaha at MIT.EDU  Thu Jul 12 15:44:21 2007
From: jsamaha at MIT.EDU (Jimmy A Samaha)
Date: Thu, 12 Jul 2007 18:44:21 -0400
Subject: [Live-devel] Live555 Media Server
Message-ID: <20070712184421.ugnpq8exikkk8kss@webmail.mit.edu>

Hey all,

I am trying to send live audio from a microphone through Media Server to my
client. Any ideas?

Thanks

Jimmy

From nitin.e at gmail.com  Thu Jul 12 21:32:46 2007
From: nitin.e at gmail.com (nitin.e)
Date: 12 Jul 2007 23:32:46 -0500
Subject: [Live-devel] nitin.e wants to talk to you on Yoomba
Message-ID: <18798979.1184301166394.JavaMail.SYSTEM@localhost>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070712/4a67109a/attachment-0001.html 

From finlayson at live555.com  Thu Jul 12 21:46:48 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Jul 2007 21:46:48 -0700
Subject: [Live-devel] nitin.e wants to talk to you on Yoomba
In-Reply-To: <18798979.1184301166394.JavaMail.SYSTEM@localhost>
References: <18798979.1184301166394.JavaMail.SYSTEM@localhost>
Message-ID: <f0624080cc2bcb394988d@[66.80.62.44]>

That message was apparently spam; you should not click on the link 
that was inside it.

The email address that sent that message has now been unsubscribed 
from the mailing list.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From yang-m-h at 126.com  Fri Jul 13 00:10:55 2007
From: yang-m-h at 126.com (yang-m-h at 126.com)
Date: Fri, 13 Jul 2007 15:10:55 +0800 (CST)
Subject: [Live-devel] the question about testOnDemandRTPServer
Message-ID: <4697257F.000141.13801@bj126app83.126.com>

Dear list menbers,
Now I want to know the runing sequence of teh testOnDemandRTPServer. When the media server is ready,then the client or the video playing client using the command 
rtsp://192.168.1.70:8554/mpeg4ESVideoTest
to pay the video stream.
I want to kown when the client give the command the, which program will be run to send the video data.thank you! 
 
 
 


? ? ? ??? ? ? ? ? ??? ? ? ?  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070713/4138a7ba/attachment.html 

From finlayson at live555.com  Fri Jul 13 00:22:37 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Jul 2007 00:22:37 -0700
Subject: [Live-devel] Live555 Media Server
In-Reply-To: <20070712184421.ugnpq8exikkk8kss@webmail.mit.edu>
References: <20070712184421.ugnpq8exikkk8kss@webmail.mit.edu>
Message-ID: <f0624080dc2bcb890c3b3@[66.80.62.44]>

>I am trying to send live audio from a microphone through Media Server to my
>client. Any ideas?

Jimmy,

There are future plans to upgrade the LIVE555 Media Server to support 
live input streams.  Until that time, however, I recommend that you 
instead use our "testOnDemandRTSPServer" demo application (from the 
"testProgs" directory) as a model.

Please see the FAQ <http://www.live555.com/liveMedia/faq.html> for 
tips on how to stream from a live input source.

If your microphone generates PCM audio, and you are planning to 
stream this as is, then you'll likely need to implement your own 
"ServerMediaSubsession" subclass, similar to the existing 
"WAVAudioFileServerMediaSubsession".
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From bonheur.cheung at seldes.com  Fri Jul 13 00:38:48 2007
From: bonheur.cheung at seldes.com (cheung bonheur)
Date: Fri, 13 Jul 2007 09:38:48 +0200
Subject: [Live-devel] live-devel Digest, Vol 45, Issue 11
References: <mailman.603.1184301203.802.live-devel@lists.live555.com>
Message-ID: <000d01c7c520$d9e901a0$6401a8c0@rhea>

Hello,

I want to record a stream rtsp to file using openrtsp
But when i read this file, VLC cant read it...

Thanks foryour help

----- Original Message ----- 
From: <live-devel-request at ns.live555.com>
To: <live-devel at ns.live555.com>
Sent: Friday, July 13, 2007 6:33 AM
Subject: live-devel Digest, Vol 45, Issue 11


> 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: SDP file of a multiple destination session (Ross Finlayson)
>   2. Re: SDP file of a multiple destination session
>      (Ramon Martin de Pozuelo Genis)
>   3. Re: SDP file of a multiple destination session
>      (Ramon Martin de Pozuelo Genis)
>   4. Re: SDP file of a multiple destination session (Ross Finlayson)
>   5. RTP Sequence number - alternating values (Christian Frahm)
>   6. Re: SDP file of a multiple destination session
>      (Ramon Martin de Pozuelo Genis)
>   7. Re: RTP Sequence number - alternating values (Ross Finlayson)
>   8. Re: RTCP and synchronization (Ross Finlayson)
>   9. Live555 Media Server (Jimmy A Samaha)
>  10. nitin.e wants to talk to you on Yoomba (nitin.e)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Jul 2007 03:37:54 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] SDP file of a multiple destination session
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Message-ID: <f06240807c2bbb3dd2917@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
> You probably shouldn't be using "addDestination()" - that is a
> specialized function used only to implement on-demend unicast
> streaming to multiple clients from a single source.  (Note that, for
> unicast on-demand streams, the SDP description should contain the
> special address 0.0.0.0, not a specific unicast address.)
>
> I don't really know what you are trying to do, but I suspect that you
> should just leave the existing code as it is, and use it without
> modification.
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 Jul 2007 13:00:44 +0200 (CEST)
> From: "Ramon Martin de Pozuelo Genis" <tl11305 at salle.url.edu>
> Subject: Re: [Live-devel] SDP file of a multiple destination session
> To: "LIVE555 Streaming Media - development & use"
> <live-devel at ns.live555.com>
> Message-ID:
> <1995.172.16.11.128.1184238044.squirrel at webmail.salle.url.edu>
> Content-Type: text/plain;charset=iso-8859-1
>
>> You probably shouldn't be using "addDestination()" - that is a
>> specialized function used only to implement on-demend unicast
>> streaming to multiple clients from a single source.  (Note that, for
>> unicast on-demand streams, the SDP description should contain the
>> special address 0.0.0.0, not a specific unicast address.)
>
> It's exactly my case, I create a service that streams on broadcast one
> description of H.264 SVC and the second description is streaming on-demand
> unicast, but I didn't know that SDP should contain 0.0.0.0 to this 
> address,
> thank you very much Ross.
>
>> I don't really know what you are trying to do, but I suspect that you
>> should just leave the existing code as it is, and use it without
>> modification.
>> --
>
>
> Well, I added some classes like my own class dervated from
> H264RTPVideoStreamer and some classes that make similar functions to
> testMPEG4VideoStreamer, but using my own H.264 source and using UDP 
> commands
> from a web service to add and remove sessions from RTSPServer. I want to 
> use 3
> types of services: broadcast H.264 service (all the descriptions), on 
> demand
> H.264 AVC service, the last one that I commented above. All the existing 
> code
> is not modificated, only my added classes. But if you are interested in it 
> I
> could share with you my project. There are some universities of europe
> involved and I'm doing the playout part (videoserver) and some partners of 
> my
> department the web service to control it.
>
> Thanks again Ross for all your attention,
>
> Ramon
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 Jul 2007 13:12:54 +0200 (CEST)
> From: "Ramon Martin de Pozuelo Genis" <tl11305 at salle.url.edu>
> Subject: Re: [Live-devel] SDP file of a multiple destination session
> To: "LIVE555 Streaming Media - development & use"
> <live-devel at ns.live555.com>
> Message-ID:
> <2007.172.16.11.128.1184238774.squirrel at webmail.salle.url.edu>
> Content-Type: text/plain;charset=iso-8859-1
>
> Sorry, I forgot ask you about SDP file. Now address is correct (0.0.0.0) 
> but
> what about port? "m" line of SDP is still using port I specified when I 
> create
> groupsock, could I change it? Should I change it? If the first description 
> is
> sending broadcast in te same port it will cause a problem.
>
> Thanks again,
>
> Ramon
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 12 Jul 2007 04:54:49 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] SDP file of a multiple destination session
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Message-ID: <f06240809c2bbc60930d5@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
> Again, it sounds like you're trying to reinvent the wheel.  The
> "OnDemandServerMediaSubsession" class works just fine - you should
> just use it (by defining your own subclass).  Note the several
> examples in the code.  You should be using "testOnDemandRTSPServer" -
> not "testMPEG4VideoStreamer" - as a model for your application.
>
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 12 Jul 2007 15:46:56 +0200
> From: "Christian Frahm" <frahm.c at googlemail.com>
> Subject: [Live-devel] RTP Sequence number - alternating values
> To: live-devel at ns.live555.com
> Message-ID:
> <8039fa140707120646k49f0f961w3eeb211ed2d74014 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks for the answer Ross. I will make myself a bit more clear to state 
> the
> case.
>
> I am streaming a sequence of PES (both audio and video). I use the demux
> class to stream audio and video separatelly ( audio to IP port 7777 and
> video to 8888). I am using a dedicated network - so all traffic to that 
> port
> must  be generated by the LiveMedia server.
>
> At port 7777 - audio can be received and decoded successfully.
>
> At port 8888, video was "jiggy". So ran some network traces with 
> Wireshark.
> RTP packets DO get sent in port 8888. However, as I have stated before, 
> the
> RTP sequence number is not continuous - and alternates. Secondly - I have
> also observed some RTP packets in port 8888 with payload 72!
>
> With video - the Demux is connected to a discrete framer, which is 
> connected
> to a RTP Sink (just like the VOB Streamer code...).
>
> Does anyone have any idea why this could happen? Why is my RTP sink
> generating bad sequence numbers? What about the RTP packets with payload 
> 72!
> They must be coming from the same RTPSink and Framer... but how can that
> happen!?
>
> Thanks!
>
>
>
> -------- Original Message -------------------
>>Audio works fine - I am encountering a rather peculiar error with
>>video. My video RTP packets are being send with alternating Sequence
>>Numbers. For example:
>>
>>RTP packet 1 Sequence number:54820
>>RTP packet 2 Sequence number:44758
>>RTP packet 3 Sequence number:54821
>>RTP packet 4 Sequence number:44759
>>RTP packet 5 Sequence number:54822
>>RTP packet 6 Sequence number:44760
>>RTP packet 7 Sequence number:54823
>>
>>It is as if it sees two video streams when in fact there should only be
> one.
>>
>>Can anyone tell me how the Sequence Number is calculated?
>
> Sequentially for each (video or audio) RTP stream.
>
> Therefore, you must be generating more than one RTP stream.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://lists.live555.com/pipermail/live-devel/attachments/20070712/7f31e991/attachment-0001.html
>
> ------------------------------
>
> Message: 6
> Date: Thu, 12 Jul 2007 16:37:59 +0200 (CEST)
> From: "Ramon Martin de Pozuelo Genis" <tl11305 at salle.url.edu>
> Subject: Re: [Live-devel] SDP file of a multiple destination session
> To: "LIVE555 Streaming Media - development & use"
> <live-devel at ns.live555.com>
> Message-ID:
> <1066.172.16.11.128.1184251079.squirrel at webmail.salle.url.edu>
> Content-Type: text/plain;charset=iso-8859-1
>
>> Again, it sounds like you're trying to reinvent the wheel.  The
>> "OnDemandServerMediaSubsession" class works just fine - you should
>> just use it (by defining your own subclass).  Note the several
>> examples in the code.  You should be using "testOnDemandRTSPServer" -
>> not "testMPEG4VideoStreamer" - as a model for your application.
>
> I use "testOnDemandRTSPServer" as a model for the video on demand service, 
> but
> in this case I am sending broadcast all time and resending the 
> synchronized
> source (but description 2) to some unicast address (some kind of Quality 
> On
> Demand). Maybe I can use on demand model but I need to start reading
> description 2 source at same time I start reading description 1 and 
> sending it
> on broadcast, so I thought it was the easiest way (maybe not the most
> correct). Now it works fine, and I only have the problem in "m" line 
> creating
> automatically SDP file, but thanks for your observation, I will revise it 
> for
> a better implementation.
>
> Thanks anyway,
>
> Ramon
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 12 Jul 2007 09:11:59 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] RTP Sequence number - alternating values
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Message-ID: <f0624080ac2bc01fa42dc@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>>Does anyone have any idea why this could happen? Why is my RTP sink
>>generating bad sequence numbers? What about the RTP packets with
>>payload 72! They must be coming from the same RTPSink
>
> No.  Unless you have modified the existing library code, your
> "alternating sequence numbers" must be coming from two different
> "RTPSink" objects.
>
> You're going to have to figure out for yourself why your application
> code has created two or more "RTPSink" objects that (apparently) use
> the same "groupsock" object.  But Remember, You Have Complete Source
> Code.
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 12 Jul 2007 09:24:54 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] RTCP and synchronization
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Message-ID: <f0624080bc2bc039fa58f@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>>Ok, but I still don't get how the final recipient gets to know the
>>*original* presentation time (which correspond to audio) if I generate a
>>new one in the transcoder...
>
> Each incoming frame (from your "RTPSource" object) has an accurate
> presentation time, which you know (because it's passed as a parameter
> to your "afterGetting...()" function).  If your transcoder works by
> translating each incoming frame into a corresponding new transcoded
> frame, then it should simply assign each transcoded frame the
> presentation time from its corresponding incoming frame.  (Note,
> though, that if the incoming frames contain B-frames, but the
> transcoded frames don't, then the sequence of transcoded frames will
> not exactly match the sequence of incoming frames, and you should
> reorder the presentation times accordingly.)
>
> If, however, your transcoder does *not* work by translating each
> incoming frame into a corresponding new transcoded frame, then things
> are more complicated.
>
> But in any case, you're on your own from now on...
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 12 Jul 2007 18:44:21 -0400
> From: Jimmy A Samaha <jsamaha at MIT.EDU>
> Subject: [Live-devel] Live555 Media Server
> To: live-devel at ns.live555.com
> Message-ID: <20070712184421.ugnpq8exikkk8kss at webmail.mit.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hey all,
>
> I am trying to send live audio from a microphone through Media Server to 
> my
> client. Any ideas?
>
> Thanks
>
> Jimmy
>
>
> ------------------------------
>
> Message: 10
> Date: 12 Jul 2007 23:32:46 -0500
> From: "nitin.e" <nitin.e at gmail.com>
> Subject: [Live-devel] nitin.e wants to talk to you on Yoomba
> To: live-devel at ns.live555.com
> Message-ID: <18798979.1184301166394.JavaMail.SYSTEM at localhost>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL: 
> http://lists.live555.com/pipermail/live-devel/attachments/20070712/4a67109a/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 45, Issue 11
> ******************************************
> 

From gundam at metarete.it  Fri Jul 13 02:52:02 2007
From: gundam at metarete.it (Fabio Zeri)
Date: Fri, 13 Jul 2007 11:52:02 +0200
Subject: [Live-devel] Linux Client vs Windows Server: Failed to get
	a	SDP description	from URL
In-Reply-To: <f06240803c2bac1582b88@[66.80.62.44]>
References: <1184076635.14801.14634.camel@gundam.metarete.lan>
	<f06240800c2ba7fc561b4@[66.80.62.44]>
	<1184167314.14801.18643.camel@gundam.metarete.lan>
	<f06240803c2bac1582b88@[66.80.62.44]>
Message-ID: <1184320322.14801.26848.camel@gundam.metarete.lan>

Il giorno mer, 11/07/2007 alle 10.19 -0700, Ross Finlayson ha scritto:
> I did some more testing on this "rtsp://" URL, and the problem 
> definitely seems to be at the server end.  For some reason, your 
> server is not responding properly (if at all) to RTSP requests.

I have configured a my own win2003 server with Streaming media server
and all goes well, except for x-afs-pf payload support (I have already
read the FAQ about it), ;-) so I don't think this is a Streaming media
server RTSP protocol issue...

but...

...during my investigations I have discovered, between client and
server, a Cisco ACNS (which is a digital media delivery solution for WAN
bandwidth optimization) could this match the problem?

Bye
-- 
ing. Fabio Zeri
--
[ Metarete - X Service Provider - Soluzioni in rete ]
  http://www.metarete.it - gundam at metarete.it
  Tel: +39 0372 432228 - Fax: +39 0372 590617


From stondage123 at yahoo.com  Fri Jul 13 05:16:45 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Fri, 13 Jul 2007 05:16:45 -0700 (PDT)
Subject: [Live-devel] index files and mpeg2 ts
Message-ID: <534677.63603.qm@web35902.mail.mud.yahoo.com>

Ross,

I think there might be something wrong with the way the new ts stream is being generated when scaled up by testMPEG2TransportStreamTrickPlay. I'm not an expert on this by any means though, I've just noticed that both mplayer and vlc cannot handle the output and don't understand why. Any Ideas?

Thanks,
Andrew

----- Original Message ----
From: Andrew Stone <stondage123 at yahoo.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Wednesday, July 11, 2007 9:47:14 AM
Subject: Re: [Live-devel] index files and mpeg2 ts

Thanks for the help Ross. The url is:
http://andrewjstone.net/dvd.ts

-Andrew

----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Tuesday, July 10, 2007 7:45:00 PM
Subject: Re: [Live-devel] index files and mpeg2 ts

>I am currently trying to play a scaled mpeg2 ts stream in
>vlc that I got originally from a dvd, and have gotten a multitude of
>errors. The original ts stream plays fine. I then scale the ts stream
>with index files using some live555 code. I believe this is correct,
>but vlc will not play the resulting stream. Any help would be
>appreciated.

Please put your "dvd.ts" on a web site, and send us the URL, so we 
can download and test this for ourselves.

-- 

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



_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel




From finlayson at live555.com  Fri Jul 13 07:33:11 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Jul 2007 07:33:11 -0700
Subject: [Live-devel] index files and mpeg2 ts
In-Reply-To: <534677.63603.qm@web35902.mail.mud.yahoo.com>
References: <534677.63603.qm@web35902.mail.mud.yahoo.com>
Message-ID: <f06240811c2bd3c944d26@[66.80.62.44]>

>I think there might be something wrong with the way the new ts 
>stream is being generated when scaled up by 
>testMPEG2TransportStreamTrickPlay. I'm not an expert on this by any 
>means though, I've just noticed that both mplayer and vlc cannot 
>handle the output and don't understand why. Any Ideas?

Please be patient.  I have verified the problem that you are seeing 
with 'trick play' conversion on your "dvd.ts" file, and am currently 
looking into the cause.

(Fortunately, though, your use of a "@yahoo.com" email address shows 
that this is not a priority issue for you, so you can afford to wait 
a while for this to be diagnosed :-)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From stondage123 at yahoo.com  Fri Jul 13 08:03:00 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Fri, 13 Jul 2007 08:03:00 -0700 (PDT)
Subject: [Live-devel] index files and mpeg2 ts
Message-ID: <869822.56739.qm@web35914.mail.mud.yahoo.com>

Thanks Ross. I'm glad you're looking into it. I am currently working around the problem, but will be pleased when it is fixed. It is not an absolute priority though as you have sensed. However, I wouldn't read too much into the use of a yahoo email address. I'm currently working for a stealth mode startup, and am not supposed to be using our domain yet for public transactions. I will say that cooperation with the community is of much importance though. You can look for my email address to change in the coming months. Thanks again for your great work on live555. I love it.

-Andrew

----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Friday, July 13, 2007 10:33:11 AM
Subject: Re: [Live-devel] index files and mpeg2 ts

>I think there might be something wrong with the way the new ts 
>stream is being generated when scaled up by 
>testMPEG2TransportStreamTrickPlay. I'm not an expert on this by any 
>means though, I've just noticed that both mplayer and vlc cannot 
>handle the output and don't understand why. Any Ideas?

Please be patient.  I have verified the problem that you are seeing 
with 'trick play' conversion on your "dvd.ts" file, and am currently 
looking into the cause.

(Fortunately, though, your use of a "@yahoo.com" email address shows 
that this is not a priority issue for you, so you can afford to wait 
a while for this to be diagnosed :-)
-- 

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




From frahm.c at googlemail.com  Sun Jul 15 05:17:53 2007
From: frahm.c at googlemail.com (Christian Frahm)
Date: Sun, 15 Jul 2007 14:17:53 +0200
Subject: [Live-devel] Demux does not demultiplex PES larger than 65KB
Message-ID: <8039fa140707150517y2f1543bfubdcd5689f244de9e@mail.gmail.com>

Hello everyone,

A while ago I wrote to this list with a interesting question:
We are trying to Stream DVB-T MPEG-TS signals. The problem we encountered is
that the DEMUX class cannot handle PES which are either:

1) larger than 65KB
2) have their size set to zero (this is allowed according to the standard).

I have tried to understand why this is happening - but had no luck. I did
find out that the Demux class reads the Size field in the PES header. But
the standard says that PES size is optional.

Is it really so that the Demux cannot handle big PES?

I am either thinking about modifying the Demux class or splitting PES (which
bring other problems).

Thanks!
Christian
P.S. When I say the Demux cannot handle - I mean that it recognizes the PES,
outputs a warning of type "incorrect size" - and never returns when I call
it by invoking FramedSource::afterGetting(this). If it doenst return - it
means it hasnt been able to forward what I have just given... or no?. But
where does it hang!? Is it the MPEG1or2VideoFramer that cannot handle this?
Or the DiscreteFramer!?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070715/38b685ac/attachment.html 

From finlayson at live555.com  Sun Jul 15 06:15:18 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Jul 2007 06:15:18 -0700
Subject: [Live-devel] Demux does not demultiplex PES larger than 65KB
In-Reply-To: <8039fa140707150517y2f1543bfubdcd5689f244de9e@mail.gmail.com>
References: <8039fa140707150517y2f1543bfubdcd5689f244de9e@mail.gmail.com>
Message-ID: <f06240800c2bfcc433029@[66.80.62.44]>

>A while ago I wrote to this list with a interesting question:
>We are trying to Stream DVB-T MPEG-TS signals.

Can you say more about what *specifically* you are trying to do?  If 
you are *just* trying to stream a MPEG Transport Stream, then you 
won't be parsing the contents of the stream, so PES packet sizes will 
not be an issue.

Are you trying to index a MPEG Transport Stream file (for 'trick 
play' operation)?  If not, then what specifically are you trying to 
do with the Transport Stream?

(A reminder, once again, that people with unprofessional email 
addresses (such as, in your case, @googlemail.com) get lower-priority 
service on this mailing list.)

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From bonheur.cheung at seldes.com  Mon Jul 16 00:04:44 2007
From: bonheur.cheung at seldes.com (cheung bonheur)
Date: Mon, 16 Jul 2007 09:04:44 +0200
Subject: [Live-devel] Execption error when Restarting the server  rtsp
Message-ID: <000b01c7c777$9733f9b0$6401a8c0@rhea>

Hello, 

I have an application that use the server rtsp using jpegvideosource and i 'm wonder why when i am restarting the server rtsp , my application throw an exception frame source...

I use the variable --> watchVariable.

I created a thread who launch the server, and i free all structure and pointer but i see that the socket of udp in server is not destroy so i decided manually to destroy it but same exception error.

Thankx for your help 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070716/d6654cb2/attachment.html 

From jps330 at psu.edu  Mon Jul 16 12:33:43 2007
From: jps330 at psu.edu (Jordan Shelley)
Date: Mon, 16 Jul 2007 15:33:43 -0400
Subject: [Live-devel] Streaming with Sensoray 2250 encoded data
Message-ID: <01MJ0XRCYQAC8WWA38@ponyexpress.arl.psu.edu>

I am sorry to have to bother everyone, but I have read through so much of
the archives and tried so many things, I would really like to get this
working so I need a little help if anyone has a moment.

 

I am trying to stream video from a platform that has a Sensoray 2250 encoder
installed on it. I have already verified that all of the hardware works and
that data produced from it can be streamed using the live library by doing
the following:

*         Created a process that grabs MPEG2 frames from the encoder and
dumps them to a named pipe

*         Modified testMPEG1or2VideoStreamer to look at this pipe for data,
and stream it to a specified IP address

*         Works fine, except that, as you can image, there is some major
delay in the video which I cannot have due to the nature of what this video
stream is being used for.

 

I decided to move on and write a FramedSource subclass that encapsulates my
encoder, and deliver this object directly to a MPEG1or2VideoRTPSink. I have
attached 3 files, my Encoder2250 class (subclass of FramedSource), its
header file, and my version of testMPEG1or2VideoStreamer (I have just been
changing the original test application).

 

The issue that is occurring is that after I start my version of
testMPEG1or2VideoStreamer I get the following output:

 

Beginning streaming...

Opening connection to Video Encoder

Setting video standard to NTSC

Setting video input

Setting Chip Settings

Beginning to read from file...

Right before scheduler...  

 

And that's it, it seems like it is sending data over the network at this
point, but it isn't. VLC doesn't see anything on an rtp connection on port
8888 and there isn't any network traffic. 

 

The thing that is very odd is that it seems like my implementation of
doGetNextFrame() is never executed since this printf statement in it's body
never shows up on the command line:

 

printf("Getting Frame...\n");

 

I don't understand why this is since all printf's from my encoder class's
constructor show up and no error messages show up from the live library. Is
the MPEG1or2VideoRTPSink not executing/seeing my implementation of
doGetNextFrame()? Is it some other problem? Thanks so much everyone.

 

-Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070716/1830f586/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Encoder2250.hh
Type: application/octet-stream
Size: 538 bytes
Desc: not available
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070716/1830f586/attachment-0001.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Encoder2250.cpp
Url: http://lists.live555.com/pipermail/live-devel/attachments/20070716/1830f586/attachment-0002.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testMPEG1or2VideoStreamer.cpp
Url: http://lists.live555.com/pipermail/live-devel/attachments/20070716/1830f586/attachment-0003.ksh 

From bonheur.cheung at seldes.com  Mon Jul 16 23:32:56 2007
From: bonheur.cheung at seldes.com (cheung bonheur)
Date: Tue, 17 Jul 2007 08:32:56 +0200
Subject: [Live-devel] how to restarting the server rtsp ?
Message-ID: <000a01c7c83c$4fec07d0$6401a8c0@rhea>

Hello, 

I create a thread in which i launch the server rtsp.
When i restarting the server, i have an error like :

BasicTaskScheduler:singleStep(): select() fails : erro 0

What's wrong ?

Thanks for your help !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070716/ca4c27f1/attachment.html 

From yang-m-h at 126.com  Tue Jul 17 02:16:03 2007
From: yang-m-h at 126.com (yang-m-h at 126.com)
Date: Tue, 17 Jul 2007 17:16:03 +0800 (CST)
Subject: [Live-devel] Please send me a MPEG-4 Elementary Stream video file
Message-ID: <469C88D3.000019.07847@bj126app19.126.com>

Dear list menbers,
I want a MPEG-4 Elementary Stream video file for test. But I don't have a nice network so I can't get it. so please send me one to my email.Thank you very much!
                                                     sincerely
 
 
 


? ? ? ? ? ??? ? ? ? ? ?  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070717/b06a04eb/attachment.html 

From rjbrennn at gmail.com  Tue Jul 17 05:12:51 2007
From: rjbrennn at gmail.com (Russell Brennan)
Date: Tue, 17 Jul 2007 08:12:51 -0400
Subject: [Live-devel] how to restarting the server rtsp ?
In-Reply-To: <000a01c7c83c$4fec07d0$6401a8c0@rhea>
References: <000a01c7c83c$4fec07d0$6401a8c0@rhea>
Message-ID: <469CB243.3040909@gmail.com>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070717/bc50aa6c/attachment.html 

From vinodjoshi at tataelxsi.co.in  Tue Jul 17 05:36:26 2007
From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi)
Date: Tue, 17 Jul 2007 18:06:26 +0530
Subject: [Live-devel] MPEG2 Elementary stream sync
Message-ID: <005401c7c86f$182e48c0$022a320a@telxsi.com>



  Hi all,

   We are using Live 555 streaming server as Video On Demand server 
   to stream MPEG2 streams to the set top box.

   After receiving audio and video elementary streams
   on the client side, how to synchronize them?

   i.e. how the achieve lip-sync.

   Thank You.

  

  

From bonheur.cheung at seldes.com  Tue Jul 17 05:46:43 2007
From: bonheur.cheung at seldes.com (cheung bonheur)
Date: Tue, 17 Jul 2007 14:46:43 +0200
Subject: [Live-devel] SingleStep : error in select()
Message-ID: <000b01c7c870$880accd0$6401a8c0@rhea>

Hello, i have and error occur when i restart the server rtsp in a thread.

the error's message is : 

BaskicTaskScheduler::SingleStep():select() fails: no error

i attemp to restart the server after have close the server wiith Medium::Close API.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070717/b0ccfa0e/attachment.html 

From MHosseini at newheights.com  Tue Jul 17 06:35:05 2007
From: MHosseini at newheights.com (Mojtaba Hosseini)
Date: Tue, 17 Jul 2007 07:35:05 -0600
Subject: [Live-devel] Lost packets
References: <BAY126-W179F4C149CB361D9959B73C4080@phx.gbl>
	<D6DDE2706695D34F8263D17DD29606D9AD5813@BBSC-EX01.bbsconnect.ca>
Message-ID: <D6DDE2706695D34F8263D17DD29606D9AD5816@BBSC-EX01.bbsconnect.ca>

Hello,
  It looks like there is no interface for the application using liveMedia to detect lost RTP packets based on sequence numbers. 
All it has to go on is the presentation time passed to it in the afterGettingFrame() function. Although internally liveMedia
detects packet loss based on sequence number (see MultiFramedRTPSource.cpp), it does not report this to the corresponding sink. 
We can get around this by using either of these hacks: (a) include frame number in application packet and add loss detection logic
at application layer or (b) make assumptions about presentation times and use presentation times to detect loss. The better
option would have been for liveMedia to report packet loss through the afterGettingFrame() function since it already knows this information. 
   Any comments? Has anyone else gotten around this problem in a different way? Is there a reason why this is the current design? Is it worth
while to try to add this functionality to liveMedia?

Mojtaba Hosseini


-----Original Message-----
From: live-devel-bounces at ns.live555.com on behalf of Mojtaba Hosseini
Sent: Fri 6/29/2007 7:02 AM
To: LIVE555 Streaming Media - development & use
Subject: RE: [Live-devel]  Lost packets
 
Thanks Luc,
 I just wanted to know how other people are implementing the same thing. It looks like we have done similar work which means I was not too far off the track.
Thanks for your explanation.
 In the very near future I will be looking at the packet loss issue through liveMedia. I'll report if I find a way of supporting it through liveMedia so we
wouldn't have to do it at the layer above (RTP already keeps sequence numbers so it should be able to detect packet loss and as you said provide a mechanism
for calling application to deal with it).

Mojtaba


-----Original Message-----
From: live-devel-bounces at ns.live555.com on behalf of Luc Roels
Sent: Fri 6/29/2007 1:34 AM
To: live-devel at ns.live555.com
Subject: [Live-devel]  Lost packets
 

 
Hi Mojtaba,
 
Writing a tutorial takes some time, which for the moment I don't really have, sorry. But in short, what I did to create my streaming server was to:
 
1) Create a custom DeviceSource class derived from FramedSource ( see FAQ, based on liveMedia/DeviceSource.cpp and liveMedia/DeviceSource.hh ). Basically, in the doGetNextFrame() and the deliverFrame() function there is code similar to the code in your x264VideoStreamFramer.cpp file ( the else{} part of your doGetNextFrame() function is in deliverFrame() ). I also created a simple FIFO class to store encoded video frames based on an STL queue.
 
2) Create a custom RTPSink class derived from VideoRTPSink. This is essentially a modified copy of liveMedia/MPEG4ESVideoRTPSink.cpp needed for handling my type of frames.
 
3) Create a custom MediaSubsesion class, overridding 3 functions createNewStreamSource(), createNewRTPSink() and getAuxSDPLine(). Function 1 and 2 create instances of your custom devicesource and your custom rtpsink. The getAuxSDPLine() starts the rtpsink and waits till my systemheader is created, so that it can be put in the config=... part of the reply to the DESCRIBE.
 
4) Create a custom RTSPserver class based on mediaServer/DynamicRTSPserver.hh and mediaServer/DynamicRTSPserver.cpp changing the createNewSMS() function to handle my media type
 
That's it! I also set the max packet len (OutPacketBuffer::maxSize) in MediaSink.cpp to 120 KB.
 
The whole thing is started up by ( see mediaServer/live555MediaServer.cpp )
 
- Creating a basictaskscheduler
- Creating a basicuserenvironment
- Create the RTSP server
- Entering the doeventloop
 
 
By the way, thanks for your tutorial, it helped...
 
 
About the packet loss, for my application it will be necessary to create some container format which will hold the video and audio frames. To simply fix the packet loss detection problem I could of course put a frame number in the container format, this would avoid any changes to liveMedia, but it would be nice if some function or mechanism would be added to report to the higher level that a frame was lost.
 
 
 
 
Hello,  I agree. I was also able to create an RTP streaming application for my H264 encoder within a week. More documentation would surelybe appreciated by new users. Towards this, I documented my work and put it here: (it has sample code + UML diagrams)http://www.white.ca/patrick/tutorial.tar.gzDo you think you would be able to do the same, Luc?I'm also interested in your question about packet loss. I have not yet had time to look at that part of RTP but I will have to, very soon. Are we to assume that presentation times will be regular (like every 33 ms) and if there is a gap between them on the receiving end, we know a frame was lost? I may be wrong but that doesn't seem like an elegant solution...Mojtaba Hosseini
_________________________________________________________________
Ontdek Windows Live Hotmail, het ultieme online mailprogramma!
http://get.live.com/mail/overview


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5243 bytes
Desc: not available
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070717/1f003cfb/attachment.bin 

From MHosseini at newheights.com  Tue Jul 17 06:42:01 2007
From: MHosseini at newheights.com (Mojtaba Hosseini)
Date: Tue, 17 Jul 2007 07:42:01 -0600
Subject: [Live-devel] Question about fDurationInMicroseconds
References: <005401c7c86f$182e48c0$022a320a@telxsi.com>
Message-ID: <D6DDE2706695D34F8263D17DD29606D9AD5817@BBSC-EX01.bbsconnect.ca>

Hello,
  I had a question about the 'fDurationInMicroseconds' variable of FramedSource class. What is the intended function of this variable?
What I see from the code is that it is used to schedule the 'next send time' in the sink (e.g. MultiFramedRTPSink.cpp). Is that it?
  Should I expect to receive this value on the RTP receiver side as well? I somehow always get '0' for this value from the afterGettingFrame()
of the sink. Should I expect otherwise?
   Any help would be appreciated. Thanks.

Mojtaba Hosseini


-----Original Message-----
From: live-devel-bounces at ns.live555.com on behalf of Vinod Madhav Joshi
Sent: Tue 7/17/2007 6:36 AM
To: Live 555 (E-mail)
Subject: [Live-devel] MPEG2 Elementary stream sync
 


  Hi all,

   We are using Live 555 streaming server as Video On Demand server 
   to stream MPEG2 streams to the set top box.

   After receiving audio and video elementary streams
   on the client side, how to synchronize them?

   i.e. how the achieve lip-sync.

   Thank You.

  

  
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3199 bytes
Desc: not available
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070717/679a6f10/attachment-0001.bin 

From finlayson at live555.com  Tue Jul 17 08:51:30 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Jul 2007 08:51:30 -0700
Subject: [Live-devel] Lost packets
In-Reply-To: <D6DDE2706695D34F8263D17DD29606D9AD5816@BBSC-EX01.bbsconnect.ca>
References: <BAY126-W179F4C149CB361D9959B73C4080@phx.gbl>
	<D6DDE2706695D34F8263D17DD29606D9AD5813@BBSC-EX01.bbsconnect.ca>
	<D6DDE2706695D34F8263D17DD29606D9AD5816@BBSC-EX01.bbsconnect.ca>
Message-ID: <f06240804c2c29597f7a7@[66.80.62.44]>

>  Is there a reason why this is the current design?

Because the details of the underlying transport protocol (in this 
case, RTP) are intended to be transparent to higher-level software.

There are no plans to change the current API.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 17 08:54:03 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Jul 2007 08:54:03 -0700
Subject: [Live-devel] Question about fDurationInMicroseconds
In-Reply-To: <D6DDE2706695D34F8263D17DD29606D9AD5817@BBSC-EX01.bbsconnect.ca>
References: <005401c7c86f$182e48c0$022a320a@telxsi.com>
	<D6DDE2706695D34F8263D17DD29606D9AD5817@BBSC-EX01.bbsconnect.ca>
Message-ID: <f06240806c2c2963c1e4c@[66.80.62.44]>

>Hello,
>   I had a question about the 'fDurationInMicroseconds' variable of 
>FramedSource class. What is the intended function of this variable?
>What I see from the code is that it is used to schedule the 'next 
>send time' in the sink (e.g. MultiFramedRTPSink.cpp). Is that it?

Yes.

>   Should I expect to receive this value on the RTP receiver side as well?

No, that variable is currently used only on the RTP sender side.  If 
you have a RTP receiver (i.e., a subclass of "RTPSource"), then this 
variable will always be 0 - but that's OK, because it's not currently 
used by RTP receivers.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 17 08:58:55 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Jul 2007 08:58:55 -0700
Subject: [Live-devel] Everyone - please read the FAQ!
Message-ID: <f06240807c2c2973d5a99@[66.80.62.44]>

Could everyone who's working with the "LIVE555 Streaming Media" 
software *please* read the FAQ:
	 http://www.live555.com/liveMedia/faq.html

If you have already read the FAQ, but not recently, then you might 
find it useful to read it again.

In the last couple of days several questions have been posted to the 
mailing list that could probably be answered by reading the FAQ.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 17 09:11:52 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Jul 2007 09:11:52 -0700
Subject: [Live-devel] Streaming with Sensoray 2250 encoded data
In-Reply-To: <01MJ0XRCYQAC8WWA38@ponyexpress.arl.psu.edu>
References: <01MJ0XRCYQAC8WWA38@ponyexpress.arl.psu.edu>
Message-ID: <f06240808c2c29954d801@[66.80.62.44]>

>I am trying to stream video from a platform that 
>has a Sensoray 2250 encoder installed on it. I 
>have already verified that all of the hardware 
>works and that data produced from it can be 
>streamed using the live library by doing the 
>following:
>?         Created a process that grabs MPEG2 
>frames from the encoder and dumps them to a 
>named pipe
>?         Modified testMPEG1or2VideoStreamer to 
>look at this pipe for data, and stream it to a 
>specified IP address
>?         Works fine, except that, as you can 
>image, there is some major delay in the video 
>which I cannot have due to the nature of what 
>this video stream is being used for.

You can probably eliminate most of this delay by 
reducing the maximum buffering used by your pipe. 
(I don't know how you would do this, but there 
should be a way.)

This method - piping encoded data directly to the 
(modified) "testMPEG1or2VideoStreamer" is *by 
far* the easiest way to get what you want.  I 
recommend sticking with this approach if you can.


>
>I decided to move on and write a FramedSource 
>subclass that encapsulates my encoder, and 
>deliver this object directly to a 
>MPEG1or2VideoRTPSink.

You should insert a 
"MPEG1or2VideoStreamDiscreteFramer" in front of 
your "MPEG1or2VideoRTPSink".


>The thing that is very odd is that it seems like 
>my implementation of doGetNextFrame() is never 
>executed

You should first make sure that you can walk 
before you try to run.  I suggest that you begin 
by trying to write your encoded data to a file 
rather than streaming it over a network.  I.e., 
start by using a "FileSink" instead of a 
"MPEG1or2VideoRTPSink".  Once you have shown that 
you can successfully write your encoded data into 
a file (and test that the data is correct by 
trying to play the file in a media player), then 
it would make sense to move to streaming.
-- 

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/20070717/f96f4dc8/attachment.html 

From rruthe02 at harris.com  Tue Jul 17 13:32:07 2007
From: rruthe02 at harris.com (Rutherford, Robert)
Date: Tue, 17 Jul 2007 16:32:07 -0400
Subject: [Live-devel] openRTSP, Trick Mode, and Transport Streams
Message-ID: <505F93C737C4B647A0007D96439B71770268F0DC@mlbe2k7.cs.myharris.net>

Ross,

I am able to test trick mode functionality using
testMPEG2TransportStreamTrickPlay at various scales and in both
directions.  However, when I try to test with openRTSP I see some
strange results.  I modified the call to the function playMediaSession()
as you describe in a previous thread ("Trick play problems", 4/16/2007)
to accept arguments for start time, end time, and scale.  I am using a
start time of 0.0f and an end time of -1.0f.  With a scale of 1.0f,
everything works well, with openRTSP creating a file (video-MP2T-1)
locally.  When I try scale = 2.0f, it still creates the same file, but
with the same size and scale as the first (verified by playback with
VLC).  If I try scale = 4.0f, openRTSP creates the file video-MP2T-1,
but it remains at size zero and openRTSP appears to do nothing.  I need
a method of verifying trick mode over RTSP.  Also, the directions for
using Trick Mode state that the scale must be an integer.  This means
that scales less than 1 are not support (i.e. slow motion)?

Thanks,
Rob Rutherford
Harris Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070717/eca7a470/attachment.html 

From finlayson at live555.com  Tue Jul 17 16:49:33 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Jul 2007 16:49:33 -0700
Subject: [Live-devel] openRTSP, Trick Mode, and Transport Streams
In-Reply-To: <505F93C737C4B647A0007D96439B71770268F0DC@mlbe2k7.cs.myharris.net>
References: <505F93C737C4B647A0007D96439B71770268F0DC@mlbe2k7.cs.myharris.net>
Message-ID: <f06240809c2c300f833e7@[66.80.62.44]>

>I am able to test trick mode functionality using 
>testMPEG2TransportStreamTrickPlay at various scales and in both 
>directions.  However, when I try to test with openRTSP I see some 
>strange results.  I modified the call to the function 
>playMediaSession() as you describe in a previous thread ("Trick play 
>problems", 4/16/2007) to accept arguments for start time, end time, 
>and scale.  I am using a start time of 0.0f and an end time of 
>-1.0f.  With a scale of 1.0f, everything works well, with openRTSP 
>creating a file (video-MP2T-1) locally.  When I try scale = 2.0f, it 
>still creates the same file, but with the same size and scale as the 
>first (verified by playback with VLC).  If I try scale = 4.0f, 
>openRTSP creates the file video-MP2T-1, but it remains at size zero 
>and openRTSP appears to do nothing.

That's odd.  Are you using the latest version of the code?  (Version 
2007.07.01 fixed a bug that affected 2x speedup (although it should 
not have affected 4x speedup).)

I have tested the latest version of the code (2007.07.10), and it 
works OK for me.

(In each case, I modified the call to "playMediaSession()" at line 65 
of "testProgs/openRTSP.cpp".


>  I need a method of verifying trick mode over RTSP.  Also, the 
>directions for using Trick Mode state that the scale must be an 
>integer.  This means that scales less than 1 are not support (i.e. 
>slow motion)?

Not for Transport Streams, with our implementation.
-- 

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/20070717/20b74754/attachment.html 

From jennytharayil at gmail.com  Wed Jul 18 01:12:16 2007
From: jennytharayil at gmail.com (jenny tc)
Date: Wed, 18 Jul 2007 13:42:16 +0530
Subject: [Live-devel] HD MPEG2 Movie streaming generates error
Message-ID: <47b5508f0707180112o66b62447y3cdf6ce9e9577758@mail.gmail.com>

hai all
       I tried to stream an HD MPEG2 movie using live555MediaServer . But it
exits by generating the error.I Modified BANK_SIZE to 150000 in
StreamParser.hh

Error
StreamParser internal error (85990 + 65541 > 150000)

I played  the stream with mplayer. But the display seems to be very bad. How
can I solve this problem

I used
http://digigami.in-long-beach-ca.com/megapeg/HDTV-MPEG-2/Least_Likely_PSA_720p.mpg
-Jenny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/6c9e3b90/attachment.html 

From yanrx at sina.com  Wed Jul 18 01:35:55 2007
From: yanrx at sina.com (yanrx at sina.com)
Date: Wed, 18 Jul 2007 16:35:55 +0800 
Subject: [Live-devel] Build live555 on EVC / WinCE?
Message-ID: <20070718083556.42581.qmail@mail3-111.sinamail.sina.com.cn>

Dear all,

I am trying to build live555 library on EVC to make it useable in WinCE. 
Has anyone already builded that? How can I get guide or instructions?

I have done it successfully on Visual C++. 

Thanks in advance!

Best regards,
Renxiang



-------------------------------------------------------------------
MOTONBA?????( http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2007/mail_zhuiyu_20070709.html )

===================================================================
????2G????? http://mail.sina.com.cn/chooseMode.html ?

From tl11305 at salle.url.edu  Wed Jul 18 03:48:20 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Wed, 18 Jul 2007 12:48:20 +0200 (CEST)
Subject: [Live-devel] RTSP Authentication
Message-ID: <1354.172.16.11.128.1184755700.squirrel@webmail.salle.url.edu>

Hi,
I use UserAuthentication option in RTSP making use of
UserAuthenticationDatabase and QuickTime as client. First time client wants to
connect to a streaming session QuickTime asks for user and password to
complete authentication with server. But if client closes it and then tries to
reconnect, it directly connects without asking again for authentication.

Is it a normal procedure or is it a bug?

Is it possibly caused because it remains on database memory? or maybe
Quicktime saves last uer and password used?

If I want that it always reclaims user and pasword access could I change
something on RTSPServer or UserAuthenticationDatabase classes to get this?

Thanks in advance,

Ramon


From tl11305 at salle.url.edu  Wed Jul 18 04:05:15 2007
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Wed, 18 Jul 2007 13:05:15 +0200 (CEST)
Subject: [Live-devel] RTSP Authentication
In-Reply-To: <1354.172.16.11.128.1184755700.squirrel@webmail.salle.url.edu>
References: <1354.172.16.11.128.1184755700.squirrel@webmail.salle.url.edu>
Message-ID: <1384.172.16.11.128.1184756715.squirrel@webmail.salle.url.edu>

Well, I saw that closing completely QuickTime (not only video window) and
trying to reconnect it reclaims again user and password so I supose that it
remains in Quicktime memory and it's not possible to control on server side,
because it is working properly, receiving user and password again. Could you
confirm this, Ross?

Thanks anyway,

Ramon

> Hi,
> I use UserAuthentication option in RTSP making use of
> UserAuthenticationDatabase and QuickTime as client. First time client wants to
> connect to a streaming session QuickTime asks for user and password to
> complete authentication with server. But if client closes it and then tries to
> reconnect, it directly connects without asking again for authentication.
>
> Is it a normal procedure or is it a bug?
>
> Is it possibly caused because it remains on database memory? or maybe
> Quicktime saves last uer and password used?
>
> If I want that it always reclaims user and pasword access could I change
> something on RTSPServer or UserAuthenticationDatabase classes to get this?
>
> Thanks in advance,
>
> Ramon
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>



From panospcx at gmail.com  Wed Jul 18 06:16:49 2007
From: panospcx at gmail.com (Panos Christodoulou)
Date: Wed, 18 Jul 2007 16:16:49 +0300
Subject: [Live-devel] Error while trying to build livemedia library using
	Borland C++ compiler
Message-ID: <c1124af50707180616g1ace33bbk2809d2b5088ef909@mail.gmail.com>

Hello there,
I am trying to build the livemedia library, so i could use it to build the
openrtsp application. I follow the procedure described on the live555
website but when i execute make on the command line i get

Error E2268 inputfile.cpp 85: Call to undefined function '_lseeki64' in
function
 SeekFile64(FILE *,__int64,int)
Error E2268 inputfile.cpp 99: Call to undefined function '_telli64' in
function
TellFile64(FILE *)
*** 2 errors in Compile ***

** error 1 ** deleting InputFile.obj


After that some object files are created but the library is not. Could this
be fixed????
Please try giving simple answers because i am not yet very experienced in
c++ and command line



Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/aedf0ca9/attachment.html 

From stondage123 at yahoo.com  Wed Jul 18 06:46:24 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Wed, 18 Jul 2007 06:46:24 -0700 (PDT)
Subject: [Live-devel] Error while trying to build livemedia library
	using Borland C++ compiler
Message-ID: <774617.21473.qm@web35910.mail.mud.yahoo.com>

What system are you building on? It looks like your system is lacking 64-bit lseek system calls.

-Andrew

----- Original Message ----
From: Panos Christodoulou <panospcx at gmail.com>
To: live-devel at ns.live555.com
Sent: Wednesday, July 18, 2007 9:16:49 AM
Subject: [Live-devel] Error while trying to build livemedia library using Borland C++ compiler

Hello there,
I am trying to build the livemedia library, so i could use it to build the openrtsp application. I follow the procedure described on the live555 website but when i execute make on the command line i get


Error E2268 inputfile.cpp 85: Call to undefined function '_lseeki64' in function
 SeekFile64(FILE *,__int64,int)
Error E2268 inputfile.cpp 99: Call to undefined function '_telli64' in function

TellFile64(FILE *)
*** 2 errors in Compile ***

** error 1 ** deleting InputFile.obj


After that some object files are created but the library is not. Could this be fixed????
Please try giving simple answers because i am not yet very experienced in c++ and command line




Thanks

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/fc9256ce/attachment.html 

From finlayson at live555.com  Wed Jul 18 06:52:19 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 06:52:19 -0700
Subject: [Live-devel] HD MPEG2 Movie streaming generates error
In-Reply-To: <47b5508f0707180112o66b62447y3cdf6ce9e9577758@mail.gmail.com>
References: <47b5508f0707180112o66b62447y3cdf6ce9e9577758@mail.gmail.com>
Message-ID: <f06240801c2c3cb1577ce@[66.80.62.44]>

Thanks for the report.  I have downloaded your demo file, and will be 
testing it to see how our server and client software can be improved 
to stream/receive it better.

(This may take a few days, however; Andrew Stone's problem (reported 
last week) currently takes priority.  Stay tuned...)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From bleary at harris.com  Wed Jul 18 06:59:41 2007
From: bleary at harris.com (Leary, Brent)
Date: Wed, 18 Jul 2007 09:59:41 -0400
Subject: [Live-devel] Multicast Q
In-Reply-To: <f06240802c294606b139b@[66.80.62.44]>
References: <E7191752EF4FAD498FD0E968F7A7DAF705AA36@mlbe2k5.cs.myharris.net>
	<f06240802c294606b139b@[66.80.62.44]>
Message-ID: <E7191752EF4FAD498FD0E968F7A7DAF72B7A6A@mlbe2k5.cs.myharris.net>

Ross,
Are their any major differences in functionality provided by
testOnDemandRTSPServer and the Live555 Media Server?
 
Thanks,
-Brent


________________________________

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, June 12, 2007 10:56 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Multicast Q



	I am using the 'testOnDemandRTSPServer' to support unicast
streaming of MPEG transport streams to a PC running VLC.  This is
working with no problems.  When I started the 'Live555 Media Server' was
unavailable. Now I am interested in adding multicast support to the RTSP
Server I'm running. From reading your responses to prior posts to this
message board, neither 'testOnDemandRTSPServer' nor 'Live555 Media
Server' support multicast playback (I'm assuming this is still the
case).  In order to support mutlicast, 'testMPEG1or2VideoStreamer' would
have to be integrated/started to allow the running RTSP Server to
perform mutlicast playback.  Is this correct or has multicast support
been incorporated into an RTSP Server?


Yes, our RTSP server implementation supports multicast streams.  This is
demonstrated in the various "test*Streamer" demo applications.  E.g.,
You can demonstrate this by uncommenting the line
//#define IMPLEMENT_RTSP_SERVER 1
in "testProgs/testMPEG1or2VideoStreamer.cpp".


	Does the existing RTSP Server & streamer software support the
RFC's 2326's multicast example (below)?


Yes.


	  If it does would it be able to handle having the client set
the multicast IP destination & port in the setup command? 


No, because that is a silly idea.  It's the role of the server, not
clients, to choose whether - and with what address/port - a stream is
multicast.  See
http://lists.live555.com/pipermail/live-devel/2007-February/006273.html


	Is there a client already available that supports having the
client setup the multicast destination & port


No.
-- 

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/20070718/eb48c43a/attachment.html 

From finlayson at live555.com  Wed Jul 18 07:06:07 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 07:06:07 -0700
Subject: [Live-devel] Error while trying to build livemedia library
 using Borland C++ compiler
In-Reply-To: <774617.21473.qm@web35910.mail.mud.yahoo.com>
References: <774617.21473.qm@web35910.mail.mud.yahoo.com>
Message-ID: <f06240802c2c3cd0bed46@[66.80.62.44]>

>What system are you building on? It looks like your system is 
>lacking 64-bit lseek system calls.

The problem is probably Panos's use of the Borland C++ compiler. 
This compiler unfortunately requires some special-case hacks in the 
code (search for "BORLANDC" in the code for examples of this).

The library header files that the Borland compiler uses apparently do 
not use the functions "_lseeki64()" and "_telli64(}" that GCC and 
Visual C++ use.  Do these functions have equivalent versions (with 
different names) in the Borland libraries?  If so, please let me 
know, and I can modifiy the code to support this.  If, however, they 
don't have equivalent versions in the Borland libraries, then you're 
out of luck - sorry.


>Error E2268 inputfile.cpp 85: Call to undefined function '_lseeki64' 
>in function
>  SeekFile64(FILE *,__int64,int)
>Error E2268 inputfile.cpp 99: Call to undefined function '_telli64' 
>in function
>TellFile64(FILE *)


-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul 18 09:18:18 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 09:18:18 -0700
Subject: [Live-devel] (not a) Multicast Q
In-Reply-To: <E7191752EF4FAD498FD0E968F7A7DAF72B7A6A@mlbe2k5.cs.myharris.net>
References: <E7191752EF4FAD498FD0E968F7A7DAF705AA36@mlbe2k5.cs.myharris.net>
	<f06240802c294606b139b@[66.80.62.44]>
	<E7191752EF4FAD498FD0E968F7A7DAF72B7A6A@mlbe2k5.cs.myharris.net>
Message-ID: <f06240803c2c3eb79aa6e@[66.80.62.44]>

>Are their any major differences in functionality provided 
>by testOnDemandRTSPServer and the Live555 Media Server?

The one major difference (although there will be many more in the 
future) is that the "LIVE555 Media Server" lets you stream any file 
(residing in the same directory), provided that it has an appropriate 
file name extension (e.g., ".mpg", ".ts", ".mp3"). 
"testOnDemandRTSPServer" streams only a small set of 'hard-wired' 
file names (e.g., "test.mpg", "test.ts", "test.mp3").

In most cases, if you are developing your own unicast on-demand RTSP 
server implementation, you should use the "testOnDemandRTSPServer" 
code as a starting point, because it is simpler to understand and 
work with.  In contrast, the "LIVE555 Media Server" is intended to be 
a complete server product that most people will run 'as is' from the 
pre-supplied binary version (although the source code for this is 
also provided, as a courtesy).
-- 

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/20070718/3f2cdae5/attachment-0001.html 

From finlayson at live555.com  Wed Jul 18 09:28:46 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 09:28:46 -0700
Subject: [Live-devel] RTSP Authentication
In-Reply-To: <1354.172.16.11.128.1184755700.squirrel@webmail.salle.url.edu>
References: <1354.172.16.11.128.1184755700.squirrel@webmail.salle.url.edu>
Message-ID: <f06240805c2c3f028c39b@[66.80.62.44]>

>I use UserAuthentication option in RTSP making use of
>UserAuthenticationDatabase and QuickTime as client. First time client wants to
>connect to a streaming session QuickTime asks for user and password to
>complete authentication with server. But if client closes it and then tries to
>reconnect, it directly connects without asking again for authentication.

This sounds like a QuickTime Player issue.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From Chen.Li2 at boeing.com  Wed Jul 18 09:49:10 2007
From: Chen.Li2 at boeing.com (Li, Chen)
Date: Wed, 18 Jul 2007 09:49:10 -0700
Subject: [Live-devel] Actual Trick Play Functionality Needed
Message-ID: <FBE587797E2D164EA422C24856583F340200A2D7@XCH-SW-2V1.sw.nos.boeing.com>

Hello,

I have been working with the live555 media server as well as live555
test programs.  So far I see no test script that actually sends a
command over rtcp to tell the server to fast forward a particular
stream.  Thus, any help would be appreciated if someone could point me
to:
Code examples
Documentation
Test program
Anything
(Preferable in this order)
That actually sends a command to the server.  The current test program
testMPEG2TransportStreamTrickPlay.cpp fakes it by using the indexer to
skip through frames and create a new file and scripts such as
openRTSP.cpp do not have a class that handles trickplay nor could I find
it in the media server scripts.  Also, I did not find it in the class
definitions so any help would be appreciated.

Any help would be appreicated.  Thanks!

--Chen Li


From bleary at harris.com  Wed Jul 18 11:07:34 2007
From: bleary at harris.com (Leary, Brent)
Date: Wed, 18 Jul 2007 14:07:34 -0400
Subject: [Live-devel] Multicast & TrickModes mutually exclusive?
Message-ID: <E7191752EF4FAD498FD0E968F7A7DAF72B7A75@mlbe2k5.cs.myharris.net>

Ross,
Are  pause and trick modes supported for multicast streams?  It doesn't
seem like they would be, but wanted to verify with you before just
making the assumption.
 
Thanks,
-Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/dd670b45/attachment.html 

From xcsmith at rockwellcollins.com  Wed Jul 18 11:09:03 2007
From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com)
Date: Wed, 18 Jul 2007 13:09:03 -0500
Subject: [Live-devel] Trick Mode Data Rate Limitation
Message-ID: <OF2422C248.D248D786-ON8625731C.0051914B-8625731C.006402AA@rockwellcollins.com>

Ross and Community,

I am hoping to implement a bandwidth limitation on trick mode streams 
only, such that the bitrate of the trick mode stream would not exceed the 
average bitrate of the original stream.  For the particular 5 Mbps streams 
that I  have, I cannot get above 4x speed-up without significantly 
exceeding the 5 Mbps data rate.  (I have stopped the filter from repeating 
I-Frames because my client's network buffers have no hope of handling 
these repetitions.  Also, I was told that the I-frames which were repeated 
had identical PCR if - I remember correctly - and so the decoder buffer of 
my client would become full before a new PCR was available in the buffer.)

I have figured out a very crude way to implement this for my specific 
system, but I am trying to figure out a better way to do the math to 
determine which I-frames to discard to implement a bitrate limitation. 
Initially, I think that if I add another count to 
MPEG2TransportStreamTrickModeFilter such that each GOP would be divided 
into 4 "time slots", and allow only 1 I-frame to be sent per "time-slot", 
that my trick-mode bitrate limitation would work most of the time.  I 
think this was the suggestion here: 
http://lists.live555.com/pipermail/live-devel/2007-March/006317.html

It would work something like this:
Each GOP I can think of as being divided into 15 time-slots, T0-T14.  I 
must send "scale" number of I-frames per GOP.  If "scale" > 15, then some 
I-frames will be discarded.
I can figure out which I-frame, IN, from the original stream goes in any 
given slot with: 

        floor function ( scale * slot-number / GOP-length) = N

To limit the bitrate on top of this, I would have to divide the GOP into 4 
and allow only one I-frame to be sent in each of T0-T3, T4-T7, T8-T11, 
T12-T14.

You can see that this implementation would not scale very well at all, and 
in fact might not even work for particular streams in my system.  I would 
most like to ensure that the trick mode bitrate would not exceed the 
average bitrate of the original stream.  But if that is not possible, then 
I would like to figure out a way to specify the maximum bitrate.  Can you 
provide any suggestions on how to implement either of these changes?  I 
see here, you have a different idea altogether: 
http://lists.live555.com/pipermail/live-devel/2007-April/006509.html

Thank you!
Xochitl Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/645eac7e/attachment.html 

From stondage123 at yahoo.com  Wed Jul 18 11:30:30 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Wed, 18 Jul 2007 11:30:30 -0700 (PDT)
Subject: [Live-devel] trick play errors - possible diagnosis
Message-ID: <801941.22357.qm@web35910.mail.mud.yahoo.com>

Ross,

I am not sure of this, however I think this may be the problem with the trick play. I don't know if this helps or not, but just wanted to alert you to this.

What seems to be happening is that when I play the dvd2.ts file the PCR is advancing beyond the PTS of frames to be displayed by VLC, thus making those frames' timestamps occur in the past. The decoder is then dropping those frames, because it doesn't know when to decode them. I believe the correct thing for vlc to do is to adjust the PTS of those frames somehow so that they can be displayed based on the latest PCR, or something of this nature. I need to look into it more. Furthermore, I need to fix this backwards PTS stuff soon, so I will  be working on implementing this in VLC. This is independent of my trick play needs for kno. We mainly need it for splicing and other stuff. This may allow playing of dvd2.ts. as a bonus though.

Mainly, what I'm saying is that the live555 trick play code may be correct, and VLC just can't handle the generated ts streams properly( if this is the problem of course).

I will be contacting the vlc team about this.

Thanks for all the hard work.

-Andrew





From finlayson at live555.com  Wed Jul 18 11:53:26 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 11:53:26 -0700
Subject: [Live-devel] Multicast & TrickModes mutually exclusive?
In-Reply-To: <E7191752EF4FAD498FD0E968F7A7DAF72B7A75@mlbe2k5.cs.myharris.net>
References: <E7191752EF4FAD498FD0E968F7A7DAF72B7A75@mlbe2k5.cs.myharris.net>
Message-ID: <f06240809c2c411c32a0d@[66.80.62.44]>

>Are  pause and trick modes supported for multicast streams?

No.  Because multicast streams are usually intended to be received by 
potentially multiple clients, it doesn't usually make sense to allow 
a single ciient to control the stream like this.
-- 

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/20070718/2c6fd670/attachment.html 

From finlayson at live555.com  Wed Jul 18 12:00:42 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 12:00:42 -0700
Subject: [Live-devel] trick play errors - possible diagnosis
In-Reply-To: <801941.22357.qm@web35910.mail.mud.yahoo.com>
References: <801941.22357.qm@web35910.mail.mud.yahoo.com>
Message-ID: <f0624080ac2c412c96757@[66.80.62.44]>

>Mainly, what I'm saying is that the live555 trick play code may be 
>correct, and VLC just can't handle the generated ts streams properly

Maybe, but note that Transport Stream files from other sources don't 
seem to have this problem.  If your hypothesis is correct, then there 
is something special (strange) about your Transport Stream files that 
are causing this problem.  If that's the case, then you should look 
into whether your Transport Streams really are compliant.

In any case, I'll stop looking into your problem for now, unless I 
hear word back from you that there really is a problem with the 
LIVE555 code, rather than with your Transport Stream data.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul 18 12:03:06 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 12:03:06 -0700
Subject: [Live-devel] Actual Trick Play Functionality Needed
In-Reply-To: <FBE587797E2D164EA422C24856583F340200A2D7@XCH-SW-2V1.sw.nos.boeing.com>
References: <FBE587797E2D164EA422C24856583F340200A2D7@XCH-SW-2V1.sw.nos.boeing.com>
Message-ID: <f0624080bc2c413fdaf8f@[66.80.62.44]>

>  So far I see no test script that actually sends a
>command over rtcp to tell the server to fast forward a particular
>stream.

"openRTSP" currently has no option for doing this (although one might 
get added in the future).

For now, you need to explicitly modify the call to 
"playMediaSession()" at line 65 of "testProgs/openRTSP.cpp".  (See 
"liveMedia/include/RTSPClient.hh" for the parameter signature of this 
call.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From Chen.Li2 at boeing.com  Wed Jul 18 13:24:56 2007
From: Chen.Li2 at boeing.com (Li, Chen)
Date: Wed, 18 Jul 2007 13:24:56 -0700
Subject: [Live-devel] Actual Trick Play Functionality Needed
In-Reply-To: <f0624080bc2c413fdaf8f@[66.80.62.44]>
References: <FBE587797E2D164EA422C24856583F340200A2D7@XCH-SW-2V1.sw.nos.boeing.com>
	<f0624080bc2c413fdaf8f@[66.80.62.44]>
Message-ID: <FBE587797E2D164EA422C24856583F340200A2D9@XCH-SW-2V1.sw.nos.boeing.com>

>From my read through of the RTSPClient.hh it does not appear to have a
specific fastforwardMediaSession or something to that nature.  Does this
mean the live555 media server currently supports trick play only through
the creation of a "subsession" with a file created by skipping frames of
the original and streaming that file? 

-----Original Message-----
From: Ross Finlayson [mailto:finlayson at live555.com] 
Sent: Wednesday, July 18, 2007 12:03 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Actual Trick Play Functionality Needed

>  So far I see no test script that actually sends a command over rtcp 
>to tell the server to fast forward a particular stream.

"openRTSP" currently has no option for doing this (although one might
get added in the future).

For now, you need to explicitly modify the call to "playMediaSession()"
at line 65 of "testProgs/openRTSP.cpp".  (See
"liveMedia/include/RTSPClient.hh" for the parameter signature of this
call.)
-- 

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

From rruthe02 at harris.com  Wed Jul 18 13:38:14 2007
From: rruthe02 at harris.com (Rutherford, Robert)
Date: Wed, 18 Jul 2007 16:38:14 -0400
Subject: [Live-devel] Slow Motion (MPEG2TS)
Message-ID: <505F93C737C4B647A0007D96439B71770268F0FF@mlbe2k7.cs.myharris.net>

Has anyone tried to implement slow motion (scale < 1.0) with MPEG2
Transport Stream Trick Play?  I need to be able to test and support this
feature, but it is not included in the latest Live555 baseline.  I am
looking for a good starting point for parsing the index file and
choosing which frames to send to the client in the Live555 code.  Also,
Ross, is this something you plan to include in future releases?

Thanks,
Rob Rutherford
Harris Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070718/5578b6d6/attachment.html 

From finlayson at live555.com  Wed Jul 18 18:29:45 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 18:29:45 -0700
Subject: [Live-devel] trick play errors - possible diagnosis
Message-ID: <f0624080dc2c46e186c6d@[66.80.62.44]>

>Mainly, what I'm saying is that the live555 trick play code may be 
>correct, and VLC just can't handle the generated ts streams properly

Note that the following Transort Stream file
	http://www.live555.com/osbournes.ts
works OK (indexing and trick play).  So you might want to check to 
see what is different about your Transport Stream compared to one 
that works OK.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Wed Jul 18 18:37:03 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Jul 2007 18:37:03 -0700
Subject: [Live-devel] Actual Trick Play Functionality Needed
In-Reply-To: <FBE587797E2D164EA422C24856583F340200A2D9@XCH-SW-2V1.sw.nos.boeing.com>
References: <FBE587797E2D164EA422C24856583F340200A2D7@XCH-SW-2V1.sw.nos.boeing.com>
	<f0624080bc2c413fdaf8f@[66.80.62.44]>
	<FBE587797E2D164EA422C24856583F340200A2D9@XCH-SW-2V1.sw.nos.boeing.com>
Message-ID: <f0624080ec2c46f65ba77@[66.80.62.44]>

>  >From my read through of the RTSPClient.hh it does not appear to have a
>specific fastforwardMediaSession or something to that nature.

No, as a RTSP client you specify fast-forward using the "scale" 
parameter to "playMediaSession()".  E.g., "4.0" to request 4x speedup.

(Note that someone else was asking about this just yesterday; see
http://lists.live555.com/pipermail/live-devel/2007-July/007195.html
and
http://lists.live555.com/pipermail/live-devel/2007-July/007196.html
)

Of course, 'fast-forward' play will work only if the server supports 
it (and on the specified media type).
-- 

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/20070718/f9e4fa4c/attachment.html 

From stondage123 at yahoo.com  Wed Jul 18 19:13:17 2007
From: stondage123 at yahoo.com (Andrew Stone)
Date: Wed, 18 Jul 2007 19:13:17 -0700 (PDT)
Subject: [Live-devel] trick play errors - possible diagnosis
Message-ID: <474538.53401.qm@web35901.mail.mud.yahoo.com>

Thanks Ross. I appreciate the sample.

-Andrew

----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Wednesday, July 18, 2007 9:29:45 PM
Subject: Re: [Live-devel] trick play errors - possible diagnosis

>Mainly, what I'm saying is that the live555 trick play code may be 
>correct, and VLC just can't handle the generated ts streams properly

Note that the following Transort Stream file
    http://www.live555.com/osbournes.ts
works OK (indexing and trick play).  So you might want to check to 
see what is different about your Transport Stream compared to one 
that works OK.
-- 

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




From achaloyan at yahoo.com  Wed Jul 18 22:56:11 2007
From: achaloyan at yahoo.com (Arsen Chaloyan)
Date: Wed, 18 Jul 2007 22:56:11 -0700 (PDT)
Subject: [Live-devel] MRCP over RTSP
Message-ID: <795173.32850.qm@web52703.mail.re2.yahoo.com>

Hello,

I'm going to utilize liveMedia library for MRCP implementation.

According to RFC 4463
   When a media server implementing MRCP over RTSP receives a PLAY,
   RECORD, or PAUSE RTSP method from an MRCP resource URL, it should
   respond with an RTSP 405 "Method not Allowed" response.  For these
   resources, the only allowed RTSP methods are SETUP, TEARDOWN,
   DESCRIBE, and ANNOUNCE.
Unfortunately liveMedia (RTSPServer) has nos support for RTSP ANNOUNCE method.
More over, seems there are no plans to support it in the future http://lists.live555.com/pipermail/live-devel/2007-February/006234.html

May be I can add it myself?
Can you please give some hints on this?

Thanks,
Arsen.




       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

From bonheur.cheung at seldes.com  Thu Jul 19 07:29:10 2007
From: bonheur.cheung at seldes.com (cheung bonheur)
Date: Thu, 19 Jul 2007 16:29:10 +0200
Subject: [Live-devel] Close the client session RTSP
Message-ID: <000d01c7ca11$2c6e4f30$6401a8c0@rhea>

Hello all,

I use RTSP server in a thread and when i restart this, rtsp client session socket is not destroyed. And then client browser or application is freeze...
So how can i destroy client rtsp socket without reboot my application ?

Thanks for your help 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070719/a5573353/attachment.html 

From rruthe02 at harris.com  Thu Jul 19 08:24:04 2007
From: rruthe02 at harris.com (Rutherford, Robert)
Date: Thu, 19 Jul 2007 11:24:04 -0400
Subject: [Live-devel] openRTSP, Trick Mode, and Transport Streams
Message-ID: <505F93C737C4B647A0007D96439B71770268F10A@mlbe2k7.cs.myharris.net>

Ross,

I was not running the latest baseline before, so I tried that and I get
the same result.  Also, I used Wireshark to trace the RTSP commands to
setup the stream and everything looks the same (i.e. OPTIONS, DESCRIBE,
SETUP, PLAY). The 1.0 scale immediately starts sending the RTP packets
after the setup.  The 2.0 scale sends a TCP message (appears to be an
ACK) immediately after the "OK" response to the PLAY command, but never
sends any RTP packets.  I don't see any errors on the server or client
side (in the form of prints), but I am also not sure I have the most
verbose output on.  I am using MPEG2 Transport Streams and version
2007.07.09.


Rob Rutherford
Harris Corporation

------------------------------

>I am able to test trick mode functionality using 
>testMPEG2TransportStreamTrickPlay at various scales and in both 
>directions.  However, when I try to test with openRTSP I see some 
>strange results.  I modified the call to the function 
>playMediaSession() as you describe in a previous thread ("Trick play 
>problems", 4/16/2007) to accept arguments for start time, end time, 
>and scale.  I am using a start time of 0.0f and an end time of 
>-1.0f.  With a scale of 1.0f, everything works well, with openRTSP 
>creating a file (video-MP2T-1) locally.  When I try scale = 2.0f, it 
>still creates the same file, but with the same size and scale as the 
>first (verified by playback with VLC).  If I try scale = 4.0f, 
>openRTSP creates the file video-MP2T-1, but it remains at size zero 
>and openRTSP appears to do nothing.

That's odd.  Are you using the latest version of the code?  (Version 
2007.07.01 fixed a bug that affected 2x speedup (although it should 
not have affected 4x speedup).)

I have tested the latest version of the code (2007.07.10), and it 
works OK for me.

(In each case, I modified the call to "playMediaSession()" at line 65 
of "testProgs/openRTSP.cpp".


>  I need a method of verifying trick mode over RTSP.  Also, the 
>directions for using Trick Mode state that the scale must be an 
>integer.  This means that scales less than 1 are not support (i.e. 
>slow motion)?

Not for Transport Streams, with our implementation.
-- 

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/20070717/20b74
754/attachment-0001.html 

------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070719/b00cf93c/attachment.html 

From finlayson at live555.com  Thu Jul 19 09:47:03 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Jul 2007 09:47:03 -0700
Subject: [Live-devel] MRCP over RTSP
In-Reply-To: <795173.32850.qm@web52703.mail.re2.yahoo.com>
References: <795173.32850.qm@web52703.mail.re2.yahoo.com>
Message-ID: <f06240800c2c544f1514d@[66.80.62.44]>

>I'm going to utilize liveMedia library for MRCP implementation.
>
>According to RFC 4463

Note that RFC 4463 is just an "informational" RFC.  "MRCP" is not an 
Internet Standard protocol.

>Unfortunately liveMedia (RTSPServer) has nos support for RTSP ANNOUNCE method.
>More over, seems there are no plans to support it in the future 
>http://lists.live555.com/pipermail/live-devel/2007-February/006234.html

That's correct, and the link that you included explains why.

If the IETF ever re-adopts the "ANNOUNCE" method as part of the RTSP 
standard, then we *might* support it.  But until then, we won't.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Thu Jul 19 09:49:25 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Jul 2007 09:49:25 -0700
Subject: [Live-devel] openRTSP, Trick Mode, and Transport Streams
In-Reply-To: <505F93C737C4B647A0007D96439B71770268F10A@mlbe2k7.cs.myharris.net>
References: <505F93C737C4B647A0007D96439B71770268F10A@mlbe2k7.cs.myharris.net>
Message-ID: <f06240801c2c5461b96ed@[66.80.62.44]>

>I was not running the latest baseline before, so I tried that and I 
>get the same result.  Also, I used Wireshark to trace the RTSP 
>commands to setup the stream and everything looks the same (i.e. 
>OPTIONS, DESCRIBE, SETUP, PLAY).

Please rerun (your modified) "openRTSP" with the "-V" (verbose 
output) option, and send us the console output, so we can take a look 
at this, to try to figure out why it's not working for you.
-- 

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/20070719/5d2518e3/attachment-0001.html 

From dgf3208 at gmail.com  Thu Jul 19 17:12:53 2007
From: dgf3208 at gmail.com (Dan Franke)
Date: Thu, 19 Jul 2007 18:12:53 -0600
Subject: [Live-devel] Unicast and Multicast from a single source server?
Message-ID: <62ca8cdb0707191712u30fd0c01m842ad8aa3b6a1794@mail.gmail.com>

Hello All,

I want to make a server that will stream from a single source to multiple
unicast clients and at least one multicast address.  To further complicate
matters I believe it will need to support ASM (I haven't been able to
convince Quicktime to supports SSM).

Before I go too far down the wrong path I thought I'd pose the problem to
the mailing list for any suggestions.

I see three options:

1. Use two different server sessions one for unicast (OnDemand based
subsession) and a separate session for multicast (Passive based subsession)
then feed them from a single FramedSource.  This has complications in the
design of the FramedSource and it duplicates the RTP framing and buffering.

2. Start with the OnDemandRTSPServer example.  I'd subclass the RTSPServer
and ServerMediaSession so that I can parse the URL to distinguish between
the unicast and multicast stream requests, then use this information to
format up the DESCRIBE responses correctly.  Then (what appears to the the
most difficult part) the OnDemandServerMediaSubsession class would need to
be subclassed to handle the fact we would need two different server RTCP
addresses (the ASM requirement).

3. Construct a RTP relay from a unicast address to a multicast address.  I'm
not sure how RTSP plays into this solution.  It probably doesn't matter
since Quicktime doesn't appear to use RTSP for multicast anyway.

I prefer solution 2 but I'm concerned that the two RTCP server addresses
might complicate things too much.

Any suggestions other alternatives or comments?

              Thanks,

                  Dan Franke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070719/c1c139b2/attachment.html 

From finlayson at live555.com  Thu Jul 19 22:53:58 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Jul 2007 22:53:58 -0700
Subject: [Live-devel] Unicast and Multicast from a single source server?
In-Reply-To: <62ca8cdb0707191712u30fd0c01m842ad8aa3b6a1794@mail.gmail.com>
References: <62ca8cdb0707191712u30fd0c01m842ad8aa3b6a1794@mail.gmail.com>
Message-ID: <f06240800c2c5f5160cfa@[66.80.62.44]>

>I want to make a server that will stream from a single source to 
>multiple unicast clients and at least one multicast address.  To 
>further complicate matters I believe it will need to support ASM (I 
>haven't been able to convince Quicktime to supports SSM).
>
>Before I go too far down the wrong path I thought I'd pose the 
>problem to the mailing list for any suggestions.
>
>I see three options:
>
>1. Use two different server sessions one for unicast (OnDemand based 
>subsession) and a separate session for multicast (Passive based 
>subsession)

This is by far the best solution, because it doesn't require messing 
around with the existing RTSP/RTP implementation - which works well 
as is.  The RTSP protocol works differently for unicast and multicast 
streams, and I definitely don't recommend trying to hack the unicast 
implementation to support multicast, or vice versa.


>  then feed them from a single FramedSource.

No, each would need to read from a different "FramedSource" (because 
the implementation of "FramedSource" does not allow more than one 
object to read from a single "FramedSource").

However, is your input source accessible as a file (e.g., in /dev/)? 
If so, then you could probably just create two separate 
"ByteStreamFileSource" objects, each reading from this file.

If, however, your input source is not accessible as a file, then you 
would need to
	1/ Write a class (which would *not* be a "FramedSource" 
subclass to encapsulate it), and
	2/ Write a FramedSource subclass that encapsulates a single 
copy of data from the source.
This is nontrivial, but you could use the existing "MPEG1or2Demux" 
and "MPEG1or2DemuxedElementaryStream" code as a model, because this 
does something similar.


>   This has complications in the design of the FramedSource

Yes, but that's much simpler than hacking with the RTSP/RTP code.


>  and it duplicates the RTP framing and buffering.

That really doesn't matter at all.  You just create two "RTPSink" 
(subclass) objects instead of one.
-- 

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/20070719/5aa0007a/attachment.html 

From rupak.p at gmail.com  Fri Jul 20 00:00:16 2007
From: rupak.p at gmail.com (Rupak Patel)
Date: Fri, 20 Jul 2007 12:30:16 +0530
Subject: [Live-devel] First RTCP packet changing the current time to zero
Message-ID: <d84b766a0707200000u1572c3a4i3ade21bf7c41934d@mail.gmail.com>

Hi

While using Live555 as server and VLC player as client after the file starts
playing, the first RTCP packet makes the current time of the player to zero.
And then again the timer starts from zero. Thus, the real current time is 2
or 3 seconds more than the returned current time by the VLC player. Thus,
the slider after moving to certain distance again starts from zero.

Other players as clients don't show such behavior.

Has anyone using VLC player as client faced any such issue.

Thanks and regards,
Rupak.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070720/24794476/attachment.html 

From jps330 at psu.edu  Fri Jul 20 05:46:21 2007
From: jps330 at psu.edu (Jordan Shelley)
Date: Fri, 20 Jul 2007 08:46:21 -0400
Subject: [Live-devel] Streaming with Sensoray 2250 encoded data
In-Reply-To: <f06240808c2c29954d801@[66.80.62.44]>
Message-ID: <01MJ64PPUW8W8WWCO4@ponyexpress.arl.psu.edu>

Ross,

 

Thanks for your reply. I took your advice and worked on getting data written
to a file. I pretty much just added a FileSink object in and dropped my
Encoder2250 object into it. It worked perfectly. Now that this works, do you
have any advice for me to get it working over RTP? I'm sorry to bother you
with this, but this is part of a very important project and I don't exactly
know what to try since getting it to write to a file was so easy. I just
can't understand why the FileSink object was able to read my doGetNextFrame
function so easily and the RTPSink object cant. Thanks a lot.

 

-Jordan

 

  _____  

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, July 17, 2007 12:12 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Streaming with Sensoray 2250 encoded data

 

I am trying to stream video from a platform that has a Sensoray 2250 encoder
installed on it. I have already verified that all of the hardware works and
that data produced from it can be streamed using the live library by doing
the following:

*         Created a process that grabs MPEG2 frames from the encoder and
dumps them to a named pipe

*         Modified testMPEG1or2VideoStreamer to look at this pipe for data,
and stream it to a specified IP address

*         Works fine, except that, as you can image, there is some major
delay in the video which I cannot have due to the nature of what this video
stream is being used for.

 

You can probably eliminate most of this delay by reducing the maximum
buffering used by your pipe.  (I don't know how you would do this, but there
should be a way.)

 

This method - piping encoded data directly to the (modified)
"testMPEG1or2VideoStreamer" is *by far* the easiest way to get what you
want.  I recommend sticking with this approach if you can.

 

 

 

I decided to move on and write a FramedSource subclass that encapsulates my
encoder, and deliver this object directly to a MPEG1or2VideoRTPSink.

 

You should insert a "MPEG1or2VideoStreamDiscreteFramer" in front of your
"MPEG1or2VideoRTPSink".

 

 

The thing that is very odd is that it seems like my implementation of
doGetNextFrame() is never executed

 

You should first make sure that you can walk before you try to run.  I
suggest that you begin by trying to write your encoded data to a file rather
than streaming it over a network.  I.e., start by using a "FileSink" instead
of a "MPEG1or2VideoRTPSink".  Once you have shown that you can successfully
write your encoded data into a file (and test that the data is correct by
trying to play the file in a media player), then it would make sense to move
to streaming.

-- 


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/20070720/972c268c/attachment-0001.html 

From nantonop at orbitech.gr  Fri Jul 20 07:19:47 2007
From: nantonop at orbitech.gr (Nikos Antonopoulos)
Date: Fri, 20 Jul 2007 17:19:47 +0300
Subject: [Live-devel] MPEG2TransportStreamIndexer & h264 (cont)
Message-ID: <46A0C483.4040505@orbitech.gr>

Hi all, 

i've finally had the time to have a closer look at the indexer and some 
x264 specifics and i'm starting to feel lucky on getting the 1st cope with
the 2nd... However it'd be great if anyone could give me some more info:

Firstly, can u please verify i've got this straight and please excuse 
if i'm running long. i'd like to get this right :

For each TS packet the indexer retrieves some relevant timing info and stores an index record.
The indexer then copies the mpeg payload of the TS packet to a parse buffer,
and scans for bitstream codes (Video sequence start, GOPs and a default case
for all the rest - pictures, slices, the lot.). When an entire section has been found 
(000001XX - 000001YY) the indexer marks all corresponding index records with the appropriate
type (RECORD_VSH, RECORD_GOP, RECORD_PIC_NON_IFRAME, RECORD_PIC_IFRAME) 
and writes them (all index records available) to the index file before parsing again. 
I must admit i can't really see why the first indices of each section/frame are marked by 
( | 0x80 )... but anyhow! I also have a small gap of understanding as to why the indexer sometimes 
splits an index record in two...

Now, i believe i've understood how to parse the x264 stream. The code prefix is the same (00 00 01)
and i've found the stream (btw, i make my testfiles either w/ VLC or mencoder) to consist of:

1: Coded slice of a non-IDR picture
5: Coded slice of an IDR picture
7: Sequence parameter set
8: Picture parameter set

the stream is structured as: 7-8-5-1-1-...-1-7-8-5-1-1...

I understand that only the '5' elements (Coded slices of an IDR pic) hold indexing info. 
They are the equivalent of 'RECORD_PIC_IFRAME' type records for an mpeg1-2 file.

Ok, so would all this be adequate to make an index file? If so, i suppose that most
changes would go in function parseFrame(). But something i can't really see is what would
go in the type member of each index record. I suppose that a new enumeration of possible types
is needed but then would the user of the index file know what to do with the records?
Anything u think i'm missing here?

I'll try to stay on this and hopefully i will have a more complete picture (& hopefully some code to share) 
soon but any suggestions would be greatly appreciated...

sorry for the lengthy text...

many thanks
Nik


>>I've been trying to use trick play by creating an index file (using
>>MPEG2TransportStreamIndexer) for an MPEG-TS (h264/mp3) file.
>>I've has no luck with it - been getting an empty index file.
>>
>>I understand that the indexer is designed to work with mpeg1-2 files.
>>Question is whether I should spend some time into making this handle
>>h264 files as well. Would that be too difficult?


>It's on our "to do" list.  What makes it non-trivial is that the 
>index file generation code works by analyzing each of the video 
>frames in the Video Elementary Stream embedded within the Transport 
>Stream - in order to figure out which frames are 'key frames' (i.e., 
>I-frames), and where they are.  I.e., the indexing code would need to 
>know the structure of MPEG-4 video frames (just as it currently knows 
>about MPEG-2 video frames).




From jps330 at psu.edu  Fri Jul 20 08:38:27 2007
From: jps330 at psu.edu (Jordan Shelley)
Date: Fri, 20 Jul 2007 11:38:27 -0400
Subject: [Live-devel] Streaming with Sensoray 2250 encoded data
In-Reply-To: <f06240808c2c29954d801@[66.80.62.44]>
Message-ID: <01MJ6AQ2W3608WWCQ5@ponyexpress.arl.psu.edu>

Ross,

 

Don't worry about answering my last email, I was able to get the live code
working with my encoder. It works great, I appreciate all the work you have
done on this project. 

 

On another note, to you and everyone else that might see this email, does
anyone have any tips for optimizing latency when streaming live video
through this library? Now that I have my encoder working, I am getting video
on the client machine which is only delayed about 1-1.5 seconds from real
time. Any suggestions for optimizing it a little more? I am streaming to the
client wirelessly, but I have already tried it over a wired LAN, same delay
results. Thanks to anyone who can help.

 

-Jordan

 

  _____  

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, July 17, 2007 12:12 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Streaming with Sensoray 2250 encoded data

 

I am trying to stream video from a platform that has a Sensoray 2250 encoder
installed on it. I have already verified that all of the hardware works and
that data produced from it can be streamed using the live library by doing
the following:

*         Created a process that grabs MPEG2 frames from the encoder and
dumps them to a named pipe

*         Modified testMPEG1or2VideoStreamer to look at this pipe for data,
and stream it to a specified IP address

*         Works fine, except that, as you can image, there is some major
delay in the video which I cannot have due to the nature of what this video
stream is being used for.

 

You can probably eliminate most of this delay by reducing the maximum
buffering used by your pipe.  (I don't know how you would do this, but there
should be a way.)

 

This method - piping encoded data directly to the (modified)
"testMPEG1or2VideoStreamer" is *by far* the easiest way to get what you
want.  I recommend sticking with this approach if you can.

 

 

 

I decided to move on and write a FramedSource subclass that encapsulates my
encoder, and deliver this object directly to a MPEG1or2VideoRTPSink.

 

You should insert a "MPEG1or2VideoStreamDiscreteFramer" in front of your
"MPEG1or2VideoRTPSink".

 

 

The thing that is very odd is that it seems like my implementation of
doGetNextFrame() is never executed

 

You should first make sure that you can walk before you try to run.  I
suggest that you begin by trying to write your encoded data to a file rather
than streaming it over a network.  I.e., start by using a "FileSink" instead
of a "MPEG1or2VideoRTPSink".  Once you have shown that you can successfully
write your encoded data into a file (and test that the data is correct by
trying to play the file in a media player), then it would make sense to move
to streaming.

-- 


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/20070720/c86c959f/attachment.html 

From aviadr1 at gmail.com  Sun Jul 22 07:27:35 2007
From: aviadr1 at gmail.com (aviad rozenhek)
Date: Sun, 22 Jul 2007 17:27:35 +0300
Subject: [Live-devel] creating a simple RTP server
Message-ID: <cae870a70707220727y3d8dcb58nff18f515bea10e27@mail.gmail.com>

Hi,

I have media in some unknown format, but already divided into frames, cached
in memory.
I want to start streaming immediately to a known client ip/port.

how do I do this as easily as possible? what are the minimum stuff to setup
and implement?

thanks
Aviad Rozenhek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070722/e5b0136a/attachment.html 

From finlayson at live555.com  Sun Jul 22 16:51:41 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 22 Jul 2007 18:51:41 -0500
Subject: [Live-devel] creating a simple RTP server
In-Reply-To: <cae870a70707220727y3d8dcb58nff18f515bea10e27@mail.gmail.com>
References: <cae870a70707220727y3d8dcb58nff18f515bea10e27@mail.gmail.com>
Message-ID: <f06240801c2c99d670f7c@[66.80.62.44]>

>I have media in some unknown format, but already divided into 
>frames, cached in memory.
>I want to start streaming immediately to a known client ip/port.

Sorry, but RTP payload formats (network packing rules) are designed 
for specific media types.  If you don't know the format of your 
media, then you can't stream it using RTP (and can't stream it using 
the "LIVE555 Streaming Media" software).

Are you *sure* that you don't know anything about the format of your media?

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From ymreddy at ssdi.sharp.co.in  Sun Jul 22 22:42:01 2007
From: ymreddy at ssdi.sharp.co.in (Mallikharjuna Reddy (NAVT))
Date: Mon, 23 Jul 2007 11:12:01 +0530
Subject: [Live-devel] pauseMediaSession
Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB01D8D9EC@KABEX01.sharpamericas.com>

Hi Everybody,

 

We are using latest LIVE555 streaming media server and client. We would
like to test pause functionality from client side. Where can I call this


pauseMediaSession () function in the client side during streaming.

 

Thanks and Regards

Y. Mallikharjuna Reddy

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070722/47506854/attachment-0001.html 

From morgan.torvolt at gmail.com  Mon Jul 23 05:47:44 2007
From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=)
Date: Mon, 23 Jul 2007 14:47:44 +0200
Subject: [Live-devel] Lost packets
In-Reply-To: <f06240804c2c29597f7a7@66.80.62.44>
References: <BAY126-W179F4C149CB361D9959B73C4080@phx.gbl>
	<D6DDE2706695D34F8263D17DD29606D9AD5813@BBSC-EX01.bbsconnect.ca>
	<D6DDE2706695D34F8263D17DD29606D9AD5816@BBSC-EX01.bbsconnect.ca>
	<f06240804c2c29597f7a7@66.80.62.44>
Message-ID: <3cc3561f0707230547p110fec1eo796eb60fd1669e6b@mail.gmail.com>

Could not this be added very easily using a singleton? This would make
the data accessible anywhere, and not demand any change to the API.

-Morgan-

On 17/07/07, Ross Finlayson <finlayson at live555.com> wrote:
> >  Is there a reason why this is the current design?
>
> Because the details of the underlying transport protocol (in this
> case, RTP) are intended to be transparent to higher-level software.
>
> There are no plans to change the current API.
>
> --
>
> 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
>

From finlayson at live555.com  Mon Jul 23 05:49:47 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 23 Jul 2007 07:49:47 -0500
Subject: [Live-devel] pauseMediaSession
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB01D8D9EC@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB01D8D9EC@KABEX01.sharpamericas.com>
Message-ID: <f06240803c2ca53fe630d@[66.80.62.44]>

>We are using latest LIVE555 streaming media server and client. We 
>would like to test pause functionality from client side. Where can I 
>call this
>pauseMediaSession () function in the client side during streaming.

Any time while the stream is playing - i.e., sometime after "PLAY", 
and before "TEARDOWN".
-- 

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/20070723/95993567/attachment.html 

From nantonop at orbitech.gr  Mon Jul 23 07:15:04 2007
From: nantonop at orbitech.gr (Nikos Antonopoulos)
Date: Mon, 23 Jul 2007 17:15:04 +0300
Subject: [Live-devel] buffered RTSP to multiple clients
Message-ID: <46A4B7E8.9060802@orbitech.gr>

Hi,

I've been trying to get RTSP streaming to work though a buffer. I am 
using a named pipe filled by mencoder.
My aim is to have multiple clients viewing the "stream". I've tried 
using the 'testOnDemandRTSPServer' from the
testProgs directory and set the reuseFirstSource flag to true.

// To make the second and subsequent client for each stream reuse the same
// input stream as the first client (rather than playing the file from the
// start for each client), change the following "False" to "True":
Boolean reuseFirstSource = True     // was False

I have been trying to view the stream though an mplayer client and 
through an STB. Regardless of which goes first it connects and gets the 
stream nicely. The 2nd (either mplayer or STB) however can't connect 
properly and the reported problem "out of date/stray packets" or similar.
However, this DOES work as expected with 2 mplayer clients...

Any clues why that is would be most welcome...

thanks in advance
Nik


From aviadr1 at gmail.com  Mon Jul 23 10:02:37 2007
From: aviadr1 at gmail.com (aviad rozenhek)
Date: Mon, 23 Jul 2007 20:02:37 +0300
Subject: [Live-devel] creating a simple RTP server
Message-ID: <cae870a70707231002v781d7722rb3d85e049b87ea52@mail.gmail.com>

>
> >>I have media in some unknown format, but already divided into
> >>frames, cached in memory.
> >>I want to start streaming immediately to a known client ip/port.
>
> >Sorry, but RTP payload formats (network packing rules) are designed
> >for specific media types.  If you don't know the format of your
> >media, then you can't stream it using RTP (and can't stream it using
> >the "LIVE555 Streaming Media" software).
>
> >Are you *sure* that you don't know anything about the format of your
> media?



ok then, suppose I know what media type it is, for instance h263+ or mpeg2
or whatever is easiest to converse about.
further suppose that they media is not coming from file, but rather it is
handed out to me, already divided into frames.

I wish to properly package them in RTP and send them to a known RTP client,
who is already listening and waiting for the packets.

The live555 library already has a XXXframer class for the codec, but do I
really need it, after all, its already framed ...
how do I go about implementing the a ServerMediaSubsession class?
or should I use PassiveServerMediaSubsession instead?

Thanks
Aviad Rozenhek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070723/aab88750/attachment.html 

From fherna04 at harris.com  Mon Jul 23 12:30:04 2007
From: fherna04 at harris.com (Hernandez, Fernando)
Date: Mon, 23 Jul 2007 15:30:04 -0400
Subject: [Live-devel] openRTSP's CPU Usage
Message-ID: <4C1EB210CB4D784D89E9B4858CF5DE8B08B6B5@mlbe2k5.cs.myharris.net>

Hello,

I am running openRTSP to test a streaming server and am running into
some CPU usage problems.  The client is a 533 MHz PowerPC machine with
256 MB RAM running Linux.  Apparently the client is not powerful enough
for openRTSP, as every time I run it see 99.9% CPU usage by openRTSP and
there is anywhere from 10 - 30% packet loss.  I have eliminated the
server as the source of the problem, as streaming the same file to a
more powerful Linux computer or a windows PC using VLC results in no
problems.

My question is two-fold:  How feasible will it be to modify openRTSP to
not eat up so much CPU, and where should I look to make the changes?
The video file is a 10 megabit/sec video file (1.25 megabyte/sec), and
you'd figure a 500 MHz machine could handle such a stream without such
dramatic CPU usage?

Thanks!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070723/6b56a22e/attachment.html 

From finlayson at live555.com  Mon Jul 23 13:01:50 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 23 Jul 2007 15:01:50 -0500
Subject: [Live-devel] creating a simple RTP server
In-Reply-To: <cae870a70707231002v781d7722rb3d85e049b87ea52@mail.gmail.com>
References: <cae870a70707231002v781d7722rb3d85e049b87ea52@mail.gmail.com>
Message-ID: <f06240804c2cab86e35ac@[66.80.62.44]>

>  >Are you *sure* that you don't know anything about the format of your media?
>
>
>
>ok then, suppose I know what media type it is, for instance h263+ or 
>mpeg2 or whatever is easiest to converse about.
>further suppose that they media is not coming from file, but rather 
>it is handed out to me, already divided into frames.
>
>I wish to properly package them in RTP and send them to a known RTP 
>client, who is already listening and waiting for the packets.
>
>The live555 library already has a XXXframer class for the codec, but 
>do I really need it, after all, its already framed ...

No, you shouldn't need a "*Framer" class, provided that you provide 
accurate presentation times for each frame.  (Note, though, that if 
you have MPEG-2 video with B-frames, then the presentation times will 
*not* be monotonically increasing.  If you don't understand what I 
mean by this, then you should use a 
"MPEG1or2VideoStreamDiscreteFramer" with MPEG-2 video.)

>how do I go about implementing the a ServerMediaSubsession class?

Just use the existing "*FileServerMediaSubsession" class as a model.

Of course, you will also need to write your own "FramedSource" 
subclass that encapsultes your data source - delivering one frame at 
a time.  See the "DeviceSource.cpp" code for a model.

>or should I use PassiveServerMediaSubsession instead?

"PassiveServerMediaSubsession" is used only for multicast streams.
-- 

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/20070723/a766576c/attachment.html 

From jnitin at ssdi.sharp.co.in  Mon Jul 23 21:28:10 2007
From: jnitin at ssdi.sharp.co.in (Nitin Jain)
Date: Tue, 24 Jul 2007 09:58:10 +0530
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request in
	openrtsp
Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>

Hi all,

We are using openRTSP Client to receive mpeg2 streams. When we call PAUSE and then PLAY request during streaming then 
 we observed function getResponse1() is getting called from two places simultaneously i.e.

1 ) from inside getResponse("PAUSE", bytesRead, responseCode, firstLine, nextLineStart) in pauseMediaSession() in RTSPClient.cpp

2)  bytesRead = getResponse1(readBuf, fResponseBufferSize) in incomingRequestHandler1() in RTSPClient.cpp.

Hence we cannot play the stream again after pausing because the readSocket call is blocking in getResponse1() function.


unsigned bytesReadNow   = readSocket(envir(), fInputSocketNum,  (unsigned char*)(responseBuffer+bytesRead),  1, fromAddress);


Please provide your feedback why its happening or we need to call the  pauseMediaSession()  function from some where else.

Thanks and Regards
Nitin 






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070723/39f5e71a/attachment.html 

From finlayson at live555.com  Tue Jul 24 03:06:53 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Jul 2007 05:06:53 -0500
Subject: [Live-devel] openRTSP's CPU Usage
In-Reply-To: <4C1EB210CB4D784D89E9B4858CF5DE8B08B6B5@mlbe2k5.cs.myharris.net>
References: <4C1EB210CB4D784D89E9B4858CF5DE8B08B6B5@mlbe2k5.cs.myharris.net>
Message-ID: <f06240800c2cb7ee5b41d@[66.80.62.44]>

>I am running openRTSP to test a streaming server and am running into 
>some CPU usage problems.  The client is a 533 MHz PowerPC machine 
>with 256 MB RAM running Linux.  Apparently the client is not 
>powerful enough for openRTSP, as every time I run it see 99.9% CPU 
>usage by openRTSP and there is anywhere from 10 - 30% packet loss. 
>I have eliminated the server as the source of the problem, as 
>streaming the same file to a more powerful Linux computer or a 
>windows PC using VLC results in no problems.
>
>My question is two-fold:  How feasible will it be to modify openRTSP 
>to not eat up so much CPU, and where should I look to make the 
>changes?  The video file is a 10 megabit/sec video file (1.25 
>megabyte/sec), and you'd figure a 500 MHz machine could handle such 
>a stream without such dramatic CPU usage?

Yes, you'd figure...

For me, one important piece of information in your message was that 
you are seeing packet loss.  See the following message
	http://lists.live555.com/pipermail/live-devel/2007-May/006798.html
for a tip on how to increase the internal buffering that your OS uses 
when receiving incoming network packets.  That might help.

Otherwise, I can't tell you why you are experiencing 100% CPU, as the 
"openRTSP" reception code is basically quite simple: Just sit in a 
loop, running "select()" on incoming network sockets.  You're going 
to have to track this down yourself.  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/20070724/01846409/attachment-0001.html 

From finlayson at live555.com  Tue Jul 24 03:19:12 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Jul 2007 05:19:12 -0500
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request in
 openrtsp
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
Message-ID: <f06240801c2cb7fecf194@[66.80.62.44]>

>We are using openRTSP Client to receive mpeg2 streams. When we call 
>PAUSE and then PLAY request during streaming then
>  we observed function getResponse1() is getting called from two 
>places simultaneously

No. Remember that the code is single-threaded.  It is not possible 
for "getResponse1()" - or any other function - to be called from two 
places 'simultaneously'.

What I suspect is happening is that you have requested RTP-over-TCP - 
i.e., using the "-t" command-line option to "openRTSP".  There is 
currently a known bug in the code that - iff you have requested 
RTP-over-TCP - any response to a RTSP command - after the initial 
"PLAY" command(s) - is not read by the RTSP client code.  Therefore, 
iff you have requested RTP-over-TCP, then you currently can't do a 
RTSP "PAUSE" (because you won't then be able to send a subsequent 
"PLAY" to restart the stream).

(With regular, RTP-over-UDP, streaming, there are no known problems 
with sending "PAUSE" (or other) commands during streaming.)
-- 

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/20070724/67019c98/attachment.html 

From and at faonet.com  Tue Jul 24 08:38:23 2007
From: and at faonet.com (Andrey Kaminsky)
Date: Tue, 24 Jul 2007 18:38:23 +0300
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request
	in	openrtsp
In-Reply-To: <f06240801c2cb7fecf194@[66.80.62.44]>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
	<f06240801c2cb7fecf194@[66.80.62.44]>
Message-ID: <1185291504.23131.18.camel@and.faonet.com>

On Tue, 2007-07-24 at 05:19 -0500, Ross Finlayson wrote:
> > We are using openRTSP Client to receive mpeg2 streams. When we call
> > PAUSE and then PLAY request during streaming then
> >  we observed functiongetResponse1() is getting called from two
> > places simultaneously
> 
> 
> No. Remember that the code is single-threaded.  It is not possible for
> "getResponse1()" - or any other function - to be called from two
> places 'simultaneously'.
> 
I found the same things. live.2007.04.24a

in file RTSPClient.cpp: function

Boolean RTSPClient::playMediaSession(MediaSession& session,
                                     float start, float end, float
scale) {
................
line 1096
    if (fTCPStreamIdCount == 0) { // we're not receiving RTP-over-TCP
      // Arrange to handle incoming requests sent by the server

envir().taskScheduler().turnOnBackgroundReadHandling(fInputSocketNum,

(TaskScheduler::BackgroundHandlerProc*)&incomingRequestHandler, this);
    }

If you comment out this code block, than you can always resume from
 pause. Otherwise this is like a russian roulette :-). 

getResponse -> getResponse1 -> (pause/resume okey)
OR
incomingRequestHandler -> incomingRequestHandler1 -> getResponse1 ->
you are blocked in select

Regards
Andrey Kaminsky




From finlayson at live555.com  Tue Jul 24 10:54:03 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Jul 2007 12:54:03 -0500
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request
 in	openrtsp
In-Reply-To: <1185291504.23131.18.camel@and.faonet.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
	<f06240801c2cb7fecf194@[66.80.62.44]>
	<1185291504.23131.18.camel@and.faonet.com>
Message-ID: <f06240804c2cbeb14f4f3@[66.80.62.44]>

>On Tue, 2007-07-24 at 05:19 -0500, Ross Finlayson wrote:
>>  > We are using openRTSP Client to receive mpeg2 streams. When we call
>>  > PAUSE and then PLAY request during streaming then
>>  >  we observed functiongetResponse1() is getting called from two
>>  > places simultaneously
>>
>  >
>>  No. Remember that the code is single-threaded.  It is not possible for
>>  "getResponse1()" - or any other function - to be called from two
>>  places 'simultaneously'.
>>
>I found the same things. live.2007.04.24a
>
>in file RTSPClient.cpp: function
>
>Boolean RTSPClient::playMediaSession(MediaSession& session,
>                                      float start, float end, float
>scale) {
>................
>line 1096
>     if (fTCPStreamIdCount == 0) { // we're not receiving RTP-over-TCP
>       // Arrange to handle incoming requests sent by the server
>
>envir().taskScheduler().turnOnBackgroundReadHandling(fInputSocketNum,
>
>(TaskScheduler::BackgroundHandlerProc*)&incomingRequestHandler, this);
>     }
>
>If you comment out this code block, than you can always resume from
>  pause. Otherwise this is like a russian roulette :-).
>
>getResponse -> getResponse1 -> (pause/resume okey)
>OR
>incomingRequestHandler -> incomingRequestHandler1 -> getResponse1 ->
>you are blocked in select

 From what I can tell, the second case should not be happening, 
because the "pauseMediaS(ubs)ession()"  function does synchronous 
I/O, and does not enter the event loop.  ("incomingRequestHandler()" 
is called only from within the event loop.)   I.e., if you call 
"pauseMediaS(ubs)ession()", you'll sent the "PAUSE" command, and then 
wait for and read the subsequent response - without any problem.

(Nonetheless, as I noted earlier, this currently works only for 
RTP-over-UDP streaming, not RTP-over-TCP.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From and at faonet.com  Tue Jul 24 12:09:23 2007
From: and at faonet.com (Andrey Kaminsky)
Date: Tue, 24 Jul 2007 22:09:23 +0300
Subject: [Live-devel] Problem in sending PAUSE and then PLAY
	request	in	openrtsp
In-Reply-To: <f06240804c2cbeb14f4f3@[66.80.62.44]>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
	<f06240801c2cb7fecf194@[66.80.62.44]>
	<1185291504.23131.18.camel@and.faonet.com>
	<f06240804c2cbeb14f4f3@[66.80.62.44]>
Message-ID: <1185304163.23131.55.camel@and.faonet.com>

On Tue, 2007-07-24 at 12:54 -0500, Ross Finlayson wrote:
> >On Tue, 2007-07-24 at 05:19 -0500, Ross Finlayson wrote:
> >>  > We are using openRTSP Client to receive mpeg2 streams. When we call
> >>  > PAUSE and then PLAY request during streaming then
> >>  >  we observed functiongetResponse1() is getting called from two
> >>  > places simultaneously
> >>
> >  >
> >>  No. Remember that the code is single-threaded.  It is not possible for
> >>  "getResponse1()" - or any other function - to be called from two
> >>  places 'simultaneously'.
> >>
> >I found the same things. live.2007.04.24a
> >
> >in file RTSPClient.cpp: function
> >
> >Boolean RTSPClient::playMediaSession(MediaSession& session,
> >                                      float start, float end, float
> >scale) {
> >................
> >line 1096
> >     if (fTCPStreamIdCount == 0) { // we're not receiving RTP-over-TCP
> >       // Arrange to handle incoming requests sent by the server
> >
> >envir().taskScheduler().turnOnBackgroundReadHandling(fInputSocketNum,
> >
> >(TaskScheduler::BackgroundHandlerProc*)&incomingRequestHandler, this);
> >     }
> >
> >If you comment out this code block, than you can always resume from
> >  pause. Otherwise this is like a russian roulette :-).
> >
> >getResponse -> getResponse1 -> (pause/resume okey)
> >OR
> >incomingRequestHandler -> incomingRequestHandler1 -> getResponse1 ->
> >you are blocked in select
> 
>  From what I can tell, the second case should not be happening, 
> because the "pauseMediaS(ubs)ession()"  function does synchronous 
> I/O, and does not enter the event loop.  ("incomingRequestHandler()" 
> is called only from within the event loop.)   I.e., if you call 
> "pauseMediaS(ubs)ession()", you'll sent the "PAUSE" command, and then 
> wait for and read the subsequent response - without any problem.

Ok, Ross. You are designer, and you know this code much better.

We are trying to implement udp streaming server (up to 16 jpeg video
 streams per client) and client application to recieve and visualise
 this streams. And I had problem with pauseMediaSubsession and resume
paused subsessions (playMediaSubsession) with client subsessions lockups
sometimes in pauseMediaSubsession call, sometimes in playMediaSubsession
 call (to resume paused subsessions), sometimes without subsessions
 lockups. And I had tracked problem to this  piece of code. After I had
 commented out this block, I had 100% success with this functions. 
May be this is due my incorrect library use. But this work for me
 without any problem. live555 is live now!!!
Thanx for Your work.

And additional patches against live.2007.04.24a, to prevent segfaults.

diff -u JPEGVideoRTPSink.cpp /usr/src/RPM/BUILD/live/liveMedia/
--- JPEGVideoRTPSink.cpp        2007-04-24 12:38:22.000000000 +0300
+++ /usr/src/RPM/BUILD/live/liveMedia/JPEGVideoRTPSink.cpp
2007-04-26 15:54:47.000000000 +0300
@@ -60,13 +60,15 @@
   mainJPEGHeader[1] = fragmentationOffset >> 16;
   mainJPEGHeader[2] = fragmentationOffset >> 8;
   mainJPEGHeader[3] = fragmentationOffset;
-  mainJPEGHeader[4] = source->type();
-  mainJPEGHeader[5] = source->qFactor();
-  mainJPEGHeader[6] = source->width();
-  mainJPEGHeader[7] = source->height();
+  if (source != NULL) {
+    mainJPEGHeader[4] = source->type();
+    mainJPEGHeader[5] = source->qFactor();
+    mainJPEGHeader[6] = source->width();
+    mainJPEGHeader[7] = source->height();
+  }
   setSpecialHeaderBytes(mainJPEGHeader, sizeof mainJPEGHeader);

-  if (fragmentationOffset == 0 && source->qFactor() >= 128) {
+  if (source != NULL && fragmentationOffset == 0 && source->qFactor()
>= 128) {
     // There is also a Quantization Header:
     u_int8_t precision;
     u_int16_t length;
@@ -108,7 +110,7 @@

   unsigned headerSize = 8; // by default

-  if (curFragmentationOffset() == 0 && source->qFactor() >= 128) {
+  if (source != NULL && curFragmentationOffset() == 0 &&
source->qFactor() >= 128) {
     // There is also a Quantization Header:
     u_int8_t dummy;
     u_int16_t quantizationTablesSize;


Regards
Andrey Kaminsky




From jnitin at ssdi.sharp.co.in  Wed Jul 25 00:15:40 2007
From: jnitin at ssdi.sharp.co.in (Nitin Jain)
Date: Wed, 25 Jul 2007 12:45:40 +0530
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request
Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563214@KABEX01.sharpamericas.com>

Hi all,

Thanks for all the feedback .
I agree with with Ross that it  is not possible for  "getResponse1()" - or any other function - to be called from two places  simultaneously .
.It was my  mistake to call pauseMediaSession() from different thread  instead of  from regular doeventloop()  in our program.
PAUSE and  then  PLAY is working absolutely fine now in case of  RTP-over UDP.
Thanks and Regards
Nitin .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070725/1ec32e5f/attachment.html 

From finlayson at live555.com  Wed Jul 25 01:08:52 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 25 Jul 2007 03:08:52 -0500
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB563214@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563214@KABEX01.sharpamericas.com>
Message-ID: <f06240800c2ccb569c759@[66.80.62.44]>

>.It was my  mistake to call pauseMediaSession() from different thread

Sigh... How many times do I need to remind people to read the FAQ?!
-- 

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/20070725/d8548526/attachment.html 

From finlayson at live555.com  Wed Jul 25 01:41:43 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 25 Jul 2007 03:41:43 -0500
Subject: [Live-devel] Problem in sending PAUSE and then PLAY request
 in	openrtsp
In-Reply-To: <1185304163.23131.55.camel@and.faonet.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563212@KABEX01.sharpamericas.com>
	<f06240801c2cb7fecf194@[66.80.62.44]>
	<1185291504.23131.18.camel@and.faonet.com>
	<f06240804c2cbeb14f4f3@[66.80.62.44]>
	<1185304163.23131.55.camel@and.faonet.com>
Message-ID: <f06240801c2ccbcf78c8e@[66.80.62.44]>

>And additional patches against live.2007.04.24a, to prevent segfaults.


Thanks.  I have added this to the latest release of the software.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From rruthe02 at harris.com  Thu Jul 26 07:27:31 2007
From: rruthe02 at harris.com (Rutherford, Robert)
Date: Thu, 26 Jul 2007 10:27:31 -0400
Subject: [Live-devel] openRTSP -r -p
Message-ID: <505F93C737C4B647A0007D96439B71770268F178@mlbe2k7.cs.myharris.net>

Ross,

We are trying to determine the bottleneck in playback of streamed MPEG2
on our PPC Linux system.  When running openRTSP with no arguments, we
see poor throughput because the CPU is running at 100%
(http://lists.live555.com/pipermail/live-devel/2007-July/007238.html).
To get around this, we are using openRTSP with the -r and -p options
(openRTSP -r -p 20006 rtsp://192.168.1.9:8554/path/video.ts) and
receiving the RTP data with a separate application (just receiving it,
counting how much we receive, and throwing it away).  However, at 45
seconds, our RTP streaming stops (consistently).  The video file is
definitely longer than this (and works properly without -r -p).  We
believe it may be related to the server not receiving some sort of
heartbeat (maybe via RTCP).  Can you offer insight in to what might be
happening?

Thanks,
Rob Rutherford
Harris Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070726/ebe37b6d/attachment-0001.html 

From finlayson at live555.com  Thu Jul 26 07:43:34 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Jul 2007 09:43:34 -0500
Subject: [Live-devel] openRTSP -r -p
In-Reply-To: <505F93C737C4B647A0007D96439B71770268F178@mlbe2k7.cs.myharris.net>
References: <505F93C737C4B647A0007D96439B71770268F178@mlbe2k7.cs.myharris.net>
Message-ID: <f06240800c2ce6254ac05@[66.80.62.44]>

>To get around this, we are using openRTSP with the -r and -p options 
>(openRTSP -r -p 20006 rtsp://192.168.1.9:8554/path/video.ts) and 
>receiving the RTP data with a separate application (just receiving 
>it, counting how much we receive, and throwing it away).  However, 
>at 45 seconds, our RTP streaming stops (consistently).  The video 
>file is definitely longer than this (and works properly without -r 
>-p).  We believe it may be related to the server not receiving some 
>sort of heartbeat (maybe via RTCP).

That's exactly what's happening.  The server apparently uses RTCP 
"RR" packets - from the receiver - as a liveness indication.  If it 
doesn't receive these, it assumes that the receiver has died, and it 
times out the session.

If your RTSP server uses our implementation, then you can modify it 
to disable this timeout by setting the "reclamationTestSeconds" 
parameter from 45 to 0.  (E.g., if you are using the "LIVE555 Media 
Server", then see "DynamicRTSPServer.cpp", line 44.)

Alternatively, of course, you could add RTCP to your reception application.
-- 

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/20070726/7bf7df52/attachment.html 

From aviadr1 at gmail.com  Thu Jul 26 08:18:00 2007
From: aviadr1 at gmail.com (aviad rozenhek)
Date: Thu, 26 Jul 2007 18:18:00 +0300
Subject: [Live-devel] H264 save to file
Message-ID: <cae870a70707260818n91b04cdr7a663d4d44a38df@mail.gmail.com>

Hi,

I am using openRTSP to connect to wirecast, which provides an H264 video
stream (with no audio).
looking at the code and at the packet it seems that everything works ok,
except that I have found no way of playing back the file ...

what can I do to have the easiest sanity check to see if the media was
streamed correctly?
I thought of using ffmpeg to properly write the coded packets to file, but I
am having problems with setting up the lib...
can you think of a better idea?

thanks
Aviad Rozenhek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070726/121ead7c/attachment.html 

From steve2021 at walla.com  Thu Jul 26 08:18:15 2007
From: steve2021 at walla.com (=?windows-1255?Q?=73=74=65=76=65=20=63=68=6F=65=6E?=)
Date: Thu, 26 Jul 2007 18:18:15 +0300
Subject: [Live-devel] =?windows-1255?q?muticast_stream?=
Message-ID: <1185463094.961000-51485606-12054@walla.com>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070726/86b93ee7/attachment.html 

From wills_71 at yahoo.com  Thu Jul 26 08:29:32 2007
From: wills_71 at yahoo.com (William Chung-How)
Date: Thu, 26 Jul 2007 16:29:32 +0100 (BST)
Subject: [Live-devel] RTP Elementary Stream to RTP Transport Stream
Message-ID: <448682.71462.qm@web31605.mail.mud.yahoo.com>

Hi

I'm trying to receive an RTP Elementary Stream and encapsulate that into a RTP Transport Stream on another multicast address and port number.

I used the testMPEG1or2VideoReceiver as a starting point and have 2 problems.

========================
If I change the input source from a file to a RTP ES, by using MPEG1or2VideoRTPSource and then use SimpleRTPSink to transmit out, I get the error
 BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor

=========================
I am not able to encapsulate an ES that is read from a file  into an RTP Transport Stream. I changed the sink to a FileSink and when playing back the file, the video jumps several frames on VLC. I have tried this with different ES sources and get the same result. Any ideas what steps is missing?

I modified the testMPEG1or2VideoReceiver function play as shown below

void play() {
  // Open the input file as a 'byte-stream file source':
  ByteStreamFileSource* fileSource
    = ByteStreamFileSource::createNew(*env, inputFileName);
  if (fileSource == NULL) {
    *env << "Unable to open file \"" << inputFileName
     << "\" as a byte-stream file source\n";
    exit(1);
  }
  
  FramedSource* videoES;
  // The input source is assumed to already be a Video Elementary Stream:
  videoES = fileSource;
  // Insert MPEG1or2VideoStreamFramer
  MPEG1or2VideoStreamFramer* framer = MPEG1or2VideoStreamFramer::createNew(*env, videoES,
                          False, 5.0);

  // Add ES to TS
  MPEG2TransportStreamFromESSource * pESSource =
        MPEG2TransportStreamFromESSource::createNew(*env);
  
  pESSource->addNewVideoSource(framer, 2);
   MPEG2TransportStreamFramer * tsVideoSource = MPEG2TransportStreamFramer::createNew(*env, pESSource);
  
  // Finally, start playing:
  *env << "Beginning to read from file...\n";
  videoSink->startPlaying(*tsVideoSource, afterPlaying, NULL);
}

Thanks for your help

William

       
---------------------------------
 Yahoo! Answers - Get better answers from someone who knows. Tryit now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070726/b2155e73/attachment.html 

From finlayson at live555.com  Thu Jul 26 08:48:22 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Jul 2007 10:48:22 -0500
Subject: [Live-devel] muticast stream
In-Reply-To: <1185463094.961000-51485606-12054@walla.com>
References: <1185463094.961000-51485606-12054@walla.com>
Message-ID: <f06240802c2ce7252e7df@[66.80.62.44]>

>Hi Everyone,
>
I'm using the "PasssiveServerMediaSubsession" to stream multicast.

>But i'm little confused, Where can i decide who will get the stream?

I don't really understand your question.  Because your stream is 
multicast, any RTSP client that plays it will receive the same 
stream.  (Provided, of course, that multicast routing exists between 
the server and these clients.)

>I don't want to broadcast the stream, i want only predefined clients 
>to play it.

Multicast is not broadcast.  If you multicast a stream, then only 
those clients that ask to receive the stream will receive it.
-- 

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/20070726/23f2898b/attachment.html 

From bleary at harris.com  Thu Jul 26 13:57:53 2007
From: bleary at harris.com (Leary, Brent)
Date: Thu, 26 Jul 2007 16:57:53 -0400
Subject: [Live-devel] MPEG2TransportStreamIndexer Question
Message-ID: <E7191752EF4FAD498FD0E968F7A7DAF72B7AE6@mlbe2k5.cs.myharris.net>

Ross,
Within the MPEG2TransportStreamIndexer's main, is there an existing
class that could replace the ByteStreamFileSource that would receive its
video data off a UDP socket instead of reading from a file?  

"FramedSource* input = ByteStreamFileSource::createNew(*env,
inputFileName, TRANSPORT_PACKET_SIZE);"

Thanks,
-Brent

From finlayson at live555.com  Thu Jul 26 14:19:02 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Jul 2007 16:19:02 -0500
Subject: [Live-devel] MPEG2TransportStreamIndexer Question
In-Reply-To: <E7191752EF4FAD498FD0E968F7A7DAF72B7AE6@mlbe2k5.cs.myharris.net>
References: <E7191752EF4FAD498FD0E968F7A7DAF72B7AE6@mlbe2k5.cs.myharris.net>
Message-ID: <f06240802c2cebfe5a066@[66.80.62.44]>

>Within the MPEG2TransportStreamIndexer's main, is there an existing
>class that could replace the ByteStreamFileSource that would receive its
>video data off a UDP socket instead of reading from a file?

IMHO, it doesn't make any sense to apply the indexing algorithm to 
anything but a file, because
	1/ You want the input data to be exactly the same when you 
later *use* the index file, and
	2/ When you later use the index file, you will need to be 
able to seek within it.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From devendra.banker at gmail.com  Thu Jul 26 22:40:31 2007
From: devendra.banker at gmail.com (devendra banker)
Date: Fri, 27 Jul 2007 11:10:31 +0530
Subject: [Live-devel] MPEG 2 TS streaming at pre encoded bit rate over LAN
Message-ID: <fde71e130707262240x3ef12271j90e31b5dbae5ab7e@mail.gmail.com>

Dear all,

Hope every one is doing gr888.....
I happen to face some problems and hope with the help of u guys would be
able to find it solved...

Say i have one MPEG 2 TS stream ( stream1.ts encoded at 5.00 Mbps) ..and now
i want to transmit it over lan at 5.00 Mbps.

problem 1  : how do i get to know the bit rate from given TS stream?
                 does it entirely depend on PCR distance..i.e for every .1
sec i would get PCR and after that i can find out how many
                packets  in 1 sec ..and this tells me bit rate???
                it this is the case then how does other formats like MPEG 4,
MP3 gets streamed..I am not sure abt PCRs for them..
                so sorry for that??
                 does this mean that if i have corrupted PCR..the streaming
would have problems?

problem 2 : how does a single program find out ..how many TS packets should
go in one set ..and the time between them..
                 using bit rate i can find out ..but why 7 packets in the
ethernet packet..is it because of frame size??

Problem 3 : Please suggest some tutorial which actually explains in depth of
streaming.i checked on web..but not able to get
                  hold of tutorial for MPEG 2 streaming.

Thank you very much....

Devendra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070726/5b97354a/attachment-0001.html 

From Ambra.Cristaldi at elsagdatamat.com  Fri Jul 27 02:03:42 2007
From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra)
Date: Fri, 27 Jul 2007 11:03:42 +0200
Subject: [Live-devel] ".mp4","m4e","TS" recording and streaming
Message-ID: <268315E5844A704AB431589863FE8EEFBADD14@els00wmx04.elsag.it>

 

Hi all,

I'm working with live555 library to do a client-server application, for
recording and streaming rtsp video flows.

I read in your forum and documentation that live555 can stream ".m4e"
video file, but not ".mp4". 

However, if I produce ".mp4" files, setting the flag "-4" in the
openRTSP program (as I read in the documentation), I can still stream it
using both VLC and "live555MediaServer.exe" application. Is it possible?
There is any incoherence in this? 

Finally, my last question is: is it possible recording in ".ts"
container, with MPEG-4 encoding?

 

Thanks a lot.

 

--------------------

Ambra Cristaldi

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070727/2081e6be/attachment.html 

From finlayson at live555.com  Fri Jul 27 02:20:16 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 04:20:16 -0500
Subject: [Live-devel] ".mp4","m4e","TS" recording and streaming
In-Reply-To: <268315E5844A704AB431589863FE8EEFBADD14@els00wmx04.elsag.it>
References: <268315E5844A704AB431589863FE8EEFBADD14@els00wmx04.elsag.it>
Message-ID: <f06240801c2cf68624070@[66.80.62.44]>

>I'm working with live555 library to do a client-server application, 
>for recording and streaming rtsp video flows.
>I read in your forum and documentation that live555 can stream 
>".m4e" video file, but not ".mp4".
>However, if I produce ".mp4" files, setting the flag "-4" in the 
>openRTSP program (as I read in the documentation), I can still 
>stream it using both VLC and "live555MediaServer.exe" application. 
>Is it possible?

No.  The "LIVE555 Streaming Media" code currently does not contain 
any mechanism for *reading* (and thus streaming) ".mp4"-format files.

>Finally, my last question is: is it possible recording in ".ts" 
>container, with MPEG-4 encoding?

It *might* be possible, using either the 
"MPEG2TransportStreamFromESSource" class, or (more likely) some new 
subclass of "MPEG2TransportStreamMultiplexor", similar to the 
existing "MPEG2TransportStreamFromESSource" class.  I haven't 
investigated this in detail, though.
-- 

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/20070727/ccc78e49/attachment.html 

From finlayson at live555.com  Fri Jul 27 02:24:38 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 04:24:38 -0500
Subject: [Live-devel] MPEG 2 TS streaming at pre encoded bit rate over
 LAN
In-Reply-To: <fde71e130707262240x3ef12271j90e31b5dbae5ab7e@mail.gmail.com>
References: <fde71e130707262240x3ef12271j90e31b5dbae5ab7e@mail.gmail.com>
Message-ID: <f06240802c2cf69a38b8b@[66.80.62.44]>

>Say i have one MPEG 2 TS stream ( stream1.ts encoded at 5.00 Mbps) 
>..and now i want to transmit it over lan at 5.00 Mbps.
>
>problem 1  : how do i get to know the bit rate from given TS stream?

Our software does this automatically for you (using the 
"MPEG2TransportStreamFramer" class).  E.g., just use our existing 
"testMPEG2TransportStreamer" demo application (for muilticast 
streaming), or "testOnDemandRTSPServer" or "live555MediaServer" 
applications (for unicast streaming).

ps. This mailing list is specifically for questions about the 
"LIVE555 Streaming Media" software, not for general questions about 
the MPEG Transport Stream format.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From Ambra.Cristaldi at elsagdatamat.com  Fri Jul 27 05:31:20 2007
From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra)
Date: Fri, 27 Jul 2007 14:31:20 +0200
Subject: [Live-devel] openRTSP-recording both audio and video?
Message-ID: <268315E5844A704AB431589863FE8EEFBADDAE@els00wmx04.elsag.it>

Hi Ross,

 

First of all, thanks for having answered to my last email.

I have another question to make: can openRTSP record ".mp4" multiple
Elementary Streams files (i.e. with audio and video), or just ".m4e"
Elementary Stream files (with only audio or video, not both)?

In fact, I still don't understand if, using openRTSP application, I can
both record audio and video signals, and save it as ".mp4". 

I read in documentation that we can set the appropriate flags: "-v" to
play only video stream, "-a" to play only the audio stream, or "-y" to
synchronize audio and video tracks (at the moment, unfortunately, I have
no camera to record audio track, so I can't do any tests, right now. I
hope I will soon).

So, I've played the OpenRTSP with these parameters:  "-4 -e90 TLC-url >
FileName.mp4"

to stream from an AXIS Camera (without audio, only video) and I've
recorded the stream into that ".mp4" file (the flag -4 means that I
build an mp4 container, doesn't it?). Then, using the test-program
"live555MediaServer.exe", I've streamed it through my LAN and received
it with a VLC RTSP Client. And it works. 

So, this is my doubt: as you told me that Live555 streams only m4e
files, I think that OpenRTSP save the stream only in a *m4e* format. Is
it right? Or does it work only because I've used an *audioless* camera?

 

Thanks a lot, 

 

--------------------

Ambra Cristaldi

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070727/5d32461f/attachment.html 

From bleary at harris.com  Fri Jul 27 05:39:53 2007
From: bleary at harris.com (Leary, Brent)
Date: Fri, 27 Jul 2007 08:39:53 -0400
Subject: [Live-devel] MPEG2TransportStreamIndexer Question
In-Reply-To: <f06240802c2cebfe5a066@[66.80.62.44]>
References: <E7191752EF4FAD498FD0E968F7A7DAF72B7AE6@mlbe2k5.cs.myharris.net>
	<f06240802c2cebfe5a066@[66.80.62.44]>
Message-ID: <E7191752EF4FAD498FD0E968F7A7DAF72B7AEB@mlbe2k5.cs.myharris.net>

Ross,
The video data being received over the socket would need to be written
to a file as well as sent to the indexing object. It can't be written to
a file first & then indexed b/c the server may need to play the video
data immediately after its finished being received over the socket.
What interfaces does deriving from a FramedSource impose on a class? I'm
guessing by your response that something along the lines of a
ByteStreamSocketSource would need to be created from scratch? Is there
anything close to this already to start from?

Thanks,
-Brent

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, July 26, 2007 5:19 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MPEG2TransportStreamIndexer Question

>Within the MPEG2TransportStreamIndexer's main, is there an existing
>class that could replace the ByteStreamFileSource that would receive
its
>video data off a UDP socket instead of reading from a file?

IMHO, it doesn't make any sense to apply the indexing algorithm to 
anything but a file, because
	1/ You want the input data to be exactly the same when you 
later *use* the index file, and
	2/ When you later use the index file, you will need to be 
able to seek within it.
-- 

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

From finlayson at live555.com  Fri Jul 27 06:34:40 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 08:34:40 -0500
Subject: [Live-devel] MPEG2TransportStreamIndexer Question
In-Reply-To: <E7191752EF4FAD498FD0E968F7A7DAF72B7AEB@mlbe2k5.cs.myharris.net>
References: <E7191752EF4FAD498FD0E968F7A7DAF72B7AE6@mlbe2k5.cs.myharris.net>
	<f06240802c2cebfe5a066@[66.80.62.44]>
	<E7191752EF4FAD498FD0E968F7A7DAF72B7AEB@mlbe2k5.cs.myharris.net>
Message-ID: <f06240803c2cfa2ce4236@[66.80.62.44]>

>The video data being received over the socket would need to be written
>to a file as well as sent to the indexing object.

Is your incoming Transport Stream data (received over a socket) raw 
data, rather than RTP-encapsulated data?  If so, I would just handle 
this using pipes and (e.g.) the Unix "tee" and "nc" commands - then 
you could use the existing "ByteStreamFileSource" object, but with a 
'file name' of "stdin".

E.g., run
	nc some-params | tee your-output-file-name | your-indexer-program

However, if you *insist* on using a "FramedSource" subclass for your 
input, then should use "BasicUDPSource" if your data is raw data, and 
a "SimpleRTPSource" if it's RTP-encapsulated data.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Fri Jul 27 06:39:18 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 08:39:18 -0500
Subject: [Live-devel] openRTSP-recording both audio and video?
In-Reply-To: <268315E5844A704AB431589863FE8EEFBADDAE@els00wmx04.elsag.it>
References: <268315E5844A704AB431589863FE8EEFBADDAE@els00wmx04.elsag.it>
Message-ID: <f06240804c2cfa552d909@[66.80.62.44]>

>I have another question to make: can openRTSP record ".mp4" multiple 
>Elementary Streams files (i.e. with audio and video), or just ".m4e" 
>Elementary Stream files (with only audio or video, not both)?
>In fact, I still don't understand if, using openRTSP application, I 
>can both record audio and video signals, and save it as ".mp4".

Yes - that's what the "-4" option does.  Please read the documentation.

>So, I've played the OpenRTSP with these parameters:  "-4 -e90 
>TLC-url > FileName.mp4"
>to stream from an AXIS Camera (without audio, only video) and I've 
>recorded the stream into that ".mp4" file (the flag -4 means that I 
>build an mp4 container, doesn't it?).

Yes.

>Then, using the test-program "live555MediaServer.exe", I've streamed 
>it through my LAN and received it with a VLC RTSP Client. And it 
>works.

No it won't.  The "live555MediaServer" aplication *cannot* currently 
stream MPEG-4 format files (and doesn't even understand the ".mp4" 
file name suffix).  You are mistaken.
-- 

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/20070727/b2a04adc/attachment.html 

From Ambra.Cristaldi at elsagdatamat.com  Fri Jul 27 07:03:30 2007
From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra)
Date: Fri, 27 Jul 2007 16:03:30 +0200
Subject: [Live-devel] openRTSP-recording both audio and video?
Message-ID: <268315E5844A704AB431589863FE8EEFBADDEC@els00wmx04.elsag.it>

 

You're right. I'm sorry, I forgot to say that I've streamed the file using "live555MediaServer", after having changed its extension and renamed itself from ".mp4" in ".m4e". And it works, perhaps because I have no audio right now, but just video- information. However, finally I understand the reason of this "incoherence".

Best regards.

 

--------------------

Ambra Cristaldi

 

________________________________

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: venerd? 27 luglio 2007 15.39
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] openRTSP-recording both audio and video?

 

	I have another question to make: can openRTSP record ".mp4" multiple Elementary Streams files (i.e. with audio and video), or just ".m4e" Elementary Stream files (with only audio or video, not both)?

	In fact, I still don't understand if, using openRTSP application, I can both record audio and video signals, and save it as ".mp4".

 

Yes - that's what the "-4" option does.  Please read the documentation.

 

	So, I've played the OpenRTSP with these parameters:  "-4 -e90 TLC-url > FileName.mp4"

	to stream from an AXIS Camera (without audio, only video) and I've recorded the stream into that ".mp4" file (the flag -4 means that I build an mp4 container, doesn't it?).


Yes.

	Then, using the test-program "live555MediaServer.exe", I've streamed it through my LAN and received it with a VLC RTSP Client. And it works.

 

No it won't.  The "live555MediaServer" aplication *cannot* currently stream MPEG-4 format files (and doesn't even understand the ".mp4" file name suffix).  You are mistaken.

-- 


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/20070727/ec670fe6/attachment.html 

From finlayson at live555.com  Fri Jul 27 07:17:48 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 09:17:48 -0500
Subject: [Live-devel] openRTSP-recording both audio and video?
In-Reply-To: <268315E5844A704AB431589863FE8EEFBADDEC@els00wmx04.elsag.it>
References: <268315E5844A704AB431589863FE8EEFBADDEC@els00wmx04.elsag.it>
Message-ID: <f06240805c2cfaeb3729b@[66.80.62.44]>

>You're right. I'm sorry, I forgot to say that I've streamed the file 
>using "live555MediaServer", after having changed its extension and 
>renamed itself from ".mp4" in ".m4e".

If that works at all, then it's only by accident - because the MPEG-4 
video parsing code skips over the MPEG-4 file format-specific headers 
at the beginning of the file.  That certainly won't work if the 
MPEG-4 file contains audio as well as video.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From jnitin at ssdi.sharp.co.in  Fri Jul 27 07:32:35 2007
From: jnitin at ssdi.sharp.co.in (Nitin Jain)
Date: Fri, 27 Jul 2007 20:02:35 +0530
Subject: [Live-devel] Problem in sending  RTSP  Requests from media server
Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563218@KABEX01.sharpamericas.com>

Hi all,

I am sending GET_PARAMETER and SET_PARAMETER RTSP requests from the server after it receives PLAY  to to the openRTSP Client. But I observed that when i do PLAY and PAUSE  then  instead of getting PAUSE response  pauseMediaSession  is getting SET/GET Parameter  request .

 But the incoming request should be processed in the incomingRequestHandler and not in pauseMediaSesion().

Do I need to modify the code to support this feature or it will be handled in the current code ?

Regards
Nitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070727/1b7f480b/attachment.html 

From finlayson at live555.com  Fri Jul 27 07:47:27 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Jul 2007 09:47:27 -0500
Subject: [Live-devel] Problem in sending RTSP Requests from media server
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB563218@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563218@KABEX01.sharpamericas.com>
Message-ID: <f06240806c2cfb597103e@[66.80.62.44]>

>I am sending GET_PARAMETER and SET_PARAMETER RTSP requests from the server

I don't recommend doing this.

As you noticed, our current RTSP client code doesn't handle this 
well.  It will eventually be fixed to handle all incoming RTSP data 
asynchronously - but until this is done, I don't recommend sending 
commands from the server.
-- 

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/20070727/0b0b835f/attachment.html 

From dmaljur at elma.hr  Mon Jul 30 00:06:11 2007
From: dmaljur at elma.hr (Dario maljur)
Date: Mon, 30 Jul 2007 09:06:11 +0200
Subject: [Live-devel] Streaming MPEG4 from live network camera
Message-ID: <005501c7d278$1fa69db0$1201000a@DARIO>

Hi all.

Can someone give me instructions on how this is done.

I red in FAQ that i can change test*streamer.cpp to do this, by changing
test*streamer.cpp file.

But this is pretty confusing, couse it says that I can use the name of that
file instead of test*???

I don't understand that.

Basically my system is representing network camera as a file named something
like:

rtsp://100.1.1.21:554/mpeg4/nmedia.amp

So how can I use this information to receive stream from that device. And i
even don't know where to start.

Any info, or pointers are welcome.

Thanks.




ELMA Kurtalj d.o.o. (ELMA Kurtalj ltd.)
Vitezi?eva 1a, 10000 Zagreb, Hrvatska (Viteziceva 1a, 10000 Zagreb, Croatia)
Tel: 01/3035555, Faks: 01/3035599 (Tel: ++385-1-3035555, Fax: ++385-1-3035599 )

Www:
www.elma.hr; shop.elma.hr

E-mail:
elma at elma.hr (elma at elma.hr)
pitanje at elma.hr (questions at elma.hr)
primjedbe at elma.hr (complaints at elma.hr)
prodaja at elma.hr (sales at elma.hr)
servis at elma.hr (servicing at elma.hr)
shop at elma.hr (shop at elma.hr)
skladiste at elma.hr (warehouse at elma.hr)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070730/f6be3006/attachment-0001.html 

From Chen.Li2 at boeing.com  Mon Jul 30 07:34:41 2007
From: Chen.Li2 at boeing.com (Li, Chen)
Date: Mon, 30 Jul 2007 07:34:41 -0700
Subject: [Live-devel] UDP Instead of TCP
Message-ID: <FBE587797E2D164EA422C24856583F340200A2F9@XCH-SW-2V1.sw.nos.boeing.com>

Hey,

Looking through the code while trying to build from scratch a custom
rtsp command sender, it seems the libraries that come with Live555
utilize TCP and are base64 encoded.  Is there a way to transport
commands UDP and have the server respond?  If so, could you please point
me to the source code?  So far, I have traced the send command to down
to the library and only found a TCP implementation.

If the server does not support receiving commands over UDP, please let
me know.

Thank you,

--Chen Li

From Chen.Li2 at boeing.com  Mon Jul 30 07:54:10 2007
From: Chen.Li2 at boeing.com (Li, Chen)
Date: Mon, 30 Jul 2007 07:54:10 -0700
Subject: [Live-devel] Case Sensitive Server Handling of Commands
Message-ID: <FBE587797E2D164EA422C24856583F340200A2FA@XCH-SW-2V1.sw.nos.boeing.com>

Hello,

After doing some tests using LabView, it appears the server is case
sensitive.  Such as rtsp/1.0 must be RTSP/1.0 and Cseq must be Cseq.
Why is this?  And will future versions be able to account for this?

Thanks,

--Chen Li

From finlayson at live555.com  Mon Jul 30 18:44:58 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 30 Jul 2007 21:44:58 -0400
Subject: [Live-devel] Case Sensitive Server Handling of Commands
In-Reply-To: <FBE587797E2D164EA422C24856583F340200A2FA@XCH-SW-2V1.sw.nos.boeing.com>
References: <FBE587797E2D164EA422C24856583F340200A2FA@XCH-SW-2V1.sw.nos.boeing.com>
Message-ID: <f06240800c2d443fde0fe@[66.80.62.44]>

>After doing some tests using LabView, it appears the server is case
>sensitive.  Such as rtsp/1.0 must be RTSP/1.0 and Cseq must be Cseq.
>Why is this?

Basically, laziness on my part. (A lot of the input parsing is done 
using "sscanf()" - which is case sensitive - because it was easy to 
do that way.)

>   And will future versions be able to account for this?

Quite possibly (but I can't give you an ETA).
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From finlayson at live555.com  Tue Jul 31 04:15:39 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 31 Jul 2007 07:15:39 -0400
Subject: [Live-devel] UDP Instead of TCP
In-Reply-To: <FBE587797E2D164EA422C24856583F340200A2F9@XCH-SW-2V1.sw.nos.boeing.com>
References: <FBE587797E2D164EA422C24856583F340200A2F9@XCH-SW-2V1.sw.nos.boeing.com>
Message-ID: <f06240808c2d4c9c25964@[66.80.62.44]>

>Looking through the code while trying to build from scratch a custom
>rtsp command sender, it seems the libraries that come with Live555
>utilize TCP

RTSP (the control protocol) always uses TCP.  RTP (the audio/video 
data protocol) can use either UDP (the default), or TCP.

>  and are base64 encoded.

No, BASE-64 encoding is used only for RTSP-over-HTTP tunneling, not 
for the normal RTSP-over-TCP protocol

>   Is there a way to transport
>commands UDP and have the server respond?

No.  Noone ever implements RTSP-over-UDP (which was mentioned in the 
original RTSP specification), and it has been removed from the latest 
version of the RTSP specification.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

From noamatari at yahoo.com  Tue Jul 31 06:21:18 2007
From: noamatari at yahoo.com (Noam Camiel)
Date: Tue, 31 Jul 2007 06:21:18 -0700 (PDT)
Subject: [Live-devel] issue with a streaming server having multiple network
	interfaces
Message-ID: <900003.99079.qm@web53305.mail.re2.yahoo.com>

hi,

i would like to report an issue regarding running a live555 streaming server when more than one network interface is available.

this issue is relevant for unicast connections such as in example testOnDemandRTSPServer in the test programs.

symptom:  when connecting through a virtual lan to the streaming server, the streaming to the client is stopped after approx. 40 seconds due to reported inactivity from the server.

details: suppose the streaming server has ip address 192.168.1.205 and the server has another virtual address 100.100.100.1.  When the RTSP server is initiated, its url is rtsp://192.168.1.205:8554/testStream.
Now suppose a connection to the server is made through a machine on the other network 100.100.100.30 using rtsp://100.100.100.1:8554/testStream.
The streaming is started and works but after about 40 seconds the streaming stops and a message from the server is printed that the stream is stopped due to inactivity (using VLC viewer).

analysis: after looking into the subject, it looks like on the responses in the rtsp protocol for the 100.100.100.* network, the 192.168.1.205 address is used for content body and information and various other places.   As a result, the keepalive that is supposed to be sent back to address 100.100.100.1 is being returned to 192.168.1.205 and therefore not received by the server, hence idle client is detected.

solution: the current RTSPServer implementation holds a single url for the server (see RTSPServer::rtspURL) .  Instead i used a connection per session ( RTSPServer::RTSPClientSession::rtspURL), which is determined from the request received from the client.  This url is determined for each session in the incoming request handler for DESCRIBE command, as received in the RTSPServer::RTSPClientSession::incomingRequestHandler1() method.  The server then responds to each client using the specific url information for that client, hence solving the above problem.

if anyone has comments regarding this issue please send them.
thanks
noam camiel






       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/

From qinghai.gan2 at mail.dcu.ie  Tue Jul 31 07:04:40 2007
From: qinghai.gan2 at mail.dcu.ie (qinghai.gan2 at mail.dcu.ie)
Date: Tue, 31 Jul 2007 15:04:40 +0100
Subject: [Live-devel] Live555 Proxy
Message-ID: <469A51A40000CB2B@hawk.dcu.ie>

Dear Madam/Sir

 I am a master student from Dublin City University, Ireland. I want to develop
a multi-source proxy use these libraries. Should I change the code in packet
level or session level?  Can you help me with some hints or sample source
code? 

Thanks.

Qing Hai



From xqma at marvell.com  Tue Jul 31 19:33:02 2007
From: xqma at marvell.com (Xianqing Ma)
Date: Tue, 31 Jul 2007 19:33:02 -0700
Subject: [Live-devel] About Streaming MP4 through RTSP
Message-ID: <7F6B283111E9EB4BA570D4C0322C8EEE0B1060@sc-exch04.marvell.com>

Hi:

       The live555 media server supports the format of MPEG4 Elementary
Stream. But I do not know what the m4e file is. 

The mp4 files that I have with the suffix of mp4 cannot be streamed by
live555. (I tested it by VLC). I used MediaInfo to check the format of
these files and found that they are composed of the MPEG4 Visual
(Video), AAC (Audio) or H264 (Video), AAC (Audio).

How can I stream these files? Does the live555 media server support the
format? If not, how can I get the m4e files?

Thank you!

 

Best regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070731/002fe311/attachment.html 

From finlayson at live555.com  Tue Jul 31 22:31:07 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 1 Aug 2007 00:31:07 -0500
Subject: [Live-devel] About Streaming MP4 through RTSP
In-Reply-To: <7F6B283111E9EB4BA570D4C0322C8EEE0B1060@sc-exch04.marvell.com>
References: <7F6B283111E9EB4BA570D4C0322C8EEE0B1060@sc-exch04.marvell.com>
Message-ID: <f06240801c2d5caba04ba@[66.80.62.44]>

>        The live555 media server supports the format of MPEG4 
>Elementary Stream. But I do not know what the m4e file is.

A MPEG-4 Elementary Stream (as defined by the MPEG-4 video standard 
(ISO_IEC_14496-2)).

>The mp4 files that I have with the suffix of mp4 cannot be streamed 
>by live555. (I tested it by VLC). I used MediaInfo to check the 
>format of these files and found that they are composed of the MPEG4 
>Visual (Video), AAC (Audio) or H264 (Video), AAC (Audio).
>How can I stream these files? Does the live555 media server support 
>the format?

No, not at present.

>  If not, how can I get the m4e files?

Please read the FAQ!
-- 

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/20070731/68f7d0f7/attachment.html 

From shaswata at alumnux.com  Tue Jul 31 22:42:19 2007
From: shaswata at alumnux.com (Shaswata Jash)
Date: Wed, 1 Aug 2007 11:12:19 +0530
Subject: [Live-devel] About Streaming MP4 through RTSP
In-Reply-To: <7F6B283111E9EB4BA570D4C0322C8EEE0B1060@sc-exch04.marvell.com>
References: <7F6B283111E9EB4BA570D4C0322C8EEE0B1060@sc-exch04.marvell.com>
Message-ID: <004001c7d3fe$b9e5d670$2e0aa8c0@alumnusshas>

You can always extract MPEG4 Video elementary stream out of .mp4 using some
tool like Mpeg4IP. These tools extract the video elementary stream as .m4v -
just rename it as 'test.m4e' for live555.

Darwin Streaming Server (DSS) is one such server which can stream .mp4
files.

 

  _____  

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Xianqing Ma
Sent: Wednesday, August 01, 2007 8:03 AM
To: live-devel at ns.live555.com
Subject: [Live-devel] About Streaming MP4 through RTSP

 

Hi:

       The live555 media server supports the format of MPEG4 Elementary
Stream. But I do not know what the m4e file is. 

The mp4 files that I have with the suffix of mp4 cannot be streamed by
live555. (I tested it by VLC). I used MediaInfo to check the format of these
files and found that they are composed of the MPEG4 Visual (Video), AAC
(Audio) or H264 (Video), AAC (Audio).

How can I stream these files? Does the live555 media server support the
format? If not, how can I get the m4e files?

Thank you!

 

Best regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070731/5cbc4ed8/attachment-0001.html