From finlayson at live555.com  Fri Jun  1 00:11:52 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 00:11:52 -0700
Subject: [Live-devel] live-devel Digest, Vol 43, Issue 24
In-Reply-To: <7EAD1AEEA7621C45899FE99123E124A0E02D53@dbde01.ent.ti.com>
References: <7EAD1AEEA7621C45899FE99123E124A0E02D53@dbde01.ent.ti.com>
Message-ID: <f06240806c2857323989c@[66.80.62.44]>

Here's the problem:

>Opened URL "rtsp://172.24.141.104:554/Video/edit.mpg", returning a SDP
>description:
>v=0
>o=- 3389626461 0 IN IP4 0.0.0.0
>s=Video RTSP Server
>t=3389626461 0
>m=video 0 RTP/AVP 33
>a=rtpmap:33 H264/90000
>a=control:rtsp://172.24.141.104:554/Video/edit.mpg
>a=range:npt=0.0-144.159

Your server is explicitly saying that your stream lasts 144.159 
seconds.  Therefore "openRTSP", by default, records only for that 
length of time.

If you want to (try to) record for a longer period of time, then you 
can do so using the "-e <endTime>" option.
-- 

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

From julian.lamberty at mytum.de  Fri Jun  1 01:15:42 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Fri, 01 Jun 2007 10:15:42 +0200
Subject: [Live-devel] UDP checksum wrong
Message-ID: <465FD5AE.1000501@mytum.de>

Hi!

Since my transcoder now transcodes I have a new problem:

I deliver complete MPEG4 Frames to MPEG4VideoStreamDiscreteFramer 
followed by MPEG4ESVideoRTPSink.
But all the packets sent have a wrong UDP checksum. Wireshark reports 
that a lot of subsequent UDP packets have the SAME checksum. For example:

...
Checksum: 0xb63d [incorrect, should be 0x9e8c]
Checksum: 0xb63d [incorrect, should be 0x9e8b]
Checksum: 0xb63d [incorrect, should be 0x9e8a]
Checksum: 0xb63d [incorrect, should be 0x9e89]
...

Additionally all the packets do have the same Length (347 in the example 
above).
It also seems strange that the correct checksum should decrease by 0x1 
for each packet. What's the problem here? How can that be?

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070601/52e93158/attachment.bin 

From julian.lamberty at mytum.de  Fri Jun  1 04:05:41 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Fri, 01 Jun 2007 13:05:41 +0200
Subject: [Live-devel]  UDP checksum wrong
Message-ID: <465FFD85.8000806@mytum.de>

Sorry, my fault ;) You should not run wireshark on the same computer 
that sends the packets...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070601/9b27e442/attachment.bin 

From lartc at manchotnetworks.net  Fri Jun  1 04:42:36 2007
From: lartc at manchotnetworks.net (lartc)
Date: Fri, 01 Jun 2007 13:42:36 +0200
Subject: [Live-devel] UDP checksum wrong
In-Reply-To: <465FFD85.8000806@mytum.de>
References: <465FFD85.8000806@mytum.de>
Message-ID: <1180698156.5587.1.camel@sumatra.radius.fr>

this "error" can also occur when your the checksum process is offloaded
and performed by the network adapter ...



On Fri, 2007-06-01 at 13:05 +0200, Julian Lamberty wrote:
> Sorry, my fault ;) You should not run wireshark on the same computer 
> that sends the packets...
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
-- 
"simplified chinese" is not nearly as easy as they would
have you believe ... a superlative oxymoron" --anonymous


From finlayson at live555.com  Fri Jun  1 04:53:14 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 04:53:14 -0700
Subject: [Live-devel] UDP checksum wrong
In-Reply-To: <465FD5AE.1000501@mytum.de>
References: <465FD5AE.1000501@mytum.de>
Message-ID: <f06240808c285b8e23fb5@[66.80.62.44]>

UDP checksumming is done by the OS or network adaptor, and has 
absolutely nothing to do with the "LIVE555 Streaming Media" code, 
which runs above all of this.
-- 

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

From severin.schoepke at gmail.com  Fri Jun  1 07:08:24 2007
From: severin.schoepke at gmail.com (Severin Schoepke)
Date: Fri, 01 Jun 2007 16:08:24 +0200
Subject: [Live-devel] Synchronizing audio and video streams
In-Reply-To: <f06240800c27ced9fe534@[66.80.62.44]>
References: <46571067.6040101@gmail.com> <f06240800c27ced9fe534@[66.80.62.44]>
Message-ID: <46602858.7030603@gmail.com>

Hello again,

I'm referring to the following mail:


I'm working on an application that streams live generated content (audio 
and video) using the Darwin Streamnig Server. I decided to use ffmpeg 
for the encoding part and live555 for the streaming part. The basic 
architecture is as follows: In a first thread I generate the content, 
and in a second one I stream the content to the DSS. Data is passed 
between the threads using two buffers.
I implemented two FramedSource subclasses for the streaming part, one 
for audio and one for video data. Both work as follows: They read raw 
data from their input buffer and encode it using ffmpeg (using MPEG4 and 
MP2 codecs) and write to their output buffers (fTo). My sources are then 
connected to an MPEG4VideoStreamFramer and an MPEG1or2AudioStreamFramer 
respectively. These are connected to a DarwinInjector (based on the code 
of testMPEG4VideoToDarwin).
The problem I have now is that the streams are not synchronized when 
viewing them (using QuickTime or VLC). Based on debug printf's I found 
out that the audio source's doGetNextFrame() is called much more that 
the video source's. Therefore, the audio stream is played ahead and the 
video stream is lagging behind.
I set correct presentation times for both streams, so I thought that 
live555 does 'the rest' synchronizing the streams, but it seems not to 
work. Therefore I'd like to ask you if I should implement a 
synchronization of the streams by myself, or if I'm doing something 
wrong...
I followed your suggestion and tried it using your server...


I got an answer:

Ross Finlayson schrieb:
> We're no longer providing support for the "DarwinInjector" code. 
> Instead, we recommend that you use our own RTSP server 
> implementation, rather than a separate "Darwin Streaming Server".
>   


So I tried to use your RTSP server but it didn't change the situation. 
My streams are still diverting. I investigated the problem further and 
fond out, that live555 queries my sound source much more often than it 
queries the video source. I suspect it has something to do with data 
size: my audio source provides only about 300 bytes per invocation, 
whereas the video source provides between 3000 and 8000bytes per 
invocation (I'm referring to a call of doGetNextFrame() as an 
invocation). I suspect that live555 waits with streaming out video until 
it has aboout the same size of audio data. This way, my audio source 
gets polled about 10 times as much as the video source, even though it 
can only provide about twice as much frames than the video source...
I know, the above sounds a bit strange and is not very clear, but I hope 
someone understands what I mean and I hope that this person tells me 
wether this behaviour is to be expected and how I could change it.

cheers, Severin


From finlayson at live555.com  Fri Jun  1 12:53:52 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 12:53:52 -0700
Subject: [Live-devel] Synchronizing audio and video streams
In-Reply-To: <46602858.7030603@gmail.com>
References: <46571067.6040101@gmail.com>
	<f06240800c27ced9fe534@[66.80.62.44]> <46602858.7030603@gmail.com>
Message-ID: <f0624080cc28629336088@[66.80.62.44]>

>So I tried to use your RTSP server but it didn't change the situation.
>My streams are still diverting. I investigated the problem further and
>fond out, that live555 queries my sound source much more often than it
>queries the video source. I suspect it has something to do with data
>size

No, that shouldn't matter.  If you (ii) give your data (audio and 
video) accurate presentation times (the "fPresentationTime" variable) 
- tied to the local 'wall clock' time (e.g., using "gettimeofday()"), 
and (ii) use RTCP (by creating "RTCPInstance" objects for each 
"RTPSink"), then audio/video sync *will* work correctly at the client 
end.
-- 

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

From mjn at oxysys.com  Fri Jun  1 13:34:57 2007
From: mjn at oxysys.com (Marc Neuberger)
Date: Fri, 01 Jun 2007 16:34:57 -0400
Subject: [Live-devel] Performance
Message-ID: <466082F1.9050409@oxysys.com>

A couple of months ago, there was a discussion of performance of the 
live555 libraries on Linux, and the discussion turned to the efficiency 
of select() vs. epoll().

Studying the performance my own epoll()-based scheduler, I strongly 
suspect that the far bigger source of inefficiency is the DelayQueue 
implementation that BasicTaskScheduler0 uses. This queue is a linked 
list, causing O(n) cost to adding and deleting timers. Which happens a 
lot. If I understand the behavior correctly, a 45-second idle timer is 
rescheduled on each packet. This almost invariably goes to the end of 
the scheduling queue.

With the stock code, I had results similar to Vlad Seyakov's: I petered 
out at about 140-150 sessions. With my rewritten scheduler, I've been 
able to get to 400-500 sessions. My scheduling queue is based on an STL 
set<> with an appropriate less-than operator. This provides O(log n) 
insert/delete. Even so, I find that scheduling and unscheduling timers 
accounts for approximately 1/3 of the CPU at 400 sessions.

I made one other observation: readSocket() in GroupsockHelper.cpp calls 
blockUntilReadable(). blockUntilReadable() uses select() to wait for the 
socket to be ready. This has two problems: first, we really shouldn't 
ever be blocking, since this blocks all sessions: if the data isn't 
ready, we should go back to the event loop. This should happen rarely, 
if ever, of course, since presumably we're only calling this after a 
select()/epoll() has triggered. The larger problem is that the use of 
select() a server to 1024 file descriptors unless you override the size 
of fd_sets in your build, and that of course, creates a performance 
degradation. Architecturally is seems a little harder to replace parts 
of groupsock than to replace parts of UsageEnvironment to make changes 
like this.


Marc Neuberger


From finlayson at live555.com  Fri Jun  1 14:09:46 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 14:09:46 -0700
Subject: [Live-devel] Performance
In-Reply-To: <466082F1.9050409@oxysys.com>
References: <466082F1.9050409@oxysys.com>
Message-ID: <f06240811c28637adc515@[66.80.62.44]>

>Studying the performance my own epoll()-based scheduler, I strongly
>suspect that the far bigger source of inefficiency is the DelayQueue
>implementation that BasicTaskScheduler0 uses. This queue is a linked
>list, causing O(n) cost to adding and deleting timers. Which happens a
>lot. If I understand the behavior correctly, a 45-second idle timer is
>rescheduled on each packet.

No, that's not correct.  The RTSP server implementation's 'liveness 
check' timer gets rescheduled only after the receipt of an incoming 
*RTCP packet* (or an incoming RTSP command) - not on every (or any) 
outgoing packet.

>With the stock code, I had results similar to Vlad Seyakov's: I petered
>out at about 140-150 sessions. With my rewritten scheduler, I've been
>able to get to 400-500 sessions. My scheduling queue is based on an STL
>set<> with an appropriate less-than operator. This provides O(log n)
>insert/delete.

I'd be happy to consider replacing the current DelayQueue 
implementation with something that performs better with large number 
of tasks (with relatively small number of tasks, the existing 
implementation shoud be OK).  However, I don't want to use the STL, 
because I don't want to make the "LIVE555 Streaming Media" dependent 
upon it (because I want this code to continue to be useful for (e.g.) 
embedded systems that are relatively memory constrained, or which 
might not have the STL available for other reasons).

>I made one other observation: readSocket() in GroupsockHelper.cpp calls
>blockUntilReadable(). blockUntilReadable() uses select() to wait for the
>socket to be ready. This has two problems: first, we really shouldn't
>ever be blocking, since this blocks all sessions: if the data isn't
>ready, we should go back to the event loop.

Yes.  Unfortunately there are still a few places in the code where we 
want to do a synchronous (blocking) read on a socket.  To handle that 
case, we include the "select()" call in "readSocket()", even though 
it's usually (i.e., for asynchronous reading) a no-op.

At some point, I should get rid of these (few) remaining blocking 
socket reads, and remove the "select()" call from "readSocket()". 
Actually, as you're just running a RTSP server, you can probably 
remove the "select()" call right now.  You could give that a try, to 
see if it improves performance on your system.
-- 

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

From mjn at oxysys.com  Fri Jun  1 14:59:47 2007
From: mjn at oxysys.com (Marc Neuberger)
Date: Fri, 01 Jun 2007 17:59:47 -0400
Subject: [Live-devel] Performance
In-Reply-To: <f06240811c28637adc515@[66.80.62.44]>
References: <466082F1.9050409@oxysys.com> <f06240811c28637adc515@[66.80.62.44]>
Message-ID: <466096D3.3070002@oxysys.com>

Ross Finlayson wrote:
> No, that's not correct.  The RTSP server implementation's 'liveness 
> check' timer gets rescheduled only after the receipt of an incoming 
> *RTCP packet* (or an incoming RTSP command) - not on every (or any) 
> outgoing packet.
>   
Ah good, that makes a great deal more sense.
> However, I don't want to use the STL, 
> because I don't want to make the "LIVE555 Streaming Media" dependent 
> upon it (because I want this code to continue to be useful for (e.g.) 
> embedded systems that are relatively memory constrained, or which 
> might not have the STL available for other reasons).
>   
Yeah, that makes sense, too. I certainly wouldn't attempt to write the 
equivalent of the STL class (a Red-Black tree) myself. I agree that the 
current implementation is perfectly fine for most uses. Largely, I'm 
offering a tip to others that may find themselves in my situation about 
where to look for performance.
> At some point, I should get rid of these (few) remaining blocking 
> socket reads, and remove the "select()" call from "readSocket()". 
> Actually, as you're just running a RTSP server, you can probably 
> remove the "select()" call right now.  You could give that a try, to 
> see if it improves performance on your system.
>   
Yes, I did this. The figures of 400-500 sessions I quoted had the call 
to blockUntilReadable commented out.

Marc Neuberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070601/c6b8dd8b/attachment.html 

From mjn at oxysys.com  Fri Jun  1 15:00:48 2007
From: mjn at oxysys.com (Marc Neuberger)
Date: Fri, 01 Jun 2007 18:00:48 -0400
Subject: [Live-devel] RTCP socket blocking
Message-ID: <46609710.40802@oxysys.com>

I am having an extremely occasional hang of a live555-based linux rtsp 
server under heavy load. I have induced a core dump to see where the 
hang occurs. It seems that we hang waiting for a packet on the RTCP 
socket. The RTCP socket does not appear to be set to non-blocking. Now, 
at first glance, it would appear that, even though it is a blocking 
socket, this should never happen, since we've had select() (or in my 
case, epoll()) report data available. However, it turns out that the 
linux kernel feels free to drop UDP packets after notifying a socket 
that it is readable. From the select() man page:

Under  Linux,  select()  may report a socket file descriptor as "ready 
for reading", while nevertheless a subsequent read blocks. This could 
for example happen when data has arrived but upon examination has wrong 
checksum and is discarded. There may be other circumstances in  which  
a  file  descriptor  is  spuriously reported as ready.  Thus it may be 
safer to use O_NONBLOCK on sockets that should not block.


As I thought about the complete hang I was seeing, I became suspicious 
of my theory, since presumably, the read would return on the next RTCP 
packet. So I instrumented my scheduler with timings of the callbacks for 
turnOnBackgroundReading. I counted callbacks that take >10ms >100ms and 
 >1000ms. I find that I do see quite a few instances of a background 
read task taking over 1 second. This leads me to believe that the read 
of an RTCP packet has to wait for the _next_ RTCP packet from time to 
time. My server hangs on the exceptionally rare instance that this lost 
RTCP packet is the _last_ RTCP packet coming from the client.

Is there a built-in assumption that the RTCP socket is blocking? If I 
just change the code to make it non-blocking, will there be any ill 
effect on the session when such an RTCP packet is lost?

Marc Neuberger


From xcsmith at rockwellcollins.com  Fri Jun  1 15:34:52 2007
From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com)
Date: Fri, 1 Jun 2007 17:34:52 -0500
Subject: [Live-devel] openRTSP Subsession Destruction
Message-ID: <OF9BEB21E8.A55CA61C-ON862572ED.007A362E-862572ED.007C48AB@rockwellcollins.com>

I am looking at the source testProgs/playCommon.cpp, in particular the 
shutdown() and afterPlaying() functions.
Does calling Medium::close(subsession->sink) call the subsession 
destructor also?  This is what the comment says in 
subsessionAfterPlaying().
I set a breakpoint on MediaSubsession::~MediaSubsession() and it does not 
get called.  Are these cleared some other way, or don't they need to be 
cleared?

./openRTSP -V rtsp://10.145.223.24:8554/incredibles.ts

Ross Finlayson 1/14/07:
Generally speaking, you should destroy objects in the opposite order from 
that in which they were created.  Also, subclasses of "Medium" are 
destroyed using  "Medium::close()", whereas "Groupsock" objects are 
destroyed using "delete".  (This is historical ugliness...)

Thx! (And thank you very much for helping me with ReceivingInterfaceAddr!)
Xochitl


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

From finlayson at live555.com  Fri Jun  1 16:10:19 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 16:10:19 -0700
Subject: [Live-devel] RTCP socket blocking
In-Reply-To: <46609710.40802@oxysys.com>
References: <46609710.40802@oxysys.com>
Message-ID: <f06240812c28656cf839f@[66.80.62.44]>

>Is there a built-in assumption that the RTCP socket is blocking?

No.  Both incoming RTCP and incoming RTP packets are read 
asynchronously, from the event loop, so their sockets don't need to 
be blocking.

>  If I
>just change the code to make it non-blocking, will there be any ill
>effect on the session when such an RTCP packet is lost?

Probably not.

The best way to do this would be to add the line
	makeSocketNonBlocking(fGS->socketNum());
to the (currently empty) "RTPInterface::RTPInterface" constructor (in 
"liveMedia/RTPInterface.cpp").  That way, it will work for incoming 
RTP packets also.  (Although your application - as a RTSP server - 
doesn't have any incoming RTP packets, other applications do.)

Please let us know whether that works OK for you.  If so, I'll add it 
to the next release of the code.
-- 

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

From finlayson at live555.com  Fri Jun  1 16:27:46 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jun 2007 16:27:46 -0700
Subject: [Live-devel] openRTSP Subsession Destruction
In-Reply-To: <OF9BEB21E8.A55CA61C-ON862572ED.007A362E-862572ED.007C48AB@rockwellcollins
	.com>
References: <OF9BEB21E8.A55CA61C-ON862572ED.007A362E-862572ED.007C48AB@rockwellcollins
	.com>
Message-ID: <f06240813c28658ee02b9@[66.80.62.44]>

>I am looking at the source testProgs/playCommon.cpp, in particular 
>the shutdown() and afterPlaying() functions.
>Does calling Medium::close(subsession->sink) call the subsession 
>destructor also?  This is what the comment says in 
>subsessionAfterPlaying().

That comment is perhaps a bit misleading.  When it says that it 
"closes the subsession", it means that it closes down the stream 
that's associated with the subsession.

The actual "MediaSubsession" object itself is closed within the 
"MediaSession" destructor, which (should) get called from within the 
"shutdown()" routine (in the call to "Medium::close(session)").
-- 

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/20070601/f4b119db/attachment.html 

From julian.lamberty at mytum.de  Sat Jun  2 02:59:00 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Sat, 02 Jun 2007 11:59:00 +0200
Subject: [Live-devel] FramedFilter questions
Message-ID: <46613F64.5060102@mytum.de>

Hi!

I've some questions related to the FramedFilter class. I subclassed it 
to transcode a MPEG2 Stream to MPEG4. So the structure of my program 
looks like:

MPEG1or2VideoRTPSource -> Transcoder (my class) -> 
MPEG4VideoStreamDiscreteFramer -> MPEG4ESVideoRTPSink

My Transcoder class reads data as long as it is able to decode one 
frame. When one frame has been decoded it is passed to an encoder 
(ffmpeg) which writes one complete frame into the fTo buffer (limited by 
fMaxSize).

The problem is that the MPEG4 stream I send seems to be totally 
corrupted. Thus I have some questions:

Which variables do I have to set before I pass data to 
MPEG4VideoStreamDiscreteFramer? Do I need to care about 
fpresentationTime, fdurationInMicrosecond? If yes, how do they have to 
be set? Right now I just set them to the values I get from the source 
(presentationTime, durationIn Microseconds (which equals -1 btw)). Is 
this correct?

I'm somehow stuck right now, I do not know whats wrong. When I just pass 
packets everything works fine (of course I use another structure then: 
MPEG1or2VideoRTPSource -> Transcoder (just memcpys) -> 
MPEG2VideoStreamDiscreteFramer -> MPEG1or2VideoRTPSink).

Ideas and help appreciated ;)

Thanks!

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070602/80ce68c7/attachment-0001.bin 

From finlayson at live555.com  Sat Jun  2 09:40:48 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 2 Jun 2007 09:40:48 -0700
Subject: [Live-devel] FramedFilter questions
In-Reply-To: <46613F64.5060102@mytum.de>
References: <46613F64.5060102@mytum.de>
Message-ID: <f06240814c2874ddf371e@[66.80.62.44]>

>Ideas and help appreciated ;)

If you haven't already done so, look at the commented section of 
"DeviceSource.cpp" for hints/advice.  (Also, of course, the code of 
existing "FramedFilter" subclasses.)
-- 

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

From julian.lamberty at mytum.de  Sun Jun  3 02:02:02 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Sun, 03 Jun 2007 11:02:02 +0200
Subject: [Live-devel]  FramedFilter questions
References: 46613F64.5060102@mytum.de
Message-ID: <4662838A.4040509@mytum.de>

As you already guessed, I did that ;)

I took MP3ADUTranscoder as an example where presentation time and 
duration are just passed through. I don't get why my code does not work. 
When I write one complete frame to fTo, MPEG4VideoStreamDiscreteFramer 
should be able to pass them correctly to MPEG4ESVideoRTPSink, right?
If that is the case and I can pass through duration and presentation 
time, then I'm really stuck. I use VLC to receive the data an display 
the stream but it gives me lots of "macroblock errors" and "motion 
vectors not available" warnings...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070603/3946fa4c/attachment.bin 

From ravinder.singh at ti.com  Sun Jun  3 22:23:12 2007
From: ravinder.singh at ti.com (singh, Ravinder)
Date: Mon, 4 Jun 2007 10:53:12 +0530
Subject: [Live-devel] Complete file not streamed
In-Reply-To: <mailman.490.1180706908.796.live-devel@lists.live555.com>
Message-ID: <7EAD1AEEA7621C45899FE99123E124A0E02F9F@dbde01.ent.ti.com>

Hi Ross
Stream is of 144.159 seconds duration only; problem is server stops
streaming the file after 60 seconds only, as a result rest of the file
Is not streamed, our client wait for 144.159 sec's duration and when
Sending teardown response to server after 144.159 duration it reports 

Received TEARDOWN response: RTSP/1.0 454 Session Not Found
CSeq: 5
Session: 93547611

What I think is openRTSP is not returning responses to server while 
Streaming is going on as a result of which server is aborting after 
Some time. Server is playing fine with bit band client.

Regards
Ravinder


From finlayson at live555.com  Sun Jun  3 22:37:40 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 3 Jun 2007 22:37:40 -0700
Subject: [Live-devel] Complete file not streamed
In-Reply-To: <7EAD1AEEA7621C45899FE99123E124A0E02F9F@dbde01.ent.ti.com>
References: <7EAD1AEEA7621C45899FE99123E124A0E02F9F@dbde01.ent.ti.com>
Message-ID: <f06240801c289543a7680@[66.80.62.44]>

>Hi Ross
>Stream is of 144.159 seconds duration only; problem is server stops
>streaming the file after 60 seconds only

Well then that's a problem with your server - not our client!

As far as I can tell, our client is working perfectly.

What *might* be happening is that your server is expecting some 
non-standard periodic keep-alive packets or requests from the client, 
and if it doesn't receive any within 60 seconds, then the server 
times out the session.  But again, that is a problem with your 
server.  The standard way for a server to check the 'liveness' of a 
client is via incoming RTCP "RR" packets (from the client).  Our 
client sends such packets.

You need to contact the manufacturer of your server to ask them why 
it's not working properly with our (IETF standard) client.
-- 

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

From bidibulle at operamail.com  Mon Jun  4 01:18:45 2007
From: bidibulle at operamail.com (David Betrand)
Date: Mon, 4 Jun 2007 09:18:45 +0100
Subject: [Live-devel] Performance
Message-ID: <20070604081845.C4892CA0BF@ws5-11.us4.outblaze.com>


Hello Marc,

We use liveMedia library in a server-side application and we noticed the same performance issue with DelayQueue class. We tried to optimize it but couldn't get good results. Would you mind if I ask you to share your optimized code ? Ross, I understand your point regarding embedded sysytems but one solution could be to define a compilation flag which determines if STL classes can be used. This would allow using optimized code like what Marc did in DelayQueue, for server-side solutions which require very good performance.
Thanks for your feedback.
David

> > However, I don't want to use the STL, because I don't want to 
> > make the "LIVE555 Streaming Media" dependent upon it (because I 
> > want this code to continue to be useful for (e.g.) embedded 
> > systems that are relatively memory constrained, or which might 
> > not have the STL available for other reasons).
> >
> Yeah, that makes sense, too. I certainly wouldn't attempt to write 
> the equivalent of the STL class (a Red-Black tree) myself. I agree 
> that the current implementation is perfectly fine for most uses. 
> Largely, I'm offering a tip to others that may find themselves in 
> my situation about where to look for performance.


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

From julian.lamberty at mytum.de  Mon Jun  4 05:13:08 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Mon, 04 Jun 2007 14:13:08 +0200
Subject: [Live-devel] MPEG4VideoStreamDiscreteFramer
Message-ID: <466401D4.4010109@mytum.de>

Hi!

I have an encoder that writes MPEG4 frames to a buffer which I want to 
stream out with MPEG4ESVideoRTPSink.

I'm using the MPEG4VideoStreamDiscreteFramer class in between.

The problem is that the stream is corrupted, but if I write the buffer 
to a file like "test.m4e" it can be played correctly. There seems to be 
a problem passing the buffer into MPEG4VideoStreamDiscreteFramer.

I have also tried to stream the "test.m4e" I created with the test 
program "testMPEG4VideoStreamer", the output is also corrupted. What 
could that be caused by?

I have my encode function write to a buffer and memcpy that buffer into 
fTo before I set fFrameSize and fNumTruncatedBytes.

Could that be a problem relating timestamps?

Please help me, I'm stuck...

Thanks
Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070604/4900ba15/attachment.bin 

From severin.schoepke at gmail.com  Mon Jun  4 10:32:39 2007
From: severin.schoepke at gmail.com (Severin Schoepke)
Date: Mon, 04 Jun 2007 19:32:39 +0200
Subject: [Live-devel] Synchronizing audio and video streams
In-Reply-To: <f0624080cc28629336088@[66.80.62.44]>
References: <46571067.6040101@gmail.com>	<f06240800c27ced9fe534@[66.80.62.44]>
	<46602858.7030603@gmail.com> <f0624080cc28629336088@[66.80.62.44]>
Message-ID: <46644CB7.1030909@gmail.com>

Hello again!

I investigated a little deeper and here is what I came up with: Just to 
recap: I have two threads, one is reading audio and video frames and 
stores them in two queues. Another thread reads these queues, encodes 
the frames to MPEG4 and MP3, and streams them out via live555. The 
live555 part is organized as follows: I have two FramedSource subclasses 
that provide encoded audio and video frames respectively. These are 
connected to an MPEG4VideoFramer and an MPEG1or2AudioFramer 
respectively, which are connected to an MPEG4ESVideoRTPSink and an 
MPEG1or2AudioRTPSink. To provide the stream, I use a DarwinInjector (I 
tested your RTSPServer and it yielded in the same results).
My problem is, that the video source's doGetNextFrame() is called much 
less than the audio source's. As a result, the video source's queue gets 
filled with video frames, that are not consumed immediately. Therefore, 
the video stream begins to lag behind the audio stream.

Here is some debug output (sorry, it has to be that detailed and long 
for it to make sense):

Beginning streaming...
Beginning to read from video input...
2007-06-04 15:36:58.101 Mischpult[12008] 1180964218:69929 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.107 Mischpult[12008] 1180964218:102202 - buffering 
audio frame (now 2 audio frames in queue)
2007-06-04 15:36:58.133 Mischpult[12008] 1180964218:118806 - buffering 
video frame (now 1 video frames in queue)
2007-06-04 15:36:58.138 Mischpult[12008] 1180964218:135415 - buffering 
audio frame (now 3 audio frames in queue)
2007-06-04 15:36:58.152 Mischpult[12008] 1180964218:151894 - 
doGetNextFrame(): provided Video frame: fFrameSize = 16505 bytes with 
fPresentationTime = 1180964218:118806 (now 0 Video frames in queue)
2007-06-04 15:36:58.178 Mischpult[12008] 1180964218:168648 - buffering 
video frame (now 1 video frames in queue)
2007-06-04 15:36:58.179 Mischpult[12008] 1180964218:168648 - buffering 
audio frame (now 4 audio frames in queue)
2007-06-04 15:36:58.206 Mischpult[12008] 1180964218:201928 - buffering 
audio frame (now 5 audio frames in queue)
2007-06-04 15:36:58.207 Mischpult[12008] 1180964218:206957 - 
doGetNextFrame(): provided Video frame: fFrameSize = 10751 bytes with 
fPresentationTime = 1180964218:168648 (now 0 Video frames in queue)
Beginning to read from audio input...
2007-06-04 15:36:58.209 Mischpult[12008] 1180964218:208258 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:69929 (now 4 Audio frames in queue)
2007-06-04 15:36:58.209 Mischpult[12008] 1180964218:208463 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:102202 (now 3 Audio frames in queue)
2007-06-04 15:36:58.209 Mischpult[12008] 1180964218:208654 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:135415 (now 2 Audio frames in queue)
Play this stream (from the Darwin Streaming Server) using the URL:
2007-06-04 15:36:58.226 Mischpult[12008] 1180964218:218542 - buffering 
video frame (now 1 video frames in queue)
    rtsp://127.0.0.1/test.sdp
2007-06-04 15:36:58.238 Mischpult[12008] 1180964218:235192 - buffering 
audio frame (now 3 audio frames in queue)
2007-06-04 15:36:58.239 Mischpult[12008] 1180964218:238262 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:168648 (now 2 Audio frames in queue)
2007-06-04 15:36:58.239 Mischpult[12008] 1180964218:238564 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:201928 (now 1 Audio frames in queue)
2007-06-04 15:36:58.239 Mischpult[12008] 1180964218:238838 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:235192 (now 0 Audio frames in queue)
2007-06-04 15:36:58.275 Mischpult[12008] 1180964218:268453 - buffering 
video frame (now 2 video frames in queue)
2007-06-04 15:36:58.276 Mischpult[12008] 1180964218:268453 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.291 Mischpult[12008] 1180964218:290250 - 
doGetNextFrame(): provided Video frame: fFrameSize = 33815 bytes with 
fPresentationTime = 1180964218:218542 (now 1 Video frames in queue)
2007-06-04 15:36:58.304 Mischpult[12008] 1180964218:301744 - buffering 
audio frame (now 2 audio frames in queue)
2007-06-04 15:36:58.324 Mischpult[12008] 1180964218:323193 - 
doGetNextFrame(): provided Video frame: fFrameSize = 18718 bytes with 
fPresentationTime = 1180964218:268453 (now 0 Video frames in queue)
2007-06-04 15:36:58.327 Mischpult[12008] 1180964218:326644 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:268453 (now 1 Audio frames in queue)
2007-06-04 15:36:58.327 Mischpult[12008] 1180964218:326893 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:301744 (now 0 Audio frames in queue)
2007-06-04 15:36:58.328 Mischpult[12008] 1180964218:318377 - buffering 
video frame (now 2 video frames in queue)
2007-06-04 15:36:58.338 Mischpult[12008] 1180964218:334998 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.338 Mischpult[12008] 1180964218:337320 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:334998 (now 0 Audio frames in queue)
2007-06-04 15:36:58.366 Mischpult[12008] 1180964218:365940 - 
doGetNextFrame(): provided Video frame: fFrameSize = 15993 bytes with 
fPresentationTime = 1180964218:318377 (now 0 Video frames in queue)
2007-06-04 15:36:58.376 Mischpult[12008] 1180964218:368262 - buffering 
video frame (now 1 video frames in queue)
2007-06-04 15:36:58.376 Mischpult[12008] 1180964218:368262 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.405 Mischpult[12008] 1180964218:401508 - buffering 
audio frame (now 2 audio frames in queue)
2007-06-04 15:36:58.406 Mischpult[12008] 1180964218:405368 - 
doGetNextFrame(): provided Video frame: fFrameSize = 11362 bytes with 
fPresentationTime = 1180964218:368262 (now 0 Video frames in queue)
2007-06-04 15:36:58.406 Mischpult[12008] 1180964218:405875 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:368262 (now 1 Audio frames in queue)
2007-06-04 15:36:58.407 Mischpult[12008] 1180964218:406090 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:401508 (now 0 Audio frames in queue)
2007-06-04 15:36:58.425 Mischpult[12008] 1180964218:418148 - buffering 
video frame (now 1 video frames in queue)
2007-06-04 15:36:58.438 Mischpult[12008] 1180964218:434783 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.438 Mischpult[12008] 1180964218:437275 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:434783 (now 0 Audio frames in queue)
2007-06-04 15:36:58.463 Mischpult[12008] 1180964218:462300 - 
doGetNextFrame(): provided Video frame: fFrameSize = 6914 bytes with 
fPresentationTime = 1180964218:418148 (now 0 Video frames in queue)
2007-06-04 15:36:58.475 Mischpult[12008] 1180964218:468062 - buffering 
video frame (now 1 video frames in queue)
2007-06-04 15:36:58.475 Mischpult[12008] 1180964218:468062 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.480 Mischpult[12008] 1180964218:479619 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:468062 (now 0 Audio frames in queue)
2007-06-04 15:36:58.503 Mischpult[12008] 1180964218:501314 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.504 Mischpult[12008] 1180964218:503167 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:501314 (now 0 Audio frames in queue)
2007-06-04 15:36:58.526 Mischpult[12008] 1180964218:517955 - buffering 
video frame (now 2 video frames in queue)
2007-06-04 15:36:58.537 Mischpult[12008] 1180964218:534568 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.537 Mischpult[12008] 1180964218:536853 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:534568 (now 0 Audio frames in queue)
2007-06-04 15:36:58.576 Mischpult[12008] 1180964218:567849 - buffering 
video frame (now 3 video frames in queue)
2007-06-04 15:36:58.576 Mischpult[12008] 1180964218:567849 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.576 Mischpult[12008] 1180964218:575914 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:567849 (now 0 Audio frames in queue)
2007-06-04 15:36:58.604 Mischpult[12008] 1180964218:601117 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.604 Mischpult[12008] 1180964218:603868 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:601117 (now 0 Audio frames in queue)
2007-06-04 15:36:58.625 Mischpult[12008] 1180964218:617749 - buffering 
video frame (now 4 video frames in queue)
2007-06-04 15:36:58.637 Mischpult[12008] 1180964218:634375 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.637 Mischpult[12008] 1180964218:636793 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:634375 (now 0 Audio frames in queue)
2007-06-04 15:36:58.674 Mischpult[12008] 1180964218:667639 - buffering 
video frame (now 5 video frames in queue)
2007-06-04 15:36:58.675 Mischpult[12008] 1180964218:667639 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.677 Mischpult[12008] 1180964218:676360 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:667639 (now 0 Audio frames in queue)
2007-06-04 15:36:58.703 Mischpult[12008] 1180964218:700917 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.703 Mischpult[12008] 1180964218:702700 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:700917 (now 0 Audio frames in queue)
2007-06-04 15:36:58.725 Mischpult[12008] 1180964218:717556 - buffering 
video frame (now 6 video frames in queue)
2007-06-04 15:36:58.737 Mischpult[12008] 1180964218:734194 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.737 Mischpult[12008] 1180964218:736303 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:734194 (now 0 Audio frames in queue)
2007-06-04 15:36:58.775 Mischpult[12008] 1180964218:767466 - buffering 
video frame (now 7 video frames in queue)
2007-06-04 15:36:58.776 Mischpult[12008] 1180964218:767466 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.777 Mischpult[12008] 1180964218:776165 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:767466 (now 0 Audio frames in queue)
2007-06-04 15:36:58.804 Mischpult[12008] 1180964218:800710 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.804 Mischpult[12008] 1180964218:803513 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:800710 (now 0 Audio frames in queue)
2007-06-04 15:36:58.824 Mischpult[12008] 1180964218:817343 - buffering 
video frame (now 8 video frames in queue)
2007-06-04 15:36:58.836 Mischpult[12008] 1180964218:833977 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.836 Mischpult[12008] 1180964218:835898 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:833977 (now 0 Audio frames in queue)
2007-06-04 15:36:58.874 Mischpult[12008] 1180964218:867232 - buffering 
video frame (now 9 video frames in queue)
2007-06-04 15:36:58.874 Mischpult[12008] 1180964218:867232 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.874 Mischpult[12008] 1180964218:873908 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:867232 (now 0 Audio frames in queue)
2007-06-04 15:36:58.903 Mischpult[12008] 1180964218:900515 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.903 Mischpult[12008] 1180964218:902707 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:900515 (now 0 Audio frames in queue)
2007-06-04 15:36:58.925 Mischpult[12008] 1180964218:917143 - buffering 
video frame (now 10 video frames in queue)
2007-06-04 15:36:58.936 Mischpult[12008] 1180964218:933803 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.936 Mischpult[12008] 1180964218:935908 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:933803 (now 0 Audio frames in queue)
2007-06-04 15:36:58.975 Mischpult[12008] 1180964218:967039 - buffering 
video frame (now 11 video frames in queue)
2007-06-04 15:36:58.975 Mischpult[12008] 1180964218:967039 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:58.976 Mischpult[12008] 1180964218:975325 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964218:967039 (now 0 Audio frames in queue)
2007-06-04 15:36:59.004 Mischpult[12008] 1180964219:318 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.004 Mischpult[12008] 1180964219:3354 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:318 (now 0 Audio frames in queue)
2007-06-04 15:36:59.024 Mischpult[12008] 1180964219:16939 - buffering 
video frame (now 12 video frames in queue)
2007-06-04 15:36:59.036 Mischpult[12008] 1180964219:33566 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.037 Mischpult[12008] 1180964219:36807 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:33566 (now 0 Audio frames in queue)
2007-06-04 15:36:59.073 Mischpult[12008] 1180964219:66841 - buffering 
video frame (now 13 video frames in queue)
2007-06-04 15:36:59.074 Mischpult[12008] 1180964219:66841 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.078 Mischpult[12008] 1180964219:77372 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:66841 (now 0 Audio frames in queue)
2007-06-04 15:36:59.102 Mischpult[12008] 1180964219:100110 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.103 Mischpult[12008] 1180964219:102081 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:100110 (now 0 Audio frames in queue)
2007-06-04 15:36:59.124 Mischpult[12008] 1180964219:116753 - buffering 
video frame (now 14 video frames in queue)
2007-06-04 15:36:59.136 Mischpult[12008] 1180964219:133379 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.136 Mischpult[12008] 1180964219:135859 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:133379 (now 0 Audio frames in queue)
2007-06-04 15:36:59.174 Mischpult[12008] 1180964219:166671 - buffering 
video frame (now 15 video frames in queue)
2007-06-04 15:36:59.175 Mischpult[12008] 1180964219:166671 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.175 Mischpult[12008] 1180964219:174519 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:166671 (now 0 Audio frames in queue)
2007-06-04 15:36:59.203 Mischpult[12008] 1180964219:199908 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.203 Mischpult[12008] 1180964219:202622 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:199908 (now 0 Audio frames in queue)
2007-06-04 15:36:59.224 Mischpult[12008] 1180964219:216545 - buffering 
video frame (now 16 video frames in queue)
2007-06-04 15:36:59.235 Mischpult[12008] 1180964219:233167 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.236 Mischpult[12008] 1180964219:235221 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:233167 (now 0 Audio frames in queue)
2007-06-04 15:36:59.260 Mischpult[12008] 1180964219:259716 - 
doGetNextFrame(): provided Video frame: fFrameSize = 5938 bytes with 
fPresentationTime = 1180964218:468062 (now 15 Video frames in queue)
2007-06-04 15:36:59.273 Mischpult[12008] 1180964219:266457 - buffering 
video frame (now 16 video frames in queue)
2007-06-04 15:36:59.274 Mischpult[12008] 1180964219:266457 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.274 Mischpult[12008] 1180964219:273770 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:266457 (now 0 Audio frames in queue)
2007-06-04 15:36:59.302 Mischpult[12008] 1180964219:299706 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.302 Mischpult[12008] 1180964219:301692 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:299706 (now 0 Audio frames in queue)
2007-06-04 15:36:59.324 Mischpult[12008] 1180964219:316339 - buffering 
video frame (now 17 video frames in queue)
2007-06-04 15:36:59.335 Mischpult[12008] 1180964219:332990 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.336 Mischpult[12008] 1180964219:335085 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:332990 (now 0 Audio frames in queue)
2007-06-04 15:36:59.374 Mischpult[12008] 1180964219:366240 - buffering 
video frame (now 18 video frames in queue)
2007-06-04 15:36:59.375 Mischpult[12008] 1180964219:366240 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.375 Mischpult[12008] 1180964219:374349 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:366240 (now 0 Audio frames in queue)
2007-06-04 15:36:59.414 Mischpult[12008] 1180964219:399538 - buffering 
video frame (now 19 video frames in queue)
2007-06-04 15:36:59.415 Mischpult[12008] 1180964219:399538 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.415 Mischpult[12008] 1180964219:414506 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:399538 (now 0 Audio frames in queue)
2007-06-04 15:36:59.443 Mischpult[12008] 1180964219:432771 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.443 Mischpult[12008] 1180964219:442352 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:432771 (now 0 Audio frames in queue)
2007-06-04 15:36:59.463 Mischpult[12008] 1180964219:449407 - buffering 
video frame (now 20 video frames in queue)
2007-06-04 15:36:59.476 Mischpult[12008] 1180964219:466037 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.477 Mischpult[12008] 1180964219:476075 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:466037 (now 0 Audio frames in queue)
2007-06-04 15:36:59.513 Mischpult[12008] 1180964219:499305 - buffering 
video frame (now 21 video frames in queue)
2007-06-04 15:36:59.514 Mischpult[12008] 1180964219:499305 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.514 Mischpult[12008] 1180964219:513593 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:499305 (now 0 Audio frames in queue)
2007-06-04 15:36:59.542 Mischpult[12008] 1180964219:532585 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.542 Mischpult[12008] 1180964219:541832 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:532585 (now 0 Audio frames in queue)
2007-06-04 15:36:59.564 Mischpult[12008] 1180964219:549203 - buffering 
video frame (now 22 video frames in queue)
2007-06-04 15:36:59.576 Mischpult[12008] 1180964219:565836 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.576 Mischpult[12008] 1180964219:575712 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:565836 (now 0 Audio frames in queue)
2007-06-04 15:36:59.613 Mischpult[12008] 1180964219:599108 - buffering 
video frame (now 23 video frames in queue)
2007-06-04 15:36:59.614 Mischpult[12008] 1180964219:599108 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.614 Mischpult[12008] 1180964219:613753 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:599108 (now 0 Audio frames in queue)
2007-06-04 15:36:59.643 Mischpult[12008] 1180964219:632373 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.643 Mischpult[12008] 1180964219:642488 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:632373 (now 0 Audio frames in queue)
2007-06-04 15:36:59.664 Mischpult[12008] 1180964219:649007 - buffering 
video frame (now 24 video frames in queue)
2007-06-04 15:36:59.675 Mischpult[12008] 1180964219:665632 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.676 Mischpult[12008] 1180964219:675335 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:665632 (now 0 Audio frames in queue)
2007-06-04 15:36:59.714 Mischpult[12008] 1180964219:698906 - buffering 
video frame (now 25 video frames in queue)
2007-06-04 15:36:59.714 Mischpult[12008] 1180964219:698906 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.718 Mischpult[12008] 1180964219:717617 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:698906 (now 0 Audio frames in queue)
2007-06-04 15:36:59.743 Mischpult[12008] 1180964219:732171 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.743 Mischpult[12008] 1180964219:742665 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:732171 (now 0 Audio frames in queue)
2007-06-04 15:36:59.764 Mischpult[12008] 1180964219:748806 - buffering 
video frame (now 26 video frames in queue)
2007-06-04 15:36:59.770 Mischpult[12008] 1180964219:769106 - 
doGetNextFrame(): provided Video frame: fFrameSize = 4694 bytes with 
fPresentationTime = 1180964218:517955 (now 25 Video frames in queue)
2007-06-04 15:36:59.775 Mischpult[12008] 1180964219:765447 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.776 Mischpult[12008] 1180964219:775119 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:765447 (now 0 Audio frames in queue)
2007-06-04 15:36:59.813 Mischpult[12008] 1180964219:798720 - buffering 
video frame (now 26 video frames in queue)
2007-06-04 15:36:59.813 Mischpult[12008] 1180964219:798720 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.813 Mischpult[12008] 1180964219:812770 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:798720 (now 0 Audio frames in queue)
2007-06-04 15:36:59.842 Mischpult[12008] 1180964219:831974 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.842 Mischpult[12008] 1180964219:841810 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:831974 (now 0 Audio frames in queue)
2007-06-04 15:36:59.863 Mischpult[12008] 1180964219:848610 - buffering 
video frame (now 27 video frames in queue)
2007-06-04 15:36:59.875 Mischpult[12008] 1180964219:865244 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.879 Mischpult[12008] 1180964219:878629 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:865244 (now 0 Audio frames in queue)
2007-06-04 15:36:59.913 Mischpult[12008] 1180964219:898514 - buffering 
video frame (now 28 video frames in queue)
2007-06-04 15:36:59.913 Mischpult[12008] 1180964219:898514 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.921 Mischpult[12008] 1180964219:920452 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:898514 (now 0 Audio frames in queue)
2007-06-04 15:36:59.942 Mischpult[12008] 1180964219:931772 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.942 Mischpult[12008] 1180964219:941443 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:931772 (now 0 Audio frames in queue)
2007-06-04 15:36:59.963 Mischpult[12008] 1180964219:948405 - buffering 
video frame (now 29 video frames in queue)
2007-06-04 15:36:59.975 Mischpult[12008] 1180964219:965043 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:36:59.976 Mischpult[12008] 1180964219:975041 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:965043 (now 0 Audio frames in queue)
2007-06-04 15:37:00.013 Mischpult[12008] 1180964219:998321 - buffering 
video frame (now 30 video frames in queue)
2007-06-04 15:37:00.013 Mischpult[12008] 1180964219:998321 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.014 Mischpult[12008] 1180964220:13239 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964219:998321 (now 0 Audio frames in queue)
2007-06-04 15:37:00.041 Mischpult[12008] 1180964220:31567 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.041 Mischpult[12008] 1180964220:40842 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:31567 (now 0 Audio frames in queue)
2007-06-04 15:37:00.063 Mischpult[12008] 1180964220:48199 - buffering 
video frame (now 31 video frames in queue)
2007-06-04 15:37:00.075 Mischpult[12008] 1180964220:64833 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.078 Mischpult[12008] 1180964220:77866 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:64833 (now 0 Audio frames in queue)
2007-06-04 15:37:00.113 Mischpult[12008] 1180964220:98101 - buffering 
video frame (now 32 video frames in queue)
2007-06-04 15:37:00.113 Mischpult[12008] 1180964220:98101 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.119 Mischpult[12008] 1180964220:117985 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:98101 (now 0 Audio frames in queue)
2007-06-04 15:37:00.141 Mischpult[12008] 1180964220:131378 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.141 Mischpult[12008] 1180964220:140775 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:131378 (now 0 Audio frames in queue)
2007-06-04 15:37:00.163 Mischpult[12008] 1180964220:147998 - buffering 
video frame (now 33 video frames in queue)
2007-06-04 15:37:00.175 Mischpult[12008] 1180964220:164647 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.175 Mischpult[12008] 1180964220:174591 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:164647 (now 0 Audio frames in queue)
2007-06-04 15:37:00.212 Mischpult[12008] 1180964220:197905 - buffering 
video frame (now 34 video frames in queue)
2007-06-04 15:37:00.213 Mischpult[12008] 1180964220:197905 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.213 Mischpult[12008] 1180964220:212492 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:197905 (now 0 Audio frames in queue)
2007-06-04 15:37:00.241 Mischpult[12008] 1180964220:231172 - buffering 
audio frame (now 1 audio frames in queue)
2007-06-04 15:37:00.241 Mischpult[12008] 1180964220:240791 - 
doGetNextFrame(): provided Audio frame: fFrameSize = 384 bytes with 
fPresentationTime = 1180964220:231172 (now 0 Audio frames in queue)
2007-06-04 15:37:00.262 Mischpult[12008] 1180964220:247802 - buffering 
video frame (now 35 video frames in queue)
2007-06-04 15:37:00.269 Mischpult[12008] 1180964220:268774 - 
doGetNextFrame(): provided Video frame: fFrameSize = 4600 bytes with 
fPresentationTime = 1180964218:567849 (now 34 Video frames in queue)




I also added some debug printfs to MultiframedRTPSink and found out, 
that the sinks are queried in the same 'asynchronous' manner (the video 
sink is queried much less than the audio sink). The strange numbers in 
the following are pointer values and let you distinguish the audio and 
the video sink.

Beginning streaming...
Beginning to read from video input...
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
Beginning to read from audio input...
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
Play this stream (from the Darwin Streaming Server) using the URL:
    rtsp://127.0.0.1/test.sdp
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)
MultiframedRTPSink (0xef6a0c0) querying input source (0xef6a420)
MultiframedRTPSink (0xef67490) querying input source (0xef6a710)


Now to my question: Why is the video sink and thus  the video source 
queried at a much lower frequency than the audio respectives?

I'm sorry for the long mail, but I hope it makes sense that way...


cheers, Severin














Ross Finlayson schrieb:
>> So I tried to use your RTSP server but it didn't change the situation.
>> My streams are still diverting. I investigated the problem further and
>> fond out, that live555 queries my sound source much more often than it
>> queries the video source. I suspect it has something to do with data
>> size
>>     
>
> No, that shouldn't matter.  If you (ii) give your data (audio and 
> video) accurate presentation times (the "fPresentationTime" variable) 
> - tied to the local 'wall clock' time (e.g., using "gettimeofday()"), 
> and (ii) use RTCP (by creating "RTCPInstance" objects for each 
> "RTPSink"), then audio/video sync *will* work correctly at the client 
> end.
>   


From raphael.kindt at gmail.com  Tue Jun  5 00:33:05 2007
From: raphael.kindt at gmail.com (=?ISO-8859-1?Q?Rapha=EBl_Kindt?=)
Date: Tue, 5 Jun 2007 09:33:05 +0200
Subject: [Live-devel] [live-devel] Too long delay for JPEG live image.
Message-ID: <8b9f68640706050033w75f13b16l62d8abea5417f48b@mail.gmail.com>

Hello,

I'm trying to developpe a MJPEG live streamer server.
I work with a camera and our specific driver (that I've wrote too) for our
frame grabber.
To do this I've learned about Elphel example.
I've wrote a JPEGVideoSource derivated class then I've overload the
doGetNextFrame function.

Now I can see remotely live JPEG video from camera with a VLC client
program.
But I've observe a delay of 2 sec between images received by the driver and
those received by VLC client.
It seem there is a too big fifo buffer for live image between them.
I've disable our fifo buffer to see what's happened.
Now I copy directly image (30 kB) to FramedSource::fTo data members.
But the problem is always present.

How can I reduce this delay?

Thanks in advance for your help...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070605/59ee8926/attachment.html 

From finlayson at live555.com  Tue Jun  5 01:36:26 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 5 Jun 2007 01:36:26 -0700
Subject: [Live-devel] [live-devel] Too long delay for JPEG live image.
In-Reply-To: <8b9f68640706050033w75f13b16l62d8abea5417f48b@mail.gmail.com>
References: <8b9f68640706050033w75f13b16l62d8abea5417f48b@mail.gmail.com>
Message-ID: <f06240803c28ad028e40e@[66.80.62.44]>

>Hello,
>
>I'm trying to developpe a MJPEG live streamer server.
>I work with a camera and our specific driver (that I've wrote too) 
>for our frame grabber.
>To do this I've learned about Elphel example.
>I've wrote a JPEGVideoSource derivated class then I've overload the 
>doGetNextFrame function.
>
>Now I can see remotely live JPEG video from camera with a VLC client program.
>But I've observe a delay of 2 sec between images received by the 
>driver and those received by VLC client.
>It seem there is a too big fifo buffer for live image between them.
>I've disable our fifo buffer to see what's happened.
>Now I copy directly image (30 kB) to FramedSource::fTo data members.
>But the problem is always present.
>
>How can I reduce this delay?

There's no signifcant delay in the "LIVE555 Streaming Media" code - 
at either the sending end or the receiving (VLC) end.

However, VLC does have a separate jitter buffer that - by default - 
adds 1.2 seconds (1200 ms) at the receiving end.  You can reduce this 
by changing VLC's
	Preferences->Input/Codecs->Demuxers->RTP/RTSP->Advanced->Caching 
value (ms)

Don't forget also that JPEG encoding (even in hardware) and decoding 
also add some delay, which you are unlikely to be able to reduce.
-- 

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

From raphael.kindt at gmail.com  Tue Jun  5 02:26:18 2007
From: raphael.kindt at gmail.com (=?us-ascii?Q?Raphael_KINDT?=)
Date: Tue, 5 Jun 2007 11:26:18 +0200
Subject: [Live-devel] [live-devel] Too long delay for JPEG live image.
In-Reply-To: <f06240803c28ad028e40e@[66.80.62.44]>
Message-ID: <MKEBIAIDCOCMGKEPIMDBOEKPHJAA.raphael.kindt@gmail.com>

OK... It works fine now.
Just by changing caching value to 50 ms.
Thanks!   :-)


-----Message d'origine-----
De : live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com]De la part de Ross Finlayson
Envoye : mardi 5 juin 2007 10:36
A : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] [live-devel] Too long delay for JPEG live
image.


>Hello,
>
>I'm trying to developpe a MJPEG live streamer server.
>I work with a camera and our specific driver (that I've wrote too)
>for our frame grabber.
>To do this I've learned about Elphel example.
>I've wrote a JPEGVideoSource derivated class then I've overload the
>doGetNextFrame function.
>
>Now I can see remotely live JPEG video from camera with a VLC client
program.
>But I've observe a delay of 2 sec between images received by the
>driver and those received by VLC client.
>It seem there is a too big fifo buffer for live image between them.
>I've disable our fifo buffer to see what's happened.
>Now I copy directly image (30 kB) to FramedSource::fTo data members.
>But the problem is always present.
>
>How can I reduce this delay?

There's no signifcant delay in the "LIVE555 Streaming Media" code -
at either the sending end or the receiving (VLC) end.

However, VLC does have a separate jitter buffer that - by default -
adds 1.2 seconds (1200 ms) at the receiving end.  You can reduce this
by changing VLC's
	Preferences->Input/Codecs->Demuxers->RTP/RTSP->Advanced->Caching
value (ms)

Don't forget also that JPEG encoding (even in hardware) and decoding
also add some delay, which you are unlikely to be able to reduce.
--

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 raphael.kindt at gmail.com  Tue Jun  5 03:35:50 2007
From: raphael.kindt at gmail.com (=?us-ascii?Q?Raphael_KINDT?=)
Date: Tue, 5 Jun 2007 12:35:50 +0200
Subject: [Live-devel] [live-devel] Too long delay for JPEG live image.
In-Reply-To: <f06240803c28ad028e40e@[66.80.62.44]>
Message-ID: <MKEBIAIDCOCMGKEPIMDBGELAHJAA.raphael.kindt@gmail.com>

Hello,

I've another question.
I observe that there is a difference between my original JPEG header and the
header constructs by the client.
To detect this difference I've used OpenRTSP.

The difference is the quantization table.
I've used a qFactor = 128 and I've overload the
JPEGVideoSource::quantizationTables (with precision = 0 and length = 128).
I've forced the driver (and thus hardware coder) to use the same table as
that which JPEGVideoRTPSource uses.
The driver use 100% for the quality factor.

After all that, there is always a difference.

What can I do to use the same quantization table as that which originals
images use?

Thanks a lot.

-----Message d'origine-----
De : live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com]De la part de Ross Finlayson
Envoye : mardi 5 juin 2007 10:36
A : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] [live-devel] Too long delay for JPEG live
image.


>Hello,
>
>I'm trying to developpe a MJPEG live streamer server.
>I work with a camera and our specific driver (that I've wrote too)
>for our frame grabber.
>To do this I've learned about Elphel example.
>I've wrote a JPEGVideoSource derivated class then I've overload the
>doGetNextFrame function.
>
>Now I can see remotely live JPEG video from camera with a VLC client
program.
>But I've observe a delay of 2 sec between images received by the
>driver and those received by VLC client.
>It seem there is a too big fifo buffer for live image between them.
>I've disable our fifo buffer to see what's happened.
>Now I copy directly image (30 kB) to FramedSource::fTo data members.
>But the problem is always present.
>
>How can I reduce this delay?

There's no signifcant delay in the "LIVE555 Streaming Media" code -
at either the sending end or the receiving (VLC) end.

However, VLC does have a separate jitter buffer that - by default -
adds 1.2 seconds (1200 ms) at the receiving end.  You can reduce this
by changing VLC's
	Preferences->Input/Codecs->Demuxers->RTP/RTSP->Advanced->Caching
value (ms)

Don't forget also that JPEG encoding (even in hardware) and decoding
also add some delay, which you are unlikely to be able to reduce.
--

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 adigupt_000 at rediffmail.com  Tue Jun  5 23:13:10 2007
From: adigupt_000 at rediffmail.com (aditya  gupta)
Date: 6 Jun 2007 06:13:10 -0000
Subject: [Live-devel] how to use live555 with JMF
Message-ID: <20070606061310.28074.qmail@webmail90.rediffmail.com>

 ?
hi, 

I want to use live555MediaServer as a streaming server and JMStudio 
(JMF player ) as a client side player to run the media streamed by 
live555 server . Can any one tell me how to do that ???

thanx 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070605/8d305876/attachment.html 

From adigupt_000 at rediffmail.com  Tue Jun  5 23:15:14 2007
From: adigupt_000 at rediffmail.com (aditya  gupta)
Date: 6 Jun 2007 06:15:14 -0000
Subject: [Live-devel] how to use live555 as a RTP server
Message-ID: <20070606061514.24514.qmail@webmail87.rediffmail.com>

 ?
hi , 

Can any one tell me how to use live555MediaServer to transmit the 
media file through RTP (i.e without using any RTSP messages ) . 

thanx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070605/7972b134/attachment.html 

From finlayson at live555.com  Tue Jun  5 23:19:54 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 5 Jun 2007 23:19:54 -0700
Subject: [Live-devel] how to use live555 with JMF
In-Reply-To: <20070606061310.28074.qmail@webmail90.rediffmail.com>
References: <20070606061310.28074.qmail@webmail90.rediffmail.com>
Message-ID: <f06240806c28c0222785e@[66.80.62.44]>

>
>hi,
>
>I want to use live555MediaServer as a streaming server and JMStudio
>(JMF player ) as a client side player to run the media streamed by
>live555 server . Can any one tell me how to do that ???

You will have to ask a JMF mailing list.  The "live555MediaServer" is 
a standards-compliant RTSP/RTP server, so any standard RTSP/RTP 
client should be able to play from it.

Unfortunately this is not the right mailing list for someone who 
wants to develope a client in Java.
-- 

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

From finlayson at live555.com  Tue Jun  5 23:48:21 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 5 Jun 2007 23:48:21 -0700
Subject: [Live-devel] how to use live555 as a RTP server
In-Reply-To: <20070606061514.24514.qmail@webmail87.rediffmail.com>
References: <20070606061514.24514.qmail@webmail87.rediffmail.com>
Message-ID: <f06240807c28c08a416a3@[66.80.62.44]>

>Can any one tell me how to use live555MediaServer to transmit the
>media file through RTP (i.e without using any RTSP messages ) .

The "live555MediaServer" can't do this; it's a RTSP server.

However, you should look at the various demo applications in the 
"testProgs" directory (in the "LIVE555 Streaming Media" software). 
There are several applications there - called "test*Streamer" - that 
stream via RTP, in some cases without a built-in RTSP server.
-- 

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

From ken.hilliard at gmail.com  Wed Jun  6 00:44:24 2007
From: ken.hilliard at gmail.com (Ken Hilliard)
Date: Wed, 6 Jun 2007 14:44:24 +0700
Subject: [Live-devel] multiple audio stream w/Live555 Media Server
Message-ID: <4b531160706060044g6973a44amedc0278a97087c29@mail.gmail.com>

I downloaded and installed the Linux version of live555MediaServer into a
directory on Ubuntu. I copied my mpegts files in that directory and started
streaming videos with a single audio track via an Amino 125 STB. The video
was h.264 and the audio aac. I used the Amino's javascript play function (
AVMedia.Play), passing it the url "rtsp://192.168.2.5:8554/test.ts" to
stream and play the video. At this point everything's OK. Then I added video
files with 2 audio streams. There seems to be only 1 audio stream
received--at least as reported by the Amino STB. Also the reported audio pid
is not the same value that is in the mpegts source file. To verify the
mpegts file's correctness I used a media player to play the video and could
select either audio streams. I also used an mpeg editor to verify the pes
and stream ids.

Is there something special I must do to stream multiple audio streams?  Does
live555MediaServer output logging that would provide diagnostic information?
Is there a simple command line tool that could be used to connect to the
RTSP server and report the available streams. BTW: I'm a newbie.

                       thx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070606/3dcb804c/attachment.html 

From finlayson at live555.com  Wed Jun  6 00:56:58 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jun 2007 00:56:58 -0700
Subject: [Live-devel] multiple audio stream w/Live555 Media Server
In-Reply-To: <4b531160706060044g6973a44amedc0278a97087c29@mail.gmail.com>
References: <4b531160706060044g6973a44amedc0278a97087c29@mail.gmail.com>
Message-ID: <f06240808c28c17f0cc52@[66.80.62.44]>

>I downloaded and installed the Linux version of live555MediaServer 
>into a directory on Ubuntu. I copied my mpegts files in that 
>directory and started streaming videos with a single audio track via 
>an Amino 125 STB. The video was h.264 and the audio aac. I used the 
>Amino's javascript play function (AVMedia.Play), passing it the url 
>"rtsp://192.168.2.5:8554/test.ts" to stream and play the video. At 
>this point everything's OK. Then I added video files with 2 audio 
>streams. There seems to be only 1 audio stream received--at least as 
>reported by the Amino STB

This is an issue with your Amino STB client, not our server.  Our 
server - when streaming MPEG Tranport Stream data - does not 
demultiplex the Transport Stream; instead, it streams the entire 
Transport Stream 'as is'.  Therefore, if your client cannot play the 
stream, then it is a problem with your client.

Unfortunately we cannot help you debug problems with the Amino STB 
client.  Instead, you should contact Amino, or refer to some other 
(Amino-related) mailing list or forum.
-- 

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

From adigupt_000 at rediffmail.com  Wed Jun  6 01:09:50 2007
From: adigupt_000 at rediffmail.com (aditya  gupta)
Date: 6 Jun 2007 08:09:50 -0000
Subject: [Live-devel] how to stream H.264 via RTP
Message-ID: <20070606080950.1121.qmail@webmail91.rediffmail.com>

 ?
hi, 

I am able to stream MPEG1/2 videos through RTP using 
testMPEG1or2VideoStreamer program(testprogs) .. but i want to stream 
H.264 videos through RTP. I read 
http://www.live555.com/liveMedia/faq.html#h264-streaming   but not 
able to understand it completely. 

Can any one tell how to do this (i.e what is the work of 
"H264VideoStreamFramer" module ). 

thanx 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070606/5cc2d5cf/attachment.html 

From adigupt_000 at rediffmail.com  Wed Jun  6 01:12:23 2007
From: adigupt_000 at rediffmail.com (aditya  gupta)
Date: 6 Jun 2007 08:12:23 -0000
Subject: [Live-devel] how to stream H.264 via RTP
Message-ID: <20070606081223.24161.qmail@webmail94.rediffmail.com>

 ?
hi, 

I am able to stream MPEG1/2 videos through RTP using 
testMPEG1or2VideoStreamer program(testprogs) .. but i want to stream 
H.264 videos through RTP. I read 
http://www.live555.com/liveMedia/faq.html#h264-streaming   but not 
able to understand it completely. 

Can any one tell how to do this (i.e what is the work of 
"H264VideoStreamFramer" module ). 

thanx 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070606/84a776d2/attachment.html 

From ken.hilliard at gmail.com  Wed Jun  6 01:47:45 2007
From: ken.hilliard at gmail.com (Ken Hilliard)
Date: Wed, 6 Jun 2007 15:47:45 +0700
Subject: [Live-devel] multiple audio stream w/Live555 Media Server
In-Reply-To: <f06240808c28c17f0cc52@66.80.62.44>
References: <4b531160706060044g6973a44amedc0278a97087c29@mail.gmail.com>
	<f06240808c28c17f0cc52@66.80.62.44>
Message-ID: <4b531160706060147r36af0556vbeebca0390ba9477@mail.gmail.com>

thx Ross. I was also able to verify this by using the VLC client in place of
my STB and it played all the audio tracks with no problem.

On 6/6/07, Ross Finlayson <finlayson at live555.com> wrote:
>
> >I downloaded and installed the Linux version of live555MediaServer
> >into a directory on Ubuntu. I copied my mpegts files in that
> >directory and started streaming videos with a single audio track via
> >an Amino 125 STB. The video was h.264 and the audio aac. I used the
> >Amino's javascript play function (AVMedia.Play), passing it the url
> >"rtsp://192.168.2.5:8554/test.ts" to stream and play the video. At
> >this point everything's OK. Then I added video files with 2 audio
> >streams. There seems to be only 1 audio stream received--at least as
> >reported by the Amino STB
>
> This is an issue with your Amino STB client, not our server.  Our
> server - when streaming MPEG Tranport Stream data - does not
> demultiplex the Transport Stream; instead, it streams the entire
> Transport Stream 'as is'.  Therefore, if your client cannot play the
> stream, then it is a problem with your client.
>
> Unfortunately we cannot help you debug problems with the Amino STB
> client.  Instead, you should contact Amino, or refer to some other
> (Amino-related) mailing list or forum.
> --
>
> 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/20070606/bba05441/attachment.html 

From may_ank77 at yahoo.com  Wed Jun  6 01:52:01 2007
From: may_ank77 at yahoo.com (mayank agarwal)
Date: Wed, 6 Jun 2007 01:52:01 -0700 (PDT)
Subject: [Live-devel] RTSP client application
Message-ID: <931626.53465.qm@web90406.mail.mud.yahoo.com>

Hello all,
I am new to RTSP and streaming.I have downloaded the
freely available RTSP streaming code from live555.com
site and trying to understand it.My aim is to develop
the RTSP client application using the files and
libraries already given in the code.

Please guide me how should i proceed and how much time
it will take to develop the required application.


Regards,
Mayank


 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

From vinodjoshi at tataelxsi.co.in  Wed Jun  6 03:51:55 2007
From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi)
Date: Wed, 6 Jun 2007 16:21:55 +0530
Subject: [Live-devel] PTS for Program Stream
Message-ID: <000001c7a828$b3bfd400$022a320a@telxsi.com>


Hi all,

       We are using Live 555 streaming media server to stream MPEG 2 PS to
the set top box.
        The server will stream audio and video on seperate ports for program
stream.
        After receiving the streams on client side, how to calculate PTS?
        Whether we have to use RTP timestamp values for this?

        Anybody knows about this or what information i have to look for(Any
RFC)?

       Thank You.



From julian.lamberty at mytum.de  Wed Jun  6 05:23:56 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 06 Jun 2007 14:23:56 +0200
Subject: [Live-devel] Problem Streaming MPEG4ES from buffer
Message-ID: <4666A75C.80001@mytum.de>

Hi!

I've a ffmpeg code that writes MPEG4 frames into a buffer. I want to 
stream these frames over RTP/RTSP. At the moment I pass the buffer to an 
"MPEG4VideoStreamDiscreteFramer" that sends it to an "MPEG4ESVideoRTPSink".
But the stream I receive is totally corrupted. Using wireshark I can 
see, that all the packets I send have nearly the same content, only a 
few bytes change form packet to packet.

When I write the buffer to a file ("fwrite(outbuf, 1, enc_bytes, 
file)"), I can stream that file perfectly via the test program 
"testMPEG4VideoStreamer". Taking the same buffer and copying it to fTo 
results in a broken stream("memcpy(fTo, outbuf, enc_bytes)").

Do I have to change fpresentationTime and fdurationInMicroseconds? Right 
now I just set them to presentationTime and durationInMicorseconds...

fFrameSize is set to enc_bytes if smaller fMaxSize, that should be 
correct, right?

Do I have to use "MPEG4VideoStreamFramer" instead as the test program does?

Please help me handling that buffer over to live555.

Thanks!

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070606/04c84ac1/attachment.bin 

From julian.lamberty at mytum.de  Wed Jun  6 05:32:51 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 06 Jun 2007 14:32:51 +0200
Subject: [Live-devel]  Problem Streaming MPEG4ES from buffer
Message-ID: <4666A973.3050501@mytum.de>

If I dump the stream at the receiver with openRTSP I also get a 
corrupted stream, so it's not a problem with the player I'm using (VLC 
with live555 support).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070606/53ccc9ae/attachment-0001.bin 

From severin.schoepke at gmail.com  Wed Jun  6 06:04:02 2007
From: severin.schoepke at gmail.com (Severin Schoepke)
Date: Wed, 06 Jun 2007 15:04:02 +0200
Subject: [Live-devel] Problem Streaming MPEG4ES from buffer
In-Reply-To: <4666A75C.80001@mytum.de>
References: <4666A75C.80001@mytum.de>
Message-ID: <4666B0C2.3030200@gmail.com>

Hi Julian,
I can stream ffmpeg encoded MPEG4 buffers using an 
MPEG4VideoStreamFramer perfectly well. I suppose you try that!

cheers, Severin


Julian Lamberty schrieb:
> Do I have to use "MPEG4VideoStreamFramer" instead as the test program 
> does?



From julian.lamberty at mytum.de  Wed Jun  6 06:25:03 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 06 Jun 2007 15:25:03 +0200
Subject: [Live-devel]  Problem Streaming MPEG4ES from buffer
References: 4666A75C.80001@mytum.de
Message-ID: <4666B5AF.60105@mytum.de>

Hi Severin!

How did you do that, I'm trying exactly the same. But when I use 
MPEG4VideoStreamFramer instead of the discrete one I get errors that say:

StreamParser::afterGettingBytes() warning: read 23329 bytes; expected no 
more than 10026
MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too 
large for our buffer size (60752).  90747 bytes of trailing data was 
dropped!  Correct this by increasing "OutPacketBuffer::maxSize" to at 
least 151499, *before* creating this 'RTPSink'.  (Current value is 60000.)
MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 
'short video header', which we current don't support

[mpeg4 @ 0xa23148]buffer smaller than minimum size

I use the following code to fill the buffer:

enc_bytes = avcodec_encode_video(enc_codec_ctx, outbuf, fMaxSize, 
dec_frame);
if(enc_bytes >= 0)
                {                 
                    memcpy(fTo, outbuf, enc_bytes);
                   
                    if(enc_bytes > fMaxSize)
                    {
                        fFrameSize = fMaxSize;
                        fNumTruncatedBytes = enc_bytes - fMaxSize;
                    }
                    else
                    {
                        fFrameSize = enc_bytes;
                        fNumTruncatedBytes = 0;
                    }
                    fPresentationTime = presentationTime;
                    fDurationInMicroseconds = durationInMicroseconds;
                }
    afterGetting(this);

Would be very nice if you could help me finding my mistake...

Thanks!

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070606/26998584/attachment.bin 

From finlayson at live555.com  Wed Jun  6 06:45:30 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jun 2007 06:45:30 -0700
Subject: [Live-devel] PTS for Program Stream
In-Reply-To: <000001c7a828$b3bfd400$022a320a@telxsi.com>
References: <000001c7a828$b3bfd400$022a320a@telxsi.com>
Message-ID: <f06240809c28c68f13e81@[66.80.62.44]>

>        We are using Live 555 streaming media server to stream MPEG 2 PS to
>the set top box.
>         The server will stream audio and video on seperate ports for program
>stream.
>         After receiving the streams on client side, how to calculate PTS?

Are you using our software to develop your client?  If not, then we 
can't help you - sorry.

If, however, you are using our software to develop your client, then 
the presentation timestamp for each piece of data read from a 
"RTPSource" object is passed - as a parameter - to the 'after 
getting' function that was previously passed in the call to 
"getNextFrame" on the "RTPSource" object.  (Note the many examples in 
the code.)

>         Whether we have to use RTP timestamp values for this?

No.  Our software automatically calculates the presentation time from 
the RTP timestamps and RTCP reports.  You don't need to calculate 
this yourself - instead, just use the "presentationTime" parameter.
-- 

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

From finlayson at live555.com  Wed Jun  6 06:52:30 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jun 2007 06:52:30 -0700
Subject: [Live-devel] Problem Streaming MPEG4ES from buffer
In-Reply-To: <4666B5AF.60105@mytum.de>
References: 4666A75C.80001@mytum.de <4666B5AF.60105@mytum.de>
Message-ID: <f0624080ac28c6c04f6ed@[66.80.62.44]>

>I use the following code to fill the buffer:
>
>enc_bytes = avcodec_encode_video(enc_codec_ctx, outbuf, fMaxSize, dec_frame);
>if(enc_bytes >= 0)
>                {                
>                    memcpy(fTo, outbuf, enc_bytes);
>                  
>                    if(enc_bytes > fMaxSize)

This is very bad.  You must never copy more than "fMaxSize" bytes to 
the destination pointed to by "fTo".  Therefore, you must check the 
data size against "fMaxSize" *before* you copy it.

I.e, you should instead do:

                    if(enc_bytes > fMaxSize)
                    {
                        fFrameSize = fMaxSize;
                        fNumTruncatedBytes = enc_bytes - fMaxSize;
                    }
                    else
                    {
                        fFrameSize = enc_bytes;
                        fNumTruncatedBytes = 0;
                    }
                    memcpy(fTo, outbuf, fFrameSize);

-- 

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

From julian.lamberty at mytum.de  Wed Jun  6 07:03:20 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Wed, 06 Jun 2007 16:03:20 +0200
Subject: [Live-devel]  Problem Streaming MPEG4ES from buffer
References: 4666B5AF.60105@mytum.de
Message-ID: <4666BEA8.6050304@mytum.de>

Thanks for your reply, I changed my code.

Nevertheless, enc_bytes did never exceed fMaxSize in my program before 
and thus the problem still exists. VLC, which I use to play the stream, 
reports loads of errors regarding late pictures and damaged headers... 
:( Any more ideas?

Thank you!
Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070606/c13cc764/attachment.bin 

From homocean at ibr.cs.tu-bs.de  Wed Jun  6 07:46:14 2007
From: homocean at ibr.cs.tu-bs.de (homocean at ibr.cs.tu-bs.de)
Date: Wed, 6 Jun 2007 16:46:14 +0200 (CEST)
Subject: [Live-devel] SeqNo
In-Reply-To: <f06240801c282fb4831b5@[66.80.62.44]>
References: <1878.134.169.173.74.1180388606.squirrel@mail.ibr.cs.tu-bs.de>
	<f06240802c28122a3400f@[66.80.62.44]>
	<3059.134.169.35.237.1180516648.squirrel@mail.ibr.cs.tu-bs.de>
	<f06240801c282fb4831b5@[66.80.62.44]>
Message-ID: <4808.134.169.35.237.1181141174.squirrel@mail.ibr.cs.tu-bs.de>

>>Is there any posibility to access this information (the sequence numbers
>>that make up each frame) from mplayer without modifying any live source
>
> No.

My goal is to optimize mplayer based on live for wlan streaming. But I am
not allowed to modify the live library. If I do not have access to the
sequence numbers that make up a frame how can I tell if a frame got lost?
It would be at least helpful to know the seq no of each frame. I tried
interrogating the bufferQueue->rtpSource()->curPacketRTPSeqNum() before
each getBuffer(), but this does not behave as I would have expected. The
seqNo I get does not correspond to the beginning of the frame I read with
getBuffer. And this is because live continues receiving rtp packets from
the server before mplayer receives its buffered frame (if I understood
wrong please correct me).

Is there another way of finding out if a frame(or parts of it) got lost?
Or is it the last solution to implements my own rtp client and link it to
mplayer(I might not have enough time for that)?

Regards,
Silviu

> --
>
> 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  Wed Jun  6 13:15:36 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jun 2007 13:15:36 -0700
Subject: [Live-devel] Problem Streaming MPEG4ES from buffer
In-Reply-To: <4666BEA8.6050304@mytum.de>
References: 4666B5AF.60105@mytum.de <4666BEA8.6050304@mytum.de>
Message-ID: <f0624080ec28cc4f69f17@[66.80.62.44]>

>Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
>	micalg=sha1; boundary="------------ms020209000004030702020306"
>
>Thanks for your reply, I changed my code.
>
>Nevertheless, enc_bytes did never exceed fMaxSize in my program 
>before and thus the problem still exists. VLC, which I use to play 
>the stream, reports loads of errors regarding late pictures and 
>damaged headers... :( Any more ideas?

The only other thing I can think of is that perhaps you are modifying 
the "fTo" variable before you call "memcpy()"-  thereby copying your 
data to the wrong place.

Apart from this, you're on your own.  You've probably made a simple 
error somewhere.  But fortunately, You Have Complete Source Code.
-- 

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

From ravinder.singh at ti.com  Wed Jun  6 22:25:06 2007
From: ravinder.singh at ti.com (singh, Ravinder)
Date: Thu, 7 Jun 2007 10:55:06 +0530
Subject: [Live-devel] getting link time errors while building for arm.linux
In-Reply-To: <mailman.638.1181141172.796.live-devel@lists.live555.com>
Message-ID: <7EAD1AEEA7621C45899FE99123E124A0E035A4@dbde01.ent.ti.com>

Hi Ross
I am getting lot of undefined  reference errors when I am cross
compiling the code for arm architecture, following are some errors. I am
using uclibc
Tool chain.

make[1]: Entering directory `/home/ravinder/rtsp/live_arm/testProgs'
arm-linux-gcc -otestMP3Streamer -L. testMP3Streamer.o
../liveMedia/libliveMedia.a ../groupsock/libgroupsock.a
../UsageEnvironment/libUsageEnvironment.a
../BasicUsageEnvironment/libBasicUsageEnvironment.a
testMP3Streamer.o: In function `main':
testMP3Streamer.cpp:(.text+0x140): undefined reference to `operator
new(unsigned int)'
testMP3Streamer.cpp:(.text+0x18c): undefined reference to `operator
new(unsigned int)'
testMP3Streamer.cpp:(.text+0x280): undefined reference to `operator
delete(void*)'
testMP3Streamer.cpp:(.text+0x294): undefined reference to
`__gxx_personality_sj0'
../liveMedia/libliveMedia.a: In function `Medium::~Medium()':
Locale.cpp:(.text+0xbc): undefined reference to `operator delete(void*)'
../liveMedia/libliveMedia.a: In function
`_Tables::getOurTables(UsageEnvironment&)':
Locale.cpp:(.text+0x160): undefined reference to `operator new(unsigned
int)'
../liveMedia/libliveMedia.a: In function `_Tables::~_Tables()':
Locale.cpp:(.text+0x2a0): undefined reference to `operator
delete(void*)'
../liveMedia/libliveMedia.a: In function
`MediaLookupTable::ourMedia(UsageEnvironment&)':
Locale.cpp:(.text+0x35c): undefined reference to `operator new(unsigned
int)'
Locale.cpp:(.text+0x3b0): undefined reference to `operator
delete(void*)'
Locale.cpp:(.text+0x3c4): undefined reference to `__gxx_personality_sj0'
../liveMedia/libliveMedia.a: In function
`MediaLookupTable::~MediaLookupTable()':
Locale.cpp:(.text+0x5e0): undefined reference to `operator
delete(void*)'
../liveMedia/libliveMedia.a: In function `MediaSource::~MediaSource()':
Locale.cpp:(.text+0x67c): undefined reference to `operator
delete(void*)'
../liveMedia/libliveMedia.a: In function
`FramedSource::~FramedSource()':
Locale.cpp:(.text+0x838): undefined reference to `operator
delete(void*)'
../liveMedia/libliveMedia.a: In function
`FramedFileSource::~FramedFileSource()':
Locale.cpp:(.text+0xaa4): undefined reference to `operator
delete(void*)'
../liveMedia/libliveMedia.a: In function
`FramedFilter::~FramedFilter()':
Locale.cpp:(.text+0xba0): undefined reference to `__gxx_personality_sj0'
../liveMedia/libliveMedia.a: In function
`FramedFilter::~FramedFilter()':
Locale.cpp:(.text+0xc5c): undefined reference to `__gxx_personality_sj0'
../liveMedia/libliveMedia.a: In function
`FramedFilter::~FramedFilter()':
Locale.cpp:(.text+0xce0): undefined reference to `operator
delete(void*)'
Locale.cpp:(.text+0xd20): undefined reference to `__gxx_personality_sj0'
Regards
Ravinder

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of
live-devel-request at ns.live555.com
Sent: Wednesday, June 06, 2007 8:16 PM
To: live-devel at ns.live555.com
Subject: live-devel Digest, Vol 44, Issue 6

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: Problem Streaming MPEG4ES from buffer (Severin Schoepke)
   2.  Problem Streaming MPEG4ES from buffer (Julian Lamberty)
   3. Re: PTS for Program Stream (Ross Finlayson)
   4. Re: Problem Streaming MPEG4ES from buffer (Ross Finlayson)
   5.  Problem Streaming MPEG4ES from buffer (Julian Lamberty)
   6. Re: SeqNo (homocean at ibr.cs.tu-bs.de)


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

Message: 1
Date: Wed, 06 Jun 2007 15:04:02 +0200
From: Severin Schoepke <severin.schoepke at gmail.com>
Subject: Re: [Live-devel] Problem Streaming MPEG4ES from buffer
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <4666B0C2.3030200 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Hi Julian,
I can stream ffmpeg encoded MPEG4 buffers using an 
MPEG4VideoStreamFramer perfectly well. I suppose you try that!

cheers, Severin


Julian Lamberty schrieb:
> Do I have to use "MPEG4VideoStreamFramer" instead as the test program 
> does?




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

Message: 2
Date: Wed, 06 Jun 2007 15:25:03 +0200
From: Julian Lamberty <julian.lamberty at mytum.de>
Subject: [Live-devel]  Problem Streaming MPEG4ES from buffer
To: live-devel at ns.live555.com
Message-ID: <4666B5AF.60105 at mytum.de>
Content-Type: text/plain; charset="iso-8859-15"

Hi Severin!

How did you do that, I'm trying exactly the same. But when I use 
MPEG4VideoStreamFramer instead of the discrete one I get errors that
say:

StreamParser::afterGettingBytes() warning: read 23329 bytes; expected no

more than 10026
MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too 
large for our buffer size (60752).  90747 bytes of trailing data was 
dropped!  Correct this by increasing "OutPacketBuffer::maxSize" to at 
least 151499, *before* creating this 'RTPSink'.  (Current value is
60000.)
MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 
'short video header', which we current don't support

[mpeg4 @ 0xa23148]buffer smaller than minimum size

I use the following code to fill the buffer:

enc_bytes = avcodec_encode_video(enc_codec_ctx, outbuf, fMaxSize, 
dec_frame);
if(enc_bytes >= 0)
                {                 
                    memcpy(fTo, outbuf, enc_bytes);
                   
                    if(enc_bytes > fMaxSize)
                    {
                        fFrameSize = fMaxSize;
                        fNumTruncatedBytes = enc_bytes - fMaxSize;
                    }
                    else
                    {
                        fFrameSize = enc_bytes;
                        fNumTruncatedBytes = 0;
                    }
                    fPresentationTime = presentationTime;
                    fDurationInMicroseconds = durationInMicroseconds;
                }
    afterGetting(this);

Would be very nice if you could help me finding my mistake...

Thanks!

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://lists.live555.com/pipermail/live-devel/attachments/20070606/26998
584/attachment-0001.bin 

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

Message: 3
Date: Wed, 6 Jun 2007 06:45:30 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] PTS for Program Stream
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <f06240809c28c68f13e81@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>        We are using Live 555 streaming media server to stream MPEG 2
PS to
>the set top box.
>         The server will stream audio and video on seperate ports for
program
>stream.
>         After receiving the streams on client side, how to calculate
PTS?

Are you using our software to develop your client?  If not, then we 
can't help you - sorry.

If, however, you are using our software to develop your client, then 
the presentation timestamp for each piece of data read from a 
"RTPSource" object is passed - as a parameter - to the 'after 
getting' function that was previously passed in the call to 
"getNextFrame" on the "RTPSource" object.  (Note the many examples in 
the code.)

>         Whether we have to use RTP timestamp values for this?

No.  Our software automatically calculates the presentation time from 
the RTP timestamps and RTCP reports.  You don't need to calculate 
this yourself - instead, just use the "presentationTime" parameter.
-- 

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


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

Message: 4
Date: Wed, 6 Jun 2007 06:52:30 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] Problem Streaming MPEG4ES from buffer
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <f0624080ac28c6c04f6ed@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>I use the following code to fill the buffer:
>
>enc_bytes = avcodec_encode_video(enc_codec_ctx, outbuf, fMaxSize,
dec_frame);
>if(enc_bytes >= 0)
>                {                
>                    memcpy(fTo, outbuf, enc_bytes);
>                  
>                    if(enc_bytes > fMaxSize)

This is very bad.  You must never copy more than "fMaxSize" bytes to 
the destination pointed to by "fTo".  Therefore, you must check the 
data size against "fMaxSize" *before* you copy it.

I.e, you should instead do:

                    if(enc_bytes > fMaxSize)
                    {
                        fFrameSize = fMaxSize;
                        fNumTruncatedBytes = enc_bytes - fMaxSize;
                    }
                    else
                    {
                        fFrameSize = enc_bytes;
                        fNumTruncatedBytes = 0;
                    }
                    memcpy(fTo, outbuf, fFrameSize);

-- 

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


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

Message: 5
Date: Wed, 06 Jun 2007 16:03:20 +0200
From: Julian Lamberty <julian.lamberty at mytum.de>
Subject: [Live-devel]  Problem Streaming MPEG4ES from buffer
To: live-devel at ns.live555.com
Message-ID: <4666BEA8.6050304 at mytum.de>
Content-Type: text/plain; charset="iso-8859-15"

Thanks for your reply, I changed my code.

Nevertheless, enc_bytes did never exceed fMaxSize in my program before 
and thus the problem still exists. VLC, which I use to play the stream, 
reports loads of errors regarding late pictures and damaged headers... 
:( Any more ideas?

Thank you!
Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://lists.live555.com/pipermail/live-devel/attachments/20070606/c13cc
764/attachment-0001.bin 

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

Message: 6
Date: Wed, 6 Jun 2007 16:46:14 +0200 (CEST)
From: homocean at ibr.cs.tu-bs.de
Subject: Re: [Live-devel] SeqNo
To: "LIVE555 Streaming Media - development & use"
	<live-devel at ns.live555.com>
Message-ID:
	<4808.134.169.35.237.1181141174.squirrel at mail.ibr.cs.tu-bs.de>
Content-Type: text/plain;charset=iso-8859-1

>>Is there any posibility to access this information (the sequence
numbers
>>that make up each frame) from mplayer without modifying any live
source
>
> No.

My goal is to optimize mplayer based on live for wlan streaming. But I
am
not allowed to modify the live library. If I do not have access to the
sequence numbers that make up a frame how can I tell if a frame got
lost?
It would be at least helpful to know the seq no of each frame. I tried
interrogating the bufferQueue->rtpSource()->curPacketRTPSeqNum() before
each getBuffer(), but this does not behave as I would have expected. The
seqNo I get does not correspond to the beginning of the frame I read
with
getBuffer. And this is because live continues receiving rtp packets from
the server before mplayer receives its buffered frame (if I understood
wrong please correct me).

Is there another way of finding out if a frame(or parts of it) got lost?
Or is it the last solution to implements my own rtp client and link it
to
mplayer(I might not have enough time for that)?

Regards,
Silviu

> --
>
> 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


End of live-devel Digest, Vol 44, Issue 6
*****************************************

From finlayson at live555.com  Wed Jun  6 23:13:41 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jun 2007 23:13:41 -0700
Subject: [Live-devel] getting link time errors while building for
 arm.linux
In-Reply-To: <7EAD1AEEA7621C45899FE99123E124A0E035A4@dbde01.ent.ti.com>
References: <7EAD1AEEA7621C45899FE99123E124A0E035A4@dbde01.ent.ti.com>
Message-ID: <f06240817c28d52215303@[66.80.62.44]>

>I am getting lot of undefined  reference errors when I am cross
>compiling the code for arm architecture, following are some errors. I am
>using uclibc
>Tool chain.
>
>make[1]: Entering directory `/home/ravinder/rtsp/live_arm/testProgs'
>arm-linux-gcc -otestMP3Streamer -L. testMP3Streamer.o
>../liveMedia/libliveMedia.a ../groupsock/libgroupsock.a
>../UsageEnvironment/libUsageEnvironment.a
>../BasicUsageEnvironment/libBasicUsageEnvironment.a
>testMP3Streamer.o: In function `main':
>testMP3Streamer.cpp:(.text+0x140): undefined reference to `operator
>new(unsigned int)'

The problem is that you're not linking with the C++ runtime libraries.

Try changing the definition of LINK in "config.armlinux" from
	$(CROSS_COMPILE)gcc -o
to
	$(CROSS_COMPILE)g++ -o

Perhaps that might help.
-- 

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

From may_ank77 at yahoo.com  Thu Jun  7 02:08:18 2007
From: may_ank77 at yahoo.com (mayank agarwal)
Date: Thu, 7 Jun 2007 02:08:18 -0700 (PDT)
Subject: [Live-devel] Delay between audio and video
Message-ID: <647756.61625.qm@web90414.mail.mud.yahoo.com>

Hi all,
I am running the downloaded LiveMedia code for
steaming multiplexed audio/video stream using RTSP on
client side.I was going through the code but i was not
able to find out the code or the file in which
audio/video synchronization is done.
Please help me in this regard.

Regards,
Mayank


       
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

From igor at mir2.org  Thu Jun  7 03:37:21 2007
From: igor at mir2.org (Igor Bukanov)
Date: Thu, 7 Jun 2007 12:37:21 +0200
Subject: [Live-devel] OnDemandServerMediaSubsession::deleteStream problem
Message-ID: <7dee4710706070337k14029eebrc78f3dd3f79fd577@mail.gmail.com>

The current code for OnDemandServerMediaSubsession::deleteStream,
http://live555.com/liveMedia/doxygen/html/classOnDemandServerMediaSubsession.html#55a633f69121ee4f71874003d422f41c
calls streamState->endPlaying even when destination is null. This
immediately segfaults in endPlaying on null dereference.

I observe this pretty reliably when OnDemandServerMediaSubsession is
used in a video server implementation when the same source is unicasts
to several VLC. When all VLC processes crashes when decoding
particular MPEG4 frame almost at the same time this eventually leads
to that  deleteStream calls with already removed clientSessionId.

The attached patch fixes that via skipping calls to
streamState->endPlaying with unknown clientSessionId.

Regards, Igor

Index: OnDemandServerMediaSubsession.cpp
===================================================================
RCS file: /var/cvsroot/repos1/videoserver/external/live/liveMedia/OnDemandServerMediaSubsession.cpp,v
retrieving revision 1.1
diff -U7 -p -r1.1 OnDemandServerMediaSubsession.cpp
--- OnDemandServerMediaSubsession.cpp	29 May 2007 11:35:10 -0000	1.1
+++ OnDemandServerMediaSubsession.cpp	7 Jun 2007 10:17:31 -0000
@@ -295,24 +295,25 @@ void OnDemandServerMediaSubsession::setS
   if (streamState != NULL && streamState->mediaSource() != NULL) {
     setStreamSourceScale(streamState->mediaSource(), scale);
   }
 }

 void OnDemandServerMediaSubsession::deleteStream(unsigned clientSessionId,
 						 void*& streamToken) {
+  StreamState* streamState = (StreamState*)streamToken;
+
   // Look up (and remove) the destinations for this client session:
   Destinations* destinations
     = (Destinations*)(fDestinationsHashTable->Lookup((char
const*)clientSessionId));
   if (destinations != NULL) {
     fDestinationsHashTable->Remove((char const*)clientSessionId);
-  }

-  // Stop streaming to these destinations:
-  StreamState* streamState = (StreamState*)streamToken;
-  if (streamState != NULL) streamState->endPlaying(destinations);
+    // Stop streaming to these destinations:
+    if (streamState != NULL) streamState->endPlaying(destinations);
+  }

   // Delete the "StreamState" structure if it's no longer being used:
   if (streamState != NULL && streamState->referenceCount() >= 0) {
     if (streamState->referenceCount() > 0) --streamState->referenceCount();
     if (streamState->referenceCount() == 0) {
       delete streamState;
       if (fLastStreamToken == streamToken) fLastStreamToken = NULL;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OnDemandServerMediaSubsession.patch
Type: application/octet-stream
Size: 1740 bytes
Desc: not available
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070607/1e8fb169/attachment.obj 

From may_ank77 at yahoo.com  Thu Jun  7 06:34:14 2007
From: may_ank77 at yahoo.com (mayank agarwal)
Date: Thu, 7 Jun 2007 06:34:14 -0700 (PDT)
Subject: [Live-devel] Understanding RTSP reference code from live555.com
Message-ID: <153149.84720.qm@web90404.mail.mud.yahoo.com>

Hi all,
I have downloaded the freely available reference code
from live555.com and compile,run it and tried to
stream test.mpg file as input in client/server mode.
Actually i am getting the delay between audio and
video on streaming.
Now i am trying to understand the code.I have the
following doubts:

In MPEG1or2ProgramStreamFileDuration function in do
while loop
file duration is calculated.I want to go into the
detail of the steps involved in calculating the file
duration.


Thanks and Regards,
Mayank


      ____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


From finlayson at live555.com  Thu Jun  7 06:37:07 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jun 2007 06:37:07 -0700
Subject: [Live-devel] OnDemandServerMediaSubsession::deleteStream problem
In-Reply-To: <7dee4710706070337k14029eebrc78f3dd3f79fd577@mail.gmail.com>
References: <7dee4710706070337k14029eebrc78f3dd3f79fd577@mail.gmail.com>
Message-ID: <f0624081bc28dba6ffe5d@[66.80.62.44]>

Thanks for the bug report.  This fix will be included in the next 
release of the software.
-- 

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

From xcsmith at rockwellcollins.com  Thu Jun  7 14:30:52 2007
From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com)
Date: Thu, 7 Jun 2007 16:30:52 -0500
Subject: [Live-devel] LIVE555 code standard: comments
Message-ID: <OF15BA3060.1D29BCAC-ON862572F3.0075C3B0-862572F3.00766CD2@rockwellcollins.com>

When commenting LIVE555 code, is it prefered to have the comment blocks 
appear after the code block or function definition the comment block 
pertains to?  I can't tell which is the prefered location.  Are larger 
comment blocks using // prefered over /* */ ?  What about Doxygen 
comments?  ( /** @class **/ ?)
Thanks!
Xochitl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070607/3154a8df/attachment.html 

From finlayson at live555.com  Thu Jun  7 16:48:29 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jun 2007 16:48:29 -0700
Subject: [Live-devel] LIVE555 code standard: comments
In-Reply-To: <OF15BA3060.1D29BCAC-ON862572F3.0075C3B0-862572F3.00766CD2@rockwellcollins
	.com>
References: <OF15BA3060.1D29BCAC-ON862572F3.0075C3B0-862572F3.00766CD2@rockwellcollins
	.com>
Message-ID: <f06240800c28e4918fe4c@[66.80.62.44]>

>When commenting LIVE555 code, is it prefered to have the comment 
>blocks appear after the code block or function definition the 
>comment block pertains to?

It depends.  If the comment is of the form
	// We're about to do X
then I usually put it before.  If the comment is of the form
	// We just did X, because Y
then I usually put it after.

>Are larger comment blocks using // prefered over /* */ ?

Yes, because // blocks are easier to edit.

>   What about Doxygen comments?  ( /** @class **/ ?)

I don't use those.  From what I can tell, Doxygen does a good job already.
-- 

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/20070607/8b2ecd68/attachment.html 

From jnitin at ssdi.sharp.co.in  Thu Jun  7 22:57:02 2007
From: jnitin at ssdi.sharp.co.in (Nitin Jain)
Date: Fri, 8 Jun 2007 11:27:02 +0530
Subject: [Live-devel] Support for multiple NPT ranges in the Range header
Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB5631FB@KABEX01.sharpamericas.com>

 

Hi all,
 
I have one question regarding LIVE555 media server. Does LIVE 555 RTSP server support multiple NPT ranges in the Range header?
 
e.g  Range: npt=10-30, npt=45.5-60.
 
By looking at sourcecode I think presently LIVE555  does not support this feature.Can anyone conform this.
 
Regards
Nitin 

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

From finlayson at live555.com  Thu Jun  7 23:35:23 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jun 2007 23:35:23 -0700
Subject: [Live-devel] Support for multiple NPT ranges in the Range header
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB5631FB@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB5631FB@KABEX01.sharpamericas.com>
Message-ID: <f06240800c28ea919149d@[66.80.62.44]>

>I have one question regarding LIVE555 media server. Does LIVE 555 
>RTSP server support multiple NPT ranges in the Range header?

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/20070607/13fc0e3b/attachment.html 

From sony at mht.bme.hu  Fri Jun  8 00:24:02 2007
From: sony at mht.bme.hu (Tran Minh Son)
Date: Fri, 08 Jun 2007 09:24:02 +0200
Subject: [Live-devel] Ports for RTSP
Message-ID: <46690412.3060302@mht.bme.hu>

Dear all,
I would like to run RTSP server on a Linux machine with firewall. How 
can I open the port for Live555 media server? As I know, it uses a fix 
port (554 or 8554) to receive request from client. After that Live 
server will open an arbitrary port to send out the media via RTP over 
TCP or UDP; It informs this port to client so that he / she knows where 
to connect. From the viewpoint of firewall how can I release this 
on-the-fly port?
Thank you



From finlayson at live555.com  Fri Jun  8 01:17:58 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jun 2007 01:17:58 -0700
Subject: [Live-devel] Ports for RTSP
In-Reply-To: <46690412.3060302@mht.bme.hu>
References: <46690412.3060302@mht.bme.hu>
Message-ID: <f06240801c28ec0aa9ac1@[66.80.62.44]>

>Dear all,
>I would like to run RTSP server on a Linux machine with firewall. How
>can I open the port for Live555 media server? As I know, it uses a fix
>port (554 or 8554) to receive request from client. After that Live
>server will open an arbitrary port to send out the media via RTP over
>TCP or UDP

That's true only for UDP streaming.  If you stream over TCP, then no 
UDP ports are used.  In that case, you need only open the RTSP TCP 
port (554 or 8554).

If you're behind a firewall, and cannot open UDP ports, then you can 
still serve streams via TCP, provided that you open the RTSP TCP port.
-- 

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

From sony at mht.bme.hu  Fri Jun  8 01:59:18 2007
From: sony at mht.bme.hu (Tran Minh Son)
Date: Fri, 08 Jun 2007 10:59:18 +0200
Subject: [Live-devel] Ports for RTSP
In-Reply-To: <f06240801c28ec0aa9ac1@[66.80.62.44]>
References: <46690412.3060302@mht.bme.hu> <f06240801c28ec0aa9ac1@[66.80.62.44]>
Message-ID: <46691A66.2090402@mht.bme.hu>

Hi Ross Finlayson
Thank you for your answer. Can you show me how I can "order" the media 
with TCP not UDP using OpenRTSPClient (Sorry that I didnot check the 
syntax of OpenRTSPClient, you are here that is why I am lazy :-))
I wonder how many clients the MediaServer can serve simutanously through 
TCP using  only one port
Regards
 
Ross Finlayson a ?crit :
>> Dear all,
>> I would like to run RTSP server on a Linux machine with firewall. How
>> can I open the port for Live555 media server? As I know, it uses a fix
>> port (554 or 8554) to receive request from client. After that Live
>> server will open an arbitrary port to send out the media via RTP over
>> TCP or UDP
>>     
>
> That's true only for UDP streaming.  If you stream over TCP, then no 
> UDP ports are used.  In that case, you need only open the RTSP TCP 
> port (554 or 8554).
>
> If you're behind a firewall, and cannot open UDP ports, then you can 
> still serve streams via TCP, provided that you open the RTSP TCP port.
>   


From finlayson at live555.com  Fri Jun  8 02:06:58 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jun 2007 02:06:58 -0700
Subject: [Live-devel] Ports for RTSP
In-Reply-To: <46691A66.2090402@mht.bme.hu>
References: <46690412.3060302@mht.bme.hu>
	<f06240801c28ec0aa9ac1@[66.80.62.44]> <46691A66.2090402@mht.bme.hu>
Message-ID: <f06240802c28ecbee1115@[66.80.62.44]>

>Thank you for your answer. Can you show me how I can "order" the media
>with TCP not UDP using OpenRTSPClient (Sorry that I didnot check the
>syntax of OpenRTSPClient, you are here that is why I am lazy :-))


In other words, you'd rather bother the hundreds of other people on 
this mailing list than take the time to read the online documentation 
for "openRTSP"?

If you read the documentation, you'll get the answer that you're looking for.
-- 

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

From may_ank77 at yahoo.com  Fri Jun  8 03:27:21 2007
From: may_ank77 at yahoo.com (mayank agarwal)
Date: Fri, 8 Jun 2007 03:27:21 -0700 (PDT)
Subject: [Live-devel] Delay between capture and display
Message-ID: <274257.32861.qm@web90415.mail.mud.yahoo.com>

Hi all,
I am streaming capturing live video fro webcam and
streaming it using live555 code to RTSP server and
then displaying the output in m player.But i am
getting the delay between the capture and what is
being displayed of about 4-5 seconds.I am trying to
find out the reason for this delay.

Any points or suggestions why this delay is happening.


Regards,
Mayank


       
____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

From julian.lamberty at mytum.de  Fri Jun  8 04:09:47 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Fri, 08 Jun 2007 13:09:47 +0200
Subject: [Live-devel] doGetNextFrame()
Message-ID: <466938FB.7030605@mytum.de>

Hi!

I've added some stdout messages to MPEG4VideoStreamDiscreteFramer and I 
can see that there are many calls to doGetNextFrame() and 
afterGettingFrame1() even if my source did not deliver one frame:

MPEG4VideoStreamDiscreteFramer::doGetNextFrame() passed
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 0
MPEG4VideoStreamDiscreteFramer::doGetNextFrame() passed
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 0
MPEG4VideoStreamDiscreteFramer::doGetNextFrame() passed
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 0
...(repeats ~50 times)

Decoded frame    1 [I, 138484 Bytes] in 11.76 ms
Encoded frame    1 [I,  23329 Bytes] in 10.41 ms

MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() assuming complete 
picture
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() 
VISUAL_OBJECT_SEQUENCE_START_CODE
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 23329
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
...(more packets sent)
MPEG4VideoStreamDiscreteFramer::doGetNextFrame() passed
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() assuming complete 
picture
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() 
VISUAL_OBJECT_SEQUENCE_START_CODE
MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 23329
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
MultiFramedRTPSink::sendPacketIfNecessary() Packet sent
...(more packets sent)

How do I tell the framer to wait for one frame until asking for the next?

Thanks
Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070608/26671521/attachment-0001.bin 

From may_ank77 at yahoo.com  Fri Jun  8 06:04:29 2007
From: may_ank77 at yahoo.com (mayank agarwal)
Date: Fri, 8 Jun 2007 06:04:29 -0700 (PDT)
Subject: [Live-devel] Live555 code
Message-ID: <626150.97921.qm@web90407.mail.mud.yahoo.com>

Hi all,
I want to run the downloaded live 555 code as RTSP
client.Please guide me how i would be able to do this.


Regards,
Mayank


       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

From julian.lamberty at mytum.de  Fri Jun  8 06:24:56 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Fri, 08 Jun 2007 15:24:56 +0200
Subject: [Live-devel] afterGetting(this)
Message-ID: <466958A8.9010601@mytum.de>

Hi!

I would like to know how I can

1. Request more data from a source (MPEG1or2VideoRTPSource)
2. Tell a sink (MPEG4VideoStreamDiscreteFramer) that data is completely 
delivered to buffer (this should be afterGetting(this), right?)

Right now I have a code structure like:

void Transcoder::doGetNextFrame()
{
    fInputSource->getNextFrame(...);
}

void Transcoder::afterGettingFrame(...)
{
    Transcoder* transcoder = (Transcoder*)clientData;
    transcoder->afterGettingFrame1(...);
}

void Transcoder::afterGettingFrame1(...)
{
    decode_from_inbuf_to_frame
    if(successfully decoded)
    {
       encode_frame_to_fTo
       if(successfully encoded)
       {
           deliver (<- afterGetting(this)?)
       }
    }
    else
    {
       request more data (<- I don't know how to do this, if I simply 
call doGetNextFrame() once again it complains about being read more than 
once)
    }
}

Thanks for your help!

Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070608/1cd389d7/attachment.bin 

From finlayson at live555.com  Fri Jun  8 07:03:08 2007
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jun 2007 07:03:08 -0700
Subject: [Live-devel] doGetNextFrame()
In-Reply-To: <466938FB.7030605@mytum.de>
References: <466938FB.7030605@mytum.de>
Message-ID: <f06240803c28f1133eb41@[66.80.62.44]>

>I've added some stdout messages to MPEG4VideoStreamDiscreteFramer 
>and I can see that there are many calls to doGetNextFrame() and 
>afterGettingFrame1() even if my source did not deliver one frame:
>
>MPEG4VideoStreamDiscreteFramer::doGetNextFrame() passed
>MPEG4VideoStreamDiscreteFramer::afterGettingFrame1() frame size: 0

That's your problem: Your upstream source (your "Transcoder" object) 
is delivering a 0-length frame.  Are you sure that your "Transcoder" 
code is always correctly setting "fFrameSize" before calling 
"afterGetting(this)"?
-- 

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

From julian.lamberty at mytum.de  Fri Jun  8 07:22:28 2007
From: julian.lamberty at mytum.de (Julian Lamberty)
Date: Fri, 08 Jun 2007 16:22:28 +0200
Subject: [Live-devel]  doGetNextFrame()
References: 466938F