From finlayson at live555.com  Fri Oct  1 00:40:29 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Oct 2010 00:40:29 -0700
Subject: [Live-devel] VLC does not display any video when streaming with
 testMPEG4VideoStreamer
In-Reply-To: <4CA49698.8090305@cs.nott.ac.uk>
References: <402121524.651285774543199.JavaMail.root@mail.stretchinc.com>
	<f06240802c8c967fa510d@[66.80.62.44]> <4CA49698.8090305@cs.nott.ac.uk>
Message-ID: <f06240804c8cb40b3cb98@[66.80.62.44]>

>You can either stop outputting any debug info until you know what 
>the real issue is or just check for a null value returned from 
>ctime().

Yes, to be on the safe side, the next version of the code will allow 
for the possibility of the "ctime()" call returning NULL.
-- 

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

From zdenek at next-stream.com  Fri Oct  1 05:00:39 2010
From: zdenek at next-stream.com (Zdenek Bouresh)
Date: Fri, 1 Oct 2010 15:00:39 +0300
Subject: [Live-devel] Many multicast sources with same port problem
In-Reply-To: <f06240800c8bbabdef973@66.80.62.44>
References: <AANLkTim3jCqEP2CXb7Od04ZYsdKhsd3Sc6NjojqGMUC2@mail.gmail.com>
	<f06240800c8bbabdef973@66.80.62.44>
Message-ID: <AANLkTim64hAYbWEWTvxqhG8UH02zaiyFU3UNB-iDU580@mail.gmail.com>

Hello Ross,

I have done some investigation on this issue and here are the results and
suggestions.

1. You were right, it works on  freeBSD , but see 2.

2. This is not a Linux bug, but intended behavior. making 1. an exception
due to how multicast is implemented (different) in freeBSD.

Here is why:
We know that one should not bind() to a multicast address, but according to
the kernel developers and other multicast developers this is intended in
case you want to receive only from one address and port and not all. It
depends on whats needed, so no bug..
.
http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html (shows a bind
is required)
http://marc.info/?l=linux-netdev&m=121579883022264&w=2
http://marc.info/?l=linux-netdev&m=121580189427089&w=2

In short if you join a group with IN_ADDRANY, the indended behavior is you
that you DO get all multicast groups sending on the same port, which is the
case in Live.

If you do want to receive only packets from a specific address and port, you
must not use IN_ADDRANY and  you should bind() the socket to the required
multicast address to receive packets only from this address /port/

All this is reported as intended behavior and the reason there is no FIX in
the linux kernel
The above documents and discussion explain it.

Here is what linux net dev team has to say about the reported "bug".

That's how it has always worked in the original socket implementation (BSD)
> and derivatives. The control for socket reception is the binding, so if you
> want only mcast X packets, you need to bind to X. If you bind to INADDR_ANY,
> that *means* you don't care what the destination address is and you'll
> receive all unicast and multicast packets with a matching port and protocol.


The above explains why the Linux patch has been declined.

I hope you can add support for this in live as I believe both are valid uses
cases.

I also hope that my research on the matter helps and shows that its not a
linux bug or a live bug but a case that live does not currently handle, (A)
not bindng and using INADDR_ANY
Some apps take advantage of this for messaging for example, in my case and I
believe in most live555 cases its actually the opposite that we need.

Thank You,
looking forward to resolving this scenario in live555. Its a great library.

Zed.




On Sun, Sep 19, 2010 at 3:12 PM, Ross Finlayson <finlayson at live555.com>wrote:

> If your application is receiving - on a socket - traffic that was sent to a
> multicast address that that socket did not subscribe to, then that is
> definitely a problem with the operating system, not with your application,
> and not with our libraries.
>
> Because you say that you are unwilling to change your operating system[*],
> and because you say that you can't stop your incoming traffic (for different
> multicast addresses) from using distinct port numbers, then there's no help
> that I can give you.  Sorry.
>
> [*] Note that FreeBSD - as far as I can tell - does not appear to have this
> problem.  If I were you, I'd try using FreeBSD instead of Linux.
> --
>
> 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
>



-- 
Zdenek Bouresh
NextStream LTD.

The information contained within this email transmission and any attachments
is confidential and intended solely for the attention and use of the named
individual addressee(s) or entity. It may not be legally revealed or be
disclosed to any other person or third party without the express authority
(prior written approval) of NextStream LTD and/or the original recipient, or
the intended recipients, or both. If you are not the intended recipient, you
must not disclose, copy, distribute, print, rely on or retain this message
or any part of it. The information contained within is strictly prohibited.
If you have received this email in error please notify the sender by reply,
and delete this message from your email system(s). Any hard copies must also
be destroyed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101001/04baa153/attachment-0001.html>

From finlayson at live555.com  Fri Oct  1 07:05:05 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Oct 2010 07:05:05 -0700
Subject: [Live-devel] Many multicast sources with same port problem
In-Reply-To: <AANLkTim64hAYbWEWTvxqhG8UH02zaiyFU3UNB-iDU580@mail.gmail.com>
References: <AANLkTim3jCqEP2CXb7Od04ZYsdKhsd3Sc6NjojqGMUC2@mail.gmail.com>
	<f06240800c8bbabdef973@66.80.62.44>
	<AANLkTim64hAYbWEWTvxqhG8UH02zaiyFU3UNB-iDU580@mail.gmail.com>
Message-ID: <f06240800c8cb8caa02b8@[66.80.62.44]>

>I have done some investigation on this issue and here are the 
>results and suggestions.
>
>1. You were right, it works on  freeBSD , but see 2.
>
>2. This is not a Linux bug

I guess we'll just have to disagree on this.


>We know that one should not bind() to a multicast address

Agreed :-)


>, but according to the kernel developers and other multicast 
>developers this is intended in case you want to receive only from 
>one address and port and not all. It depends on whats needed, so no 
>bug..
>.
><http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html>http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html (shows 
>a bind is required)
><http://marc.info/?l=linux-netdev&m=121579883022264&w=2>http://marc.info/?l=linux-netdev&m=121579883022264&w=2
><http://marc.info/?l=linux-netdev&m=121580189427089&w=2>http://marc.info/?l=linux-netdev&m=121580189427089&w=2


I don't agree with the arguments made here.  In particular:

>That's how it has always worked in the original socket 
>implementation (BSD) and derivatives.

is most definitely not true, because (as you have discovered 
yourself) it doesn't work this way in FreeBSD.

I also don't agree with the claim that "Multicast addresses, like 
unicast addresses, are for the entire
machine, not just the socket that does the join", because the 
IP_ADD_MEMBERSHIP operation is explicitly done on a socket (i.e., 
using "setsockopt()").  It also seems wrong that a process should 
have the potential to - by joining a multicast group - control which 
packets that are received by a separate process.  (This is arguably a 
security violation.)

In any case, this is all a moot point, because I'm not going to be 
changing the LIVE555 code to bind to the multicast address (when 
creating a multicast 'groupsock'), because in the past - when this 
suggestion has been made - some people have discovered and reported 
that it doesn't work for them.  It does not appear to be portable 
across different OSs, so I can't put it in the released code.  It's 
not inconceivable that sometime in the future I might make a change 
to support this, but have it #ifdef'd out by default.  This is not a 
high priority, though, and the whole "groupsock" interface will 
eventually be replaced anyway (to make it more consistent with the 
"liveMedia" object model).  So it might not happen for a while, if 
ever.  Sorry.

In the meantime, you *might* be able to get the effect you want by 
making the following small change to "liveMedia/MediaSession.cpp", 
and also changing "groupsock/GroupsockHelper.cpp" to replace the line
	if (port.num() == 0) addr = ReceivingInterfaceAddr;
with
	addr = ReceivingInterfaceAddr;

(or, you could patch your Linux kernel :-)

*** MediaSession.cpp.save	Fri Oct  1 05:49:35 2010
--- MediaSession.cpp	Fri Oct  1 06:02:43 2010
***************
*** 568,573 ****
--- 568,574 ----
   Boolean MediaSubsession::initiate(int useSpecialRTPoffset) {
     if (fReadSource != NULL) return True; // has already been initiated

+   netAddressBits savedReceivingInterfaceAddr = ReceivingInterfaceAddr;
     do {
       if (fCodecName == NULL) {
         env().setResultMsg("Codec is unspecified");
***************
*** 579,584 ****
--- 580,586 ----
       struct in_addr tempAddr;
       tempAddr.s_addr = connectionEndpointAddress();
           // This could get changed later, as a result of a RTSP "SETUP"
+     if (IsMulticastAddress(tempAddr.s_addr)) ReceivingInterfaceAddr 
= tempAddr.s_addr;

       if (fClientPortNum != 0) {
         // The sockets' port numbers were specified for us.  Use these:
***************
*** 892,897 ****
--- 894,900 ----
       return True;
     } while (0);

+   ReceivingInterfaceAddr = savedReceivingInterfaceAddr;
     delete fRTPSocket; fRTPSocket = NULL;
     delete fRTCPSocket; fRTCPSocket = NULL;
     Medium::close(fRTCPInstance); fRTCPInstance = NULL;
-- 

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/20101001/97ff23cd/attachment.html>

From zdenek at next-stream.com  Fri Oct  1 08:47:28 2010
From: zdenek at next-stream.com (Zdenek Bouresh)
Date: Fri, 1 Oct 2010 18:47:28 +0300
Subject: [Live-devel] Many multicast sources with same port problem
In-Reply-To: <f06240800c8cb8caa02b8@66.80.62.44>
References: <AANLkTim3jCqEP2CXb7Od04ZYsdKhsd3Sc6NjojqGMUC2@mail.gmail.com>
	<f06240800c8bbabdef973@66.80.62.44>
	<AANLkTim64hAYbWEWTvxqhG8UH02zaiyFU3UNB-iDU580@mail.gmail.com>
	<f06240800c8cb8caa02b8@66.80.62.44>
Message-ID: <AANLkTinra=kTP1HhNZ2YShVJReA-OATuvS7fgh+dgvH7@mail.gmail.com>

On Fri, Oct 1, 2010 at 5:05 PM, Ross Finlayson <finlayson at live555.com>wrote:

>  I have done some investigation on this issue and here are the results and
> suggestions.
>
>
> 1. You were right, it works on  freeBSD , but see 2.
>
>
> 2. This is not a Linux bug
>
>
> I guess we'll just have to disagree on this.
>
>
> We know that one should not bind() to a multicast address
>
>
> Agreed :-)
>
>
> , but according to the kernel developers and other multicast developers
> this is intended in case you want to receive only from one address and port
> and not all. It depends on whats needed, so no bug..
>
> .
>
> http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html<http://jungla.dit.upm.es/%7Ejmseyas/linux/mcast.lj/mcast-lj.html> (shows
> a bind is required)
>
> http://marc.info/?l=linux-netdev&m=121579883022264&w=2
>
> http://marc.info/?l=linux-netdev&m=121580189427089&w=2
>
>
>
> I don't agree with the arguments made here.  In particular:
>
>  That's how it has always worked in the original socket implementation
> (BSD) and derivatives.
>
>
> is most definitely not true, because (as you have discovered yourself) it
> doesn't work this way in FreeBSD.
>
> I also don't agree with the claim that "Multicast addresses, like unicast
> addresses, are for the entire
> machine, not just the socket that does the join", because the
> IP_ADD_MEMBERSHIP operation is explicitly done on a socket (i.e., using
> "setsockopt()").  It also seems wrong that a process should have the
> potential to - by joining a multicast group - control which packets that are
> received by a separate process.  (This is arguably a security violation.)
>
> In any case, this is all a moot point, because I'm not going to be changing
> the LIVE555 code to bind to the multicast address (when creating a multicast
> 'groupsock'), because in the past - when this suggestion has been made -
> some people have discovered and reported that it doesn't work for them.  It
> does not appear to be portable across different OSs, so I can't put it in
> the released code.  It's not inconceivable that sometime in the future I
> might make a change to support this, but have it #ifdef'd out by default.
> This is not a high priority, though, and the whole "groupsock" interface
> will eventually be replaced anyway (to make it more consistent with the
> "liveMedia" object model).  So it might not happen for a while, if ever.
> Sorry.
>

Thank you Ross,
I do agree about the portability issue and do undestand you reasons not
wanting to include it in main code.
Perhaps if it ever works, an ifdef solution may make the most sence.

As for the binding, the linux net folks have this undestanding, I am not
going to argue on that one, but explains why there is no officeal patch for
linux.



>
> In the meantime, you *might* be able to get the effect you want by making
> the following small change to "liveMedia/MediaSession.cpp", and also
> changing "groupsock/GroupsockHelper.cpp" to replace the line
>         if (port.num() == 0) addr = ReceivingInterfaceAddr;
> with
>         addr = ReceivingInterfaceAddr;
>
> (or, you could patch your Linux kernel :-)
>
> *** MediaSession.cpp.save       Fri Oct  1 05:49:35 2010
> --- MediaSession.cpp    Fri Oct  1 06:02:43 2010
> ***************
> *** 568,573 ****
> --- 568,574 ----
>   Boolean MediaSubsession::initiate(int useSpecialRTPoffset) {
>     if (fReadSource != NULL) return True; // has already been initiated
>
> +   netAddressBits savedReceivingInterfaceAddr = ReceivingInterfaceAddr;
>     do {
>       if (fCodecName == NULL) {
>         env().setResultMsg("Codec is unspecified");
> ***************
> *** 579,584 ****
> --- 580,586 ----
>       struct in_addr tempAddr;
>       tempAddr.s_addr = connectionEndpointAddress();
>           // This could get changed later, as a result of a RTSP "SETUP"
> +     if (IsMulticastAddress(tempAddr.s_addr)) ReceivingInterfaceAddr =
> tempAddr.s_addr;
>
>       if (fClientPortNum != 0) {
>         // The sockets' port numbers were specified for us.  Use these:
> ***************
> *** 892,897 ****
> --- 894,900 ----
>       return True;
>     } while (0);
>
> +   ReceivingInterfaceAddr = savedReceivingInterfaceAddr;
>     delete fRTPSocket; fRTPSocket = NULL;
>     delete fRTCPSocket; fRTCPSocket = NULL;
>     Medium::close(fRTCPInstance); fRTCPInstance = NULL;
>
> --
>
>
>
Thanks for the provided patch, I was really looking for some guidance after
hours of unsuccessful mods to the Groupsock and binding but still same
behaiviour.
Unfortunately none has worked , neither does the above which really had me
hoping for a while.

Any ideas? Did it work for you when you tried it ?

I think the reason its not working is socket requires GroupAddress to bind
to in adition to ifaddress.

According to the linux folks the combination of mcastaddress:port is the one
we have to bind to isolate sockets, else binding on the interface we get all
traffic to all ports on the interface since we only bind to port without
desitnation.

In any case thanks for all your help, I will still be looking for some work
around in the groupsock and in my code before patching the kernel, but so
far no luck.

Does anyone know of a patch for kernles 2.6.29 and above ?

P.S is UDP performance in freeBSD 8.x poor or is it just me?

Thanks again.

Zed




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


-- 
Zdenek Bouresh
NextStream LTD.

The information contained within this email transmission and any attachments
is confidential and intended solely for the attention and use of the named
individual addressee(s) or entity. It may not be legally revealed or be
disclosed to any other person or third party without the express authority
(prior written approval) of NextStream LTD and/or the original recipient, or
the intended recipients, or both. If you are not the intended recipient, you
must not disclose, copy, distribute, print, rely on or retain this message
or any part of it. The information contained within is strictly prohibited.
If you have received this email in error please notify the sender by reply,
and delete this message from your email system(s). Any hard copies must also
be destroyed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101001/b7c19575/attachment.html>

From mehran at stretchinc.com  Mon Oct  4 12:20:29 2010
From: mehran at stretchinc.com (Mehran Ansari)
Date: Mon, 4 Oct 2010 12:20:29 -0700 (PDT)
Subject: [Live-devel] Defintion of the ServerMediaSession and
 SeverMediaSubsession classed and their usage in relation with
 doGetNextFrame()
In-Reply-To: <239316268.4891286219794697.JavaMail.root@mail.stretchinc.com>
Message-ID: <341733677.4971286220028869.JavaMail.root@mail.stretchinc.com>

I am trying to understand the relationship and interaction of different Live555 classes so that I can implement an OnDemandRTSPServer to be able to send live video/audio frames that are generated by my encoder associated to different video port channels.

To start, I derived myOnDyanmicRTSPServer from RTSPServer. I also subclassed myDyanmicRTSPClientSession from RTSPServer::RTSPClientSession  within myOnDyanmicRTSPServer and implemented handlCmd_PLAY and handleCmd_TEARDOWN vitrual methods. Additionally, I implemented lookupServerMediaSession() virtual method in  myOnDyanmicRTSPServer. Now in lookupServerMediaSession() I checked to see if the channel name in the URI passed to this method does not exist then I created a ServerMediaSession and added addSubsession() for the corresponding video codec and dataport on my video board for the channel specified in the URI. Now when handleCmd_PLAY() or handleCmd_TEARDOWN is called I start/stop my video encoder for that particular video data port. Lastly when doGetNextFrame() is called in my my sub-classed VideoStreamFramer, I get the frame provided by my video encoder and copy it to  fTo buffer and call afterGetting() to inform the sink the frame was obtained.

My Questions are:

1) What is the relationship between the ServerMediaSession and SeverMediaSubsession? What is the rule of each of these classes? My understanding is that their relationship in case video only is one to one. I create a ServerMediaSession for a particular video port channel requested by the RTSP URI DESCRIBE command, then add the associated video encoder which is my SeverMediaSubsession to this ServerMediaSession. I also think that if I had audio I would have added a audio SeverMediaSubsession. But is it possible that there are more than one audio or video SeverMediaSubsession to be associated to a ServerMediaSession. If yes, what is the purpose of it?

2) I need to know when to start/stop my video encoder. Currently, I do this by sub-classing RTSPServer::RTSPClientSession and handling the handlCmd_PLAY and handleCmd_TEARDOWN. Is this the correct place or should I sub-class the ServerMediaSubsession class and handle startStream() and deleteStream() virtual methods?

3) How does clientSessionId that is passed to various xxxStream() methods (i,e, startStream(), deleteStream()) relates to a particular URI associated to a ServerMediaSession?

4) Lastly, how do I relate doGetNextFrame(), that is called by the framer to get the next video frame, to the channel name as it was specified in the RTSP URI command Play?

Thanks for your help.

From dilip1984me at gmail.com  Mon Oct  4 14:05:48 2010
From: dilip1984me at gmail.com (dilip raghavan)
Date: Mon, 4 Oct 2010 17:05:48 -0400
Subject: [Live-devel] TestOnDemandRTSPServer Help
Message-ID: <AANLkTim4cT0twcmR_qn=PhDGXfrL5ZJ7uADZGOxOmV7z@mail.gmail.com>

Hi,
    I am new to live 555.  Could someone to me how to use the test program
TestOnDemandRTSPServer.  I compiled and executed this test program. All it
gave was a list of urls. But I am not able to play any video from that url.
Help required immediately please.  Thanks  a   lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101004/12b4566a/attachment.html>

From finlayson at live555.com  Mon Oct  4 16:15:08 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 4 Oct 2010 16:15:08 -0700
Subject: [Live-devel] Defintion of the ServerMediaSession and
 SeverMediaSubsession classed and their usage in relation with
 doGetNextFrame()
In-Reply-To: <341733677.4971286220028869.JavaMail.root@mail.stretchinc.com>
References: <341733677.4971286220028869.JavaMail.root@mail.stretchinc.com>
Message-ID: <f0624080ac8d006a21d62@[66.80.62.44]>

>Additionally, I implemented lookupServerMediaSession() virtual 
>method in  myOnDyanmicRTSPServer. Now in lookupServerMediaSession() 
>I checked to see if the channel name in the URI passed to this 
>method does not exist then I created a ServerMediaSession and added 
>addSubsession()

If you haven't already done so, I suggest that you take a look at the 
code for "DynamicRTSPServer" (a "RTSPServer" subclass) in the 
"mediaServer" directory (the code for the "LIVE555 Media Server" 
product).  It does very much the same thing.


>My Questions are:
>
>1) What is the relationship between the ServerMediaSession and 
>SeverMediaSubsession?

Together, these two classes provide the server's implementation of a 
particular type of stream.  "ServerMediaSession" is just a container; 
it contains one or more "ServerMediaSubsession" objects.  For 
example, for a stream that consists of an audio substream and a video 
substream, the "ServerMediaSession" object will contain two 
"ServerMediaSubsession" objects - one for the audio substream; the 
other for the video substream.

You will usually need to subclass only "ServerMediaSubsession". 
Specifically, because you are streaming via unicast, you should 
subclass "OnDemandServerMediaSubsession" (once for your video 
substream, and again for an audio substream, if you have one).  You 
will need to provide your own implementations of the 
"createNewStreamSource()" and "createNewRTPSink()" pure virtual 
functions.  (Note the several examples of this already in the code.)

Also, because you are streaming from a live encoder, rather than from 
a file, be sure to set the "reuseFirstSource" parameter to True (so 
that your encoder object is read from only once, regardless of how 
many clients are accessing the stream).


>2) I need to know when to start/stop my video encoder. Currently, I 
>do this by sub-classing RTSPServer::RTSPClientSession and handling 
>the handlCmd_PLAY and handleCmd_TEARDOWN. Is this the correct place

No.  In most situations you should not need to modify the 
"RTSPServer" code's existing implementation of RTSP commands. 
Instead, special-case handling for RTSP commands can be done in the 
"ServerMediaSubsession" subclasses.


>  or should I sub-class the ServerMediaSubsession class and handle 
>startStream() and deleteStream() virtual methods?

You could do this, but I don't recommend it.  Instead, I suggest just 
doing this in your implementation of your encoder class's 
"doGetNextFrame()" virtual function, and its destructor.  In 
particular, your encoder class's "doGetNextFrame()" implementation 
could start the encoder when it's called for the first time.  Your 
encoder class's destructor can stop the encoder.


>3) How does clientSessionId that is passed to various xxxStream() 
>methods (i,e, startStream(), deleteStream()) relates to a particular 
>URI associated to a ServerMediaSession?

This is handled automatically by the RTSP server implementation.  You 
should not need to care about this.


>4) Lastly, how do I relate doGetNextFrame(), that is called by the 
>framer to get the next video frame, to the channel name as it was 
>specified in the RTSP URI command Play?

Your "ServerMediaSubsession" subclass should have a "encoder name" 
parameter in its "createNew()" function.  That way, when you create a 
new "ServerMediaSubsession" (subclass) object (in your 
reimplementation of "lookupServerMediaSubsession()", you can pass it 
this parameter, which it will remember (as a field).  Then, your 
implementation of the "createNewStreamSource()" virtual function can 
map this "encoder name" field to a particular encoder, when it 
creates source object(s) for the stream.

Look, for example, at the implementation of the 
"MP3AudioFileServerMediaSubsession" class (which implements streaming 
from a particular named MP3 file), and how this is used in the 
"testOnDemandRTSPServer" and "live555MediaServer" applications.

By the time your encoder class's "doGetNextFrame()" implementation 
gets called, the encoder object should already know which encoder 
it's going to use.  As I noted above, when "doGetNextFrame()" gets 
called for the first time, it can start the encoder.
-- 

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

From finlayson at live555.com  Mon Oct  4 21:59:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 4 Oct 2010 21:59:56 -0700
Subject: [Live-devel] TestOnDemandRTSPServer Help
In-Reply-To: <AANLkTim4cT0twcmR_qn=PhDGXfrL5ZJ7uADZGOxOmV7z@mail.gmail.com>
References: <AANLkTim4cT0twcmR_qn=PhDGXfrL5ZJ7uADZGOxOmV7z@mail.gmail.com>
Message-ID: <f06240803c8d05fcbb5de@[66.80.62.44]>

>Hi,
>     I am new to live 555.  Could someone to me how to use the test 
>program TestOnDemandRTSPServer.  I compiled and executed this test 
>program. All it gave was a list of urls. But I am not able to play 
>any video from that url. Help required immediately please.

I very much doubt that you require help 'immediately', especially 
considering that your use of a "@gmail.com" email address tells the 
world that you are just a casual hobbyist.  (Serious professionals do 
not use "@gmail.com" addresses.)

But anyway, to play these "rtsp://" URLs, you need a media player 
like VLC <http://www.videolan.org/vlc/>.  Plus, of course, you need 
to have a file of the given name, of the appropriate type, in the 
same directory as "testOnDemandRTSPServer".  (For example, to play 
the "mp3AudioTest" URL, you'll need a MP3 file named "test.mp3".)
-- 

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

From mehran at stretchinc.com  Tue Oct  5 17:15:13 2010
From: mehran at stretchinc.com (Mehran Ansari)
Date: Tue, 5 Oct 2010 17:15:13 -0700 (PDT)
Subject: [Live-devel] Question regarding ParseRTSPRequestString() and
 URLSuffix/URLPreSuffix
In-Reply-To: <1001395682.8441286324001211.JavaMail.root@mail.stretchinc.com>
Message-ID: <1010382878.8521286324113252.JavaMail.root@mail.stretchinc.com>

It seems to me the ParseRTSPRequestString() only handles one specific RTSP URI format and does not handle the generic allowed format. According to RFC2326  syntax and semantics for RTSP URLs is:


   rtsp_URL  =   ( "rtsp:" | "rtspu:" )
                 "//" host [ ":" port ] [ abs_path ]
   host      =   <A legal Internet host domain name of IP address
                 (in dotted decimal form), as defined by Section 2.1
                 of RFC 1123 \cite{rfc1123}>
   port      =   *DIGIT

   abs_path is defined in [H3.2.1].

This means I should be allowed to have a rtsp_URL of:
   
   RTSP://192.168.1.20:8554/PSIA/Streaming/channels/0 

But this function parses this URL as URLSuffix="0" and URLPreSuffix="channels"

I modified this function such that it sets URLSuffix="PSIA/Streaming/channels/0" and URLPreSuffix="192.168.1.20:8554"
and named my session to be the value of URLSuffix. Now I am having problem with RTSP_cmd_setup as the openRTCP client appends "track1" to the URL which makes this session non-existent. Then I realized that is the reason you have URLSuffix and URLPreSuffix to remove "track1" and see the actual URL.

In my server I won't have different tracks and according to the RFC 2326: 

   If the presentation comprises only a single stream, the media-level
   "a=control:" attribute may be omitted altogether.

Is there any way for me to disable this appending of "track1" to the URL? I mean, other than actually deleting it from the sdpFmt in OnDemandServerMediaSession.cpp. If I do this would I cause other problem?

Thank you for any help you can give me in this regard.

--Mehran

From finlayson at live555.com  Tue Oct  5 18:43:49 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 5 Oct 2010 18:43:49 -0700
Subject: [Live-devel] Question regarding ParseRTSPRequestString() and
 URLSuffix/URLPreSuffix
In-Reply-To: <1010382878.8521286324113252.JavaMail.root@mail.stretchinc.com>
References: <1010382878.8521286324113252.JavaMail.root@mail.stretchinc.com>
Message-ID: <f06240800c8d17dc5d8fb@[66.80.62.44]>

You shouldn't worry about the server returning "a=control:track1" in 
the SDP description, and thus having "/track1" appended to the 
control URL that RTSP clients use internally, when sending a RTSP 
"SETUP" command.  RTSP clients do this automatically, and it doesn't 
affect the URL that you give the client originally.

Your problem is that you are trying to use a session name that 
contains "/" characters.  Our RTSP server code currently does not 
support this, so you shouldn't do this.
-- 

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

From sebastien-devel at celeos.eu  Wed Oct  6 01:38:21 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Wed, 06 Oct 2010 10:38:21 +0200
Subject: [Live-devel] Callback not being called in case of unknown response
Message-ID: <1286354301.4cac357d12af5@imp.celeos.eu>



Hi,

In some cases, my callbacks are not called and my application hang.
It happens when live555 does not recognize the response of the RTSP server.

The logs say :
Received a complete (unknown) response:
RTSP/1.0 404 Not found

In this case, in RTSPClient.cpp line 1556 foundRequest is NULL and the user
callback is never called.
foundRequest is NULL because the response does not include a CSeq value.
Would there be a way to tell the application we received something invalid in
this case ?

Sebastien.


From finlayson at live555.com  Wed Oct  6 02:38:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Oct 2010 02:38:50 -0700
Subject: [Live-devel] Callback not being called in case of unknown
 response
In-Reply-To: <1286354301.4cac357d12af5@imp.celeos.eu>
References: <1286354301.4cac357d12af5@imp.celeos.eu>
Message-ID: <f06240800c8d1f018f31b@[66.80.62.44]>

>foundRequest is NULL because the response does not include a CSeq value.

Can you fix the server? :-)


>Would there be a way to tell the application we received something invalid in
>this case ?

Mumble...  Probably.  In principle, each request is supposed to have 
a corresponding response, and responses are supposed to come back in 
order, so if the response doesn't include a CSeq - but is otherwise 
valid - then we can generally assume that it was intended for the 
first request in the 'awaiting reponse' queue.

So, if you change line 1448 from
           } else if (request->cseq() == cseq) {
to
           } else if (request->cseq() == cseq || cseq == 0) {
then things should work in this case.
-- 

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

From sebastien-devel at celeos.eu  Wed Oct  6 07:33:04 2010
From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier)
Date: Wed, 06 Oct 2010 16:33:04 +0200
Subject: [Live-devel] Callback not being called in case of unknown
 response
In-Reply-To: <f06240800c8d1f018f31b@[66.80.62.44]>
References: <1286354301.4cac357d12af5@imp.celeos.eu>
	<f06240800c8d1f018f31b@[66.80.62.44]>
Message-ID: <1286375584.7176.23.camel@sebastien-desktop>

On Wed, 2010-10-06 at 02:38 -0700, Ross Finlayson wrote:
> >foundRequest is NULL because the response does not include a CSeq value.
> 
> Can you fix the server? :-)

I'll try :)

> So, if you change line 1448 from
>            } else if (request->cseq() == cseq) {
> to
>            } else if (request->cseq() == cseq || cseq == 0) {
> then things should work in this case.

It can't work like that because we don't reach this code because of :
checkForHeader(lineStart, "CSeq:", 5, headerParamsStr)

But I have another solution. line 1482, replace :

if (foundRequest == NULL && responseIsHTTP) {
// Hack: HTTP responses don't have a "CSeq:" header, so if we got a HTTP response, assume it's for our most recent request:

by

if (foundRequest == NULL) {
 // Hack: The response don't have a "CSeq:" header, assume it's for our most recent request:

Would you accept this change for the next version ?



From finlayson at live555.com  Wed Oct  6 14:13:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Oct 2010 14:13:20 -0700
Subject: [Live-devel] Callback not being called in case of unknown
 response
In-Reply-To: <1286375584.7176.23.camel@sebastien-desktop>
References: <1286354301.4cac357d12af5@imp.celeos.eu>
	<f06240800c8d1f018f31b@[66.80.62.44]>
	<1286375584.7176.23.camel@sebastien-desktop>
Message-ID: <f06240801c8d296d18177@[66.80.62.44]>

>But I have another solution. line 1482, replace :
>
>if (foundRequest == NULL && responseIsHTTP) {
>// Hack: HTTP responses don't have a "CSeq:" header, so if we got a 
>HTTP response, assume it's for our most recent request:
>
>by
>
>if (foundRequest == NULL) {
>  // Hack: The response don't have a "CSeq:" header, assume it's for 
>our most recent request:
>
>Would you accept this change for the next version ?

OK, I've now installed a new version (2010.10.06) of the code that 
includes this change.
-- 

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

From eyals at aeronautics-sys.com  Thu Oct  7 02:19:04 2010
From: eyals at aeronautics-sys.com (Eyal Shveky)
Date: Thu, 7 Oct 2010 11:19:04 +0200
Subject: [Live-devel] Compile live555 in vsts 2008
Message-ID: <10C6D4821E0BAA44A73B987733947B16BF14AA@OREV.ads.local>

Hi ,

 

I compiled live555 in windows using instructions in your site, build the
following libraries :

*         libBasicUsageEnvironment.lib

*         libgroupsock.lib

*         libliveMedia.lib

*         libUsageEnvironment.lib

 

and exe's

*         openRTSP.exe

*         live555MediaServer.exe

*         MPEG2TransportStreamIndexer.exe

*         playSIP.exe

*         sapWatch.exe

*         vobStreamer.exe

*         also all tests exe's

 

How can I create a live555 solution/project in vsts2008?

Or use the libraries above from a c# project?

Thanks

 

    Shveky Eyal

Software Engineer at Aeronautics

E-Mail: eyals at aeronautics-sys.com <mailto:eyals at aeronautics-sys.com> 

Ext: +972-8-9433600 #731

 

**********************************************************************************************
LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes, 
any subsequent correspondence, and any document, data, sketches, plans and/or other material that is 
hereby attached, are proprietary. confidential and may be legally privileged. 
Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or 
make it subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase Order.
This transmission is intended for the named addressee only. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any 
disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is 
unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately.

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/9a4c8668/attachment-0001.html>

From gbonneau at miranda.com  Thu Oct  7 07:20:04 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Thu, 7 Oct 2010 14:20:04 +0000
Subject: [Live-devel] Compile live555 in vsts 2008
In-Reply-To: <10C6D4821E0BAA44A73B987733947B16BF14AA@OREV.ads.local>
References: <10C6D4821E0BAA44A73B987733947B16BF14AA@OREV.ads.local>
Message-ID: <8691AB8A396ED446A4D01C69CE2F5D3F040F36C9@CA-OPS-MAILBOX.miranda.com>

I already posted that Visual Studio 2008 solution file a few months that you can find in the archive. It compiles in Visual Studio the live555 library and all the testing applications. I repost it because the linking configuration had to be changed to remove dependency with the DLL of Visual Studio 2008 run time.


Make sure you have the latest library dated 8 Mars 2010.



If you want to debug OpenRTSP for example :



1-            Unzip the latest live555 library to a folder were you want the library. The main folder should be "live" but could be renamed if you want.

2-            Inside the main folder "live" unzip the included archive and copy the Visual2008 Folder as a new folder inside the main "live" folder

3-            Open the live.sln solution in folder Visual2008 file with either Visual Studio Express 2008 or Visual Studio Professional 2008.

4-            Compile the solution

5-            Set OpenRTSP as the startup project

6-            Configure you openRTSP command arguments

7-            Debug!



You will have 1 link error with project testGSMStreamer when you compile the solution. But this is normal because a class is purposely not defined for this project. Otherwise all other projects will compile fine either in release or debug mode.



Some unused artifact might be present in the preprocessor definition for the projects but it shouldn't be harmful. If anyone on the list find a problem or have any suggestion let me know!



Regards

Guy Bonneau




From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Eyal Shveky
Sent: Thursday, October 7, 2010 5:19
To: live-devel at ns.live555.com
Subject: [Live-devel] Compile live555 in vsts 2008

Hi ,

I compiled live555 in windows using instructions in your site, build the following libraries :

*         libBasicUsageEnvironment.lib

*         libgroupsock.lib

*         libliveMedia.lib

*         libUsageEnvironment.lib

and exe's

*         openRTSP.exe

*         live555MediaServer.exe

*         MPEG2TransportStreamIndexer.exe

*         playSIP.exe

*         sapWatch.exe

*         vobStreamer.exe

*         also all tests exe's

How can I create a live555 solution/project in vsts2008?
Or use the libraries above from a c# project?
Thanks

    Shveky Eyal
Software Engineer at Aeronautics
E-Mail: eyals at aeronautics-sys.com<mailto:eyals at aeronautics-sys.com>
Ext: +972-8-9433600 #731

________________________________
LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes,
any subsequent correspondence, and any document, data, sketches, plans and/or other material that
is hereby attached, are proprietary confidential and may be legally privileged.
Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or
make it subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.
This transmission is intended for the named addressee only. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any
disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is
unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/5472a55d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Visual2008.zip
Type: application/x-zip-compressed
Size: 40908 bytes
Desc: Visual2008.zip
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/5472a55d/attachment-0001.bin>

From a.nemec at atlas.cz  Thu Oct  7 07:43:50 2010
From: a.nemec at atlas.cz (=?UTF-8?B?QWxleGFuZHIgTsSbbWVj?=)
Date: Thu, 07 Oct 2010 16:43:50 +0200
Subject: [Live-devel] Compile live555 in vsts 2008
In-Reply-To: <10C6D4821E0BAA44A73B987733947B16BF14AA@OREV.ads.local>
References: <10C6D4821E0BAA44A73B987733947B16BF14AA@OREV.ads.local>
Message-ID: <1286462630.138442.24743.nullmailer@mail1005.cent>

Hi,

you cannot do this directly (or I am not aware of how it could be done), but there are some approaches that may be used. Some months ago we used live555 code in VS 2005 in a .NET project.

1. If you intend to use some features only, you can create a dynamic link library (dll) in Visual C++, link to the libs you created and use P/Invoke from C# (or other .NET language). But since live555 is object based, this is unlikely to be enough for you.

2. Use managed C++ to create wrapper classes for live555 objects. Thus you will get reusable classes for direct use in C#. Some coding is necessary for this, but as long as the interface of live555 classes stays compatible in future versions, you do this only once.

Best regards
Alex

______________________________________________________________
> Od: "Eyal Shveky" 
> Komu: 
> Datum: 07.10.2010 14:31
> P?edm?t: [Live-devel] Compile live555 in vsts 2008
>


Hi ,

?

I compiled live555 in windows using instructions in your site, build the following libraries :

????????? libBasicUsageEnvironment.lib

????????? libgroupsock.lib

????????? libliveMedia.lib

????????? libUsageEnvironment.lib

?

and exe's

????????? openRTSP.exe

????????? live555MediaServer.exe

????????? MPEG2TransportStreamIndexer.exe

????????? playSIP.exe

????????? sapWatch.exe

????????? vobStreamer.exe

????????? also all tests exe's

?

How can I create a live555 solution/project in vsts2008?

Or use the libraries above from a c# project?

Thanks

?

??? Shveky Eyal

Software Engineer at Aeronautics

E-Mail: eyals at aeronautics-sys.com

Ext: +972-8-9433600 #731

?



LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes, 
any subsequent correspondence, and any document, data, sketches, plans and/or other material that
is hereby attached, are proprietary confidential and may be legally privileged.
Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or 
make it subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase Order.
This transmission is intended for the named addressee only. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any 
disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is 
unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately.
_______________________________________________ 
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/20101007/990ea62c/attachment.html>

From zdenek at next-stream.com  Thu Oct  7 07:17:35 2010
From: zdenek at next-stream.com (Zdenek Bouresh)
Date: Thu, 7 Oct 2010 17:17:35 +0300
Subject: [Live-devel] Monitoring and stats.
Message-ID: <AANLkTikEEFSGrvNfYW2rHD1CMuZ-ZP7ecYNVkhtGU8dg@mail.gmail.com>

Hello,
this may be a simple question but I still need your opinions suggestions and
advice.

How would one be be able to monitor all clients connected (count, IP, Client
session), their duration and subSession name say at an interval of 10
seconds.
I have based my apps the testOnDemandServer and want to see actual usage.
define Debug is nice, but does not really do it for me.
I was thinking of getting the HashTable with client sessions, but I am
facing several issues: 1. how do I call it ? 2. How to iterate thought it,
and also it does not really contain all the metrics one would want to see.
Also all connects and disconnects would be nice. I can put this in the
RTSPSrver code, but is there a way to call this some how without changing
the code ?

Additionally how do I use the GroupSock statistics for traffic, could not
find and example for this anywhere.
I want to display bandwidth usage for incoming multicast and outgoing
unicast traffic for example.
I know how to schedule an event every xxxxxx milliseconds, but need help on
getting the data.

Any advice, code hints or fragments anyone can share will be appreciated ?

Thanks,
Zed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/023a0c5b/attachment-0001.html>

From iain at idcl.co.uk  Thu Oct  7 09:12:12 2010
From: iain at idcl.co.uk (iain)
Date: Thu, 7 Oct 2010 17:12:12 +0100
Subject: [Live-devel] Newbie with a DirectShow headache
Message-ID: <00f301cb663a$66d7dbf0$348793d0$@idcl.co.uk>

I'm currently trying to get a Live555 DirectShow RTSP working correctly
(http://sourceforge.net/projects/rtspdirectshow/).

 

After a certain amount of tweaking of the code I've got it to compile and
basically work - that is it can stream from an RTSP compatible source.

 

The two issues at this point were firstly, that pause backed up samples
until a 400 frame buffer was full and released them in a splurge (sorry
about the technical term!) and more critically, once the filter stopped
(either by calling Stop() or by a timeout when paused) it would never start
again.

 

In addition to that it's still more than a little bit flaky when going
through Start/Pause/Start/Pause and other scenarios, with sockets locking
up, virtual functions appearing to be missing and other miscellanea.

 

I've made some progress with diagnosing the Stopped problem (an event handle
in a circular buffer wasn't being reset, so when restarted, the code found
no the buffer was signalled, but with no samples so immediately stopped the
thread before any samples had a chance to arrive).  However, that's only a
partial fix since although the source is now delivering samples with no
errors, the graph is not rendering them (and I have no idea why not).

 

I am quite experienced in DirectShow, but this is my first time with
Live555.

 

I've got two requests, really.  Firstly, has anyone got this to work
properly or can they recommend an alternative (open source) which works
reliably.

 

Secondly, the documentation for Live555 is a touch on the light side,
however I have found some references to tutorials
(http://www.mail-archive.com/live-devel at lists.live555.com/msg00238.html),
however the referenced link does not appear to exist anymore.  Does anyone
have a copy of this.

 

Allied to that, I can more or less see how the RTSP control stream works,
but I can't figure out what it is that starts the communication to receive
any RTP or other payload.

 

Any assistance would be VERY gratefully received.

 

Iain

 

Description: iain-downs-logo

 

01423 872988  -  http://www.idcl.co.uk <http://www.idcl.co.uk/> 

 

Iain Downs Consulting Limited is registered in the UK with number 329446

at The Old Coachhouse, Rear Eastville Terrace, Harrogate HG1 4HJ

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/0a8b98a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3773 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/0a8b98a5/attachment-0001.gif>

From jnoring at logitech.com  Thu Oct  7 11:34:46 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 7 Oct 2010 11:34:46 -0700
Subject: [Live-devel] Newbie with a DirectShow headache
In-Reply-To: <00f301cb663a$66d7dbf0$348793d0$@idcl.co.uk>
References: <00f301cb663a$66d7dbf0$348793d0$@idcl.co.uk>
Message-ID: <AANLkTi=fTmSjiUVNt02BsDJKHOz0c8m3YJ1kHAu=Chww@mail.gmail.com>

On Thu, Oct 7, 2010 at 9:12 AM, iain <iain at idcl.co.uk> wrote:

> I?ve got two requests, really.  Firstly, has anyone got this to work
> properly or can they recommend an alternative (open source) which works
> reliably.
>

Hey Iain, long time no see.  :)  I also looked at that sourceforge project
when I was first trying to integrate Live555 into a DirectShow source
filter, and ultimately decided that their filter implementation was
horrible, which it is.  So I wrote an RTSP Source Filter using Live555 from
scratch, and it works fairly well.  I inherited from
CBaseFilter/CBaseOutputPin and made my own streaming threads (I used
QThread, but of course you can use any threading library you
like)--CSource/CSourceStream aren't well suited towards Live555.  I also
implemented IFileSourceFilter to aid testability.

As for Live555 code, I started with the openRTSP code (which implements an
RTSP client), hacked out most of the stuff I didn't care about and then
integrated that into the filter.   I generally connect twice to the
server--once to fetch media types so I can generate output pins, and a
second time to start streaming media--this is sort of a necessity if you're
going to test in GraphEdit.  However, I also put in a small hack to
IFileSourceFilter to do this in a single pull in my own app where it happens
fast enough that I can pull all at once.  Live555 is single-threaded, so I
have one thread that runs the openRTSP-ish code and plops samples into
queues based on media type--it's important to do all Live555 operations on a
single thread and not to block the Live555 thread in any way.  Then, I have
the streaming threads for the output pins service those queues.

However, getting timestamping working correctly has been (and continues to
be) an issue.  Live555 timestamps aren't accurate until the RTCP channel has
been sync-d up, so the first few frame that come through have invalid
timestamps.  And DirectShow's timestamping for live sources sucks in
general--I have yet to make heads or tails of it.  If you have any good
advice for getting timestamping working better in DShow, that'd be awesome.


> Secondly, the documentation for Live555 is a touch on the light side,
> however I have found some references to tutorials (
> http://www.mail-archive.com/live-devel at lists.live555.com/msg00238.html),
> however the referenced link does not appear to exist anymore.  Does anyone
> have a copy of this.
>

My biggest recommendation, if you want to stream H264, is to completely
disregard that guy's code.  It's profoundly incorrect (particularly if
you're writing a server component), and I made the mistake of following it
as well.  Your best resource is definitely openRTSP code, the FAQ on
Live555's site, and the mailing list here.

Are you writing a server filter as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/4a76d925/attachment.html>

From john.orr at scala.com  Thu Oct  7 12:12:00 2010
From: john.orr at scala.com (John Orr)
Date: Thu, 07 Oct 2010 15:12:00 -0400
Subject: [Live-devel] Newbie with a DirectShow headache
Message-ID: <4CAE1B80.3030200@scala.com>

  Iain,

I played with that same rtspdirectshow sourceforge project a few months 
back while trying to get my feet wet on live555 and apply it to 
DirectShow.  That project is certainly not cooked all the way.  It been 
a while, but I think the author there struggled with parsing out proper 
media characteristics for video (like width and height).  If I recall 
correctly, they hard coded width and height on their video out pin.

The author there apparently borrowed some parts from the RTSP client 
code from VLC.  The code in the wrapper's live.cpp module is obviously a 
modified version of vlc/modules/demux/live555.cpp.  FWIW, in 
vlc/modules/access/rtsp/access.c, you also see some similar code.

That code doesn't implement a formal live555 "sink" object, which would 
be more in line with recommendations you'll find on this list:

http://www.live555.com/liveMedia/faq.html#control-flow
http://lists.live555.com/pipermail/live-devel/2010-June/012199.html




I did come across a better open source directshow source filter that 
uses a sink object:

http://videoprocessing.sourceforge.net/

There are a handful of DirectShow filters in there, one is an 
rtspsourcefilter built on live555.  I think at the moment it's audio 
only, but adding other media types shouldn't be that hard.  I found this 
code quite a bit better than the other project although it does have 
other flaws.  I recall that I hit some multithreading issues in some 
edge cases while starting and shutting down.

--Johno



From mehran at stretchinc.com  Thu Oct  7 14:02:50 2010
From: mehran at stretchinc.com (Mehran Ansari)
Date: Thu, 7 Oct 2010 14:02:50 -0700 (PDT)
Subject: [Live-devel] Question regarding ParseRTSPRequestString() and
 URLSuffix/URLPreSuffix
In-Reply-To: <299746820.7971286484874302.JavaMail.root@mail.stretchinc.com>
Message-ID: <1897146063.8121286485370130.JavaMail.root@mail.stretchinc.com>

Unfortunately, the RTSP server that I am implementing is for an IP Camera that should support PSIA conformance client. PSIA requires handling of fully qualified path in URL. I changed parseRTSPRequestString() in RTSPCommon.cpp to support the fully qualified path. 

To minimize the change, I am checking to see if the last component of the URL is "/track", if so, I set the resultURLSuffix to "track[xx]" and resultURLPreSuffix to have everything after the <host address xx.yy.zz.aa> upto "/track". Otherwise,  resultURLPreSuffix  is NULL and resultURLSuffix equal to everything after the <host address xx.yy.zz.aa> up to the space before next "RTSP/". 

This changed seemed to have fixed my problem. Do you see any problem with this change? Also are you planning to add fully qualified path to the URL in any of the future versions?

Thanks
--Mehran

From jnoring at logitech.com  Thu Oct  7 14:11:08 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 7 Oct 2010 14:11:08 -0700
Subject: [Live-devel] Newbie with a DirectShow headache
In-Reply-To: <4CAE1B80.3030200@scala.com>
References: <4CAE1B80.3030200@scala.com>
Message-ID: <AANLkTikfRXEZY02zH-BTLGjdxw6JXV0KSr45zofsms88@mail.gmail.com>

On Thu, Oct 7, 2010 at 12:12 PM, John Orr <john.orr at scala.com> wrote:

>  Iain,
>
> I played with that same rtspdirectshow sourceforge project a few months
> back while trying to get my feet wet on live555 and apply it to DirectShow.
>  That project is certainly not cooked all the way.  It been a while, but I
> think the author there struggled with parsing out proper media
> characteristics for video (like width and height).  If I recall correctly,
> they hard coded width and height on their video out pin.
>

Ah, yeah--I forgot about that.  For H264, you really need to write some code
to parse the SPS/PPS information that's present in the SDP exchange to get
the video resolution--same principle applies for AAC.  Or if the RTSP server
(incorrectly) sends it in-stream, sniff until you find it, parse, and then
you can generate output pins.  Live555, of course, lets you get this info
assuming your server H264 RTSP implementation isn't braindead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/05fc00d8/attachment.html>

From finlayson at live555.com  Thu Oct  7 17:27:15 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Oct 2010 17:27:15 -0700
Subject: [Live-devel] Monitoring and stats.
In-Reply-To: <AANLkTikEEFSGrvNfYW2rHD1CMuZ-ZP7ecYNVkhtGU8dg@mail.gmail.com>
References: <AANLkTikEEFSGrvNfYW2rHD1CMuZ-ZP7ecYNVkhtGU8dg@mail.gmail.com>
Message-ID: <f06240800c8d414efc266@[66.80.62.44]>

>How would one be be able to monitor all clients connected (count, 
>IP, Client session), their duration and subSession name say at an 
>interval of 10 seconds.

I suggest subclassing "RTSPServer" and "RTSPClientSession".  Have 
your "RTSPServer" subclass maintain a set of "RTSPClientSession" 
(subclass) objects, and iterate through this set periodically.  You 
can add the fields (metrics) that you want to "RTSPClientSession" by 
subclassing it.

>  I can put this in the RTSPServer code, but is there a way to call 
>this some how without changing the code ?

Yes - by subclassing!  That's the proper way to extend the existing 
"RTSPServer" code.  You should *not* need to modify the supplied code.
-- 

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

From finlayson at live555.com  Thu Oct  7 17:47:48 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Oct 2010 17:47:48 -0700
Subject: [Live-devel] Newbie with a DirectShow headache
In-Reply-To: <AANLkTikfRXEZY02zH-BTLGjdxw6JXV0KSr45zofsms88@mail.gmail.com>
References: <4CAE1B80.3030200@scala.com>
	<AANLkTikfRXEZY02zH-BTLGjdxw6JXV0KSr45zofsms88@mail.gmail.com>
Message-ID: <f06240800c8d419d6e88a@[66.80.62.44]>

>Ah, yeah--I forgot about that.  For H264, you really need to write 
>some code to parse the SPS/PPS information that's present in the SDP 
>exchange

Note that we already provide code to do this parsing; you don't need 
to write it yourself.

Just call "MediaSubsession:: fmtp_spropparametersets()" to get the 
SPS/PPS string, and then call "parseSPropParameterSets()" to parse 
it.  See, for example, the code for "H264VideoFileSink", which uses 
this.
-- 

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

From finlayson at live555.com  Thu Oct  7 17:53:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Oct 2010 17:53:20 -0700
Subject: [Live-devel] Question regarding ParseRTSPRequestString() and
 URLSuffix/URLPreSuffix
In-Reply-To: <1897146063.8121286485370130.JavaMail.root@mail.stretchinc.com>
References: <1897146063.8121286485370130.JavaMail.root@mail.stretchinc.com>
Message-ID: <f06240801c8d41b20360b@[66.80.62.44]>

>Unfortunately, the RTSP server that I am implementing is for an IP 
>Camera that should support PSIA conformance client. PSIA requires 
>handling of fully qualified path in URL

You have things backwards.  Just because a client is required to 
handle such "rtsp://" URLs (with "/" characters in the 'stream name' 
portion of the URL) doesn't necessarily mean that a server is 
required to generate such URLs.


>Also are you planning to add fully qualified path to the URL in any 
>of the future versions?

Maybe, but it's not a high-priority issue.
-- 

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

From jnoring at logitech.com  Thu Oct  7 19:50:02 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 7 Oct 2010 19:50:02 -0700
Subject: [Live-devel] Newbie with a DirectShow headache
In-Reply-To: <f06240800c8d419d6e88a@66.80.62.44>
References: <4CAE1B80.3030200@scala.com>
	<AANLkTikfRXEZY02zH-BTLGjdxw6JXV0KSr45zofsms88@mail.gmail.com>
	<f06240800c8d419d6e88a@66.80.62.44>
Message-ID: <AANLkTikc7A5u7fbJ6ZnEUZG=fY20RrFGuB2cCyXsjM22@mail.gmail.com>

On Thu, Oct 7, 2010 at 5:47 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Ah, yeah--I forgot about that.  For H264, you really need to write some
>> code to parse the SPS/PPS information that's present in the SDP exchange
>>
>
> Note that we already provide code to do this parsing; you don't need to
> write it yourself.
>
> Just call "MediaSubsession:: fmtp_spropparametersets()" to get the SPS/PPS
> string, and then call "parseSPropParameterSets()" to parse it.  See, for
> example, the code for "H264VideoFileSink", which uses this.
>
>
No, not just base-64 decode it, but actually _decode_ the SPS/PPS info.  You
do need to do this to get the properties of the incoming video, like
resolution, profile, level, etc.  It involves exponential golomb decoding
and following the H264 specification, and is generally necessary for most
media frameworks like DShow and GStreamer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101007/3dec4a5c/attachment-0001.html>

From rglobisch at csir.co.za  Fri Oct  8 01:08:35 2010
From: rglobisch at csir.co.za (Ralf Globisch)
Date: Fri, 08 Oct 2010 10:08:35 +0200
Subject: [Live-devel] Newbie with a DirectShow headache
Message-ID: <4CAEEDA30200004D0004A4A8@pta-emo.csir.co.za>

Hi Iain,


Here's my two cents on the topic: 


Ross, I hope this is not too OT but it is closely related to live555
since it concerns the integration with DirectShow.


The problem of integrating live555 and DirectShow consists of two main aspects:
- DirectShow requires you to "know" the media type in order to setup a 
DirectShow media pipeline (generate output pins as Jeremy stated): You 
need to send an RTSP DESCRIBE to the server before your filter can 
generate an output pin and before GetMediaType is called. To send the DESCRIBE with live555
and process responses you need to start the live555 eventloop. 
Since this eventloop is blocking, you need to start it in a separate thread.


- Integration between live555 single-threaded eventloop and DirectShow's source 
filter eventloop via CSource::DoBufferProcessing): use some kind of shared queue or memory.


Also, it might be helpful search the mailing lists for topics related to a "watch variable". 
This allows you to control the live555 eventloop.


Like John stated, you can download our live555-based OS RTSP filter from sourceforge.
I'll explain the approach used in it: I decided to start a thread that is responsible only for 
the live555 RTSP related code in IFileSourceFilter::Load (This is your entry point when 
using WMP or GraphEdit/Studio). This thread will then issue RTSP requests like DESCRIBE. 
IFileSourceFilter::Load blocks on the result of this operation. Once the DESCRIBE is 
successful in obtaining media session parameters (SPS, PPS, or Channel,bits per second, 
etc for audio) I notify the blocked thread (IFileSourceFilter::Load) of the outcome so that 
it can either continue to setup the output pins or show an error message and cleanup. 
If the pin creation is successful the RTSP thread then goes on to call SETUP and PLAY 
and starts receiving RTP packets similar to Jeremy's description and adds them to a 
shared queue. In the case of failure, the live555 eventloop is ended.


Then in the DirectShow DoBufferProcessingLoop I check for new media packets and pass them
into the DirectShow pipeline. As Jeremy stated, one of the tricky bits is that the first couple
of packets in a stream do not have RTCP synchronised timestamps. Once the sync occurs,
you need to adjust your DirectShow timestamps to take this shift into account.
It's been one of the most frustrating parts for me as well.


> However, getting timestamping working correctly has been (and continues to
> be) an issue.  Live555 timestamps aren't accurate until the RTCP channel has
> been sync-d up, so the first few frame that come through have invalid
> timestamps.  And DirectShow's timestamping for live sources sucks in
> general--I have yet to make heads or tails of it.  If you have any good
> advice for getting timestamping working better in DShow, that'd be awesome.


Agreed, I have tried so many things and am still not sure, what is effective, redundant etc.
We seem to have got it working through lots of trial and error (at least in our test infrastructure). 
When we startup, the video and audio seem to sync correctly and play correctly.
>From my experience so far, live555 does a great job with the RTCP synchronisation.
We left a test system stream for days and the media was still in sync.


@John: I'd be interested in the flaws you found. It still only supports 
audio since my "real" work is keeping me rather busy... 


@Iain: Like John stated you can use it to add video, in fact the "original" RTSP source filter
that it's based on also contained H.263 video but due to company IP issues I had to strip out the video 
related code. I'm still planning to add some video support but have no timeframe as yet.


Hope this helps,
Ralf






-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.



From iain at idcl.co.uk  Fri Oct  8 02:40:59 2010
From: iain at idcl.co.uk (iain)
Date: Fri, 8 Oct 2010 10:40:59 +0100
Subject: [Live-devel] Newbie with a DirectShow headache
In-Reply-To: <4CAEEDA30200004D0004A4A8@pta-emo.csir.co.za>
References: <4CAEEDA30200004D0004A4A8@pta-emo.csir.co.za>
Message-ID: <01be01cb66cc$ea1ece00$be5c6a00$@idcl.co.uk>

Thanks to everyone for their help and pointers.

I've updated my client on the options from what you've said and recommend
that we restart from Ralf's filter (hey! Comments as well!).  

Ralf, I'll see if the client will allow me to post any updates (e.g. video)
back up to Sourceforge.  

Iain


From rglobisch at csir.co.za  Fri Oct  8 05:48:21 2010
From: rglobisch at csir.co.za (Ralf Globisch)
Date: Fri, 08 Oct 2010 14:48:21 +0200
Subject: [Live-devel]  Newbie with a DirectShow headache
Message-ID: <4CAF2F350200004D0004A4FB@pta-emo.csir.co.za>

Iain,> I've updated my client on the options from what you've said and recommend > that we restart from Ralf's filter (hey! Comments as well!).I hope the code is up to scratch, I just released it open source in the hope that someone integratingDirectShow and live555 might find it useful, sinceI found it difficult to get going being new to DirectShow and live555. Any feedback or criticism regarding design/correctness/efficiency would be appreciated.As for the comments, there's prob not enough but feel free to drop me a line on the forum if something is unclear.>Ralf, I'll see if the client will allow me to post any updates (e.g. video)> back up to Sourceforge.Great stuff, would be nice to add some functionality to the filter.Ralf




-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.



From rglobisch at csir.co.za  Fri Oct  8 07:05:03 2010
From: rglobisch at csir.co.za (Ralf Globisch)
Date: Fri, 8 Oct 2010 16:05:03 +0200
Subject: [Live-devel]  Newbie with a DirectShow headache
Message-ID: <AANLkTimE+cKEW2ua80=E0dHfOsfjJRW24htdUpbvV+FW@mail.gmail.com>

I apologise for my previous post, please disregard it: my mail client seems
to have stripped out all my line feeds somehow?!? Trying again with a different
client now...

I have just added the live555 code-base to our project source repository:
I realised that the newer versions of live555 are not compatible with it
since the RTSP client now uses asynchronous IO and this will make it
easier to stay in sync.

Ross, just to double check: this should be fine from the LGPL view point?

,> I've updated my client on the options from what you've said and recommend
> that we restart from Ralf's filter (hey! Comments as well!).

Iain, I hope the code is up to scratch, I just released it open source
in the hope that
someone integrating DirectShow and live555 might find it useful, since
I found it
difficult to get going being new to DirectShow and live555. Any
feedback or criticism
regarding design/correctness/efficiency would be appreciated.

As for the comments, there's probably not enough but feel free to drop me a line
on the forum if something is unclear.

>Ralf, I'll see if the client will allow me to post any updates (e.g. video)
> back up to Sourceforge.

Great stuff, would be nice to add some functionality to the filter.

Ralf

From sukhbir.singh20 at gmail.com  Fri Oct  8 05:15:41 2010
From: sukhbir.singh20 at gmail.com (Sukhbir Singh)
Date: Fri, 8 Oct 2010 17:45:41 +0530
Subject: [Live-devel] RTSP Server.
Message-ID: <AANLkTinXaEnQJKBxyZKYz0mm2rB_-_LHEoKALbim2VKK@mail.gmail.com>

Hi All,

I need to know that how many simultaneous RTSP Client requests can be
handled by mediaServer (RTSP Server for .m4e files)?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101008/67d10859/attachment.html>

From jnoring at logitech.com  Sat Oct  9 10:59:22 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Sat, 9 Oct 2010 10:59:22 -0700
Subject: [Live-devel] RTSP Server.
In-Reply-To: <AANLkTinXaEnQJKBxyZKYz0mm2rB_-_LHEoKALbim2VKK@mail.gmail.com>
References: <AANLkTinXaEnQJKBxyZKYz0mm2rB_-_LHEoKALbim2VKK@mail.gmail.com>
Message-ID: <AANLkTim3EFaRRG7_m=y0-Ga2f-DgENEEnzUbQ+ObEaDA@mail.gmail.com>

On Fri, Oct 8, 2010 at 5:15 AM, Sukhbir Singh <sukhbir.singh20 at gmail.com>wrote:

> Hi All,
>
> I need to know that how many simultaneous RTSP Client requests can be
> handled by mediaServer (RTSP Server for .m4e files)?
>
>
Depends on your server hardware, how much bandwidth you have, and the
bitrate of your .m4e files, so you're probably the person who's best able to
answer this question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101009/ac68e1cd/attachment.html>

From ivan.alen at uclouvain.be  Mon Oct 11 06:18:45 2010
From: ivan.alen at uclouvain.be (Ivan Alen Fernandez)
Date: Mon, 11 Oct 2010 15:18:45 +0200
Subject: [Live-devel] Error of the server running in Linux
Message-ID: <f8217d7651b0d73f8f7baf552d1df083.squirrel@mmp.sipr-dc.ucl.ac.be>

Hello i have solved the problem in linux by applying the variable #define
READ_FROM_FILES_SYNCHRONOUSLY 1, as by default for windows, within the
class ByteStreamFileSource.
Can anyone guess why from the last update in my code, i need this
modification in order to run properly the server? Does it damage a lot the
performance and scalability of the server? Just remember i am streaming
H264 sequences divided in multiple video files. When the buffer on the
server gets empty i use a xml script to decide the next video segment of
h264 to send and therefore to include in the buffer before.

Thanks a lot i advance for your help.


>>My problem is that i have done lately some modifications in the class
ByteStreamFileSource
> Rather than modifying the existing code, you should really define a
*new* class (perhaps copying much of the existing code).  That way, you
can easily upgrade to new versions of the released LIVE555
> library code.
>>  and for linux i have to run the player two times in
>>order that the video starts playing and after 20 seconds or so the
server
>>exits with the next error:
>>BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
> That error means that you closed a socket, but did not call
> "TaskScheduler:: turnOffBackgroundReadHandling()" beforehand.
> --
> 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 eyals at aeronautics-sys.com  Mon Oct 11 08:33:38 2010
From: eyals at aeronautics-sys.com (Eyal Shveky)
Date: Mon, 11 Oct 2010 17:33:38 +0200
Subject: [Live-devel] live-devel Digest, Vol 84, Issue 4
In-Reply-To: <mailman.4444.1286461181.874.live-devel@lists.live555.com>
References: <mailman.4444.1286461181.874.live-devel@lists.live555.com>
Message-ID: <10C6D4821E0BAA44A73B987733947B16BF16FB@OREV.ads.local>

Hi Guy

Thank you for your fast response. It's not easy to search the archive
for the correct "Visual Studio 2008 solution".

Can you please direct me to the right month or alternately send me a zip
of the solution.

 

Thanks Eyal

 

 

    Shveky Eyal

Software Engineer at Aeronautics

E-Mail: eyals at aeronautics-sys.com <mailto:eyals at aeronautics-sys.com> 

Ext:   +972-8-9433600 #731

Mobile   +972-52-2800868

 

 

Today's Topics:

 

   1. Re: Compile live555 in vsts 2008 (BONNEAU Guy)

 

 

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

 

Message: 1

Date: Thu, 7 Oct 2010 14:20:04 +0000

From: BONNEAU Guy <gbonneau at miranda.com>

Subject: Re: [Live-devel] Compile live555 in vsts 2008

To: LIVE555 Streaming Media - development & use

      <live-devel at ns.live555.com>

Message-ID:

 
<8691AB8A396ED446A4D01C69CE2F5D3F040F36C9 at CA-OPS-MAILBOX.miranda.com>

Content-Type: text/plain; charset="us-ascii"

 

I already posted that Visual Studio 2008 solution file a few months that
you can find in the archive. It compiles in Visual Studio the live555
library and all the testing applications. I repost it because the
linking configuration had to be changed to remove dependency with the
DLL of Visual Studio 2008 run time.

 

 

Make sure you have the latest library dated 8 Mars 2010.

 

 

 

If you want to debug OpenRTSP for example :

 

 

 

1-            Unzip the latest live555 library to a folder were you want
the library. The main folder should be "live" but could be renamed if
you want.

 

2-            Inside the main folder "live" unzip the included archive
and copy the Visual2008 Folder as a new folder inside the main "live"
folder

 

3-            Open the live.sln solution in folder Visual2008 file with
either Visual Studio Express 2008 or Visual Studio Professional 2008.

 

4-            Compile the solution

 

5-            Set OpenRTSP as the startup project

 

6-            Configure you openRTSP command arguments

 

7-            Debug!

 

 

 

You will have 1 link error with project testGSMStreamer when you compile
the solution. But this is normal because a class is purposely not
defined for this project. Otherwise all other projects will compile fine
either in release or debug mode.

 

 

 

Some unused artifact might be present in the preprocessor definition for
the projects but it shouldn't be harmful. If anyone on the list find a
problem or have any suggestion let me know!

 

 

 

Regards

 

Guy Bonneau

 

 

 

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Eyal Shveky

Sent: Thursday, October 7, 2010 5:19

To: live-devel at ns.live555.com

Subject: [Live-devel] Compile live555 in vsts 2008

 

Hi ,

 

I compiled live555 in windows using instructions in your site, build the
following libraries :

 

*         libBasicUsageEnvironment.lib

 

*         libgroupsock.lib

 

*         libliveMedia.lib

 

*         libUsageEnvironment.lib

 

and exe's

 

*         openRTSP.exe

 

*         live555MediaServer.exe

 

*         MPEG2TransportStreamIndexer.exe

 

*         playSIP.exe

 

*         sapWatch.exe

 

*         vobStreamer.exe

 

*         also all tests exe's

 

How can I create a live555 solution/project in vsts2008?

Or use the libraries above from a c# project?

Thanks

 

    Shveky Eyal

Software Engineer at Aeronautics

E-Mail: eyals at aeronautics-sys.com<mailto:eyals at aeronautics-sys.com>

Ext: +972-8-9433600 #731

 

________________________________

LEGAL NOTICE - Unless expressly stated otherwise, this message, its
annexes, attachments, appendixes,

any subsequent correspondence, and any document, data, sketches, plans
and/or other material that

is hereby attached, are proprietary confidential and may be legally
privileged.

Nothing in this e-mail is intended to conclude a contract on behalf of
Aeronautics or

make it subject to any other legally binding commitments, unless the
e-mail

contains an express statement to the contrary or incorporates a formal
Purchase Order.

This transmission is intended for the named addressee only. Unless you
are the named addressee (or

authorised to receive it for the addressee) you may not copy or use it,
or disclose it to anyone else, any

disclosure or copying of the contents of this e-mail or any action taken
(or not taken) in reliance on it is

unauthorised and may be unlawful. If you are not an addressee, please
inform the sender immediately.

-------------- next part --------------

An HTML attachment was scrubbed...

URL:
<http://lists.live555.com/pipermail/live-devel/attachments/20101007/5472
a55d/attachment.html>

-------------- next part --------------

A non-text attachment was scrubbed...

Name: Visual2008.zip

Type: application/x-zip-compressed

Size: 40908 bytes

Desc: Visual2008.zip

URL:
<http://lists.live555.com/pipermail/live-devel/attachments/20101007/5472
a55d/attachment.bin>

 

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

 

_______________________________________________

live-devel mailing list

live-devel at lists.live555.com

http://lists.live555.com/mailman/listinfo/live-devel

 

 

End of live-devel Digest, Vol 84, Issue 4

*****************************************

**********************************************************************************************
LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes, 
any subsequent correspondence, and any document, data, sketches, plans and/or other material that is 
hereby attached, are proprietary. confidential and may be legally privileged. 
Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or 
make it subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase Order.
This transmission is intended for the named addressee only. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any 
disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is 
unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately.

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101011/2d80f04b/attachment-0001.html>

From lugesot at yahoo.com.cn  Mon Oct 11 20:47:30 2010
From: lugesot at yahoo.com.cn (town angel)
Date: Tue, 12 Oct 2010 11:47:30 +0800 (CST)
Subject: [Live-devel] Support stream ".mov" file using mediaServer
Message-ID: <470324.92917.qm@web15902.mail.cnb.yahoo.com>

Does live555MediaServer support steaming MOV(QuickTimeFile) container format? I am wondering how to implement it in live555 library? Can anyone give me a guild to what function i need to implement ? 
I'm reading sourcecode of DarwinStreamServer to investigate how Darwin packet MOV to rtp. 
Thanks.


      


From finlayson at live555.com  Mon Oct 11 20:55:59 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 11 Oct 2010 20:55:59 -0700
Subject: [Live-devel] Error of the server running in Linux
In-Reply-To: <f8217d7651b0d73f8f7baf552d1df083.squirrel@mmp.sipr-dc.ucl.ac.be>
References: <f8217d7651b0d73f8f7baf552d1df083.squirrel@mmp.sipr-dc.ucl.ac.be>
Message-ID: <f06240803c8d98b5b9fa0@[66.80.62.44]>

>Hello i have solved the problem in linux by applying the variable #define
>READ_FROM_FILES_SYNCHRONOUSLY 1, as by default for windows, within the
>class ByteStreamFileSource.
>Can anyone guess why from the last update in my code, i need this
>modification in order to run properly the server?

Because your code is buggy.  You are closing open files (which are 
also sockets in Linux), without also calling 
"TaskScheduler::turnOffBackgroundReadHandling()" on the socket. 
That's why you're seeing the "Bad file descriptor" error.

Note how the "ByteStreamFileSource" code (when not reading from files 
synchronously) calls "TaskScheduler::turnOnBackgroundReadHandling()" 
whenever it opens a file, and calls 
"TaskScheduler::turnOffBackgroundReadHandling()" whenever it closes a 
file.


>  Does it damage a lot the performance and scalability of the server?

Yes.  Note the comment near the start of "ByteStreamFileSource.cpp".


>  Just remember i am streaming
>H264 sequences divided in multiple video files. When the buffer on the
>server gets empty i use a xml script to decide the next video segment of
>h264 to send and therefore to include in the buffer before.

If you know these multiple file names in advance, then you could use 
"ByteStreamMultiFileSource" (unmodified!) instead.  It allows you to 
read multiple files - one at a time - as if they were a single file.
-- 

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

From finlayson at live555.com  Mon Oct 11 21:34:55 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 11 Oct 2010 21:34:55 -0700
Subject: [Live-devel] Support stream ".mov" file using mediaServer
In-Reply-To: <470324.92917.qm@web15902.mail.cnb.yahoo.com>
References: <470324.92917.qm@web15902.mail.cnb.yahoo.com>
Message-ID: <f06240802c8d995bd0e74@[66.80.62.44]>

>Does live555MediaServer support steaming MOV(QuickTimeFile) container format?

No.
-- 

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

From rglobisch at csir.co.za  Tue Oct 12 00:26:21 2010
From: rglobisch at csir.co.za (Ralf Globisch)
Date: Tue, 12 Oct 2010 09:26:21 +0200
Subject: [Live-devel] live-devel Digest, Vol 84, Issue 4
Message-ID: <AANLkTinUdO1BYFg6SRqYST3xqs+c821-jciHE2G_yFFD@mail.gmail.com>

FYI: You can search the archives with google by specifying:
site:live555.com in the search string

Searching for "site:live555.com Visual Studio 2008 Solution Guy .sln"
will give you a link to
http://lists.live555.com/pipermail/live-devel/2010-March.txt

and searching that page for ".sln" will quickly point you to

http://lists.live555.com/pipermail/live-devel/attachments/20100309/129c2282/attachment-0001.bin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101012/e1d98243/attachment.html>

From belloni at imavis.com  Thu Oct 14 04:26:03 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 14 Oct 2010 13:26:03 +0200
Subject: [Live-devel] RTSPOverHTTPServer is no more?
Message-ID: <4CB6E8CB.3000107@imavis.com>

  Dear Ross,

I saw RTSPOverHTTPServer.cpp and RTSPOverHTTPServer.hh are no more in 
the latest tarball of LiveMedia.
This means future support for RTSP over HTTP is no more an option or 
that its release is imminent?

Also, if I use these two files from the 16th March release, what else 
should I implement to make RTSP over HTTP work?

Thanks,
Best Regards,

Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101014/90900a02/attachment.html>

From k3naaa at gmail.com  Thu Oct 14 09:09:07 2010
From: k3naaa at gmail.com (K3 Naa)
Date: Thu, 14 Oct 2010 11:09:07 -0500
Subject: [Live-devel] authentication problem
Message-ID: <AANLkTin2fxu7U6yxgAunjOcNmX2hKiXUyADW9Qj2JfF_@mail.gmail.com>

I am trying to open a password-protected rtsp stream.  After no success with
mplayer, I tried opening it directly with openRTSP, and get the following
output, with "RTSP/1.0 401 Unauthorized" at the very end:

-----
system~$ openRTSP -u FA*** PASS*****
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm
Sending request: OPTIONS
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2010.01.11)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Date: Thu, 14 Oct 2010 16:02:52 GMT
Server: Helix Mobile Server Version 14.0.0.348 (sunos-5.10-sparc-server)
(RealServer compatible)
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, GET_PARAMETER, SET_PARAMETER,
TEARDOWN
TurboPlay: 1
RealChallenge1: 8492caf7e0c56053f9d3b918cb0d9970
StatsMask: 8


Sending request: DESCRIBE
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openRTSP (LIVE555 Streaming Media v2010.01.11)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Thu, 14 Oct 2010 16:02:52 GMT
WWW-Authenticate: RN5 realm="vorena.ContentRealm", nonce="128707217270229"


Failed to get a SDP description from URL
"rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm": cannot
handle DESCRIBE response: RTSP/1.0 401 Unauthorized
------

I get the same output if a use rtsp://USERNAME:PASSWORD at HOSTNAME:PORT
instead of the command line options for authentication.  I also get the same
output if I don't specify any login information at all.  Is this a syntax
issue, or does the server use some sort of unsupported authentication?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101014/2c44b990/attachment.html>

From finlayson at live555.com  Thu Oct 14 21:22:12 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 14 Oct 2010 21:22:12 -0700
Subject: [Live-devel] authentication problem
In-Reply-To: <AANLkTin2fxu7U6yxgAunjOcNmX2hKiXUyADW9Qj2JfF_@mail.gmail.com>
References: <AANLkTin2fxu7U6yxgAunjOcNmX2hKiXUyADW9Qj2JfF_@mail.gmail.com>
Message-ID: <f06240800c8dd8716072a@[66.80.62.44]>

>I am trying to open a password-protected rtsp stream.  After no 
>success with mplayer, I tried opening it directly with openRTSP, and 
>get the following output, with "RTSP/1.0 401 Unauthorized" at the 
>very end:
>
>-----
>system~$ openRTSP -u FA*** PASS***** 
>rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm
>Sending request: OPTIONS 
>rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm 
>RTSP/1.0
>CSeq: 1
>User-Agent: openRTSP (LIVE555 Streaming Media v2010.01.11)

This is an old version of "openRTSP".  No support is given for old 
versions of the code.  Our RTSP client implementation has changed 
significantly since then.  Please upgrade to the latest version fo 
the code, and try again.
-- 

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

From finlayson at live555.com  Fri Oct 15 05:59:05 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Oct 2010 05:59:05 -0700
Subject: [Live-devel] RTSPOverHTTPServer is no more?
In-Reply-To: <4CB6E8CB.3000107@imavis.com>
References: <4CB6E8CB.3000107@imavis.com>
Message-ID: <f06240802c8de0073b3d2@[66.80.62.44]>

>I saw RTSPOverHTTPServer.cpp and RTSPOverHTTPServer.hh are no more 
>in the latest tarball of LiveMedia.
>This means future support for RTSP over HTTP is no more an option or 
>that its release is imminent?

Its release is imminent.  *Very* imminent...
-- 

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

From finlayson at live555.com  Fri Oct 15 06:55:44 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Oct 2010 06:55:44 -0700
Subject: [Live-devel] New version released - adds server support for
 RTSP-over-HTTP tunneling
Message-ID: <f06240803c8de0ac92034@[66.80.62.44]>

A new version (2010.10.15) of the "LIVE555 Streaming Media" software 
has been released that adds server support for optional 
RTSP-over-HTTP tunneling.  (*Client* support for RTSP-over-HTTP 
tunneling has been present for a long time.)

The "RTSPServer" class has two new member functions:

Boolean setUpTunnelingOverHTTP(Port httpPort);
	Attempts to support tunneling on the specified HTTP port 
number.  Returns True iff it succeeds.

portNumBits httpServerPortNum() const;
	Returns the port number (in host order) that is currently 
being used for RTSP-over-HTTP tunneling (or returns 0 if tunneling is 
not supported).


I also updated the "testOnDemandRTSPServer" and "live555MediaServer" 
applications to try to set up HTTP tunneling on port 80, then port 
8000, and then finally port 8080.  Of course, RTSP-over-HTTP 
tunneling is always optional; RTSP over the regular RTSP port (554 or 
8554) is always supported.
-- 

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

From mehran at stretchinc.com  Fri Oct 15 17:04:49 2010
From: mehran at stretchinc.com (Mehran Ansari)
Date: Fri, 15 Oct 2010 17:04:49 -0700 (PDT)
Subject: [Live-devel] The first H.264 SPS packet gets skipped
In-Reply-To: <78468899.9071287186690229.JavaMail.root@mail.stretchinc.com>
Message-ID: <1927283721.9221287187489443.JavaMail.root@mail.stretchinc.com>

I have a H.264 Streamer server, which gets the live encoded video frames from my own encoder device and tries to sent it out to the client requesting it. To do this I sub-classed H264VideoStreamFramer from FramedFilter class. I implemented currentNALUnitEndsAccessUnit() and isH264VideoStreamFramer() and returned TRUE for both since my encoder always provides me with a complete NAL. I also implemented doGetNextFrame() which when it gets called it makes sure to start with a SPS packet. In doGetNextFrame(), I copy the H.264 payload to fTo, assign the packet size to fFrameSize, and set the fNumTruncatedBytes to zero. (Note: I set the OutPacketBuffer::maxSize to the maximum buffer size that my encoder provides which is 256K). At last I call afterGetting() and before I return I scheduleDelayedTask() to be called in 1/30th of a seconds.

Everything works fine except, the very first packet that is SPS which is sent to afterGetting() gets lost.  This packet does not get sent. Instead my doGetNextFrame() gets callback due to alarm handleAlarm(). At this time I get the next frame and so. The result is that the client has a complete h.264 video file except the first SPS is missing. 

To get around this problem, when doGetNextFrame() gets called and only one SPS is sent, then I assume the last buffer was not delivered, I just call afterGetting() without changing anything. Now, everything is working fine.

My question is that what am I doing wrong that for the first very frame which in this case is SPS, the frame does not get sent. Do I need to set fDurationInMicroSeconds and fPresentationTime before calling afterGetting()? Is it possible not setting any of these variables to cause an undesired event schedule which forces doGetNextFrame() be called before sending the packet?

Thanks for any help.

From mehran at stretchinc.com  Mon Oct 18 10:17:38 2010
From: mehran at stretchinc.com (Mehran Ansari)
Date: Mon, 18 Oct 2010 10:17:38 -0700 (PDT)
Subject: [Live-devel] Meaning of member variables in FramedSource class
In-Reply-To: <2145137168.4611287422191778.JavaMail.root@mail.stretchinc.com>
Message-ID: <2053529013.4631287422257999.JavaMail.root@mail.stretchinc.com>

As I was reading the source code in Live555, I see that FramedSource class is a class that is very important to learn and understand specially if you are implementing a your own streaming class such as H.264 Live streaming.

This subclass is meant to provide video frames (in my case h.264 video frame provided by my encoder) is derived from H264VideoStramFramer which is derived from FrameFilter and that is derived from FrameSource.

First you must implement doGetNextFrame() virtual method which will be called every time a new frame needs to be sent to the client. Then my understanding from the FrameSource class is that the following member variables must be set when doGetNextFrame() is called but before calling afterGetting() method. Also I understand the afterGetting() schedules a time for doGetNextFrame() to be called again.
 
- fTo - Is a buffer provided by the Live555 where I have to copy the lasted video frame provided by my encoder to it
- fMaxSize - Is the maximum number of bytes that can be written to fTo buffer
- fFrameSize - Is the number of Bytes that my class wrote in to fTo
- fNumTruncatedBytes - If fMaxSize is less than my encoded video frame buffer, then, it indicates how many more bytes are still needed to be written to fTo next time when doGetNextFrame() is called again 
- fPresentationTime - Needs to be set by me. What is this time? Is this required?  My encoder provide a relative time which is number of ticks since some original. Do I have to translate that to the real unix time? Or can I just keep the number of relative ticks. What happens if this field is set to zero? or not set at all
- fDurationInMicroseconds - Needs to be set by me. Again is this required? What happens if this field is set to zero? or not set at all. What do I set this for buffer for frames such as SPS or PPS?

What is the purpose of virtual method isFramedSource()? 

What is the purpose of virtual method maxFrameSize()? and how does this relate to OutPacketBuffer::maxSize

What is the purpose of virtual method doStopGettingFrames()? 

Thanks for your help in clarifying my understanding which can be very helpful for many new users of this library.

From k3naaa at gmail.com  Sun Oct 17 17:43:48 2010
From: k3naaa at gmail.com (K3 Naa)
Date: Sun, 17 Oct 2010 19:43:48 -0500
Subject: [Live-devel] authentication problem
In-Reply-To: <f06240800c8dd8716072a@66.80.62.44>
References: <AANLkTin2fxu7U6yxgAunjOcNmX2hKiXUyADW9Qj2JfF_@mail.gmail.com>
	<f06240800c8dd8716072a@66.80.62.44>
Message-ID: <AANLkTi=nJMHbWmXas0Y+7B1aTp2aBiOETmJy+L+2uu5r@mail.gmail.com>

On Thu, Oct 14, 2010 at 11:22 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I am trying to open a password-protected rtsp stream.  After no success
>> with mplayer, I tried opening it directly with openRTSP, and get the
>> following output, with "RTSP/1.0 401 Unauthorized" at the very end:
>>
>> -----
>> system~$ openRTSP -u FA*** PASS*****
>> rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm
>> Sending request: OPTIONS
>> rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm RTSP/1.0
>> CSeq: 1
>> User-Agent: openRTSP (LIVE555 Streaming Media v2010.01.11)
>>
>
> This is an old version of "openRTSP".  No support is given for old versions
> of the code.  Our RTSP client implementation has changed significantly since
> then.  Please upgrade to the latest version fo the code, and try again.
>
> Running the latest version from October 15 gives me a very similar
response:
----
$ ./openRTSP -u "FA***" "PASS*****"
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm
Opening connection to 128.XXX.XXX.XXX, port 554...
...remote connection opened
Sending request: OPTIONS
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm RTSP/1.0
CSeq: 2
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.10.15)


Received 328 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Date: Mon, 18 Oct 2010 00:51:54 GMT
Server: Helix Mobile Server Version 14.0.0.348 (sunos-5.10-sparc-server)
(RealServer compatible)
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, GET_PARAMETER, SET_PARAMETER,
TEARDOWN
TurboPlay: 1
RealChallenge1: 05197b5d9a09eefde351d6a72a00a27b
StatsMask: 8


Sending request: DESCRIBE
rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm RTSP/1.0
CSeq: 3
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.10.15)
Accept: application/sdp


Received 152 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 401 Unauthorized
CSeq: 3
Date: Mon, 18 Oct 2010 00:51:54 GMT
WWW-Authenticate: RN5 realm="vorena.ContentRealm", nonce="1287363114800031"


Failed to get a SDP description from URL
"rtsp://128.XXX.XXX.XXX:554/AY1011/Fall-2/B8HST/081008201011.rm": 401
Unauthorized
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101017/d83bc312/attachment.html>

From finlayson at live555.com  Mon Oct 18 16:09:51 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 18 Oct 2010 16:09:51 -0700
Subject: [Live-devel] authentication problem
In-Reply-To: <AANLkTi=nJMHbWmXas0Y+7B1aTp2aBiOETmJy+L+2uu5r@mail.gmail.com>
References: <AANLkTin2fxu7U6yxgAunjOcNmX2hKiXUyADW9Qj2JfF_@mail.gmail.com>
	<f06240800c8dd8716072a@66.80.62.44>
	<AANLkTi=nJMHbWmXas0Y+7B1aTp2aBiOETmJy+L+2uu5r@mail.gmail.com>
Message-ID: <f06240800c8e283bd68fd@[66.80.62.44]>

OK, the problem here is that your server uses a non-standard 
proprietary authentication mechanism (the "RealChallenge" and "RN5" 
stuff) that we don't support.  (We also don't support the (again, 
nonstandard and proprietary) RTP payload format that this server 
uses.)  So you're out of luck.  Sorry.
-- 

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

From 503430770 at qq.com  Mon Oct 18 22:17:20 2010
From: 503430770 at qq.com (=?ISO-8859-1?B?NTAzNDMwNzcw?=)
Date: Tue, 19 Oct 2010 13:17:20 +0800
Subject: [Live-devel] how to do in my "FramedSource" class
Message-ID: <tencent_2503164C41B517EE254D3212@qq.com>

HI,I want to live555 Server with live source of MPEG4.The source is my camera which I can get one frame of MPEG4 from.
    I save the frames those I get to a file .Later I find that the file have  no VOSS, VOS. How can I do in my "FramedSource" class.
    Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101019/518a2b82/attachment.html>

From belloni at imavis.com  Tue Oct 19 05:15:39 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Tue, 19 Oct 2010 14:15:39 +0200
Subject: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.
Message-ID: <4CBD8BEB.9060004@imavis.com>

  Dear Ross,
I'm trying to use RTSP-over-HTTP support on server, and it works 
flawlessly. Unfortunately, software vendors (Milestone, this time) seem 
not to get it right, so I have two question, one more irrelevant, the 
other more serious.

1) Milestone doesn't send us  "Accept:" or "Content-Type:" string of 
"application/x-rtsp-tunnelled" in the HTTP GET. I deactivated the check 
in the RTSPServer.cpp code and everything works. Will you incorporate 
this in the future code?

2) Milestone sends us a base64 encoded POST that contains this SETUP:

SETUP rtsp://192.168.1.83:8554/video/track1 RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=12154-12155

This makes RtspServer send its packets in UDP, while Milestone seems to 
want them tunneled in the TCP connection (openRTSP gets it right, 
sending a more reasonable Transport: RTP/AVP/TCP;unicast;interleaved=0-1).

My question is: does not the GET imply that the stream data must be 
tunneled, regardless the (incorrect) Transport:RTP/AVT request from the 
Milestone? What could be the point on requesting UDP/RTP data over an 
RTSP/HTTP negotiation? Shouldn't be data tunneled by default on the HTTP 
socket, ignoring the Transport: line, in this case?
And, please, if not, what could be the best way to patch liveMedia to 
support RTP tunneling even if the Transport: line is incorrect?

(As there's no RFC on RTSP over HTTP, as far as I know, I use this 
document as a reference: 
http://developer.apple.com/quicktime/icefloe/dispatch028.html , but 
unfortunately it doesn't answer my question).

Best Regards,
Cristiano.


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101019/ab42c797/attachment.html>

From finlayson at live555.com  Tue Oct 19 14:49:29 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Oct 2010 14:49:29 -0700
Subject: [Live-devel] Meaning of member variables in FramedSource class
In-Reply-To: <2053529013.4631287422257999.JavaMail.root@mail.stretchinc.com>
References: <2053529013.4631287422257999.JavaMail.root@mail.stretchinc.com>
Message-ID: <f06240800c8e3c1332d4f@[66.80.62.44]>

See "liveMedia/DeviceSource.cpp" for a description (in the comments) 
of these fields.

Some more specific comments:
>- fPresentationTime - Needs to be set by me. What is this time? Is 
>this required?

Yes!


>   My encoder provide a relative time which is number of ticks since 
>some original. Do I have to translate that to the real unix time?

Yes.  The "presentationTime" values must be aligned with 'wall-clock 
time' - i.e., the time that you would get by calling "gettimeofday()".


>- fDurationInMicroseconds - Needs to be set by me. Again is this 
>required? What happens if this field is set to zero? or not set at 
>all.

If it's not set at all, it keeps its default value, of zero.  If your 
data source is live (e.g., from an encoder), then you usually don't 
need to set this.  However, if your data source is pre-recorded data 
(e.g., a file), then you should set this.

I'm not going to bother answering your questions about the rest of 
the code, because you shouldn't need to care about it.  But if you're 
curious: Remember, You Have Complete Source Code.
-- 

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

From finlayson at live555.com  Tue Oct 19 18:40:37 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Oct 2010 18:40:37 -0700
Subject: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.
In-Reply-To: <4CBD8BEB.9060004@imavis.com>
References: <4CBD8BEB.9060004@imavis.com>
Message-ID: <f06240800c8e3f405ce1b@[66.80.62.44]>

>(As there's no RFC on RTSP over HTTP, as far as I know, I use this 
>document as a reference: 
><http://developer.apple.com/quicktime/icefloe/dispatch028.html>http://developer.apple.com/quicktime/icefloe/dispatch028.html

FYI, another document - with a little more detail - is here: 
http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf (starting 
on page 107)


>1) Milestone doesn't send us "Accept:" or "Content-Type:" string of 
>"application/x-rtsp-tunnelled" in the HTTP GET. I deactivated the 
>check in the RTSPServer.cpp code and everything works. Will you 
>incorporate this in the future code?

Note that the document that I referred to above explicitly states 
that the "application/x-rtsp-tunnelled" header must be present. 
However - in the spirit of "Be liberal in what you accept" - I will 
deactivate this check in the next release of the code.  (Note, 
though, that the "x-sessioncookie:" header absolutely has to be 
present in the request, both to distinguish RTSP-tunneling requests 
from regular HTTP "GET" commands (which should be rejected because 
we're not a real HTTP server), and to enable us to tie together the 
"GET" and "POST" requests.  I presume, though, that the 'Milestone' 
client is including this header OK, otherwise the code wouldn't be 
working.)


>2) Milestone sends us a base64 encoded POST that contains this SETUP:
>
>SETUP 
><rtsp://192.168.1.83:8554/video/track1>rtsp://192.168.1.83:8554/video/track1 
>RTSP/1.0
>CSeq: 2
>Transport: RTP/AVP;unicast;client_port=12154-12155
>
>This makes RtspServer send its packets in UDP, while Milestone seems 
>to want them tunneled in the TCP connection (openRTSP gets it right, 
>sending a more reasonable Transport: 
>RTP/AVP/TCP;unicast;interleaved=0-1).
>
>My question is: does not the GET imply that the stream data must be 
>tunneled, regardless the (incorrect) Transport:RTP/AVT request from 
>the Milestone? What could be the point on requesting UDP/RTP data 
>over an RTSP/HTTP negotiation?

I can imagine that this *might* be useful for tunneling across a 
firewall that passes UDP packets, but blocks TCP connections to 
anything other than port 80.  I agree, though, that this is unlikely 
to be what you want to do.

So, with some reluctance, I will modify the server code (in the next 
release) so that - when HTTP tunneling is being done - it assumes 
that it will stream over the TCP (HTTP) connection, regardless of 
what the "SETUP" command says.  I say "with some reluctance", though, 
because I'm getting tired of the assumption that - just because we're 
Open Source - we should inevitably modify our code in order to be 
compatible with other people's broken, non-standard software (or 
hardware).  I'm willing to bet that the installed base of our 
software is larger than that of 'Milestone'.  So, even though I'll 
modify our server code to work around these two bugs, I'd like you to 
also please contact 'Milestone', informing them of these bugs, and 
asking them to fix them in their software.
-- 

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/20101019/75e56217/attachment-0001.html>

From yinhua.li at siemens.com  Tue Oct 19 19:07:15 2010
From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S)
Date: Wed, 20 Oct 2010 10:07:15 +0800
Subject: [Live-devel] send text message to player
Message-ID: <68D227E48F4B0F4EB6161523402601BE8C13E6@PEKW987A.cn001.siemens.net>

Dear Ross,
 
In my project, administrator can close video connection by specified client IP address, but after closing connection, user at client side only see the screen is freezed, so I want to send a text message to player, shown as "Your connection was closed by VOD administrator!", how can I implement this function? Thanks a lot~
 
Best regards.
--------------------------------------------------------------
??? Li Yinhua
SIEMENS
Siemens Ltd., China Nanjing Branch 
Corporate Technology Development Center (CT DC), Nanjing
?????????????37??????????211100?
Tel.: +86 (25) 51171864 
Fax: +86 (25) 51171761
Mobile: +86 15895967085
www.siemens.com

P  Save a tree. Don't print this e-mail unless it's really necessary. 
 
 


IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person.

In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk

<Disclaimer in Chinese below, characters may not be displayed correctly.>

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
?????????????????????????????????????????????????Tell us???????www.siemens.com.cn/compliancehelpdesk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/1761b2a9/attachment.html>

From belloni at imavis.com  Wed Oct 20 01:05:53 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 20 Oct 2010 10:05:53 +0200
Subject: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.
In-Reply-To: <f06240800c8e3f405ce1b@[66.80.62.44]>
References: <4CBD8BEB.9060004@imavis.com> <f06240800c8e3f405ce1b@[66.80.62.44]>
Message-ID: <4CBEA2E1.8090809@imavis.com>

  Il 20/10/2010 03:40, Ross Finlayson ha scritto:
>> (As there's no RFC on RTSP over HTTP, as far as I know, I use this 
>> document as a reference: 
>> http://developer.apple.com/quicktime/icefloe/dispatch028.html
>
> FYI, another document - with a little more detail - is here: 
> http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf (starting on 
> page 107)
>
>

Thank you.

>> 1) Milestone doesn't send us "Accept:" or "Content-Type:" string of 
>> "application/x-rtsp-tunnelled" in the HTTP GET. I deactivated the 
>> check in the RTSPServer.cpp code and everything works. Will you 
>> incorporate this in the future code?
>
> Note that the document that I referred to above explicitly states that 
> the "application/x-rtsp-tunnelled" header must be present.  However - 
> in the spirit of "Be liberal in what you accept" - I will deactivate 
> this check in the next release of the code.  (Note, though, that the 
> "x-sessioncookie:" header absolutely has to be present in the request, 
> both to distinguish RTSP-tunneling requests from regular HTTP "GET" 
> commands (which should be rejected because we're not a real HTTP 
> server), and to enable us to tie together the "GET" and "POST" 
> requests.  I presume, though, that the 'Milestone' client is including 
> this header OK, otherwise the code wouldn't be working.)
>

Yes, the session cookie is included correctly, luckily (the contrary 
would have defied the whole RTSP-on-HTTP purpose, I guess).

>
>> 2) Milestone sends us a base64 encoded POST that contains this SETUP:
>>
>> SETUP rtsp://192.168.1.83:8554/video/track1 RTSP/1.0
>> CSeq: 2
>> Transport: RTP/AVP;unicast;client_port=12154-12155
>>
>> This makes RtspServer send its packets in UDP, while Milestone seems 
>> to want them tunneled in the TCP connection (openRTSP gets it right, 
>> sending a more reasonable Transport: 
>> RTP/AVP/TCP;unicast;interleaved=0-1).
>>
>> My question is: does not the GET imply that the stream data must be 
>> tunneled, regardless the (incorrect) Transport:RTP/AVT request from 
>> the Milestone? What could be the point on requesting UDP/RTP data 
>> over an RTSP/HTTP negotiation?
>
> I can imagine that this *might* be useful for tunneling across a 
> firewall that passes UDP packets, but blocks TCP connections to 
> anything other than port 80.  I agree, though, that this is unlikely 
> to be what you want to do.
>
> So, with some reluctance, I will modify the server code (in the next 
> release) so that - when HTTP tunneling is being done - it assumes that 
> it will stream over the TCP (HTTP) connection, regardless of what the 
> "SETUP" command says.

Thank you.

>   I say "with some reluctance", though, because I'm getting tired of 
> the assumption that - just because we're Open Source - we should 
> inevitably modify our code in order to be compatible with other 
> people's broken, non-standard software (or hardware).  I'm willing to 
> bet that the installed base of our software is larger than that of 
> 'Milestone'.  So, even though I'll modify our server code to work 
> around these two bugs, I'd like you to also please contact 
> 'Milestone', informing them of these bugs, and asking them to fix them 
> in their software.

I'm getting very tired of this, too, and I can assure you I share your 
feelings. I'm sincerely astonished that big manufacturers as Milestone 
just can't stick to these simple standards.
I've already contacted Milestone developers and informed them on these 
bugs (and on other ones, such as making the first GET in HTTP 1.1, while 
all GETs *must* be done in HTTP 1.0. Luckily liveMedia seems to works 
fine with this).

Thank you again,
best regards,

Cristiano Belloni.

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


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/061472ba/attachment.html>

From finlayson at live555.com  Wed Oct 20 01:34:28 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 01:34:28 -0700
Subject: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.
In-Reply-To: <4CBEA2E1.8090809@imavis.com>
References: <4CBD8BEB.9060004@imavis.com>
	<f06240800c8e3f405ce1b@[66.80.62.44]> <4CBEA2E1.8090809@imavis.com>
Message-ID: <f06240801c8e459c53730@[66.80.62.44]>

OK, I've now installed a new version (2010.10.20) of the software 
that makes the "RTSP-over-HTTP tunneling" implementation more robust 
to the client bugs that you noted.  Please try it out and let us know 
if there are any problems.
-- 

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

From belloni at imavis.com  Wed Oct 20 05:49:05 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 20 Oct 2010 14:49:05 +0200
Subject: [Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.
In-Reply-To: <f06240801c8e459c53730@[66.80.62.44]>
References: <4CBD8BEB.9060004@imavis.com>	<f06240800c8e3f405ce1b@[66.80.62.44]>
	<4CBEA2E1.8090809@imavis.com> <f06240801c8e459c53730@[66.80.62.44]>
Message-ID: <4CBEE541.6080302@imavis.com>

  Il 20/10/2010 10:34, Ross Finlayson ha scritto:
> OK, I've now installed a new version (2010.10.20) of the software that 
> makes the "RTSP-over-HTTP tunneling" implementation more robust to the 
> client bugs that you noted.  Please try it out and let us know if 
> there are any problems.
Works like a charm. Thank you.

Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/79ff77e4/attachment-0001.html>

From kamildobk at poczta.onet.pl  Wed Oct 20 06:29:33 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Wed, 20 Oct 2010 15:29:33 +0200
Subject: [Live-devel] RTSP-over-HTTP question
Message-ID: <00B6372E54A44482A93D2E4964A4DA0F@KamilPC>

Hi, 

I have problems connecting to RTSP server with HTTP tunneling. My server closes connection immediately after the first HTTP GET request fails with `HTTP/1.0 401 Unauthorized` error, so there is no second chance to send authentication credentials in the next requests. I have a question: Is there any simple way to include my own HTTP header fields ( `Authorization: Basic` or maybe `Connection: Keep-alive` would do ) in the first GET request ? 

Regards,
Kamil 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/4f942f90/attachment.html>

From finlayson at live555.com  Wed Oct 20 07:10:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 07:10:56 -0700
Subject: [Live-devel] RTSP-over-HTTP question
In-Reply-To: <00B6372E54A44482A93D2E4964A4DA0F@KamilPC>
References: <00B6372E54A44482A93D2E4964A4DA0F@KamilPC>
Message-ID: <f06240800c8e4a8168b8a@[66.80.62.44]>

>I have problems connecting to RTSP server with HTTP tunneling. My 
>server closes connection immediately after the first HTTP GET 
>request fails with `HTTP/1.0 401 Unauthorized` error, so there is no 
>second chance to send authentication credentials in the next 
>requests.

I presume that you are talking about our *client* implementation of 
RTSP-over-HTTP tunneling, and that the server is using some other 
implementation (not ours).

Our RTSP client implementation *should*, I think, be able to handle 
this OK - but it hasn't been fully tested.  (I presume that you are 
using a recent version of the "LIVE555 Streaming Media" code.) 
Please tell us the *complete* set of headers that are returned (by 
the server) in the response to your HTTP "GET" request.
-- 

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/20101020/c1011e23/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 10:45:51 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Wed, 20 Oct 2010 17:45:51 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>

Right now, I'm developing h264 over rtp streaming. My question is the current version of live555 needs SEI packet of h264 or just video data packet?
That is, if I packet the H264 video data according RFC 3984, no SEI data, that's OK for live555 parsing?
But VLC player cannot recognize the stream, VLC selects live555 demux, I tried many times.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/33012208/attachment.html>

From finlayson at live555.com  Wed Oct 20 14:29:12 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 14:29:12 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
Message-ID: <f06240800c8e50e170a49@[66.80.62.44]>

>Right now, I'm developing h264 over rtp streaming. My question is 
>the current version of live555 needs SEI packet of h264 or just 
>video data packet?
>That is, if I packet the H264 video data according RFC 3984, no SEI 
>data, that's OK for live555 parsing?

Yes, our implementation of H.264/RTP reception - as used in VLC - 
complies with RFC 3984.


>But VLC player cannot recognize the stream, VLC selects live555 
>demux, I tried many times.

If you are packing H.264 NAL units into RTP packets as specified by 
RFC 3984, the "LIVE555" code in VLC should be able to receive them 
OK.  (Make sure that the NAL units packed within RTP packets do *not* 
include the initial 0x00000001 code.)

Assuming that your stream is properly complaint with RFC 3984, then 
the problem with VLC is probably with the H.264 decoder, which is not 
our software (and therefore off-topic for this mailing list). 
However, one common problem is that the decoder often needs to see 
initial PPS and SPS NAL units to work properly.  If you are not 
including these in the stream's SDP description (if you're using 
SDP), then you will need to insert PPS and SPS NAL units at the start 
of the stream (or frequently, periodically within the stream).
-- 

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/20101020/50b24e5d/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 14:43:15 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Wed, 20 Oct 2010 21:43:15 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240800c8e50e170a49@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
	<f06240800c8e50e170a49@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C216F@zcomb2.Zoran.com>

Thanks for your quick reply. I know this is a VLC related problem. But if anybody can give me a clue, so I can finish my project, that's great!

My stream complies with RFC 3984, and I insert SPS and PPS at the front of every I frame.
The problem is VLC always gives the message:  "live555 no data received with 10s" than rtsp tear down . I'm pretty sure the rtp stream is there and rtp port number is right. Why VLC cannot receive the stream and decode it as rtp/h264?


Thanks,

-Larry

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 2:29 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

Right now, I'm developing h264 over rtp streaming. My question is the current version of live555 needs SEI packet of h264 or just video data packet?
That is, if I packet the H264 video data according RFC 3984, no SEI data, that's OK for live555 parsing?

Yes, our implementation of H.264/RTP reception - as used in VLC - complies with RFC 3984.


But VLC player cannot recognize the stream, VLC selects live555 demux, I tried many times.

If you are packing H.264 NAL units into RTP packets as specified by RFC 3984, the "LIVE555" code in VLC should be able to receive them OK.  (Make sure that the NAL units packed within RTP packets do *not* include the initial 0x00000001 code.)

Assuming that your stream is properly complaint with RFC 3984, then the problem with VLC is probably with the H.264 decoder, which is not our software (and therefore off-topic for this mailing list).  However, one common problem is that the decoder often needs to see initial PPS and SPS NAL units to work properly.  If you are not including these in the stream's SDP description (if you're using SDP), then you will need to insert PPS and SPS NAL units at the start of the stream (or frequently, periodically within the stream).

--

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/20101020/d8515036/attachment-0001.html>

From finlayson at live555.com  Wed Oct 20 15:00:38 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 15:00:38 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C216F@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
	<f06240800c8e50e170a49@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C216F@zcomb2.Zoran.com>
Message-ID: <f06240801c8e515d7be0e@[66.80.62.44]>

>My stream complies with RFC 3984, and I insert SPS and PPS at the 
>front of every I frame.
>The problem is VLC always gives the message:  "live555 no data 
>received with 10s" than rtsp tear down . I'm pretty sure the rtp 
>stream is there and rtp port number is right. Why VLC cannot receive 
>the stream and decode it as rtp/h264?

In order for VLC to be able to play the stream, VLC needs a SDP 
description, so that it will know (i) that the stream is H.264, and 
(ii) which RTP payload format code it is using.

Are you giving VLC a SDP description - either directly (as a file), 
or indirectly, using RTSP?
-- 

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/20101020/a009a52f/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 15:12:42 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Wed, 20 Oct 2010 22:12:42 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240801c8e515d7be0e@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com>
	<f06240801c8e515d7be0e@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>

I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.  If the PPS is a little bit different from SDP in RTSP, is it a problem? I really could not find other issue.
When I open VLC, I only input rtsp://169.254.1.5, nothing else. Is this a problem? I'm reading the source code for VLC, seems they need a track id.


Note : live555 warning: no data received in 10s. Switching to TCP


Here's the VLC message

main debug: adding item `rtsp://169.254.1.5' ( rtsp://169.254.1.5 )

main debug: rebuilding array of current - root Playlist

main debug: rebuild done - 1 items, index -1

main debug: processing request item rtsp://169.254.1.5 node null skip 0

main debug: resyncing on rtsp://169.254.1.5

main debug: rtsp://169.254.1.5 is at 0

main debug: starting new item

main debug: creating new input thread

main debug: Creating an input for 'rtsp://169.254.1.5'

qt4 debug: Adding a new MRL to recent ones: rtsp://169.254.1.5

main debug: thread (input) created at priority 1 (../.././src/input/input.c:230)

main debug: thread started

main debug: using timeshift granularity of 50 MBytes

main debug: using timeshift path 'C:\Users\larryc\AppData\Local\Temp'

main debug: `rtsp://169.254.1.5' gives access `rtsp' demux `' path `169.254.1.5'

main debug: enforced demux ` h264'

main debug: creating demux: access='rtsp' demux='h264' path='169.254.1.5'

main debug: looking for access_demux module: 1 candidate

qt4 debug: IM: Setting an input

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

live555 debug: RTP subsession 'video/H264'

main debug: selecting program id=0

live555 debug: setup start: 0.000000 stop:0.000000

live555 debug: play start: 0.000000 stop:0.000000

main debug: using access_demux module "live555"

main debug: TIMER module_need() : 135.000 ms - Total 135.000 ms / 1 intvls (Avg 135.000 ms)

main warning: invalid start-time ignored

main debug: looking for a subtitle file in C:\Program Files\VideoLAN\VLC\

main debug: looking for decoder module: 36 candidates

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

avcodec debug: libavcodec initialized (interface 0x342000)

avcodec debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) started

main debug: using decoder module "avcodec"

main debug: TIMER module_need() : 190.000 ms - Total 190.000 ms / 1 intvls (Avg 190.000 ms)

main debug: looking for packetizer module: 21 candidates

packetizer_h264 debug: found NAL_SPS (sps_id=0)

packetizer_h264 debug: found NAL_PPS (pps_id=0 sps_id=0)

main debug: using packetizer module "packetizer_h264"

main debug: TIMER module_need() : 63.000 ms - Total 63.000 ms / 1 intvls (Avg 63.000 ms)

main debug: thread (decoder) created at priority 0 (../.././src/input/decoder.c:315)

main debug: thread started

main debug: `rtsp://169.254.1.5' successfully opened

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry

live555 warning: no data received in 10s. Switching to TCP

main debug: thread times: real 0m10.527105s, kernel 0m0.000000s, user 0m0.000000s

avcodec debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) stopped

main debug: removing module "avcodec"

main debug: killing decoder fourcc `h264', 0 PES in FIFO

main debug: removing module "packetizer_h264"

main debug: Program doesn't contain anymore ES

qt4 debug: Updating the geometry

qt4 debug: Updating the geometry


________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 3:01 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

My stream complies with RFC 3984, and I insert SPS and PPS at the front of every I frame.
The problem is VLC always gives the message:  "live555 no data received with 10s" than rtsp tear down . I'm pretty sure the rtp stream is there and rtp port number is right. Why VLC cannot receive the stream and decode it as rtp/h264?

In order for VLC to be able to play the stream, VLC needs a SDP description, so that it will know (i) that the stream is H.264, and (ii) which RTP payload format code it is using.

Are you giving VLC a SDP description - either directly (as a file), or indirectly, using RTSP?

--

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/20101020/d92bc93a/attachment-0001.html>

From finlayson at live555.com  Wed Oct 20 15:24:03 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 15:24:03 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50
	e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com>
	<f06240801c8e515d7be0e@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>
Message-ID: <f06240802c8e51ae0ec5b@[66.80.62.44]>

>I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.

OK, that will help a lot.  Rather than using VLC (at first), try 
using "openRTSP" <http://www.live555.com/openRTSP/> to read the 
stream.

Check whether "openRTSP" receives data correctly from your stream (it 
should write a file called "video-H264-1" or something like that). 
Does "openRTSP" write such a file (and is it nonempty)?  If so, then 
the problem is probably a VLC decoding problem (and therefore, for a 
VLC mailing list instead).  If, however, "openRTSP" doesn't record a 
file (or the file is empty), then there's apparently a problem with 
your RTSP/RTP stream (and therefore, something of interest to us).
-- 

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/20101020/1e1c4b77/attachment.html>

From jnoring at logitech.com  Wed Oct 20 15:40:57 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Wed, 20 Oct 2010 15:40:57 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
	<f06240800c8e50e170a49@66.80.62.44>
	<f06240801c8e515d7be0e@66.80.62.44>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>
Message-ID: <AANLkTi=SaFyKGY9wu0cejj6TJzg9J8SqhcC_OdCVAZOR@mail.gmail.com>

On Wed, Oct 20, 2010 at 3:12 PM, Larry Cui <Larry.Cui at zoran.com> wrote:

>  I?m using RTSP, I did not use sdp file, but through RSTP DESCIBE.  If the
> PPS is a little bit different from SDP in RTSP, is it a problem? I really
> could not find other issue.
>
> When I open VLC, I only input rtsp://169.254.1.5, nothing else. Is this a
> problem? I?m reading the source code for VLC, seems they need a track id.
>
>
>
> Note : *live555 warning: *no data received in 10s. Switching to TCP
>
>
>

I'm not totally certain, but your problem is likely due to appending SPS/PPS
information to _every_ intra-frame.  I would correctly send it in your SDP
file, and never send it in-stream; this will resolve the issue.  (To test
this hypothesis, try sending it with only the first intra-frame)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/a4040fb6/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 15:40:59 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Wed, 20 Oct 2010 22:40:59 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240802c8e51ae0ec5b@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com> <f06240802c8e51ae0ec5b@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C21BE@zcomb2.Zoran.com>

Is there any Windows version openRTSP exe file? Or I have to find to way to compile the source code under Windows?

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 3:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.

OK, that will help a lot.  Rather than using VLC (at first), try using "openRTSP" <http://www.live555.com/openRTSP/> to read the stream.

Check whether "openRTSP" receives data correctly from your stream (it should write a file called "video-H264-1" or something like that).  Does "openRTSP" write such a file (and is it nonempty)?  If so, then the problem is probably a VLC decoding problem (and therefore, for a VLC mailing list instead).  If, however, "openRTSP" doesn't record a file (or the file is empty), then there's apparently a problem with your RTSP/RTP stream (and therefore, something of interest to us).

--

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/20101020/627937b7/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 15:43:56 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Wed, 20 Oct 2010 22:43:56 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <AANLkTi=SaFyKGY9wu0cejj6TJzg9J8SqhcC_OdCVAZOR@mail.gmail.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@66.80.62.44><f06240801c8e515d7be0e@
	66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zoran.com>
	<AANLkTi=SaFyKGY9wu0cejj6TJzg9J8SqhcC_OdCVAZOR@mail.gmail.com>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C21CB@zcomb2.Zoran.com>

I first send SDP information in RTSP only, but it does not work under VLC or Quicktime. Then I try to send SPS and PPS often.

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Wednesday, October 20, 2010 3:41 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

On Wed, Oct 20, 2010 at 3:12 PM, Larry Cui <Larry.Cui at zoran.com<mailto:Larry.Cui at zoran.com>> wrote:
I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.  If the PPS is a little bit different from SDP in RTSP, is it a problem? I really could not find other issue.
When I open VLC, I only input rtsp://169.254.1.5<http://169.254.1.5>, nothing else. Is this a problem? I'm reading the source code for VLC, seems they need a track id.


Note : live555 warning: no data received in 10s. Switching to TCP


I'm not totally certain, but your problem is likely due to appending SPS/PPS information to _every_ intra-frame.  I would correctly send it in your SDP file, and never send it in-stream; this will resolve the issue.  (To test this hypothesis, try sending it with only the first intra-frame)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/b983ba98/attachment.html>

From finlayson at live555.com  Wed Oct 20 19:16:03 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 19:16:03 -0700
Subject: [Live-devel] The first H.264 SPS packet gets skipped
In-Reply-To: <1927283721.9221287187489443.JavaMail.root@mail.stretchinc.com>
References: <1927283721.9221287187489443.JavaMail.root@mail.stretchinc.com>
Message-ID: <f06240800c8e551dfbc40@[66.80.62.44]>

>I sub-classed H264VideoStreamFramer from FramedFilter class. I 
>implemented currentNALUnitEndsAccessUnit() and 
>isH264VideoStreamFramer() and returned TRUE for both since my 
>encoder always provides me with a complete NAL.

No, that's not what "currentNALUnitEndsAccessUnit()" is supposed to 
do (otherwise there'd be no point in having this function, because it 
would always return True).  "currentNALUnitEndsAccessUnit()" is 
supposed to return True if and only if the current NAL unit is the 
last one that makes up a video frame - i.e., an image.  Note that 
it's possible for a video frame to consist of more than NAL unit; if 
this is the case then "currentNALUnitEndsAccessUnit()" should return 
True only for the last of these NAL units.
-- 

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

From Larry.Cui at zoran.com  Wed Oct 20 21:52:19 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Thu, 21 Oct 2010 04:52:19 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240802c8e51ae0ec5b@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com> <f06240802c8e51ae0ec5b@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>

File name created, but it is empty, I have to Ctrl+C to terminate. How terminate it gracefully?

The weird part is stream is sending to the port 169.254.1., but nothing is written to the file,

================================================================
The following message:

Created receiver for "video/H264" subsession (client po
Sending request: SETUP rtsp://169.254.1.5/stream1/track
CSeq: 4
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010
Transport: RTP/AVP;unicast;client_port=54716-54717


Received 193 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 4
Date: Thu, Jan 01 1970 00:08:37 GMT
Transport:RTP/AVP;unicast;destination=169.254.1.1;sourc
Session: 1


Setup "video/H264" subsession (client ports 54716-54717
Created output file: "XXXvideo-H264-1"
Sending request: PLAY rtsp://169.254.1.5/stream1/ RTSP/
CSeq: 5
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010
Session: 1
Range: npt=0.000-


Received 176 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Thu, Jan 01 1970 00:08:37 GMT
Range: npt = 0.000 -
Session: 1
RTP-Info: url=rtsp://169.254.1.5/stream1/track1;seq=651


Started playing session
Receiving streamed data...

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 3:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.

OK, that will help a lot.  Rather than using VLC (at first), try using "openRTSP" <http://www.live555.com/openRTSP/> to read the stream.

Check whether "openRTSP" receives data correctly from your stream (it should write a file called "video-H264-1" or something like that).  Does "openRTSP" write such a file (and is it nonempty)?  If so, then the problem is probably a VLC decoding problem (and therefore, for a VLC mailing list instead).  If, however, "openRTSP" doesn't record a file (or the file is empty), then there's apparently a problem with your RTSP/RTP stream (and therefore, something of interest to us).

--

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/20101021/c0d64e7b/attachment.html>

From Larry.Cui at zoran.com  Wed Oct 20 22:18:01 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Thu, 21 Oct 2010 05:18:01 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com> <f06240802c8e51ae0ec5b@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C22BD@zcomb2.Zoran.com>

For H264 over RTP, the rtpPayload type must be 31???

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Larry Cui
Sent: Wednesday, October 20, 2010 9:52 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

File name created, but it is empty, I have to Ctrl+C to terminate. How terminate it gracefully?

The weird part is stream is sending to the port 169.254.1., but nothing is written to the file,

================================================================
The following message:

Created receiver for "video/H264" subsession (client po
Sending request: SETUP rtsp://169.254.1.5/stream1/track
CSeq: 4
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010
Transport: RTP/AVP;unicast;client_port=54716-54717


Received 193 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 4
Date: Thu, Jan 01 1970 00:08:37 GMT
Transport:RTP/AVP;unicast;destination=169.254.1.1;sourc
Session: 1


Setup "video/H264" subsession (client ports 54716-54717
Created output file: "XXXvideo-H264-1"
Sending request: PLAY rtsp://169.254.1.5/stream1/ RTSP/
CSeq: 5
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010
Session: 1
Range: npt=0.000-


Received 176 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Thu, Jan 01 1970 00:08:37 GMT
Range: npt = 0.000 -
Session: 1
RTP-Info: url=rtsp://169.254.1.5/stream1/track1;seq=651


Started playing session
Receiving streamed data...

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 3:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I'm using RTSP, I did not use sdp file, but through RSTP DESCIBE.

OK, that will help a lot.  Rather than using VLC (at first), try using "openRTSP" <http://www.live555.com/openRTSP/> to read the stream.

Check whether "openRTSP" receives data correctly from your stream (it should write a file called "video-H264-1" or something like that).  Does "openRTSP" write such a file (and is it nonempty)?  If so, then the problem is probably a VLC decoding problem (and therefore, for a VLC mailing list instead).  If, however, "openRTSP" doesn't record a file (or the file is empty), then there's apparently a problem with your RTSP/RTP stream (and therefore, something of interest to us).

--

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/20101021/b2f88424/attachment-0001.html>

From finlayson at live555.com  Wed Oct 20 22:20:39 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 22:20:39 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50
	e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]
	><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor	an.com>
	<f06240802c8e51ae0ec5b@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
Message-ID: <f06240801c8e57cab1f1b@[66.80.62.44]>

>File name created, but it is empty, I have to Ctrl+C to terminate. 
>How terminate it gracefully?

On Unix systems, you can kill the process with -HUP.  However, 
there's no good way to do this in Windoze.  It doesn't really matter, 
though; if the output file is empty, then that's significant.

I'm assuming that you're not behind a firewall that's blocking UDP 
packets.  I.e., I assume that you get the same result if you try 
receiving the stream over the RTSP TCP connection - i.e., using the 
"-t" flag - assuming that your server supports this.

But unfortunately, the only way I can help you now is if you put your 
server on a publically-accessible computer, and send us the "rtsp://" 
URL, so I can investigate out the problem myself.
-- 

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/20101020/736901c8/attachment.html>

From finlayson at live555.com  Wed Oct 20 22:25:32 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Oct 2010 22:25:32 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C22BD@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50
	e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]
	><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor	an.com>
	<f06240802c8e51ae0ec5b@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22BD@zcomb2.Zoran.com>
Message-ID: <f06240802c8e57e7a8b49@[66.80.62.44]>

>For H264 over RTP, the rtpPayload type must be 31???

No!  For H.264 over RTP, the payload format code must be dynamic. 
(The static code 31 is reserved for H.261.)

(If you'd used our code for your server implementation, then you 
would have gotten this automatically!)
-- 

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/20101020/12666cd7/attachment.html>

From Larry.Cui at zoran.com  Thu Oct 21 01:39:46 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Thu, 21 Oct 2010 08:39:46 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240801c8e57cab1f1b@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com><f06240802c8e51ae0ec5b@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
	<f06240801c8e57cab1f1b@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>

I'll continue...
openRTSP runs on windows, wireshark can capture the RTP packet, rtp header is correct, udp port number and ip address is right, but openRTSP does not output any error message, stays at "Receiving streamed data" while the file is empty.(Note, the port number and ip address are read from WireShark)

No Firewall, just two computer small network, cannot public.


________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, October 20, 2010 10:21 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

File name created, but it is empty, I have to Ctrl+C to terminate. How terminate it gracefully?

On Unix systems, you can kill the process with -HUP.  However, there's no good way to do this in Windoze.  It doesn't really matter, though; if the output file is empty, then that's significant.

I'm assuming that you're not behind a firewall that's blocking UDP packets.  I.e., I assume that you get the same result if you try receiving the stream over the RTSP TCP connection - i.e., using the "-t" flag - assuming that your server supports this.

But unfortunately, the only way I can help you now is if you put your server on a publically-accessible computer, and send us the "rtsp://" URL, so I can investigate out the problem myself.

--

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/20101021/6b0b8cd1/attachment.html>

From finlayson at live555.com  Thu Oct 21 05:45:13 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 21 Oct 2010 05:45:13 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50
	e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]
	><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com><f06240802c8e51ae0ec5b@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A
	5F23B4C22AE@zcomb2.Zoran.com>	<f06240801c8e57cab1f1b@[66.80.62.44]>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>
Message-ID: <f06240801c8e5e63d248f@[66.80.62.44]>

>I'll continue...
>openRTSP runs on windows, wireshark can capture the RTP packet, rtp 
>header is correct, udp port number and ip address is right, but 
>openRTSP does not output any error message, stays at "Receiving 
>streamed data" while the file is empty.(Note, the port number and ip 
>address are read from WireShark)
>
>No Firewall, just two computer small network, cannot public.

Then I'm not going to be able to help you.  Sorry.
-- 

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/20101021/b9cbcaa7/attachment.html>

From kamildobk at poczta.onet.pl  Fri Oct 22 02:05:29 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Fri, 22 Oct 2010 11:05:29 +0200
Subject: [Live-devel] RTSP-over-HTTP question
Message-ID: <8539DD1A90874B46B59845A164AE67DB@KamilPC>

Hi,

Below is wireshark output of 'openRTSP.exe -T 80 -u admin admin -F 
rtp_data -m rtsp://192.168.3.4/VideoInput/1/h264/1'


GET /VideoInput/1/h264/1 HTTP/1.0
CSeq: 1
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.10.20)
x-sessioncookie: 4d4566946d3c5c4b79a2fd3
Accept: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="You need ID"



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META HTTP-EQUIV="Content-Script-Type" CONTENT="text/javascript">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<TITLE>SANYO NETWORK CAMERA</TITLE>
<SCRIPT language="JavaScript">

<!--
//-->

</SCRIPT>
<STYLE TYPE="text/css">
<!--
BODY {color:#ffffff; font-family:Arial, sans-serif; font-size:12pt; 
font-weight:bold; background-color:#000000; }
.top {font-family:Arial, sans-serif; font-size:20pt; font-weight:bold; }
.content {font-family:Arial, sans-serif; font-size:12pt; font-weight:bold; }
-->

</STYLE></HEAD><BODY><CENTER><TABLE BORDER="0"><TR><TD ALIGN="CENTER" 
CLASS="top">AUTHENTICATION 
ERROR</TD></TR><TR><TD><BR></TD></TR><TR><TD><BR></TD></TR><TR><TD 
ALIGN="CENTER" CLASS="content">Please input a correct user 
name/password</TD></TR></TABLE><BR></CENTER></BODY></HTML>

GET /VideoInput/1/h264/1 HTTP/1.0
CSeq: 3
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.10.20)
x-sessioncookie: dbe115cec3266617fab9b26
Accept: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache



and that's all ... I see no other requests sent to the server. I think the 
problem is beacause this server does not immediately close its connection 
after http reply, so client is able to send a repeated request during the 
same connection but it is ignored by the server. When I turn off client 
authorization everything goes ok.

Regards,
Kamil



From finlayson at live555.com  Fri Oct 22 03:36:32 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Oct 2010 03:36:32 -0700
Subject: [Live-devel] RTSP-over-HTTP question
In-Reply-To: <8539DD1A90874B46B59845A164AE67DB@KamilPC>
References: <8539DD1A90874B46B59845A164AE67DB@KamilPC>
Message-ID: <f06240801c8e718e2d662@[66.80.62.44]>

>and that's all ... I see no other requests sent to the server. I 
>think the problem is beacause this server does not immediately close 
>its connection after http reply, so client is able to send a 
>repeated request during the same connection but it is ignored by the 
>server.

No, the problem is that the server is completely ignoring the 
resending of the HTTP "GET" command - the one that contains the 
properly filled-in "Authorization:" header.  Because this is not our 
server (i.e., it apparently was not developed using our code), we 
can't help you any more here.  You're going to have to contact the 
server developer for help.
-- 

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

From kamildobk at poczta.onet.pl  Fri Oct 22 04:59:50 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Fri, 22 Oct 2010 13:59:50 +0200
Subject: [Live-devel] RTSP-over-HTTP question
Message-ID: <6708B8FBE12F4E91A99AA427E3A9E8F4@KamilPC>

> No, the problem is that the server is completely ignoring the resending of 
> the HTTP "GET" command

Yes, the server ignores this request but it does it because it is closing a 
connection. I tried `live.2010.01.22` and it is working fine with this 
server - it doesn't try to send a second request during the same connection.

Regards,
Kamil 


From finlayson at live555.com  Fri Oct 22 08:51:30 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Oct 2010 08:51:30 -0700
Subject: [Live-devel] RTSP-over-HTTP question
In-Reply-To: <6708B8FBE12F4E91A99AA427E3A9E8F4@KamilPC>
References: <6708B8FBE12F4E91A99AA427E3A9E8F4@KamilPC>
Message-ID: <f06240807c8e75e986025@[66.80.62.44]>

>>No, the problem is that the server is completely ignoring the 
>>resending of the HTTP "GET" command
>
>Yes, the server ignores this request but it does it because it is 
>closing a connection.

The server can't be closing the connection, otherwise it would never 
be able to stream back data to the client later.  It's apparently 
keeping the connection open, but just not responding to the resending 
of the HTTP "GET".


>  I tried `live.2010.01.22` and it is working fine with this server - 
>it doesn't try to send a second request during the same connection.

The difference between these two versions is that - in the old 
version - we didn't resend the HTTP "GET" command, but instead 
continued as normal, sending a subsequent HTTP "POST" command (on a 
new connection), with an "Authorization:" header.

It's not clear (from the limited documentation on "RTSP-over-HTTP 
tunneling") which behavior is 'correct', but because your server 
(which I assume is Darwin/QTSS) is happier with the old behavior, 
I've installed a new version (2010.10.22) of the code that behaves 
the same way as the old version.

(ps. People are taken more seriously on this mailing list if they use 
a professional email address - i.e., one whose domain name identifies 
an organization (company or school) that they're affiliated with, or 
at least a personal custom domain name - not something like 
"@gmail.com" or "@poczta.onet.pl".)
-- 

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

From belloni at imavis.com  Fri Oct 22 10:27:56 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 22 Oct 2010 19:27:56 +0200
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
Message-ID: <4CC1C99C.6020708@imavis.com>

  Dear Ross,
I noted a very strange behaviour with you latest liveMedia implementation.
On my workstation (Linux OS), it works like a charm. On other systems 
(with Linux OS as well), it seems not to respond to the OPTIONS post, 
time-outing every client (except openRTSP, that after ~ 30 seconds tries 
a DESCRIBE - and succeeds). Please note the test program I use and the 
library version - the 20 Oct one is the same across all these systems.

After a session of debugging and wireshark, turns out that in the 
systems where liveMedia *does* not respond to the OPTIONS post, the 
first incomingRequestHandler1 sucks from the net the actual POST request 
and its headers *plus* the first Base64-Encoded request (that is the 
RTSP OPTIONS one). It can happen, because in TCP there is no assumption 
that the number of the write()s at one end is equal to the number of the 
read()s on the other end.
Having the two in one single buffer, it seems that liveMedia parses the 
first and ignores the second. The result? It does not respond to the 
OPTIONS while the client is waiting and the client eventually times out.

Just to be clear, here are the DEBUG headers (I added some fprintf here 
and there):

Returned from incomingRequestHandler1()
accept()ed connection from 192.168.1.9710This is the 
incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 431, now calling handleRequestBytes
RTSPClientSession[0x888d8]::handleRequestBytes() read 431 new bytes:POST 
/video HTTP/1.0
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)
x-sessioncookie: 0a8998e09cb7d658f9712c2
Content-Type: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT

T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjIyMC92aWRlbyBSVFNQLzEuMA0KQ1NlcTogMQ0KVXNlci1BZ2VudDogb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEwLjA0LjA5KQ0KDQo=
parseRTSPRequestString() failed
parseHTTPRequestString() succeeded, returning cmdName "POST", 
sessionCookie "0a8998e09cb7d658f9712c2"
Handled HTTP "POST" request (client input socket: 6)
Returned from incomingRequestHandler1()

As you can see, the first readSocket returned with bytesRead = 431. 
Looking at it in Wireshark, it is composed by two packets, one long 275 
bytes (that contains the POST etc.) and one 156, which contains the 
Base64 OPTIONS request. The latter gets ignored.

This is what the same logs look like in a system that does the "correct" 
thing:

Returned from incomingRequestHandler1()
accept()ed connection from 192.168.1.9710This is the 
incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 275, now calling handleRequestBytes
RTSPClientSession[0x93058d8]::handleRequestBytes() read 275 new 
bytes:POST /video HTTP/1.0
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)
x-sessioncookie: 42d4916a5815383b8142f83
Content-Type: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT

(first packet)

parseRTSPRequestString() failed
parseHTTPRequestString() succeeded, returning cmdName "POST", 
sessionCookie "42d4916a5815383b8142f83"
Handled HTTP "POST" request (client input socket: 6)
Returned from incomingRequestHandler1()
This is the incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 156, now calling handleRequestBytes
RTSPClientSession[0x9300990]::handleRequestBytes() read 156 new 
bytes:T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjk3L3ZpZGVvIFJUU1AvMS4wDQpDU2VxOiAxDQpVc2VyLUFnZW50OiBvcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTAuMDQuMDkpDQoNCg==
Base64-decided 156 input bytes into 115 new bytes:OPTIONS 
rtsp://192.168.1.97/video RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)

(second packet, *not* ignored this time).

The problem is found randomly in the systems. Probably it depends on the 
net stack, networking hardware and/or network load and lag.
Can you confirm me it's a bug?

Best Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101022/e55a533d/attachment.html>

From finlayson at live555.com  Fri Oct 22 11:55:15 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Oct 2010 11:55:15 -0700
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
In-Reply-To: <4CC1C99C.6020708@imavis.com>
References: <4CC1C99C.6020708@imavis.com>
Message-ID: <f06240808c8e78a390731@[66.80.62.44]>

>Can you confirm me it's a bug?

Yes, it appears to be a bug.  I'm curious, though: Does it still 
occur (sometimes) even with an up-to-date version of "openRTSP"?  The 
version that you're using - 2010.04.09 - is very old; our RTSP client 
implementation has changed significantly since then.
-- 

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

From finlayson at live555.com  Fri Oct 22 20:44:31 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Oct 2010 20:44:31 -0700
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
In-Reply-To: <4CC1C99C.6020708@imavis.com>
References: <4CC1C99C.6020708@imavis.com>
Message-ID: <f06240800c8e80a710dc6@[66.80.62.44]>

OK, I have now installed a new version (2010.10.23) of the "LIVE555 
Streaming Media" code that should overcome this problem.
-- 

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

From belloni at imavis.com  Sat Oct 23 04:13:09 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Sat, 23 Oct 2010 13:13:09 +0200
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
In-Reply-To: <f06240808c8e78a390731@[66.80.62.44]>
References: <4CC1C99C.6020708@imavis.com> <f06240808c8e78a390731@[66.80.62.44]>
Message-ID: <4CC2C345.8050204@imavis.com>

  Il 22/10/2010 20:55, Ross Finlayson ha scritto:
>> Can you confirm me it's a bug?
>
> Yes, it appears to be a bug.  I'm curious, though: Does it still occur 
> (sometimes) even with an up-to-date version of "openRTSP"?  The 
> version that you're using - 2010.04.09 - is very old; our RTSP client 
> implementation has changed significantly since then.
Yes, I can confirm it occurs even with the Oct 20 / 2010 version of 
openRTSP. I'm downloading the latest version right now and will make you 
know if everything's ok as soon as I test it extensively.

As usual, thank you!

Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101023/e351f874/attachment.html>

From belloni at imavis.com  Sat Oct 23 08:06:19 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Sat, 23 Oct 2010 17:06:19 +0200
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
In-Reply-To: <f06240800c8e80a710dc6@[66.80.62.44]>
References: <4CC1C99C.6020708@imavis.com> <f06240800c8e80a710dc6@[66.80.62.44]>
Message-ID: <4CC2F9EB.5000008@imavis.com>

  Il 23/10/2010 05:44, Ross Finlayson ha scritto:
> OK, I have now installed a new version (2010.10.23) of the "LIVE555 
> Streaming Media" code that should overcome this problem.
Dear Ross,
the new version works correctly (no more ignored RTSP requests), but it 
seems to introduce a new bug, this time in memory management. Glibc 
seems to crash on a double free or corruption when the RTSP connection 
is abruptedly closed (I could see this behaviour on VLC everytime I 
closed the client clicking on the "close" button on the VLC window - I 
didn't have had time to analyze the network dump yet, and I don't know 
if VLC sends a TEARDOWN or closes the socket directly in that case).
Please note that this happens *not only* on HTTP-over-RTSP connection, 
but on RTSP/UDP and RTSP/TCP sessions too.
Here's the backtrace:

*** glibc detected *** ./rtspServer: double free or corruption (out): 
0x406e5008 ***
======= Backtrace: =========
/lib/libc.so.6[0x40231f3c]
/lib/libc.so.6(cfree+0xa0)[0x40233bd0]
./rtspServer(_ZN15OutPacketBufferD1Ev+0x18)[0x5e9e8]
./rtspServer(_ZN18MultiFramedRTPSinkD2Ev+0x28)[0x6b160]
./rtspServer(_ZN12VideoRTPSinkD2Ev+0x14)[0x6b45c]
./rtspServer(_ZN19JPEGRSTVideoRTPSinkD0Ev+0x14)[0x47518]
./rtspServer(_ZN16MediaLookupTable6removeEPKc+0x60)[0x479c4]
./rtspServer(_ZN11StreamState7reclaimEv+0x24)[0x7e654]
./rtspServer(_ZN11StreamStateD0Ev+0x14)[0x7e978]
./rtspServer(_ZN29OnDemandServerMediaSubsession12deleteStreamEjRPv+0x78)[0x7ef4c]
./rtspServer(_ZN10RTSPServer17RTSPClientSession19reclaimStreamStatesEv+0x60)[0x6e8bc]
./rtspServer(_ZN10RTSPServer17RTSPClientSessionD2Ev+0xbc)[0x7222c]
./rtspServer(_ZN15LimitRTSPServer22LimitRTSPClientSessionD0Ev+0x44)[0x46e7c]
./rtspServer(_ZN10RTSPServer17RTSPClientSession18handleRequestBytesEi+0x3a8)[0x6fae4]
./rtspServer(_ZN10RTSPServer17RTSPClientSession23incomingRequestHandler1Ev+0x48)[0x6fe28]
./rtspServer(_ZN18BasicTaskScheduler10SingleStepEj+0x1ec)[0x91904]
./rtspServer(_ZN19BasicTaskScheduler011doEventLoopEPc+0x20)[0x90c84]
./rtspServer(_Z8mainLoopP16UsageEnvironmentjjPc+0x614)[0x449e8]
./rtspServer(main+0x3c)[0x410f4]
/lib/libc.so.6(__libc_start_main+0x120)[0x401ddfd4]
======= Memory map: ========
00008000-000ba000 r-xp 00000000 fe:01 68090      
/usr/local/rtspServer/rtspServer
000c2000-000c7000 rw-p 000b2000 fe:01 68090      
/usr/local/rtspServer/rtspServer
000c7000-00162000 rwxp 000c7000 00:00 0          [heap]
40000000-4001d000 r-xp 00000000 fe:01 92962      /lib/ld-2.8.so
4001d000-40021000 rw-p 4001d000 00:00 0
40021000-40022000 rw-s 00000000 00:0e 11139      
/dev/shm/sem.sem_empty_c1SnPP
40022000-40023000 rw-s 00000000 00:0e 11140      
/dev/shm/sem.sem_fill_WIxeyt
40023000-40024000 rw-p 40023000 00:00 0
40024000-40025000 r--p 0001c000 fe:01 92962      /lib/ld-2.8.so
40025000-40026000 rw-p 0001d000 fe:01 92962      /lib/ld-2.8.so
40026000-4002c000 r-xp 00000000 fe:01 92946      /lib/librt-2.8.so
4002c000-40033000 ---p 00006000 fe:01 92946      /lib/librt-2.8.so
40033000-40034000 r--p 00005000 fe:01 92946      /lib/librt-2.8.so
40034000-40035000 rw-p 00006000 fe:01 92946      /lib/librt-2.8.so
40035000-400f6000 r-xp 00000000 fe:01 32631      
/usr/lib/libstdc++.so.6.0.10
400f6000-400fd000 ---p 000c1000 fe:01 32631      
/usr/lib/libstdc++.so.6.0.10
400fd000-40100000 r--p 000c0000 fe:01 32631      
/usr/lib/libstdc++.so.6.0.10
40100000-40102000 rw-p 000c3000 fe:01 32631      
/usr/lib/libstdc++.so.6.0.10
40102000-40107000 rw-p 40102000 00:00 0
40107000-401ac000 r-xp 00000000 fe:01 92936      /lib/libm-2.8.so
401ac000-401b3000 ---p 000a5000 fe:01 92936      /lib/libm-2.8.so
401b3000-401b4000 r--p 000a4000 fe:01 92936      /lib/libm-2.8.so
401b4000-401b5000 rw-p 000a5000 fe:01 92936      /lib/libm-2.8.so
401b5000-401c1000 r-xp 00000000 fe:01 92971      /lib/libgcc_s.so.1
401c1000-401c8000 ---p 0000c000 fe:01 92971      /lib/libgcc_s.so.1
401c8000-401c9000 rw-p 0000b000 fe:01 92971      /lib/libgcc_s.so.1
401c9000-402e6000 r-xp 00000000 fe:01 92950      /lib/libc-2.8.so
402e6000-402ed000 ---p 0011d000 fe:01 92950      /lib/libc-2.8.so
402ed000-402ef000 r--p 0011c000 fe:01 92950      /lib/libc-2.8.so
402ef000-402f0000 rw-p 0011e000 fe:01 92950      /lib/libc-2.8.so
402f0000-402f3000 rw-p 402f0000 00:00 0
402f3000-40307000 r-xp 00000000 fe:01 92964      /lib/libpthread-2.8.so
40307000-4030f000 ---p 00014000 fe:01 92964      /lib/libpthread-2.8.so
4030f000-40310000 r--p 00014000 fe:01 92964      /lib/libpthread-2.8.so
40310000-40311000 rw-p 00015000 fe:01 92964      /lib/libpthread-2.8.so
40311000-40313000 rw-p 40311000 00:00 0
40313000-404fc000 rw-s 00000000 00:07 1310727    /SYSV000005d0 (deleted)
404fc000-406e5000 rw-s 00000000 00:07 1310727    /SYSV000005d0 (deleted)
406e5000-407da000 rw-p 406e5000 00:00 0
40800000-40821000 rw-p 40800000 00:00 0
40821000-40900000 ---p 40821000 00:00 0
be9a8000-be9bd000 rwxp be9a8000 00:00 0          [stack]

If you need more info, I'm gonna collect them as soon as I can.

Best Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101023/db8cc87b/attachment-0001.html>

From finlayson at live555.com  Sat Oct 23 15:17:09 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 23 Oct 2010 15:17:09 -0700
Subject: [Live-devel] Tricky bug in RTSP-on-HTTP server implementation?
In-Reply-To: <4CC2F9EB.5000008@imavis.com>
References: <4CC1C99C.6020708@imavis.com>
	<f06240800c8e80a710dc6@[66.80.62.44]> <4CC2F9EB.5000008@imavis.com>
Message-ID: <f06240801c8e90d4704d6@[66.80.62.44]>

>the new version works correctly (no more ignored RTSP requests), but 
>it seems to introduce a new bug, this time in memory management. 
>Glibc seems to crash on a double free or corruption when the RTSP 
>connection is abruptedly closed (I could see this behaviour on VLC 
>everytime I closed the client clicking on the "close" button on the 
>VLC window - I didn't have had time to analyze the network dump yet, 
>and I don't know if VLC sends a TEARDOWN or closes the socket 
>directly in that case).

It sends a "TEARDOWN", I think.  You should be able to get the same 
effect with "openRTSP" with the "-d <duration>" option.


>Please note that this happens *not only* on HTTP-over-RTSP 
>connection, but on RTSP/UDP and RTSP/TCP sessions too.

In that case, the bug could not have been introduced in the new 
version (because the changes in that version affected only 
RTSP-over-HTTP streams).

How repeatable is this??  Can you repeat this with 
"live555MediaServer" (or "testOnDemandRTSPServer") with unmodified 
source code?  Using "openRTSP -d <duration>" as a client?  (Or just 
with VLC.)  And does the crash happen every time?

If the crash happens only with modified server code, then there's not 
much I'll be able to do at my end to track it down.
-- 

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

From Larry.Cui at zoran.com  Mon Oct 25 11:37:04 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Mon, 25 Oct 2010 18:37:04 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <f06240801c8e5e63d248f@[66.80.62.44]>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@[66.80.62.44]><BC9441BA1804F74EAEF8
	A5366280A5F23B4C216F@zcomb2.Zoran.com><f06240801c8e515d7be0e@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C219B@zcomb2.Zor
	an.com><f06240802c8e51ae0ec5b@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
	<f06240801c8e57cab1f1b@[66.80.62.44]><BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>
	<f06240801c8e5e63d248f@[66.80.62.44]>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C267F@zcomb2.Zoran.com>

I solved this problem, and can stream the h264 video with VLC player, which works fine.

The current question Live555 RFC 3984 format is compatible with Quicktime or not?

With quicktime player, data is buffering and playing without any video output.

Thanks,



________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, October 21, 2010 5:45 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I'll continue...
openRTSP runs on windows, wireshark can capture the RTP packet, rtp header is correct, udp port number and ip address is right, but openRTSP does not output any error message, stays at "Receiving streamed data" while the file is empty.(Note, the port number and ip address are read from WireShark)

No Firewall, just two computer small network, cannot public.

Then I'm not going to be able to help you.  Sorry.

--

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/20101025/d41b0274/attachment.html>

From jnoring at logitech.com  Mon Oct 25 11:47:13 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Mon, 25 Oct 2010 11:47:13 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C267F@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
	<f06240800c8e50e170a49@66.80.62.44>
	<f06240801c8e515d7be0e@66.80.62.44>
	<f06240802c8e51ae0ec5b@66.80.62.44>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
	<f06240801c8e57cab1f1b@66.80.62.44>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>
	<f06240801c8e5e63d248f@66.80.62.44>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C267F@zcomb2.Zoran.com>
Message-ID: <AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com>

On Mon, Oct 25, 2010 at 11:37 AM, Larry Cui <Larry.Cui at zoran.com> wrote:

>  I solved this problem, and can stream the h264 video with VLC player,
> which works fine.
>
>
>
> The current question Live555 RFC 3984 format is compatible with Quicktime
> or not?
>
>
>
> With quicktime player, data is buffering and playing without any video
> output.
>

Yes, Live555 is RFC 3984 compliant, and my implementation works with
quicktime.  And what did you change to make VLC work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101025/69d7f338/attachment.html>

From Larry.Cui at zoran.com  Mon Oct 25 12:07:16 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Mon, 25 Oct 2010 19:07:16 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@66.80.62.44><f06240801c8e515d7be0e@
	66.80.62.44><f06240802c8e51ae0ec5b@66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com><f06240801c8e57cab1f1
	b@66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com><f06240801c8e5e63d248f@66.80.62.44><BC9441BA1804F74EAE
	F8A5366280A5F23B4C267F@zcomb2.Zoran.com>
	<AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C2696@zcomb2.Zoran.com>

Jeremy Noring,

Windows Firewall default state is ON.
After Off the firewall, streaming is ok.
With my implementation, only video packet and SPS and PPS are sent out, there is no SEI packet. VLC plays well, while Quicktime plays without video output. I believe quicktime does not select right demux/decoder. Also, the new version Quicktime has no way to select the file format in the preferences.
Did you make any select in the preferences in Quicktime?


Thanks,

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Monday, October 25, 2010 11:47 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 11:37 AM, Larry Cui <Larry.Cui at zoran.com<mailto:Larry.Cui at zoran.com>> wrote:
I solved this problem, and can stream the h264 video with VLC player, which works fine.

The current question Live555 RFC 3984 format is compatible with Quicktime or not?

With quicktime player, data is buffering and playing without any video output.

Yes, Live555 is RFC 3984 compliant, and my implementation works with quicktime.  And what did you change to make VLC work?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101025/cd4fcaea/attachment.html>

From jnoring at logitech.com  Mon Oct 25 12:15:49 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Mon, 25 Oct 2010 12:15:49 -0700
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C2696@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com>
	<f06240800c8e50e170a49@66.80.62.44>
	<f06240802c8e51ae0ec5b@66.80.62.44>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.com>
	<f06240801c8e5e63d248f@66.80.62.44>
	<AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C2696@zcomb2.Zoran.com>
Message-ID: <AANLkTi=Xv8yc+P=R0d10X0AuwOhSWZ1RC5O+LPwJH-7M@mail.gmail.com>

On Mon, Oct 25, 2010 at 12:07 PM, Larry Cui <Larry.Cui at zoran.com> wrote:

>  Jeremy Noring,
>
>  Windows Firewall default state is ON.
>
> After Off the firewall, streaming is ok.
>
> With my implementation, only video packet and SPS and PPS are sent out,
> there is no SEI packet. VLC plays well, while Quicktime plays without video
> output. I believe quicktime does not select right demux/decoder. Also, the
> new version Quicktime has no way to select the file format in the
> preferences.
>
> Did you make any select in the preferences in Quicktime?
>

No, I just type in the url (e.g. rtsp://IP_ADDRESS:PORT/SESSION).  I suspect
it's probably because you're sending sps/pps info in-stream, or maybe not
sending SPS/PPS as their own frame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101025/bc7631e5/attachment-0001.html>

From Larry.Cui at zoran.com  Mon Oct 25 12:19:54 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Mon, 25 Oct 2010 19:19:54 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <AANLkTi=Xv8yc+P=R0d10X0AuwOhSWZ1RC5O+LPwJH-7M@mail.gmail.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@66.80.62.44><f06240802c8e51ae0ec5b@
	66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com><BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.c
	om><f06240801c8e5e63d248f@66.80.62.44><AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com><BC9441BA1804F74EAEF8A53662
	80A5F23B4C2696@zcomb2.Zoran.com>
	<AANLkTi=Xv8yc+P=R0d10X0AuwOhSWZ1RC5O+LPwJH-7M@mail.gmail.com>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C26B9@zcomb2.Zoran.com>

I only type in rstp://IP_address, no port and session, let RTSP negotiate. The picture size is correct, but no video output.

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Monday, October 25, 2010 12:16 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 12:07 PM, Larry Cui <Larry.Cui at zoran.com<mailto:Larry.Cui at zoran.com>> wrote:
Jeremy Noring,
Windows Firewall default state is ON.
After Off the firewall, streaming is ok.
With my implementation, only video packet and SPS and PPS are sent out, there is no SEI packet. VLC plays well, while Quicktime plays without video output. I believe quicktime does not select right demux/decoder. Also, the new version Quicktime has no way to select the file format in the preferences.
Did you make any select in the preferences in Quicktime?

No, I just type in the url (e.g. rtsp://IP_ADDRESS:PORT/SESSION).  I suspect it's probably because you're sending sps/pps info in-stream, or maybe not sending SPS/PPS as their own frame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101025/e3cd7ced/attachment.html>

From 503430770 at qq.com  Mon Oct 25 20:21:15 2010
From: 503430770 at qq.com (=?ISO-8859-1?B?NTAzNDMwNzcw?=)
Date: Tue, 26 Oct 2010 11:21:15 +0800
Subject: [Live-devel] what to do in my "FramedSource" class
Message-ID: <tencent_1D92B7D66FBBD7F76200DD1C@qq.com>

HI,I want to write a live555 Server with live source of MPEG4.The source is my camera which I can get one frame everytime.
    Now,I have write my own "FramedSource" class  and WISMPEG4VideoServerMediaSubsession class(reference the WIS streamer).But it can't work correctly.
    I save the frames  to a file .I find  the file have  no VOSS, VOS,GOV. Can you give me some suggestion? or tell me what  can I do in my "FramedSource" class?
   
    Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101026/ad299489/attachment.html>

From satram at juniper.net  Mon Oct 25 21:35:46 2010
From: satram at juniper.net (satheesh Ramalingam)
Date: Tue, 26 Oct 2010 10:05:46 +0530
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <BC9441BA1804F74EAEF8A5366280A5F23B4C26B9@zcomb2.Zoran.com>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@66.80.62.44><f06240802c8e51ae0ec5b@
	66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com><BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.c
	om><f06240801c8e5e63d248f@66.80.62.44><AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com><BC9441BA1804F74EAEF8A53662
	80A5F23B4C2696@zcomb2.Zoran.com>
	<AANLkTi=Xv8yc+P=R0d10X0AuwOhSWZ1RC5O+LPwJH-7M@mail.gmail.com>
	<BC9441BA1804F74EAEF8A5366280A5F23B4C26B9@zcomb2.Zoran.com>
Message-ID: <FB649DA20153634794BEBBAB504DA1AD45060BEF4D@EMBX02-BNG.jnpr.net>

Larry,
SPS and PPS has to be sent to client as part of sprop-parameter-set in SDP.
RFC 3984: section 8.1 talks about how to construct sprop-parameter-set. This will solve the quicktime problem.


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Larry Cui
Sent: Tuesday, October 26, 2010 12:50 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I only type in rstp://IP_address, no port and session, let RTSP negotiate. The picture size is correct, but no video output.

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Monday, October 25, 2010 12:16 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 12:07 PM, Larry Cui <Larry.Cui at zoran.com<mailto:Larry.Cui at zoran.com>> wrote:
Jeremy Noring,
Windows Firewall default state is ON.
After Off the firewall, streaming is ok.
With my implementation, only video packet and SPS and PPS are sent out, there is no SEI packet. VLC plays well, while Quicktime plays without video output. I believe quicktime does not select right demux/decoder. Also, the new version Quicktime has no way to select the file format in the preferences.
Did you make any select in the preferences in Quicktime?

No, I just type in the url (e.g. rtsp://IP_ADDRESS:PORT/SESSION).  I suspect it's probably because you're sending sps/pps info in-stream, or maybe not sending SPS/PPS as their own frame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101026/42a98a6e/attachment.html>

From sr at coexsi.fr  Tue Oct 26 02:57:15 2010
From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=)
Date: Tue, 26 Oct 2010 11:57:15 +0200
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
Message-ID: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>

Dear all,

This is my first post in this mailing-list, I hope this will be relevant.
I'm testing and evaluating the Live555 RTSP server for streaming TS files.

Of course, as I would like to use H.264/MPAG4-AVC video stream, I can't
index my TS files with the tool "MPEG2TransportStreamIndexer" provided in
the test programs, and I've find a lot of questions about indexing this kind
of video stream in the mailing-list archives.

So, I've developed a small application (in .Net, so running on Microsoft
Windows or it may also runs on Linux with Mono as no special library is
needed). You can find it here:
http://www.coexsi.fr/publications/live555-universal-indexer/ with some extra
explanations. It creates a .tsx index file that is compatible with the one
expected by the Live555 streaming server, but only indexing the starting of
the PES sections with video data.

Of course, this isn't as good as "MPEG2TransportStreamIndexer" that is
searching for I-Frame, but it works, even if sometimes it's a little bit
"blocky".

I hope it can help and I can help if someone want to port the VB.Net code to
C in order to make a Linux application.

Best regards,
Sebastien RAILLARD.





From Larry.Cui at zoran.com  Tue Oct 26 08:55:20 2010
From: Larry.Cui at zoran.com (Larry Cui)
Date: Tue, 26 Oct 2010 15:55:20 +0000
Subject: [Live-devel] H264 over RTP/RFC 3984
In-Reply-To: <FB649DA20153634794BEBBAB504DA1AD45060BEF4D@EMBX02-BNG.jnpr.net>
References: <BC9441BA1804F74EAEF8A5366280A5F23B4C2111@zcomb2.Zoran.com><f06240800c8e50e170a49@66.80.62.44><f06240802c8e51ae0ec5b@
	66.80.62.44><BC9441BA1804F74EAEF8A5366280A5F23B4C22AE@zcomb2.Zoran.com><BC9441BA1804F74EAEF8A5366280A5F23B4C2301@zcomb2.Zoran.c
	om><f06240801c8e5e63d248f@66.80.62.44><AANLkTikGk0ybR-cfp4hiK9GUX1QWKsWS2XzbNXAoMuJD@mail.gmail.com><BC9441BA1804F74EAEF8A53662
	80A5F23B4C2696@zcomb2.Zoran.com><AANLkTi=Xv8yc+P=R0d10X0AuwOhSWZ1RC5O+LPwJH-7M@mail.gmail.com><BC9441BA1804F74EAEF8A5366280A5F2
	3B4C26B9@zcomb2.Zoran.com>
	<FB649DA20153634794BEBBAB504DA1AD45060BEF4D@EMBX02-BNG.jnpr.net>
Message-ID: <BC9441BA1804F74EAEF8A5366280A5F23B4C2807@zcomb2.Zoran.com>

I have already set SPS and PPS in SDP, also, Movie Inspector in Quicktime tells the right H264 format. Data is buffering and playing, but only QT logo is showing up. Movie FPS is 0 (abnormal), other parameters are right.
I looked through Apple Quicktime forum, other person posted the same problem, but no body replied with a solution.

Thanks,



________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of satheesh Ramalingam
Sent: Monday, October 25, 2010 9:36 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

Larry,
SPS and PPS has to be sent to client as part of sprop-parameter-set in SDP.
RFC 3984: section 8.1 talks about how to construct sprop-parameter-set. This will solve the quicktime problem.


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Larry Cui
Sent: Tuesday, October 26, 2010 12:50 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

I only type in rstp://IP_address, no port and session, let RTSP negotiate. The picture size is correct, but no video output.

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Monday, October 25, 2010 12:16 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 12:07 PM, Larry Cui <Larry.Cui at zoran.com<mailto:Larry.Cui at zoran.com>> wrote:
Jeremy Noring,
Windows Firewall default state is ON.
After Off the firewall, streaming is ok.
With my implementation, only video packet and SPS and PPS are sent out, there is no SEI packet. VLC plays well, while Quicktime plays without video output. I believe quicktime does not select right demux/decoder. Also, the new version Quicktime has no way to select the file format in the preferences.
Did you make any select in the preferences in Quicktime?

No, I just type in the url (e.g. rtsp://IP_ADDRESS:PORT/SESSION).  I suspect it's probably because you're sending sps/pps info in-stream, or maybe not sending SPS/PPS as their own frame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101026/50f15a29/attachment-0001.html>

From francisco at j2kvideo.com  Tue Oct 26 07:01:43 2010
From: francisco at j2kvideo.com (Francisco Feijoo)
Date: Tue, 26 Oct 2010 16:01:43 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
Message-ID: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>

Hello,

This is my first post in the list. Thanks for all your great work on the libraries.

My problem:

I'm trying to create a rtsp server to stream MJPEG images. I have implemented a new TestJPEGFileServerMediaSubsession that creates a TestJPEGVideoRTPSink.

In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the quantization tables of the image into the header using setSpecialHeaderBytes

This is working fine using some JPEG images, but fails with others. 

I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart Interval) and I think I have to do something else seeing this comment in the code 

// Note: We assume that there are no 'restart markers'

So, what should I do with images containing restart markers and macroblocks?

-- 
Francisco Feijoo
Software Engineer
J2K Video Limited

W: www.j2kvideo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101026/3c05f846/attachment.html>

From finlayson at live555.com  Tue Oct 26 17:18:00 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 26 Oct 2010 17:18:00 -0700
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
In-Reply-To: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>
References: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>
Message-ID: <f06240800c8ed20006f4d@[66.80.62.44]>

>So, I've developed a small application (in .Net, so running on Microsoft
>Windows or it may also runs on Linux with Mono as no special library is
>needed). You can find it here:
>http://www.coexsi.fr/publications/live555-universal-indexer/ with some extra
>explanations. It creates a .tsx index file that is compatible with the one
>expected by the Live555 streaming server, but only indexing the starting of
>the PES sections with video data.

Interesting.  Does this support 'fast forward' and/or 'reverse play' 
at all, or just 'seeking'?
-- 

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

From finlayson at live555.com  Tue Oct 26 17:39:33 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 26 Oct 2010 17:39:33 -0700
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
Message-ID: <f06240800c8ed24424f62@[66.80.62.44]>

>I'm trying to create a rtsp server to stream MJPEG images.

Ugh.  JPEG is a *terrible* codec for video streaming.


>  I have implemented a new TestJPEGFileServerMediaSubsession that 
>creates a TestJPEGVideoRTPSink.
>
>In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the 
>quantization tables of the image into the header 
>using setSpecialHeaderBytes

Note that the existing "JPEGVideoRTPSink" code already does this. 
You should not have to reinvent the wheel here.


>This is working fine using some JPEG images, but fails with others.
>
>I'm testing one image that has the marker 0xFF, 0xDD ( Define 
>Restart Interval) and I think I have to do something else seeing 
>this comment in the code
>
>// Note: We assume that there are no 'restart markers'
>
>So, what should I do with images containing restart markers and macroblocks?

The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") 
currently don't support "Restart Marker Headers" (see RFC 2435, 
section 3.1.7).  You will need to update the (definition and 
implementation) of these two classes to support them.
-- 

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

From sr at coexsi.fr  Wed Oct 27 00:21:47 2010
From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=)
Date: Wed, 27 Oct 2010 09:21:47 +0200
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
In-Reply-To: <f06240800c8ed20006f4d@[66.80.62.44]>
References: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>
	<f06240800c8ed20006f4d@[66.80.62.44]>
Message-ID: <001101cb75a7$9e61aa20$db24fe60$@coexsi.fr>



> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: mercredi 27 octobre 2010 02:18
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Indexing of TS files for non MPEG2 video
> streams
> 
> >So, I've developed a small application (in .Net, so running on
> >Microsoft Windows or it may also runs on Linux with Mono as no special
> >library is needed). You can find it here:
> >http://www.coexsi.fr/publications/live555-universal-indexer/ with some
> >extra explanations. It creates a .tsx index file that is compatible
> >with the one expected by the Live555 streaming server, but only
> >indexing the starting of the PES sections with video data.
> 
> Interesting.  Does this support 'fast forward' and/or 'reverse play'
> at all, or just 'seeking'?

I don't think 'reverse play' and 'fast forward' will work as it may heavily
relying on I-Frame.
I've just did a quick test with VLC player and I confirm it doesn't seem to
work.

I've finished the C implementation for Linux, after doing more tests, I'll
post it.

> --
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1152 / Virus Database: 424/3220 - Release Date: 10/26/10


From francisco at j2kvideo.com  Wed Oct 27 00:32:22 2010
From: francisco at j2kvideo.com (Francisco Feijoo)
Date: Wed, 27 Oct 2010 09:32:22 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <f06240800c8ed24424f62@[66.80.62.44]>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@[66.80.62.44]>
Message-ID: <3E3638C5-6C30-4F20-8C2B-2A78E6545151@j2kvideo.com>

Thanks for the quick response Ross,

> 
> Note that the existing "JPEGVideoRTPSink" code already does this. You should not have to reinvent the wheel here.

I think I should explained this better. I don't know how to obtain the qFactor from one MJPEG image so I'm copying all the values from the original image to the new header. And then  TestJPEGVideoSource::qFactor() returns 255. Maybe this part is wrong and I need to calculate the Q, but how? is there an example of this somewhere?.

> 
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") currently don't support "Restart Marker Headers" (see RFC 2435, section 3.1.7).  You will need to update the (definition and implementation) of these two classes to support them.

Ok, I have been thinking on other possibility. Do you know if is possible to decode de MJPEG image to get a simpler version and remove the restart marker headers?

-- 
Francisco Feijoo
Software Engineer
J2K Video Limited
W: www.j2kvideo.com

El 27/10/2010, a las 02:39, Ross Finlayson escribi?:

>> I'm trying to create a rtsp server to stream MJPEG images.
> 
> Ugh.  JPEG is a *terrible* codec for video streaming.
> 
> 
>> I have implemented a new TestJPEGFileServerMediaSubsession that creates a TestJPEGVideoRTPSink.
>> 
>> In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the quantization tables of the image into the header using setSpecialHeaderBytes
> 
> Note that the existing "JPEGVideoRTPSink" code already does this. You should not have to reinvent the wheel here.
> 
> 
>> This is working fine using some JPEG images, but fails with others.
>> 
>> I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart Interval) and I think I have to do something else seeing this comment in the code
>> 
>> // Note: We assume that there are no 'restart markers'
>> 
>> So, what should I do with images containing restart markers and macroblocks?
> 
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") currently don't support "Restart Marker Headers" (see RFC 2435, section 3.1.7).  You will need to update the (definition and implementation) of these two classes to support them.
> -- 
> 
> 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/20101027/925b290a/attachment.html>

From belloni at imavis.com  Wed Oct 27 00:51:35 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 27 Oct 2010 09:51:35 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <f06240800c8ed24424f62@[66.80.62.44]>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@[66.80.62.44]>
Message-ID: <4CC7DA07.7080202@imavis.com>

  Il 27/10/2010 02:39, Ross Finlayson ha scritto:
>> I'm trying to create a rtsp server to stream MJPEG images.
>
> Ugh.  JPEG is a *terrible* codec for video streaming.

I agree, but *everyone* requests JPEG as an entry point. Onvif, for 
example, requests MJPEG/RTP streaming as a MUST IMPLEMENT.

>
>
>>  I have implemented a new TestJPEGFileServerMediaSubsession that 
>> creates a TestJPEGVideoRTPSink.
>>
>> In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the 
>> quantization tables of the image into the header using 
>> setSpecialHeaderBytes
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You 
> should not have to reinvent the wheel here.
>
>
>> This is working fine using some JPEG images, but fails with others.
>>
>> I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart 
>> Interval) and I think I have to do something else seeing this comment 
>> in the code
>>
>> // Note: We assume that there are no 'restart markers'
>>
>> So, what should I do with images containing restart markers and 
>> macroblocks?
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") 
> currently don't support "Restart Marker Headers" (see RFC 2435, 
> section 3.1.7).  You will need to update the (definition and 
> implementation) of these two classes to support them.
I did something similar, Francisco. In a nutshell, you've got to extend 
JPEGVideoSource and look for DRI markers like this:

  //Look for the DRI marker
     for (unsigned i = 0; i < JPEGHeaderSize; ++i) {
         if (fBuffer[i] == 0xFF) {
             if (fBuffer[i+1] == 0xDD) { // DRI
                 if ((fBuffer[i+2] != 0) || (fBuffer[i+3] != 4)) {
                     envir() << "Wrong DRI marker!\n";
                     continue;
                 }
                 else {
                     fRestartInterval = (fBuffer[i+4] << 8) + fBuffer[i+5];
                     printf ("DRI restart Interval found @ %d is %d\n", 
i, fRestartInterval);
                     break;
                 }
             }
         }
     }

Then, extend JPEGVideoRTPSink to take care about the restart markers in 
doSpecialFrameHandling():
(In reality, here I extended VideoRTPSink because I needed to, feel free 
to do your adaptations)

u_int8_t RestartMarkerHeader[4]; // the special header
u_int16_t restartInterval = source->restartInterval();

RestartMarkerHeader[0] = restartInterval >> 8;
RestartMarkerHeader[1] = restartInterval;
RestartMarkerHeader[2] = 0xFF;
RestartMarkerHeader[3] = 0xFF;

setSpecialHeaderBytes(RestartMarkerHeader, sizeof RestartMarkerHeader, 
sizeof mainJPEGHeader /* start position */);

Finally, reflect the size change in the headers in specialHeaderSize():

// We assume that there are 'restart markers'
headerSize += 4;

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/dd3c023d/attachment-0001.html>

From belloni at imavis.com  Wed Oct 27 00:57:12 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 27 Oct 2010 09:57:12 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <3E3638C5-6C30-4F20-8C2B-2A78E6545151@j2kvideo.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>	<f06240800c8ed24424f62@[66.80.62.44]>
	<3E3638C5-6C30-4F20-8C2B-2A78E6545151@j2kvideo.com>
Message-ID: <4CC7DB58.9060007@imavis.com>

  Il 27/10/2010 09:32, Francisco Feijoo ha scritto:
> Thanks for the quick response Ross,
>
>>
>> Note that the existing "JPEGVideoRTPSink" code already does this. You 
>> should not have to reinvent the wheel here.
>
> I think I should explained this better. I don't know how to obtain the 
> qFactor from one MJPEG image so I'm copying all the values from the 
> original image to the new header. And then 
>  TestJPEGVideoSource::qFactor() returns 255. Maybe this part is wrong 
> and I need to calculate the Q, but how? is there an example of this 
> somewhere?.

Q factor is 255 if the quantization tables are dynamic. You got to 
extract the quantization tables parsing the JPEG header and looking for 
the "DQT" marker(s), [0xFF 0xDB as far as I remember]

>
>>
>> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") 
>> currently don't support "Restart Marker Headers" (see RFC 2435, 
>> section 3.1.7).  You will need to update the (definition and 
>> implementation) of these two classes to support them.
>
> Ok, I have been thinking on other possibility. Do you know if is 
> possible to decode de MJPEG image to get a simpler version and remove 
> the restart marker headers?
>
> -- 
> Francisco Feijoo
> Software Engineer
> J2K Video Limited
> W: www.j2kvideo.com <http://www.j2kvideo.com>
>
> El 27/10/2010, a las 02:39, Ross Finlayson escribi?:
>
>>> I'm trying to create a rtsp server to stream MJPEG images.
>>
>> Ugh.  JPEG is a *terrible* codec for video streaming.
>>
>>
>>> I have implemented a new TestJPEGFileServerMediaSubsession that 
>>> creates a TestJPEGVideoRTPSink.
>>>
>>> In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the 
>>> quantization tables of the image into the header using 
>>> setSpecialHeaderBytes
>>
>> Note that the existing "JPEGVideoRTPSink" code already does this. You 
>> should not have to reinvent the wheel here.
>>
>>
>>> This is working fine using some JPEG images, but fails with others.
>>>
>>> I'm testing one image that has the marker 0xFF, 0xDD ( Define 
>>> Restart Interval) and I think I have to do something else seeing 
>>> this comment in the code
>>>
>>> // Note: We assume that there are no 'restart markers'
>>>
>>> So, what should I do with images containing restart markers and 
>>> macroblocks?
>>
>> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") 
>> currently don't support "Restart Marker Headers" (see RFC 2435, 
>> section 3.1.7).  You will need to update the (definition and 
>> implementation) of these two classes to support them.
>> -- 
>>
>> 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


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/f435853b/attachment.html>

From finlayson at live555.com  Wed Oct 27 01:01:58 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 27 Oct 2010 01:01:58 -0700
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <4CC7DA07.7080202@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@[66.80.62.44]> <4CC7DA07.7080202@imavis.com>
Message-ID: <f06240800c8ed8cb10041@[66.80.62.44]>

>I did something similar, Francisco. In a nutshell, you've got to 
>extend JPEGVideoSource and look for DRI markers like this:

Feel free to post a patch file, and I'll look at folding these 
changes into a future release.
-- 

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

From francisco at j2kvideo.com  Wed Oct 27 01:12:31 2010
From: francisco at j2kvideo.com (Francisco Feijoo)
Date: Wed, 27 Oct 2010 10:12:31 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <4CC7DA07.7080202@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@66.80.62.44> <4CC7DA07.7080202@imavis.com>
Message-ID: <AANLkTikJyzWN_jN_pr+RHMFX9JVXxP1N7qZQK884C=LD@mail.gmail.com>

Thanks Cristiano!, I'm going to add the restart marker header as you are
showing.

2010/10/27 Cristiano Belloni <belloni at imavis.com>

>  Il 27/10/2010 02:39, Ross Finlayson ha scritto:
>
> I'm trying to create a rtsp server to stream MJPEG images.
>
>
> Ugh.  JPEG is a *terrible* codec for video streaming.
>
>
> I agree, but *everyone* requests JPEG as an entry point. Onvif, for
> example, requests MJPEG/RTP streaming as a MUST IMPLEMENT.
>
>
>
>
>  I have implemented a new TestJPEGFileServerMediaSubsession that creates a
> TestJPEGVideoRTPSink.
>
> In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the quantization
> tables of the image into the header using setSpecialHeaderBytes
>
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You
> should not have to reinvent the wheel here.
>
>
> This is working fine using some JPEG images, but fails with others.
>
> I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart
> Interval) and I think I have to do something else seeing this comment in the
> code
>
> // Note: We assume that there are no 'restart markers'
>
> So, what should I do with images containing restart markers and
> macroblocks?
>
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink")
> currently don't support "Restart Marker Headers" (see RFC 2435, section
> 3.1.7).  You will need to update the (definition and implementation) of
> these two classes to support them.
>
> I did something similar, Francisco. In a nutshell, you've got to extend
> JPEGVideoSource and look for DRI markers like this:
>
>  //Look for the DRI marker
>     for (unsigned i = 0; i < JPEGHeaderSize; ++i) {
>         if (fBuffer[i] == 0xFF) {
>             if (fBuffer[i+1] == 0xDD) { // DRI
>                 if ((fBuffer[i+2] != 0) || (fBuffer[i+3] != 4)) {
>                     envir() << "Wrong DRI marker!\n";
>                     continue;
>                 }
>                 else {
>                     fRestartInterval = (fBuffer[i+4] << 8) + fBuffer[i+5];
>                     printf ("DRI restart Interval found @ %d is %d\n", i,
> fRestartInterval);
>                     break;
>                 }
>             }
>         }
>     }
>
> Then, extend JPEGVideoRTPSink to take care about the restart markers in
> doSpecialFrameHandling():
> (In reality, here I extended VideoRTPSink because I needed to, feel free to
> do your adaptations)
>
> u_int8_t RestartMarkerHeader[4]; // the special header
> u_int16_t restartInterval = source->restartInterval();
>
> RestartMarkerHeader[0] = restartInterval >> 8;
> RestartMarkerHeader[1] = restartInterval;
> RestartMarkerHeader[2] = 0xFF;
> RestartMarkerHeader[3] = 0xFF;
>
> setSpecialHeaderBytes(RestartMarkerHeader, sizeof RestartMarkerHeader,
> sizeof mainJPEGHeader /* start position */);
>
> Finally, reflect the size change in the headers in specialHeaderSize():
>
> // We assume that there are 'restart markers'
> headerSize += 4;
>
> --
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com
> belloni at imavis.com <//belloni at imavis.com>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Francisco Feijoo
Software Engineer
J2K Video Limited

T: +34 654967246
E: francisco at j2kvideo.com
W: www.j2kvideo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/fb337df8/attachment.html>

From francisco at j2kvideo.com  Wed Oct 27 01:14:59 2010
From: francisco at j2kvideo.com (Francisco Feijoo)
Date: Wed, 27 Oct 2010 10:14:59 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <4CC7DB58.9060007@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@66.80.62.44>
	<3E3638C5-6C30-4F20-8C2B-2A78E6545151@j2kvideo.com>
	<4CC7DB58.9060007@imavis.com>
Message-ID: <AANLkTikzwpY9sf2hCTCT+rM+o-hKkR5L_G0mL2BaQBxx@mail.gmail.com>

Now I'm extracting the tables starting with FFDB and adding them in
doSpecialFrameHandling(). What Q value should I use? I have used 255 to
indicate that each frame could have different tables.


2010/10/27 Cristiano Belloni <belloni at imavis.com>

>  Il 27/10/2010 09:32, Francisco Feijoo ha scritto:
>
> Thanks for the quick response Ross,
>
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You
> should not have to reinvent the wheel here.
>
>
>  I think I should explained this better. I don't know how to obtain the
> qFactor from one MJPEG image so I'm copying all the values from the original
> image to the new header. And then  TestJPEGVideoSource::qFactor() returns
> 255. Maybe this part is wrong and I need to calculate the Q, but how? is
> there an example of this somewhere?.
>
>
> Q factor is 255 if the quantization tables are dynamic. You got to extract
> the quantization tables parsing the JPEG header and looking for the "DQT"
> marker(s), [0xFF 0xDB as far as I remember]
>
>
>
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink")
> currently don't support "Restart Marker Headers" (see RFC 2435, section
> 3.1.7).  You will need to update the (definition and implementation) of
> these two classes to support them.
>
>
>  Ok, I have been thinking on other possibility. Do you know if is possible
> to decode de MJPEG image to get a simpler version and remove the restart
> marker headers?
>
>     --
> Francisco Feijoo
> Software Engineer
> J2K Video Limited
>  W: www.j2kvideo.com
>
>  El 27/10/2010, a las 02:39, Ross Finlayson escribi?:
>
>  I'm trying to create a rtsp server to stream MJPEG images.
>
>
> Ugh.  JPEG is a *terrible* codec for video streaming.
>
>
>  I have implemented a new TestJPEGFileServerMediaSubsession that creates a
> TestJPEGVideoRTPSink.
>
>
>  In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the
> quantization tables of the image into the header using setSpecialHeaderBytes
>
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You
> should not have to reinvent the wheel here.
>
>
> This is working fine using some JPEG images, but fails with others.
>
>
>  I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart
> Interval) and I think I have to do something else seeing this comment in the
> code
>
>
>  // Note: We assume that there are no 'restart markers'
>
>
>  So, what should I do with images containing restart markers and
> macroblocks?
>
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink")
> currently don't support "Restart Marker Headers" (see RFC 2435, section
> 3.1.7).  You will need to update the (definition and implementation) of
> these two classes to support them.
> --
>
> 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 listlive-devel at lists.live555.comhttp://lists.live555.com/mailman/listinfo/live-devel
>
>
>
> --
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com
> belloni at imavis.com <//belloni at imavis.com>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Francisco Feijoo
Software Engineer
J2K Video Limited

T: +34 654967246
E: francisco at j2kvideo.com
W: www.j2kvideo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/ba0c4dd5/attachment-0001.html>

From belloni at imavis.com  Wed Oct 27 01:24:32 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 27 Oct 2010 10:24:32 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <f06240800c8ed8cb10041@[66.80.62.44]>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>	<f06240800c8ed24424f62@[66.80.62.44]>
	<4CC7DA07.7080202@imavis.com> <f06240800c8ed8cb10041@[66.80.62.44]>
Message-ID: <4CC7E1C0.4040904@imavis.com>

  Il 27/10/2010 10:01, Ross Finlayson ha scritto:
>> I did something similar, Francisco. In a nutshell, you've got to 
>> extend JPEGVideoSource and look for DRI markers like this:
>
> Feel free to post a patch file, and I'll look at folding these changes 
> into a future release.
As soon as I'm done with the "double free" issue (I'm investigating!), 
I'll gladly post a patch for MJPEG!

Thanks & Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/08aaff15/attachment.html>

From sr at coexsi.fr  Wed Oct 27 02:53:33 2010
From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=)
Date: Wed, 27 Oct 2010 11:53:33 +0200
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
References: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>
	<f06240800c8ed20006f4d@[66.80.62.44]> 
Message-ID: <007401cb75bc$d1b48040$751d80c0$@coexsi.fr>



> -----Original Message-----
> From: S?bastien RAILLARD (COEXSI) [mailto:sr at coexsi.fr]
> Sent: mercredi 27 octobre 2010 09:22
> To: 'LIVE555 Streaming Media - development & use'
> Subject: RE: [Live-devel] Indexing of TS files for non MPEG2 video
> streams
> 
> 
> 
> > -----Original Message-----
> > From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> > bounces at ns.live555.com] On Behalf Of Ross Finlayson
> > Sent: mercredi 27 octobre 2010 02:18
> > To: LIVE555 Streaming Media - development & use
> > Subject: Re: [Live-devel] Indexing of TS files for non MPEG2 video
> > streams
> >
> > >So, I've developed a small application (in .Net, so running on
> > >Microsoft Windows or it may also runs on Linux with Mono as no
> > >special library is needed). You can find it here:
> > >http://www.coexsi.fr/publications/live555-universal-indexer/ with
> > >some extra explanations. It creates a .tsx index file that is
> > >compatible with the one expected by the Live555 streaming server, but
> > >only indexing the starting of the PES sections with video data.
> >
> > Interesting.  Does this support 'fast forward' and/or 'reverse play'
> > at all, or just 'seeking'?
> 
> I don't think 'reverse play' and 'fast forward' will work as it may
> heavily relying on I-Frame.
> I've just did a quick test with VLC player and I confirm it doesn't seem
> to work.
> 
> I've finished the C implementation for Linux, after doing more tests,
> I'll post it.

The C program is done, it can also be downloaded here:
http://www.coexsi.fr/publications/live555-universal-indexer/
The binary was built and tested on Ubuntu 32-bits systems.

I think there are 2 smalls bugs involving integer overflow in the LiveMedia
library:

* In "MPEG2IndexFromTransportStream.cpp":
    u_int8_t pcr_frac = (u_int8_t)(256*(pcr-pcr_int));
must be replaced by:
    u_int8_t pcr_frac = (u_int8_t)(255*(pcr-pcr_int));

* In "MPEG2TransportStreamIndexFile.cpp":
  return pcr_int + pcr_frac/256.0f;
must be replaced by:
  return pcr_int + pcr_frac/255.0f;

> 
> > --
> >
> > 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
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 10.0.1152 / Virus Database: 424/3220 - Release Date: 10/26/10



From francisco at j2kvideo.com  Wed Oct 27 03:49:29 2010
From: francisco at j2kvideo.com (Francisco Feijoo)
Date: Wed, 27 Oct 2010 12:49:29 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <4CC7E1C0.4040904@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@66.80.62.44> <4CC7DA07.7080202@imavis.com>
	<f06240800c8ed8cb10041@66.80.62.44> <4CC7E1C0.4040904@imavis.com>
Message-ID: <AANLkTim2OsZzPFc6ZBmyN9yG_p5k-ZxE7sdN5Qnraxge@mail.gmail.com>

Cristiano,

I have added the restart interval to the header as you showed before. The
DRI marker is:

FF,DD,00,04,00,28 so the restartInterval = 40


I think I'm close to the solution but using VLC I can't see the image
correctly. If I use an image without restart interval markers then I can see
the image perfectly.

I think I have to return a different type() value from
my TestJPEGVideoSource (RFC 2435 3.1.3.). Normally I only return type=1.

How could I know which is the type value of the image?


2010/10/27 Cristiano Belloni <belloni at imavis.com>

>  Il 27/10/2010 10:01, Ross Finlayson ha scritto:
>
> I did something similar, Francisco. In a nutshell, you've got to extend
> JPEGVideoSource and look for DRI markers like this:
>
>
> Feel free to post a patch file, and I'll look at folding these changes into
> a future release.
>
> As soon as I'm done with the "double free" issue (I'm investigating!), I'll
> gladly post a patch for MJPEG!
>
> Thanks & Regards,
> Cristiano.
>
>
> --
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com
> belloni at imavis.com <//belloni at imavis.com>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Francisco Feijoo
Software Engineer
J2K Video Limited

T: +34 654967246
E: francisco at j2kvideo.com
W: www.j2kvideo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/69c129af/attachment.html>

From belloni at imavis.com  Wed Oct 27 04:43:09 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 27 Oct 2010 13:43:09 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <AANLkTim2OsZzPFc6ZBmyN9yG_p5k-ZxE7sdN5Qnraxge@mail.gmail.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>	<f06240800c8ed24424f62@66.80.62.44>
	<4CC7DA07.7080202@imavis.com>	<f06240800c8ed8cb10041@66.80.62.44>
	<4CC7E1C0.4040904@imavis.com>
	<AANLkTim2OsZzPFc6ZBmyN9yG_p5k-ZxE7sdN5Qnraxge@mail.gmail.com>
Message-ID: <4CC8104D.50904@imavis.com>

  Il 27/10/2010 12:49, Francisco Feijoo ha scritto:
> Cristiano,
>
> I have added the restart interval to the header as you showed before. 
> The DRI marker is:
>
> FF,DD,00,04,00,28 so the restartInterval = 40
>
>
> I think I'm close to the solution but using VLC I can't see the image 
> correctly. If I use an image without restart interval markers then I 
> can see the image perfectly.
>
> I think I have to return a different type() value from 
> my TestJPEGVideoSource (RFC 2435 3.1.3.). Normally I only return type=1.
>
> How could I know which is the type value of the image?
>

Francisco, as RFC says, "Types 64-127 are the same as types 0-63, except 
that restart markers are present in the JPEG data and a Restart Marker 
header appears immediately following the main JPEG header."

I used to return 0, w/o DRI markers, and now i return 64 if DRI are 
present. My code is

if (fRestartInterval == 0) return 0;
     else return 64;

I don't know why you use 1, but in this case you could need to return 65 
(64 is the same type of 0, but with DRI markers, and so on).

Also, please don't top-post :)

Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/b562abec/attachment.html>

From finlayson at live555.com  Wed Oct 27 05:36:58 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 27 Oct 2010 05:36:58 -0700
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
In-Reply-To: <007401cb75bc$d1b48040$751d80c0$@coexsi.fr>
References: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>
	<f06240800c8ed20006f4d@[66.80.62.44]>
	<007401cb75bc$d1b48040$751d80c0$@coexsi.fr>
Message-ID: <f06240801c8edccb50167@[66.80.62.44]>

>I think there are 2 smalls bugs involving integer overflow in the LiveMedia
>library:
>
>* In "MPEG2IndexFromTransportStream.cpp":
>     u_int8_t pcr_frac = (u_int8_t)(256*(pcr-pcr_int));
>must be replaced by:
>     u_int8_t pcr_frac = (u_int8_t)(255*(pcr-pcr_int));
>
>* In "MPEG2TransportStreamIndexFile.cpp":
>   return pcr_int + pcr_frac/256.0f;
>must be replaced by:
>   return pcr_int + pcr_frac/255.0f;

No - the original code is correct in both cases.  Note that 
"pcr_frac" (in each case) is an 8-bit integer that represents a 
multiple of 1/256.  Therefore, when converting from (or to) a float, 
we need to multiply (or divide) by 256.
-- 

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

From renatomauro at libero.it  Wed Oct 27 05:56:39 2010
From: renatomauro at libero.it (Renato MAURO (Libero))
Date: Wed, 27 Oct 2010 14:56:39 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com><f06240800c8ed24424f62@[66.80.62.44]>
	<4CC7DA07.7080202@imavis.com>
Message-ID: <8C005191AC204B8596645FD544068D1D@CSystemDev>

I'm dealing with Onvif too and I need to extend JPEGVideoSource, call it JPEGVideoSourceEx. How to make the MediaSubsession create a JPEGVideoSourceEx class instead of a JPEGVideoSource.

Thank you,

    Renato MAURO

  ----- Original Message ----- 
  From: Cristiano Belloni 
  To: LIVE555 Streaming Media - development & use 
  Sent: Wednesday, October 27, 2010 9:51 AM
  Subject: Re: [Live-devel] JPEGVideoRTPSink and Restart markers


  Il 27/10/2010 02:39, Ross Finlayson ha scritto: 
      I'm trying to create a rtsp server to stream MJPEG images. 


    Ugh.  JPEG is a *terrible* codec for video streaming. 


  I agree, but *everyone* requests JPEG as an entry point. Onvif, for example, requests MJPEG/RTP streaming as a MUST IMPLEMENT.





       I have implemented a new TestJPEGFileServerMediaSubsession that creates a TestJPEGVideoRTPSink. 

      In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the quantization tables of the image into the header using setSpecialHeaderBytes 


    Note that the existing "JPEGVideoRTPSink" code already does this. You should not have to reinvent the wheel here. 



      This is working fine using some JPEG images, but fails with others. 

      I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart Interval) and I think I have to do something else seeing this comment in the code 

      // Note: We assume that there are no 'restart markers' 

      So, what should I do with images containing restart markers and macroblocks? 


    The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink") currently don't support "Restart Marker Headers" (see RFC 2435, section 3.1.7).  You will need to update the (definition and implementation) of these two classes to support them. 

  I did something similar, Francisco. In a nutshell, you've got to extend JPEGVideoSource and look for DRI markers like this:

   //Look for the DRI marker
      for (unsigned i = 0; i < JPEGHeaderSize; ++i) {
          if (fBuffer[i] == 0xFF) {
              if (fBuffer[i+1] == 0xDD) { // DRI
                  if ((fBuffer[i+2] != 0) || (fBuffer[i+3] != 4)) {
                      envir() << "Wrong DRI marker!\n";
                      continue;
                  }
                  else {
                      fRestartInterval = (fBuffer[i+4] << 8) + fBuffer[i+5];
                      printf ("DRI restart Interval found @ %d is %d\n", i, fRestartInterval);
                      break;
                  }
              }
          }
      }

  Then, extend JPEGVideoRTPSink to take care about the restart markers in doSpecialFrameHandling():
  (In reality, here I extended VideoRTPSink because I needed to, feel free to do your adaptations)

  u_int8_t RestartMarkerHeader[4]; // the special header
  u_int16_t restartInterval = source->restartInterval();

  RestartMarkerHeader[0] = restartInterval >> 8;
  RestartMarkerHeader[1] = restartInterval;
  RestartMarkerHeader[2] = 0xFF;
  RestartMarkerHeader[3] = 0xFF;

  setSpecialHeaderBytes(RestartMarkerHeader, sizeof RestartMarkerHeader, sizeof mainJPEGHeader /* start position */);

  Finally, reflect the size change in the headers in specialHeaderSize():

  // We assume that there are 'restart markers'
  headerSize += 4;


  -- 
  Belloni Cristiano
  Imavis Srl.
  www.imavis.com
  belloni at imavis.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/20101027/8dc9b205/attachment-0001.html>

From finlayson at live555.com  Wed Oct 27 06:10:12 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 27 Oct 2010 06:10:12 -0700
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <8C005191AC204B8596645FD544068D1D@CSystemDev>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com><f06240800c8ed24424f62@
	[66.80.62.44]>	<4CC7DA07.7080202@imavis.com>
	<8C005191AC204B8596645FD544068D1D@CSystemDev>
Message-ID: <f06240802c8edd3fcb607@[66.80.62.44]>

>I'm dealing with Onvif too and I need to extend JPEGVideoSource, 
>call it JPEGVideoSourceEx. How to make the MediaSubsession create a 
>JPEGVideoSourceEx class instead of a JPEGVideoSource.

You don't - because "MediaSession* is used for *receiving* JPEG/RTP 
streams.  It doesn't deal with "JPEGVideoSource" objects at all.

A "JPEGVideoSource" is used when *transmitting* JPEG/RTP streams. 
(An object of this type is fed into a "JPEGVideoRTPSink".)

Note that "JPEGVideoSource" is an abstract base type.  You extend it 
using normal C++ subclassing.

However, what this thread is talking about is adding support for JPEG 
'restart markers'.  Doing this will require modifying 
"JPEGVideoSource" (while still keeping it as an abstract base class) 
and modifying "JPEGVideoRTPSink".
-- 

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/20101027/225531c4/attachment.html>

From sr at coexsi.fr  Wed Oct 27 06:50:11 2010
From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=)
Date: Wed, 27 Oct 2010 15:50:11 +0200
Subject: [Live-devel] Indexing of TS files for non MPEG2 video streams
In-Reply-To: <f06240801c8edccb50167@[66.80.62.44]>
References: <003c01cb74f4$2bb55f20$83201d60$@coexsi.fr>	<f06240800c8ed20006f4d@[66.80.62.44]>	<007401cb75bc$d1b48040$751d80c0$@coexsi.fr>
	<f06240801c8edccb50167@[66.80.62.44]>
Message-ID: <00c001cb75dd$e0842550$a18c6ff0$@coexsi.fr>



> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: mercredi 27 octobre 2010 14:37
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Indexing of TS files for non MPEG2 video
> streams
> 
> >I think there are 2 smalls bugs involving integer overflow in the
> >LiveMedia
> >library:
> >
> >* In "MPEG2IndexFromTransportStream.cpp":
> >     u_int8_t pcr_frac = (u_int8_t)(256*(pcr-pcr_int)); must be
> >replaced by:
> >     u_int8_t pcr_frac = (u_int8_t)(255*(pcr-pcr_int));
> >
> >* In "MPEG2TransportStreamIndexFile.cpp":
> >   return pcr_int + pcr_frac/256.0f;
> >must be replaced by:
> >   return pcr_int + pcr_frac/255.0f;
> 
> No - the original code is correct in both cases.  Note that "pcr_frac"
> (in each case) is an 8-bit integer that represents a multiple of 1/256.
> Therefore, when converting from (or to) a float, we need to multiply (or
> divide) by 256.

Ok, I understand, it's because of the truncation when casting to integer: if
the fractional part is 0.9999999, 0. 9999999*256=255.9999744 and it's
truncated to 255 by cast, so there isn't any overflow. And as the fractional
part cannot be equal to 1, the cast values are always equal or less than
255.

Thank you.

> --
> 
> 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
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1152 / Virus Database: 424/3221 - Release Date: 10/26/10


From belloni at imavis.com  Wed Oct 27 08:14:59 2010
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 27 Oct 2010 17:14:59 +0200
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers + My
	Implementation
In-Reply-To: <4CC7E1C0.4040904@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>	<f06240800c8ed24424f62@[66.80.62.44]>	<4CC7DA07.7080202@imavis.com>
	<f06240800c8ed8cb10041@[66.80.62.44]> <4CC7E1C0.4040904@imavis.com>
Message-ID: <4CC841F3.9030103@imavis.com>

  Il 27/10/2010 10:24, Cristiano Belloni ha scritto:
> Il 27/10/2010 10:01, Ross Finlayson ha scritto:
>>> I did something similar, Francisco. In a nutshell, you've got to 
>>> extend JPEGVideoSource and look for DRI markers like this:
>>
>> Feel free to post a patch file, and I'll look at folding these 
>> changes into a future release.
> As soon as I'm done with the "double free" issue (I'm investigating!), 
> I'll gladly post a patch for MJPEG!
>
> Thanks & Regards,
> Cristiano.
>
> -- 
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com <http://www.imavis.com>
> belloni at imavis.com <mailto://belloni at imavis.com>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
Dear Ross,
As I suspected, my modifications to make live555 support the MJPEG 
restart markers was the cause of the double-free issue.
In this mail, I attach my JPEGRSTVideoRTPSink class, that extends 
VideoRTPSink, and LiveJPEGStreamSource, that extends JPEGVideoSource to 
parse JPEG.
Please note I didn't modify anything in liveMedia, but only extended its 
classes, instead. That's why I attached the entire JPEGRSTVideoRTPSink 
implementation, and not a patch to your JPEGVideoRTPSink.

The double-alloc issue seems to be triggered when I add a 4-byte special 
header for the RestartMarkerHeader in JPEGRSTVideoRTPSink class. This 
calls setSpecialHeaderBytes(), that calls OutPacketBuffer::insert(). In 
JPEGRSTVideoRTPSink::specialHeaderSize, I also set headerSize += 4 at 
the end, assuming that restart markers are present.
So far so good, but, investigating, I found that, somehow, this breaks 
MultiFramedRTPSink. In particular, this seems to invalidate the 
assumptions made in this piece of code:

if (fOutBuf->haveOverflowData()
&& fOutBuf->totalBytesAvailable() > fOutBuf->totalBufferSize()/2) {
     // Efficiency hack: Reset the packet start pointer to just in front of
     // the overflow data (allowing for the RTP header and special headers),
     // so that we probably don't have to "memmove()" the overflow data
     // into place when building the next packet:
       unsigned newPacketStart = fOutBuf->curPacketSize()
       - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize());
       fOutBuf->adjustPacketStart(newPacketStart);
    }

The first time it's invoked, the efficiency hack sets newPacketStart to 
4294939175 (!), and fOutBuf is adjusted to this value. This corrupts the 
fOutBuf OutPacketBuffer. When the buffer is deleted, it tries to dealloc 
4 gigabytes, and glibc gets very angry.

Solution: commenting out the efficiency hack seems to make the whole 
thing work.

[One last note: I didn't understand very well why the hack does not 
work. Since I tested this on an ARM/Montavista platform, it might be an 
"architectural" issue, since the number is very close to 2^32. I mean, 
the problem might be that this hack works only on Intel PCs, but not on 
other architectures. But I'm absolutely not sure.]

Best Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPEGRSTVideoRTPSink.cpp
Type: text/x-c++src
Size: 4925 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPEGRSTVideoRTPSink.hh
Type: text/x-c++hdr
Size: 1946 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LiveJPEGStreamSource.cpp
Type: text/x-c++src
Size: 8655 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LiveJPEGStreamSource.h
Type: text/x-chdr
Size: 2627 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0007.bin>

From lixiaobo-023 at 163.com  Wed Oct 27 21:57:49 2010
From: lixiaobo-023 at 163.com (Li Xiao BO)
Date: Thu, 28 Oct 2010 12:57:49 +0800 (CST)
Subject: [Live-devel] should I modify the MPEG4VideoStreamDiscreteFramer
	class?
Message-ID: <13cf7b1.d40b.12bf132f31b.Coremail.lixiaobo-023@163.com>

H  
   I want to develop a stream server with live555.My source is MPEG4 stream from my camera. I have writed myown "FramedSource" classand WISMPEG4VideoServerMediaSubsession class(refer to the WIS-streamer).I get one frame data from my camera ervrytime, so I use the  MPEG4VideoStreamDiscreteFramer class.
   VLC can connect to the server,but VLC don't disply any video.I analyse my MPEG4 data.I faund my MPEG4 data have noVOSS, VOS,GOV, so the MPEG4VideoStreamDiscreteFramer
::afterGettingFrame1 function can't analyse my data correctly.
   Qustion:
             1.Should I use theMPEG4VideoStreamDiscreteFramer class?
         2.If I should use the class,should I modify the class?
         3.How to modify the the class?
   Thanks for your help!
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101028/16febc5d/attachment.html>

From finlayson at live555.com  Thu Oct 28 00:56:40 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Oct 2010 00:56:40 -0700
Subject: [Live-devel] should I modify the MPEG4VideoStreamDiscreteFramer
 class?
In-Reply-To: <13cf7b1.d40b.12bf132f31b.Coremail.lixiaobo-023@163.com>
References: <13cf7b1.d40b.12bf132f31b.Coremail.lixiaobo-023@163.com>
Message-ID: <f06240804c8eedc9004ea@[66.80.62.44]>

>              1.Should I use the MPEG4VideoStreamDiscreteFramer class?

Yes, if and only if your MPEG-4 video source delivers discrete frames 
- i.e., one frame at a time.

If, however, your MPEG-4 video source delivers an unstructured stream 
of bytes - rather than one frame at a time - then you should use a 
"MPEG4VideoStreamFramer" instead.


>          2.If I should use the class,should I modify the class?

No, it already works well, and should not need modification.
-- 

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/20101028/59897bb0/attachment.html>

From lixiaobo-023 at 163.com  Thu Oct 28 02:33:32 2010
From: lixiaobo-023 at 163.com (Li Xiao BO)
Date: Thu, 28 Oct 2010 17:33:32 +0800 (CST)
Subject: [Live-devel] About fTo and
 MPEG4VideoStreamDiscreteFramer::afterGettingFrame1 function
Message-ID: <1386d11.10792.12bf22f60f7.Coremail.lixiaobo-023@163.com>

       " discrete frames" means what? My fist frame is I Frame,next 30 frames are P Frames. Then continuou to  recycle.
          As you say.I use the MPEG4VideoStreamDiscreteFramer class in my project, My MPEG-4 video source delivers one frame to fTo each time.
          There also are two qustions I don't know how to solve it.
            1. The length of each frame is biger than fMaxSize.
                    if I abandon a part of the frame,I think the VLC will can't play correctly. If I cut the frame in diffrent parts,I should how to do it?I see some one have the same qustion in the mail list,but I can't find the solution.
            2. The first frame of MPEG-4 stream have no VOSS, VOS,GOV.
                    Because the first frame have no VOSS, VOS,GOV, I think the frame will can't be correctly analysed in MPEG4VideoStreamDiscreteFramer::afterGettingFrame1 function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101028/250753bd/attachment.html>

From finlayson at live555.com  Thu Oct 28 07:09:03 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Oct 2010 07:09:03 -0700
Subject: [Live-devel] JPEGVideoRTPSink and Restart markers
In-Reply-To: <4CC7DA07.7080202@imavis.com>
References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com>
	<f06240800c8ed24424f62@[66.80.62.44]> <4CC7DA07.7080202@imavis.com>
Message-ID: <f06240805c8ef33b26451@[66.80.62.44]>

OK, I have now installed a new version (2010.10.28) of the code that 
adds support for "Restart Marker Headers" in outgoing JPEG/RTP 
packets.  (We already supported such headers in *incoming* JPEG/RTP 
packets.)

To use this, your "JPEGVideoSource" subclass must redefine the 
virtual function "restartInterval()" to return a non-zero value if 
"type()" returns a value in the range [64,127].

You should *not* need to subclass or modify the implementation of 
"JPEGVideoRTPSink".
-- 

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

From finlayson at live555.com  Thu Oct 28 07:12:58 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Oct 2010 07:12:58 -0700
Subject: [Live-devel] About fTo and
 MPEG4VideoStreamDiscreteFramer::afterGettingFrame1 function
In-Reply-To: <1386d11.10792.12bf22f60f7.Coremail.lixiaobo-023@163.com>
References: <1386d11.10792.12bf22f60f7.Coremail.lixiaobo-023@163.com>
Message-ID: <f06240806c8ef3483958a@[66.80.62.44]>

>        " discrete frames" means what? My fist frame is I Frame,next 
>30 frames are P Frames. Then continuou to  recycle.
>           As you say.I use the MPEG4VideoStreamDiscreteFramer class 
>in my project, My MPEG-4 video source delivers one frame to fTo each 
>time.

That is what I meant by "discrete frame".  Therefore, you are correct 
in using "MPEG4VideoStreamDiscreteFramer".


>           There also are two qustions I don't know how to solve it.
>             1. The length of each frame is biger than fMaxSize.

If that happens, then you should do:
	fFrameSize = fMaxSize;
	fNumTruncatedBytes = 'the frame size' - fMaxSize;
(Note that, if this occurs, the truncated data will get lost, and 
will *not* get transmitted.)


>                     Because the first frame have no VOSS, VOS,GOV, I 
>think the frame will can't be correctly analysed in 
>MPEG4VideoStreamDiscreteFramer::afterGettingFrame1 function.

That is not correct.
-- 

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