Re: [Live-devel] Live555 EventLoop crash
On Thu, Dec 22, 2011 at 6:12 AM, Jeff Shanab jsha...@smartwire.com wrote: Above the live 555 libs I have my own frame class. It is a simple RAII data class with payload, a bit of byte alignment, and some metadata like size and type. I use a reference counted pointer to this. This allows my multiple subscribers to keep lists of pointers to frames, they each have their own list and not worry about memory management and there is minimal memcopying around. I do this as well--all of our media data is reference counted to prevent multiple copies of the same sample. That said, my embedded processor is slow enough that even a final memcpy into Live555's buffers show up in profiling. Another important detail is this makes sure he who created the memory deletes the memory. This is to keep windows happy, If memory is allocated in one heap and attempted to delete it from code running in a different heap, windows throws an access violation, especially in debug mode! I had considered this. For Live555's event-driven model, you'd need a function that gets called when Live555 is done with a sample so the calling application can appropriately free the memory. In any event, this isn't sounding like it'd be a simple or straight-forward thing to add to Live555, sonot much to discuss. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Presentaition time problem at H264 streams
On Sat, Dec 17, 2011 at 5:19 AM, 6.45 6.45.Vapuru 6.45.vap...@gmail.comwrote: Hi I modify the OpenRtspClient so that -- Now instead of writing frames to file I collect them in a queue with incoming presenttaion times -- Then give the h264 frames to MP4 muxer [ Geraint Davies MP4 mux filter] -- Finally write muxed data to file... So I can able to save h264 stream into MP4 container... But the problem is that, some of the recorded data [NOT all of them] has wrong values for time duration: Suppose that a 10 minute record seems that it was 12 h stream... VLC play the 10 minute that play last frame for the remaing time. First thing that comes to mind is you have an obvious overflow issue: #define TIMEVAL_TO_REFERENCE_TIME(x) ((__int64)(x.tv_sec * 100) + x.tv_usec) * 10 ...x.ty_sec and x.ty_usec are 32-bit signed (long). You multimply x.tv_sec by 1,000,000, and *then* cast to __int64. So you'll overflow that in about ~2147 seconds. You need to cast to __int64 *first* and then do your multiplication. This probably explains the weird jumping. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Live555 EventLoop crash
On Wed, Dec 14, 2011 at 1:27 PM, Ross Finlayson finlay...@live555.comwrote: No, you must send only one frame at a time, because downstream objects expect 'frames', not 'portions of frames'. fMaxSize is the size of the buffer that the downstream object specified when it called getNextFrame() on your input source object. If your frames are larger than fMaxSize (which is what you are seeing), then that simply means that your downstream object's buffer is too small. You need to increase it. (Unfortunately, you didn't say what your downstream object is, so until you do, I can't really tell you how to increase the buffer size.) Two quick questions: 1. One thing another open source project I maintain does is automatically adjust buffer size when a frame too large comes along using realloc. Seems like you field this question often enough that it might be worth consideration to do something similar? 2. One of the biggest performance hits in my profiling is memcpy (I use an embedded platform, so memcpy gets pricy fast), much of it due to copying media buffers. Would you ever consider adding (or consider accepting ;) code that allows live555 to work in the calling library's buffers instead of its own? (in other words, I give Live555 a pointer to a buffer to send and the size, rather than memcpy'ing the buffer into live555's space) Thanks!. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Jeremy Noring's problem with RTP-over-TCP
On Fri, Nov 25, 2011 at 12:21 AM, Ralf Globisch rglobi...@csir.co.zawrote: @Jeremy: I hope this helps. In your case, is the server also running live555 and are you able to try to upgrade the server? Yes, our server is live555 based as well. At the time, I did try updating, but that didn't appear to resolve the issue. Here's the change that would allow the library to recover: http://code.google.com/p/live555sourcecontrol/source/diff?spec=svn11r=11format=sidepath=/trunk/liveMedia/RTPInterface.cpp ...this lets the client keep going, but some data gets tossed, so I get jerky playback. Seems like it involves the stream channel ID as well, which would corroborate well with your description? When I get a chance, I'll revisit the issue and see if latest on both sides resolves anything. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] older source archives
On Thu, Nov 24, 2011 at 5:39 AM, Steffen Sledz sl...@dresearch-fe.dewrote: It seems that at http://www.live555.com/liveMedia/public only the latest source tarball is published. Is there an URL where older tarballs are available? They are needed especially for maintained distributions (in our case OpenEmbedded[1] related distributions like Ångström[2]), where it is not acceptable to switch to a latest version every few days. To the OP, I've been stuffing versions of Live555 into a google code project so I have SVN history: http://code.google.com/p/live555sourcecontrol/ ...mainly, my interest is in having SVN history so I know _why_ the code is, and what's changed over time. Still need to stuff the most recent version in there, I'll get to that sometime today. As for updating to the most recent version, this works okay--until there's some bug in the library you can't solve and nobody on the mailing list seems to know what's going on, and you have no source code history so it's much more difficult to understand how the code changed to precipitate that bug. Currently, this is the situation I face. Receiving RTP over TCP in current releases with multiple sub-sessions is, by and large, broken as best I can tell due to something with the new synchronous API--I have not been able to solve it, and the workaround I found has unacceptable results. History would help, which is why I started stuffing versions into the aforementioned project. -Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Jeremy Noring's problem with RTP-over-TCP
On Thu, Nov 24, 2011 at 1:25 PM, Ross Finlayson finlay...@live555.comwrote: Receiving RTP over TCP in current releases with multiple sub-sessions is, by and large, broken as best I can tell due to something with the new synchronous API You mean asynchronous API. We talked about your problem a lot on the mailing list back in July. As far as I can tell, you're the only person having this problem with receiving RTP-over-TCP, so it may be inaccurate to describe it as being broken. (I also doubt that the asynchronous API is responsible.) Back in July I wasn't able to explain the symptoms that you were seeing, but I still suspect that you might be using multiple threads incorrectly (by, perhaps inadvertently, accessing the same LIVE555 object(s) from multiple threads). If you stop using multiple threads (as I've noted several times, you don't need multiple threads to concurrently receive multiple RTSP/RTP streams within a single LIVE555 application if you use the asynchronous API), then I suspect your problems will go away. Yes, I meant asynchronous. My apologies. I am not using multiple threads; I've been using this library for almost four years, so I'm well aware of the threading implications. Every Live555 instance I work with is completely contained on a single thread, and the only signaling that occurs is through watch variables. Also, I could easily see someone missing this issue because in the currently library the behavior is masked. You still get marginal performance due to the workaround that was included in the library. But I can still reproduce the issue on demand, and I suspect other people A) aren't using TCP with multiple subsessions or B) aren't looking closely. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Segmentation fault in DelayQueue::removeEntry(DelayQueueEntry*)
On Fri, Nov 4, 2011 at 7:10 AM, Ross Finlayson finlay...@live555.comwrote:
Looking at the code here
http://www.live555.com/liveMedia/doxygen/html/DelayQueue_8cpp-source.html I
see this:
00153
http://www.live555.com/liveMedia/doxygen/html/classDelayQueue.html#da6c5403a9e0e40945dc2e14d0e39435
void DelayQueue::removeEntry
http://www.live555.com/liveMedia/doxygen/html/classDelayQueue.html#da6c5403a9e0e40945dc2e14d0e39435(DelayQueueEntry
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html*
entry) {00154 if (entry == NULL
http://www.live555.com/liveMedia/doxygen/html/UsageEnvironment_8hh.html#070d2ce7b6bb7e5c05602aa8c308d0c4
|| entry-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410
== NULL
http://www.live555.com/liveMedia/doxygen/html/UsageEnvironment_8hh.html#070d2ce7b6bb7e5c05602aa8c308d0c4)
return;00155 00156 entry-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410-fDeltaTimeRemaining
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#68a7578179260ad40cb4f8fbde38e491
+= entry-fDeltaTimeRemaining
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#68a7578179260ad40cb4f8fbde38e491;00157
entry-fPrev
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#9bafd3137d60cd3b5cef4298a01644fd-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410
= entry-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410;00158
entry-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410-fPrev
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#9bafd3137d60cd3b5cef4298a01644fd
= entry-fPrev
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#9bafd3137d60cd3b5cef4298a01644fd;00159
entry-fNext
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#3a2ccdcdcac760623833136b5ced2410
= entry-fPrev
http://www.live555.com/liveMedia/doxygen/html/classDelayQueueEntry.html#9bafd3137d60cd3b5cef4298a01644fd
= NULL
http://www.live555.com/liveMedia/doxygen/html/UsageEnvironment_8hh.html#070d2ce7b6bb7e5c05602aa8c308d0c4;00160
// in case we should try to remove it again00161 }
I think the first if could produce a wrong memory access if entry is NULL.
Is that correct?
No, because the statement at line 154 quite clearly tests for entry ==
NULL, and returns if it is.
Is it possible that entry-fPrev is null? I notice it checks entry and
fnext, but not fprev. But on line 157, it pretty clearly attempts to
dereference both fPrev and fPrev-fNext. Also, it dereferences
entry-fNext-fPrev, which could (in theory) be null.
Not familiar with the code, so maybe there's no problem with any of this,
but seems like ample opportunities for segmentation fault that aren't
caught by the statement at like 154.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] MP4 file creation
Try this: http://code.google.com/p/mp4v2/ On Wed, Aug 10, 2011 at 8:37 PM, k...@starseedsoft.com wrote: Arg...is FFMPEG/LibAV the best library to write an MP4 file? Thx /K --- On *Wed, 8/10/11, Ross Finlayson finlay...@live555.com* wrote: From: Ross Finlayson finlay...@live555.com Subject: Re: [Live-devel] MP4 file creation To: LIVE555 Streaming Media - development use live-de...@ns.live555.com Date: Wednesday, August 10, 2011, 6:13 PM On Aug 10, 2011, at 9:32 AM, k...@starseedsoft.comhttp://mc/compose?to=k...@starseedsoft.comwrote: Is it really this simple to generate an MP4 file? It is simply a serialized h264 stream? No it's not. A serialized H.264 stream is a '.264' or '.h264' file. A '.mp4' file has a completely different format (though it often contains H.264 video). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -Inline Attachment Follows- ___ live-devel mailing list live-devel@lists.live555.comhttp://mc/compose?to=live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Confused about how to generate fmtp line for H.264 source for SDP
On Wed, Aug 3, 2011 at 6:51 PM, Ross Finlayson finlay...@live555.comwrote: Yes, it's uncommon for a supplier of a H.264 stream to know the SPS and PPS NAL units, but for those NAL units not to appear in the stream. Most commonly, these NAL units appear in the stream, but you don't know what they are - and can find them out only by scanning the stream. We now do that for you. I don't think this is actually that common--most encoders go out of their way to provide this data for you, and to get things running quickly it can be very important to have SPS/PPS on hand. Most container formats, such as MP4, make this data readily available (you can put it in stream, but it's bad form, IMO). Hmm, I'll look into it, but my encoder gives me the sps and pps when I initialize it, it seems like it would be easier to just hand the sps and pps to the rtp sink and just re-implement auxSDPLine in my class, pretty much like I used to do. Is there a reason your recommending this approach Yes, the reason was that it would probably save you work. If the SPS and PPS NAL units also appear in the stream (which, for most encoders, they will), then you don't have to do any extra work (except perhaps duplicate some code that we already have in H264VideoFileServerMediaSubsession). FWIW, I ran into the same issue when I updated my Live555 version. It's hard to write an on-demand session because there's no clean way of handing off the SPS/PPS info before things are up and running. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problem with RTP over TCP
On Wed, Jul 20, 2011 at 4:41 PM, Ross Finlayson finlay...@live555.comwrote: ** Any ideas why this may be happening? Unfortunately not. Is it somehow possible that something else could read from the socket between when AWAITING_STREAM_CHANNEL_ID is set and the case statement? And would it be possible to complete the entire operation in tcpReadHandler1, instead of iterating through it repeatedly? (I see that's how it used to function, but maybe that approach isn't feasible with the asynchronous operation) Lastly, I haven't migrated to the new asynchronous interface--is it possible that would have an impact, or is this code shared between the two? Thanks again for the help. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problem with RTP over TCP
On Thu, Jul 21, 2011 at 1:06 AM, Ross Finlayson finlay...@live555.comwrote: Now, I don't see how. (I assume you're not doing something dump like trying to use more than one thread.) I'm using a dedicated thread for each Live555 instance. Could it have to do with the session having multiple subsessions? The session I'm pulling from has both AAC and H.264 subsessions, so I'm wondering if somehow the parsing code isn't accounting for that correctly? Any other ideas I could look into? I really need to solve this issue, so any pointers or suggestions are more than welcome. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problem with RTP over TCP
On Wed, Jul 20, 2011 at 11:15 AM, Jeremy Noring kid...@gmail.com wrote:
I updated my RTP client to the most recent version (2011.7.18) and I'm
having trouble with RTP over TCP. Occasionally Live555 will get in a state
where it no longer receives any data from the server, even though the server
is completely alive.
I narrowed down the problem to RTPInterface.cpp, line 379:
case AWAITING_STREAM_CHANNEL_ID: {
// The byte that we read is the stream channel id.
fStreamChannelId = c;
fTCPReadingState = AWAITING_SIZE1;
break;
}
fStreamChannelId gets set to some crazy value (e.g. '37') that isn't
valid (for my app, should be 0 or 2). Once it's in that bad state, this
fails repeatedly:
case AWAITING_PACKET_DATA: {
// Call the appropriate read handler to get the packet data from the
TCP stream:
RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
if (rtpInterface != NULL) {
...lookupRTPInterface(fStreamChannelId) returns NULL, which causes the
library not to call fReadHandlerProc(). Live555 consumes all the CPU, and
the only communication that still happens are the periodic SR reports (which
do still work).
I haven't managed to figure out why this is; using a debug build (i.e.
DEBUG is defined, so there are periodic log messages) seems to reproduce the
issue much more immediately--otherwise it can take a while to get in this
bad state.
Any ideas why this may be happening?
Update: I went through some older versions of the library (prior to the
async client rewrite) and I saw code that would ensure the stream channel ID
was present. So I did a quick test with the following code:
case AWAITING_STREAM_CHANNEL_ID: {
// The byte that we read is the stream channel id.
RTPInterface* rtpInterface = lookupRTPInterface(c);
if (rtpInterface != NULL)
{
fStreamChannelId = c;
fTCPReadingState = AWAITING_SIZE1;
}
else
{ // we're not interested in this channel
fTCPReadingState = AWAITING_DOLLAR;
}
...and that seems to have mostly corrected the issue. That said, I'd really
like to know how it's happening in the first place--seems to me like there
must be some other bug allowing it to get in this state? Or maybe it's not
that simple. Any insight is welcome.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] A new server extension for streaming to iPhones and iPads
On Sun, Jul 17, 2011 at 9:23 PM, Ross Finlayson finlay...@live555.comwrote: The latest version (2011.07.18) of the LIVE555 Streaming Media code includes an experimental server extension that supports streaming media files to iPhones and iPads, using Apple's HTTP Live Streaming mechanism. Very nice feature. Question: if I wanted to extend this to use a different source (say, and MP4 file with H.264 and AAC), where would be the best place to start? And would it be possible to use it with a live source somehow? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Media File in testProgs
pcr-decreasing-test2.ts (a ~3 MB file) is in live/testProgs. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Some extra files in testProgs...
In the latest release (6-14), some raw h264 files and openRTSP log files found their way into the testProgs folder. -Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Symbian Client having issues with Live555 based server
We run an RTSP server based around Live555 on our embedded device; normally, it's configured with two sessions: LowResolutionVideo and HighResolutionVideo, both of which are H264/AAC. This works well for the most part--it's broadly compatible with VLC, Quicktime and our own openRTSP based client. However, I got this report from one of our users: I am able to stream to my Nokia N8 phone just by creating txt file named live.ram and it has content like: rtsp://192.168.2.2/LowResolutionVideo Then placing that file to phone and click it from file manager. It will stream ~30s nicely and once buffer should happen difficulties started. This is something i have figured out from network packet capture: These ping-pong (keep-alive) packets or heart beats are formatted somewhat like this: SET_PARAMETER * RTSP/1.0 CSeq: 6 Ping: Pong Where “*” denotes the url, from the packet capture dump it seems camera RTSP -server is not ignoring that url when Nokia phone has a ‘ping’ parameter in the header. And hence it sends 404 url not found and resets connection. In such cases server should just respond by OK 200 or 451 RTSP/1.0 451 Parameter Not Understood CSeq: 6 Date: Wed, 11 Dec 2002 12:50:56 GMT And should not reset or finish the session. I'm not familiar with these ping-pong packets (are these a valid part of the RTSP protocol?) or streaming to symbian devices; does anyone have any idea what the problem may be? Thanks in advance. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Why no file testH264VideoToDarwin. cpp
On Tue, Jan 4, 2011 at 1:16 AM, Ross Finlayson finlay...@live555.comwrote: Why no file testH264VideoToDarwin. cpp ? Because our support for streaming from raw H.264 video files is very recent, but the test*toDarwin demo applications were developed several years ago. Also, as we note clearly in comments near the top of the file testMPEG4VideoToDarwin.cpp: // NOTE // // This demo software is provided only as a courtesy to those developers who - for whatever reason - wish // to send outgoing streams through a separate Darwin Streaming Server. However, it is not necessary to use // a Darwin Streaming Server in order to serve streams using RTP/RTSP. Instead, the LIVE555 Streaming Media // includes its own RTSP/RTP server implementation, which you should use instead. For tips on using our // RTSP/RTP server implementation, see the testOnDemandRTSPServer demo application, and/or the // live555MediaServer application (in the mediaServer) directory. // Depending on the requirements, it is sometimes necessary to use an intermediate server to relay data (specifically, for NAT traversal). Maybe it's not a usage of the library you'd expected, but it's been profoundly valuable to me. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Slight authentication change
On Wed, Nov 17, 2010 at 1:07 AM, Ross Finlayson finlay...@live555.comwrote: We updated the UserAuthenticationDatabase used in the RTSP server to have a requireAuthentication method that can be overridden in a derived class. We use it so that if default credentials are in use, we don't require authentication. Basically, this allows implementations to turn authentication on and off at will while the server is running. Unless implementations override requireAuthentication, the behavior is identical to the previous code. It's a pretty simple change so hopefully it's good enough for inclusion. Yes. In fact, I can think of another way to do this that's even simpler, yet more general: Add a new member function UserAuthenticationDatabase* RTSPServer::setAuthenticationDatabase(UserAuthenticationDatabase* newDB); This would change the server's authentication database, and return the existing one (perhaps NULL). Then, you could turn off authentication simply by doing: UserAuthenticationDatabase* oldDB = myServer-setAuthenticationDatabase(NULL); and turn it back on by doing: myServer-setAuthenticationDatabase(oldDB); This also has the benefit of not requiring an additional check in the server; the existing check against NULL is sufficient. -- That would work. But it might also lead to crashing issues if people call setAuthenticationDatabase on something other than the primary Live555 thread. (I can envision a scenario where something calls setAuthenticationDatabase(NULL) at precisely the moment between the NULL check and the actual authentication with the UserAuthenticationDatabase*, which would result in dereferencing a null pointer). With the previous change, it can be called anywhere and you wouldn't have to worry about whether or not it was on the primary thread of execution or some other thread. I know Live555 is single threaded, so maybe you consider this entire line of reasoning invalid, but I think there's considerable room for error with setting the entire object to NULL. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Slight authentication change
On Wed, Nov 17, 2010 at 1:37 PM, Ross Finlayson finlay...@live555.comwrote: That would work. But it might also lead to crashing issues if people call setAuthenticationDatabase on something other than the primary Live555 thread. (I can envision a scenario where something calls setAuthenticationDatabase(NULL) at precisely the moment between the NULL check and the actual authentication with the UserAuthenticationDatabase*, which would result in dereferencing a null pointer). And that is *precisely* why you should not be doing this. I've made it very clear (in the FAQ and elsewhere) that LIVE555 applications have a single thread of execution (using an event loop, rather than threads, for concurrency). Other threads should not access the library (except perhaps to set global variables - e.g., 'watch variables' that the event loop may use to detect 'events'). If you do otherwise, then you can't expect any support. I disagree. There is nothing wrong with this method of using the library, and my change would functionally allow both. I know your position on threads (or the lack thereof) and I don't expect you to accept my patch, so I won't belabor the point. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Slight authentication change
On Wed, Nov 17, 2010 at 3:23 PM, Ross Finlayson finlay...@live555.comwrote: Well, I have to admire your stubbornness :-) Even after having presented a perfect example of why that statement is false, you continue to insist otherwise. I take it back, I will belabor the point. Yes, this is stubbornness, and no, you did not present a perfect example of why that statement [was] false. The bottom line is yes, you can run Live555 in a threaded environment (I've been doing it for over a year now) so long as you have a dedicated thread for the event loop (your own FAQ states this). And there are plenty more ways of communicating changes to the event loop besides global variables (in fact, doing so is just sloppy-bad code, in my opinion; I struggled with some of Live555's crappy global variables that made running multiple independent instances with dedicated threads run in the same process space). Furthermore, there is _nothing_ wrong with setting a read-only boolean variable that the event loop then subsequently checks. There is almost zero functional difference between this and your global variable option. There's nothing stopping someone from doing it that way with the change I proposed, and I think saving an additional NULL check in exchange for potential threading woes isn't worth it (if you're looking to optimize, I can point you towards about a dozen things in your library that dwarf such a check). So fine, attribute it to stubbornness, but again, the patch I posted here has not only been tested but it _works_. It does this in a threaded environment, which your own library is completely compatibile with given a few pretty obvious caveats (first and foremost, a dedicated thread for the event loop). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Slight authentication change
We updated the UserAuthenticationDatabase used in the RTSP server to have a requireAuthentication method that can be overridden in a derived class. We use it so that if default credentials are in use, we don't require authentication. Basically, this allows implementations to turn authentication on and off at will while the server is running. Unless implementations override requireAuthentication, the behavior is identical to the previous code. It's a pretty simple change so hopefully it's good enough for inclusion. If not, please let me know if there's any way I can modify the patch to be acceptable. Thanks, Jeremy RTSPServer.diff Description: Binary data ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Question about a resizing filter
On Mon, Nov 15, 2010 at 2:16 PM, james.whetst...@kodak.com wrote: Hi, Can anyone tell me if a filter should be able to resize the frames of a stream? E.g Create a filter that takes each frame and resizes it as it is being streamed. I don't know of anything like that in Live555. I think you could probably kludge something like that into Live555's model, but I'd much sooner do it outside of the Live555 framework for a number of reasons (first and foremost, the single-threaded nature of the library). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Question about a resizing filter
On Mon, Nov 15, 2010 at 3:11 PM, Ross Finlayson finlay...@live555.comwrote: I don't know of anything like that in Live555. I think you could probably kludge something like that into Live555's model It wouldn't be a 'kludge' at all; it would be a natural part of the LIVE555 application model (using a subclass of FramedFilter.) I view adding a morphological filter to my network streaming library as a rather substantial kludge, so I'll chalk this up to difference of opinion. James, You could do this in or out of Live555; either is totally feasible. I personally wouldn't do this within the Live555 framework (see aforementioned difference of opinion). I'd probably do it with the Intel IPP (they have a number of scaling methods, like NN, bilinear, bicubic, supersampling, etc. and can operate in several different popular colorspaces) or some other pre-existing image processing library. Or you could code up a quick-and-dirty nearest neighboor scaling algorithm. But this is probably outside the scope of the mailing list. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 over RTP/RFC 3984
On Mon, Oct 25, 2010 at 11:37 AM, Larry Cui larry@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? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 over RTP/RFC 3984
On Wed, Oct 20, 2010 at 3:12 PM, Larry Cui larry@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) ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSP Server.
On Fri, Oct 8, 2010 at 5:15 AM, Sukhbir Singh sukhbir.sing...@gmail.comwrote: 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. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Newbie with a DirectShow headache
On Thu, Oct 7, 2010 at 9:12 AM, iain i...@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@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? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Newbie with a DirectShow headache
On Thu, Oct 7, 2010 at 12:12 PM, John Orr john@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. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Newbie with a DirectShow headache
On Thu, Oct 7, 2010 at 5:47 PM, Ross Finlayson finlay...@live555.comwrote: 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. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] segmentation fault (core dumped)
2010/9/6 Aranganathan Sankaradoss arang1...@gmail.com hello Sir, I am desperately in need of your help. I am using openRTSP source code. If I call the main function again then I get the following error Segmentation fault (core dumped) My aim for calling the main ( ) function again is that after RTSP server reset, openRTSP must keep trying to connect with RTSP server again. In sessionAfterPlaying ( ) function, instead of calling exit ( ) function, I call main ( ) again. To call main ( ), I just copied the main ( ) into a new function named RTSP_main () and I am just calling RTSP_main ( ) in place of exit ( ). Could you post your code? And why are you doing this? It seems like you could have an issue with infinite recursion, for one. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Graceful handling of socket error
On Wed, Sep 8, 2010 at 2:58 PM, Ross Finlayson finlay...@live555.comwrote: I am suggesting the call to abort() in the function BasicTaskScheduler::SingleStep() at line 95 in BasicTaskScheduler.cpp to be replace with something that is less destructive (C++ exception?) since a socket error can happen for legitimate reasons (remote closed, ...). Perhaps, although my intention for this call to abort() (and others in the code) was that it be a should never get called situation. The preceding if statement is supposed to catch the small set of error codes that we expect to see in this situation. So, my question is: What specific error code(s) are you seeing in this situation? (Also, are you running Windows, or a Unix system?) IMO, it's generally bad form for a _library_ to call abort() or exit(); it basically means some internal library error is more important than anything that could possibly be going on in the actual application, which is highly unlikely. Our application does a lot more than just stream video; to have our RTSP server library drop the whole process is a pretty thuggish method to communicate failure. These calls should be reserved for application code itself. I think you're better off A) attempting to recover or B) crashing outright or C) returning some error to the application or even D) doing nothing. I would not consider using C++ exceptions, they're an architectural disaster in my not-so-humble opinion (and particularly so with embedded platforms, there are a few gotchas, see https://developer.mozilla.org/en/C___Portability_Guide for more info). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] segmentation fault (core dumped)
2010/9/6 Aranganathan Sankaradoss arang1...@gmail.com hello Sir, I am desperately in need of your help. I am using openRTSP source code. If I call the main function again then I get the following error Segmentation fault (core dumped) Have you analyzed the dump file to get a callstack? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] dump h264 video problem
On Thu, Jul 29, 2010 at 1:14 PM, Ross Finlayson finlay...@live555.comwrote: I'm not sure. But the basic problem here is that the .mov (or .mp4) file format was very badly designed, and is especially ill-suited for what we are trying to do: Record incoming media streams into a file. The QuickTimeFileSink class tries to do this as well as it can, but the basic flaws of the file format makes it difficult. Nonethess, it's possible that the QuickTimeFileSink implementation can be improved, so feel free to take a look at it, and let us know if you have any suggestions for improvements/bug fixes. Doubtful. I've worked with the mp4 file format for a few years now and it's just fine. The more likely problem is QuickTimeFileSink is a limited and basic mov/mp4 implementation, and Live555 is a streaming library, not a container library. If the OP wants nice files, they should use a library intended for writing mp4 files, like mp4v2. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problems using Windows Media Player
On Tue, Jul 20, 2010 at 6:45 PM, Jimmy Zhang zhan...@uusee.com wrote: currently, wmp can only support file format of wmv which live hasn't support. It's off-topic for the mailing list, but this is completely incorrect. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] How to contribute code?
On Thu, Jun 24, 2010 at 9:00 AM, BONNEAU Guy gbonn...@miranda.com wrote: Jeremy, Since you already manage an open source project would you be available to setup and manage an open source public repository for live555. We could commit the sources as Ross release them since they are of public domain. I could offer some help if you want. Ross would only need to setup an URL link in the FAQ section for those people that want an history browsing of the changes for whatever reason. Assuming this is acceptable to Ross, yes, I'd be happy to. I do respect that this isn't my project, and my intention isn't to rock any boats. Ross, would this be okay with you? Of course, your policy of supporting trunk would remain in place. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] How to contribute code?
On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson finlay...@live555.comwrote: I don't use any revision control system myself. When I'm developing this code, I use exactly two commands: emacs and make. Each source code release - in tar.gz form - is less than 500 kBytes in size. These days, that's not a significant amount of data to download in order to get the latest revision, and any bandwidth savings obtained by downloading from a revision control system instead would be insignificant. And people should not be using any version of the code other than the latest one, because that's all that we support. It's not about bandwidth, it's about having a clear history of all changes made to the project, and when. It is extraordinarily difficult to isolate regression without this. I suspect that the real reason why some people want to use a revision control system is that they want to easily update to the latest version of the code after they've made custom modifications to it (i.e., without losing their modifications). I'm sorry, but this is something that I explicitly want to discourage. People *should not* be making modifications to the released LIVE555 Streaming Media code (i.e., inside the live directory). Instead, they should be leaving that directory as it is, and instead putting their own code in a separate directory (using subclassing, if necessary). This is simply not true--I do not want source control so I can easily update to the latest version of the code. I want it so I can easily have a history of all changes made, readily available diff files, and an easy way to see when changes have been made. Furthermore, most programmers *refuse* to use trunk (this is considered extraordinarily unwise by every decent program I know), which is basically the policy you're advocating. The open source project I manage has detailed download statistics, and the results are clear: people prefer sanctioned releases as opposed to trunk. So I'm going to have to disagree with you; I think your hypothesis here is flat-out wrong. If there are parts of the code that make it difficult for people to customize via subclassing - e.g., some class members that should be protected: instead of private:, then please let us know. Has absolutely nothing to do with this. It's more like, the only way I can get a diff view of the changes made to the project is to cache away the various releases you put out on a bi-monthly basis into my source control, so I can do a compare. I don't expect you to find these arguments compelling, and that's fine--I'll continue to cache away versions of the library so I can roll back to work around regression introduced in subsequent releases. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] How to contribute code?
On Fri, Jun 18, 2010 at 7:18 AM, Ross Finlayson finlay...@live555.comwrote: I was also not able to find any public git or svn repository for live555. Could you consider to make one? No. We make available - and provide support for - the most recent version of the code only. Just because you use source control doesn't mean you have to support any random release of the code. Almost no open source projects I know function this way; there are clear releases and supported versions. Is there some other reason you're opposed to public source code? It's really difficult not having a history of changes made (and a changelog is a poor substitute for source control history), or being able to roll back the library to a previous version to locate regression. My $0.02: if you've gone this long without source control, then I don't expect you're about to change, but you should really reconsider this decision at some point. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSP server hang
On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson finlay...@live555.comwrote:
I've now installed a new version (2010.06.15) of the code that completely
removes the blockUntilReadable() function. This means that readSocket()
no longer calls select(), which
should improve the performance of both client and server applications.
On a related note, here's one other hack I had to add to prevent crashing:
void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
requestByte) {
// Add this character to our buffer; then try to handle the data that we
have buffered so far:
if (fRequestBufferBytesLeft == 0) return;
if (fRequestBytesAlreadySeen = RTSP_BUFFER_SIZE ) return;// hack:
don't let us overflow fRequestBuffer, and there's some bug
// with
sessions containing multiple subsessions, when streaming over
// TCP that
causes this to fail miserably.
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
handleRequestBytes(1);
}
...I previously reported this. When there are multiple sessions being
streamed that contain both audio and video (i.e. multiple subsessions) over
TCP, sometimes the server will crash with an access violation by walking off
the end of fRequestBuffer. I do not understand the crash; I do know that
this code prevents it.
I don't understand why the hack line should be necessary, because
handleRequestBytes() should already be testing for buffer overflow.
However, this newest release of the code improves the handling of
RTP/RTCP/RTSP-over-TCP, so I'm hoping that it happened to fix the bug as
well.
It fails on this line in handleAlternativeRequestByte1:
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
...so no, it does not test for buffer overflow. For whatever reason,
fRequestBuffer gets set to a very large number (i.e. greater than 10K),
which causes this function to crash with an access violation. It doesn't
have anything to do with handleRequestBytes().
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSP server hang
On Sun, Jun 13, 2010 at 7:16 PM, Ross Finlayson finlay...@live555.comwrote:
I.e., you should be able to remove the following code from the
implementation of readSocket() in groupsock/GroupsockHelper.cpp (line
265):
int result = blockUntilReadable(env, socket, timeout);
if (timeout != NULL result == 0) {
bytesRead = 0;
break;
} else if (result = 0) {
break;
}
and I think everything will work OK (only more efficiently!).
So give this a try. If you run into any problems, let us know. (If not,
I'll remove this code from the next release of the software.)
I had read about this on the mailing list, but I was wary to disable entire
functions. So I ended up neutering one specific place that called
readSocket to have a null timeout; I added a five second timeout:
Boolean Groupsock::handleRead(unsigned char* buffer, unsigned bufferMaxSize,
unsigned bytesRead,
struct sockaddr_in fromAddress) {
// Read data from the socket, and relay it across any attached tunnels
//# later make this code more general - independent of tunnels
bytesRead = 0;
int maxBytesToRead = bufferMaxSize - TunnelEncapsulationTrailerMaxSize;
timeval to;
to.tv_sec = 5;
to.tv_usec = 0;
int numBytes = readSocket(env(), socketNum(),
buffer, maxBytesToRead, fromAddress, to);
if (numBytes 0) {
if (DebugLevel = 0) { // this is a fatal error
env().setResultMsg(Groupsock read failed: ,
env().getResultMsg());
}
return False;
}
...and the server no longer hangs. In general, given how the code works
with a dedicated worker thread, I think there should _never_ be anything
that can potentially block for any substantial amount of time (i.e. all
infinite timeout calls should be removed).
On a related note, here's one other hack I had to add to prevent crashing:
void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
requestByte) {
// Add this character to our buffer; then try to handle the data that we
have buffered so far:
if (fRequestBufferBytesLeft == 0) return;
if (fRequestBytesAlreadySeen = RTSP_BUFFER_SIZE ) return;// hack:
don't let us overflow fRequestBuffer, and there's some bug
// with
sessions containing multiple subsessions, when streaming over
// TCP that
causes this to fail miserably.
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
handleRequestBytes(1);
}
...I previously reported this. When there are multiple sessions being
streamed that contain both audio and video (i.e. multiple subsessions) over
TCP, sometimes the server will crash with an access violation by walking off
the end of fRequestBuffer. I do not understand the crash; I do know that
this code prevents it.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTSP server hang
Under load, I'm noticing our RTSP server occasionally hangs in this
location:
static int blockUntilReadable(UsageEnvironment env,
int socket, struct timeval* timeout) {
int result = -1;
do {
fd_set rd_set;
FD_ZERO(rd_set);
if (socket 0) break;
FD_SET((unsigned) socket, rd_set);
const unsigned numFds = socket+1;
result = select(numFds, rd_set, NULL, NULL, timeout); --HANG
I added some logging and found that the select() timeout is NULL, which is
infinite. I would expect this to unblock when data arrived on the socket,
but no amount of connection attempts seems to wake it up--it stays there,
blocking the Live555 thread from servicing any new clients. Also, what code
would be calling this with a NULL timeout?
The other thing I notice is our netstat output:
# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp0 0 0.0.0.0:52220.0.0.0:* LISTEN
tcp0 0 0.0.0.0:58000.0.0.0:* LISTEN
tcp0 0 0.0.0.0:50000.0.0.0:* LISTEN
tcp0 0 0.0.0.0:58020.0.0.0:* LISTEN
tcp 21 0 0.0.0.0:554 0.0.0.0:* LISTEN
When it's in a failed state, I always see 21 on the Recv-Q, which is The
count of bytes not copied by the user program connected to this socket.
We're using Linux (2.6.18, so a bit old).
Does anyone know why this may be, or have any suggestions for fixing it?
Thanks!
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Getting the JPEG payload from a JPEG file
On Thu, May 20, 2010 at 3:17 AM, Andy Bell a...@j2kvideo.com wrote: Hi, I have used the 'Elphel' code to build a simple RTSP server which streams a fixed JPEG frame. I want to be able to configure the RTSP server to use a specific JPEG file on disk. The problem I have is that different JPEG files have different header sizes and I want to work out how I can work out where the header ends and where the payload begins. Looking at the header I can locate the start of the scan using the marker 0xFFDA, but even when I send this back to the client I don't get a valid image. As I am using a JPEG file I have no idea of the Q factor so I have set this to 100 for the time being. Is there any code out there which can help me break up a JPEG file from disk and stream it back to the client? If not, where am I going wrong? You could probably use libjpeg (http://www.ijg.org/) to get at the raw image data. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Crash in RTSPServer.cpp
On Tue, May 11, 2010 at 4:42 PM, Jeremy Noring jnor...@logitech.com wrote:
On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring jnor...@logitech.comwrote:
On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson finlay...@live555.comwrote:
It would be nice to find a simple, repeatable sequence of client
operations that cause the crash. E.g., does crash ever happen if there are
two complete DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN sequences in order
(i.e., not overlapping), or does it occur only when two such sequences
overlap? Once you've found a repeatable situation that causes the crash,
then you could also test with RTP-over-UDP, and with reuseFirstSource set
to False.
Okay, I've now managed to reproduce this with openRTSP and
testOnDemandRTSPServer (which is what our RTSP server is modeled after). To
reproduce it, you need to:
1. Have your RTSP server deliver a media session with multiple subsessions.
(i.e. simply trying to reproduce with mp3AudioTest will not work; you have
to have a session with audio _and_ video, for example). I simply combined
the .wav and .mp3 sessions into one:
{
char const* streamName = mp3AudioTest;
char const* inputFileName = test.mp3;
ServerMediaSession* sms
= ServerMediaSession::createNew(*env, streamName, streamName,
descriptionString);
Boolean useADUs = False;
Interleaving* interleaving = NULL;
#ifdef STREAM_USING_ADUS
useADUs = True;
#ifdef INTERLEAVE_ADUS
unsigned char interleaveCycle[] = {0,2,1,3}; // or choose your own...
unsigned const interleaveCycleSize
= (sizeof interleaveCycle)/(sizeof (unsigned char));
interleaving = new Interleaving(interleaveCycleSize, interleaveCycle);
#endif
#endif
sms-addSubsession(MP3AudioFileServerMediaSubsession
::createNew(*env, inputFileName, reuseFirstSource,
useADUs, interleaving));
// To convert 16-bit PCM data to 8-bit u-law, prior to streaming,
// change the following to True:
inputFileName = test.wav;
Boolean convertToULaw = False;
sms-addSubsession(WAVAudioFileServerMediaSubsession
::createNew(*env, inputFileName, reuseFirstSource,
convertToULaw));
rtspServer-addServerMediaSession(sms);
announceStream(rtspServer, sms, streamName, inputFileName);
}
2. Set reuseFirstSource to True
3. Run multiple openRTSP instances to repeatedly hit the RTSP server
streaming with TCP. I use openRTSP -t -d 1 url, and have a small program
that calls that repeatedly.
Next, I'm going to isolate if this is regression in the codebase, or if it's
something that was a problem before the recent RTP-over-TCP changes.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Crash in RTSPServer.cpp
On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring jnor...@logitech.com wrote:
On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson finlay...@live555.comwrote:
It would be nice to find a simple, repeatable sequence of client
operations that cause the crash. E.g., does crash ever happen if there are
two complete DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN sequences in order
(i.e., not overlapping), or does it occur only when two such sequences
overlap? Once you've found a repeatable situation that causes the crash,
then you could also test with RTP-over-UDP, and with reuseFirstSource set
to False.
Okay, I did more testing. Definitely the issue is overlapping DESCRIBE,
SETUP, SETUP, PLAY, TEARDOWN sequences. And for me, the problem was
exacerbated by the fact that my client would connect to the server _twice_
(once to fetch media types, then a TEARDOWN, and again to start pulling
media). I changed it so my code connects a single time and I can no longer
reproduce the crash.
So I think there is a bug in there somewhere, and it definitely involves
overlapped sequences like that. I did try to isolate it with mediaServer
and openRTSP, but...haven't had a lot of luck. I'll let you know if I find
out anything else.
We're still having issues with this, so I had to do more testing. Instead
of hitting with our client application, I used openRTSP -t -d 1 url to
hit our RTSP server. The RTSP server is configured to reuse sources. This
time, I did managed to reproduce the crash:
RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(unsigned
char requestByte='T') Line 322 + 0xf bytesC++
RTSPServer::RTSPClientSession::handleAlternativeRequestByte(void *
instance=0x06010868, unsigned char requestByte='T') Line 317C++
SocketDescriptor::tcpReadHandler(SocketDescriptor *
socketDescriptor=0x05fdc2c0, int mask=2) Line 357 + 0x14 bytesC++
BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0) Line 115 +
0x11 bytesC++
BasicTaskScheduler0::doEventLoop(char * watchVariable=0x01f85698) Line
77C++
void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
requestByte) {
// Add this character to our buffer; then try to handle the data that we
have buffered so far:
if (fRequestBufferBytesLeft == 0) return;
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte; // FAILED HERE
handleRequestBytes(1);
}
fRequestBytesAlreadySeen is 3452816845, causing an access violation since
fRequestBuffer is only 10 KB. I looked at the state of this:
-this0x06010868 {fOurServer={...} fOurSessionId=3452816845
fOurServerMediaSession=0xcdcdcdcd ...}RTSPServer::RTSPClientSession *
const
+__vfptr0xcdcdcdcd*
+fOurServer{fServerSocket=??? fServerPort={...} fAuthDB=???
...}RTSPServer
fOurSessionId3452816845unsigned int
+fOurServerMediaSession0xcdcdcdcd {fIsSSM=???
fSubsessionsHead=??? fSubsessionsTail=??? ...}ServerMediaSession *
fClientSocket-842150451int
+fClientAddr{sin_family=-12851 sin_port=52685 sin_addr={...}
...}sockaddr_in
fLivenessCheckTask0xcdcdcdcdvoid *
+fRequestBuffer0x06010890
Í
unsigned char [1]
fRequestBytesAlreadySeen3452816845unsigned int
fRequestBufferBytesLeft3452816845unsigned int
+fLastCRLF0xcdcdcdcd Bad Ptrunsigned char *
+fResponseBuffer0x06012fac
Í
unsigned char [1]
fIsMulticast0unsigned int
fSessionIsActive0unsigned int
fStreamAfterSETUP4261281277unsigned int
+fCurrentAuthenticator{fRealm=0xabababab Bad Ptr
fNonce=0x Bad Ptr fUsername=0x Bad Ptr ...}
Authenticator
fTCPStreamIdCount120 'x'unsigned char
fNumStreamStates100699448unsigned int
+fStreamStates0x {subsession=??? streamToken=??? }
RTSPServer::RTSPClientSession::streamState *
This object is in a very weird state. the 0xcdcdcdcd values correspond with
freshly allocated memory from the CRT (see
http://www.nobugs.org/developer/win32/debug_crt_heap.html), so it appears to
be an object that was just allocated--but this makes little sense given the
implementation of RTSPClientSession.
I'm not sure if this extra information helps or not. I'm going to work on
running it under devpartner to see if anything else falls out of the
woodwork.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com
Re: [Live-devel] Crash in RTSPServer.cpp
On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson finlay...@live555.comwrote: It would be nice to find a simple, repeatable sequence of client operations that cause the crash. E.g., does crash ever happen if there are two complete DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN sequences in order (i.e., not overlapping), or does it occur only when two such sequences overlap? Once you've found a repeatable situation that causes the crash, then you could also test with RTP-over-UDP, and with reuseFirstSource set to False. Okay, I did more testing. Definitely the issue is overlapping DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN sequences. And for me, the problem was exacerbated by the fact that my client would connect to the server _twice_ (once to fetch media types, then a TEARDOWN, and again to start pulling media). I changed it so my code connects a single time and I can no longer reproduce the crash. So I think there is a bug in there somewhere, and it definitely involves overlapped sequences like that. I did try to isolate it with mediaServer and openRTSP, but...haven't had a lot of luck. I'll let you know if I find out anything else. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] need H264 RTP streaming tutorial
On Fri, Apr 30, 2010 at 9:21 AM, Charlie X. Liu char...@sensoray.comwrote: http://www.fileden.com/files/2008/12/4/2210768/live555_H.264_tutorial.tar.gz That tutorial is wrong in so many ways, and personally cost me a good month or two of banging my head against the wall. Worst of all: // Create an 'H264 Video RTP' sink from the RTP 'groupsock': mVideoSenderSink = H264VideoRTPSink::createNew(*mEnv, mRtpGroupsock, 96, 0, h264); ...that last parameter? It's supposed to be SPS/PPS, base-64 encoded and comma delimited. h264 is _completely_ wrong. This is probably fine code if your target is VLC, but any standards-based player will probably puke trying to read this stream (as it should, it's totally bogus). Also, the code doesn't check to make sure the NALU start codes (i.e. 0x01 or 0x0001) are stripped off before being sent--also invalid. Lastly, SPS/PPS info should not be sent in-stream; it is better to explicitly strip it out--I check NALU header info and simply discard those entirely (it's already in the SDP exchange, no need to send it in-stream). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Crash in RTSPServer.cpp
On Wed, Apr 21, 2010 at 4:44 PM, Ross Finlayson finlay...@live555.com wrote: We have a crash in our RTSP server (implemented with Live555) that reproduces when streaming the same session to multiple RTP-over-TCP clients. You have reuseFirstSource set to True in your OnDemandServerMediaSubsession subclass, right? Yes. It's hard to tell from this what's going wrong. Please add #define DEBUG 1 to the start of RTSPServer.cpp, recompile, and send us the debugging output, up to the point of the crash. Okay: accept()ed connection from 10.0.0.10110RTSPClientSession[0xb09b0]::handleRequestBytes() read 174 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 102 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName DESCRIBE, urlPreSuffix , urlSuffix HighResolutionVideo sending response: RTSP/1.0 200 OK CSeq: 102 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/9 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 accept()ed connection from 10.0.0.1810RTSPClientSession[0xdc0e0]::handleRequestBytes() read 173 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 10 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName DESCRIBE, urlPreSuffix , urlSuffix HighResolutionVideo sending response: RTSP/1.0 200 OK CSeq: 10 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/9 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 RTSPClientSession[0xb09b0]::handleRequestBytes() read 197 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 103 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName SETUP, urlPreSuffix HighResolutionVideo, urlSuffix track1 sending response: RTSP/1.0 200 OK CSeq: 103 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=0-1 Session: 089B25B5 RTSPClientSession[0xdc0e0]::handleRequestBytes() read 196 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 11 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName SETUP, urlPreSuffix HighResolutionVideo, urlSuffix track1 sending response: RTSP/1.0 200 OK CSeq: 11 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.18;source=10.0.0.102;interleaved=0-1 Session: 2FC31F4B RTSPClientSession[0xb09b0]::handleRequestBytes() read 216 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 104 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 089B25B5 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName SETUP, urlPreSuffix HighResolutionVideo, urlSuffix track2 sending response: RTSP/1.0 200 OK CSeq: 104 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=2-3 Session: 089B25B5 RTSPClientSession[0xdc0e0]::handleRequestBytes() read 215 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 12 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 2FC31F4B User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16)
Re: [Live-devel] Regarding getting H264
On Wed, Apr 21, 2010 at 7:12 AM, Nilesh Kuber nilesh.ku...@gmail.com wrote: Hi, I am using the latest Live 555 SDK and I am developing client application in which I want to read H264 streams from IP camera. I have seen source - sink model of Live 555. I am getting success upto sending PLAY option to IP camera. Now I need to read H264 payload from this camera. So what classes I need to use in my client application to form source-sink model and I am able to extract H264 frame. Any help will be appreciated. http://www.live555.com/liveMedia/faq.html#h264-streaming ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Crash in RTSPServer.cpp
We have a crash in our RTSP server (implemented with Live555) that reproduces when streaming the same session to multiple RTP-over-TCP clients. Here's the callstack: Program terminated with signal 11, Segmentation fault. #0 0x47ac7cb4 in RTSPServer::RTSPClientSession::handleAlternativeRequestByte1 () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so (gdb) bt #0 0x47ac7cb4 in RTSPServer::RTSPClientSession::handleAlternativeRequestByte1 () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #1 0x47ac4b9c in SocketDescriptor::tcpReadHandler () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #2 0x47a9ee54 in BasicTaskScheduler::SingleStep () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #3 0x47a9e2d8 in BasicTaskScheduler0::doEventLoop () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #4 0x47a96670 in RTSPServer::run (this=0x3f5c0) at ../../../../src/RTSPServer.cpp:190 #5 0x403637f0 in QThreadPrivate::start () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/libQtCore.so.4 #6 0x405158c8 in start_thread (arg=value optimized out) at pthread_create.c:300 #7 0x4078add8 in clone () from /opt/montavista/pro/devkit/arm/v5t_le/target/lib/libc.so.6 Backtrace stopped: frame did not save the PC (gdb) The callstack is a bit odd because of optimiztion, but it makes sense going through tcpReadHandler. are there any known issues from requesting multiple RTP-over-TCP streams from the same session? (also, our client is based on openRTSP--so Live555 on both sides). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] XVid + Live555
On Fri, Apr 16, 2010 at 1:04 AM, Clemens Arth clemens.a...@gmx.at wrote: 2) Assuming xvid streaming does not work out, can someone point me to other video encoder sources that are freely available? Unfortunately I haven't found any other compact libraries other than xvid so far. IMO, I wouldn't bother with xvid, which is basically just MPEG-4. For any new work, I'd go with H264. x264 is the library I'd look into. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] SegmentQueue::enqueueNewSegment() overflow
On Thu, Apr 15, 2010 at 3:13 AM, dirk.raf...@de.transport.bombardier.comwrote: Hello everyone, First, let me say that I'm totally new to Live555 and multimedia streaming in general. I'm planning to build an on-demand RTSP server for streaming WAV and/or MP3 files via RTP unicast to an RTSP client. I've built and tried the TestOnDemandRTSPServer in the testProgs directory. Streaming a WAV file works flawless, but when streaming a MP3 file I get the error SegmentQueue::enqueueNewSegment() overflow which is generated in MP3ADU.cpp. While increasing SegmentQueueSize obviously helps in avoiding this error, there are still a lot of gaps in the playback. When I ran Live555 through static code analysis, a bunch of stuff in the MP3 portions of the library was flagged, including several potential buffer overflows. I didn't do anything about it because I don't use MP3 (sorry) but some of the stuff could definitely be related to your overflow: Warning5warning C6385: Invalid data: accessing 'fSegments-s', the readable size is '20320' bytes, but '1572768' bytes might be read: Lines: 173, 174, 175, 177, 181, 182, 185, 189, 197, 198, 199, 200, 203, 205, 213, 215, 220, 222, 225, 226, 227, 228, 229, 230, 231, 234, 240, 244, 245, 246 mp3adu.cpp246 Warning6warning C6246: Local declaration of 'bytesToZero' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '442' of 'mp3adu.cpp': Lines: 442 mp3adu.cpp471 Warning12warning C4996: 'fdopen': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _fdopen. See online help for details.MP3HTTPSource.cpp55 Warning28warning C6386: Buffer overrun: accessing 'si.ch', the writable size is '480' bytes, but '720' bytes might be written: Lines: 432, 438, 439, 441, 442, 445, 447, 448, 450, 451mp3internals.cpp451 Warning25warning C6386: Buffer overrun: accessing 'si.ch', the writable size is '480' bytes, but '720' bytes might be written: Lines: 349, 355, 356, 358, 359, 362, 364, 365 mp3internals.cpp365 Warning27warning C6385: Invalid data: accessing 'si.ch', the readable size is '480' bytes, but '720' bytes might be read: Lines: 432, 438, 439, 441, 442, 445, 447, 448mp3internals.cpp448 Warning26warning C6385: Invalid data: accessing 'si.ch', the readable size is '480' bytes, but '720' bytes might be read: Lines: 349, 355, 356, 358, 359, 362, 364, 365, 366, 364, 365, 366, 364, 365, 366, 364, 369, 370, 371mp3internals.cpp371 Warning24warning C6385: Invalid data: accessing 'live_tabsel[isMPEG2]', the readable size is '192' bytes, but '384' bytes might be read: Lines: 157, 158, 159, 166, 167, 168, 170, 173, 176, 178, 179, 180, 181, 182, 183, 184, 186, 188, 194mp3internals.cpp194 Warning23warning C6244: Local declaration of 'slen' hides previous declaration at line '434' of 'mp3internalshuffman.cpp' mp3internalshuffman.cpp505 Warning22warning C6054: String 'command' might not be zero-terminated: Lines: 341, 342, 343, 344, 345, 346, 350, 351, 353, 355 mp3internalshuffman.cpp355 Warning19warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp353 Warning20warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp365 Warning21warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp376 Warning18warning C6385: Invalid data: accessing 'hbuf', the readable size is '3' bytes, but '4' bytes might be read: Lines: 226, 227, 228, 230, 231, 233, 241, 242, 243, 252, 259, 268, 288, 289, 290, 293, 294 mp3streamstate.cpp294 Warning16warning C6385: Invalid data: accessing 'argument 2', the readable size is '2500' bytes, but '1048556' bytes might be read: Lines: 153, 155, 166, 167, 168, 169, 170, 171, 173mp3streamstate.cpp173 Warning17warning C6053: Call to '_snprintf' might not zero-terminate string 'writeBuf': Lines: 201, 203, 204, 205, 206, 212, 215 mp3streamstate.cpp215 Warning13warning C4996: 'fileno': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _fileno. See online help for details.MP3StreamState.cpp417 Thanks, Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...
On Thu, Apr 1, 2010 at 7:06 PM, Ross Finlayson finlay...@live555.comwrote: I've found out that when you run a few different instances of RTSP clients in separate threads CSeq number is not increased by one with each consecutive request. It's because CSeq number is a static variable in RTSPClient. This is a perfect illustration of why you are not supposed to run LIVE555 library code in multiple threads. (Have you read the FAQ entry about threads? If not, then why not (because you were asked to read the FAQ before you subscribed/posted to the mailing list)?) Instead, you should be using a single event loop (in a single thread) - even to make multiple RTSP client requests. I interpret what the OP is doing as this section in the FAQ: Another possible way to access the code from multiple threads is to have each thread use its own UsageEnvironment and TaskScheduler objects, and thus its own event loop. The objects created by each thread (i.e., using its own UsageEnvironment) must not interact (except via global variables). ...if there's a dedicated thread for each RTSPClient, with its own UsageEnvironment and TaskScheduler objects, is that a valid configuration of the library? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...
On Fri, Apr 2, 2010 at 1:10 AM, Ross Finlayson finlay...@live555.comwrote: I personally find your disdain for threads antiquated and naive This shows a lack of understanding. It's like saying that the designers of a bullet train have a disdain for air transportation, or conversely that the designers of an aircraft have a disdain for rail transport. On the contrary. We are talking about two completely different computation models, each with their pros and cons. I have been programming with threads since the mid 1980s - but for the LIVE555 libraries, I chose a single-threaded event-driven model instead. This works well for the type of applications that these libraries are typically used for, especially given that lots of inexperienced programmers (far more than I had originally anticipated, actually) are using the software. If anyone is interested in this topic, I encourage them to view Professor John Ousterhout's slide presentation: http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm(Personally, I wouldn't state the conclusion quite as strongly as he does, but - as a very experienced threads programmer myself - I agree with the general argument.) I'd buy this. But I think the library itself must run the way the FAQ mentions; otherwise, it is seriously problematic to use in any realistic manner. It just makes sense to run one RTSPServer or RTSPClient per-thread with its own event loop. The truth of the matter is: the rest of the world uses threads, and I can count the number of projects I participate in that use an eventing model on one hand (on one finger, actually), and almost every media API I use besides this one makes heavy use of threads. Love threads or hate them, it is often tricky to reconcile this disparity. That said, I actually prefer the Live555 model for threading because it makes sense always to have a dedicated thread servicing the network. (doing work on your network thread, besides servicing the network, is a bad idea) But if I had to put multiple clients on a single thread...I'd basically be screwed. That doesn't mesh well with any decent media framework I can think of. Possibly, but remember that the OP used a @gmail.com address, which tags him as a noob (absence strong evidence to the contrary :-). Unfortunately, I've found that such people frequently do not read the FAQ. Yeahwe're probably not going to agree on that one. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Windows Media Player?
On Mon, Mar 29, 2010 at 1:51 PM, Melms, Kenneth X. -ND kenneth.x.melms@espn.com wrote: This project, regardless of my spite, ire, anger, ideals, or bloviated bluster - contains Windows Media Player as a base requirement - and no amount of pushback ill change that... (oh, trust me .. I've tried..) Depending on how you're using WMP, you may be able to extend it to use Live555 or some other standards-compliant RTSP stack (if you're using a player embedded in a web page, this probably isn't an option; if you're using the standalone player, then there is no reason you cannot extend it). Another (likely better) option is silverlight. Send me mail directly if you have questions, since this is OT for the mailing list. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Windows Media Player?
This is probably extremely OT (sorry Ross, feel free not to post should you feel the need to moderate), but I've written media code for MSFT platforms for the last seven years so I can comment on this. On Mon, Mar 29, 2010 at 3:52 PM, Dom Robinson d...@d2consulting.co.uk wrote: I doubt you could do anything to get msft to 'return' to focusing on developing wmp. Their focus has sensibly gone to silverlight and frag 4 / TCP (http) now so there is no commercial sense in continuing to 'improve' wmp. RIAs and browsers are the only 'battle ground' now 'media players' are 'old hat'. The enterprise is going to switch on flash like crazy this year with adobe adding multicast support and that will flush wmp leaving silverlight (which already plays msft multicast) as the only contender. Silverlight is extensible to support new protocols and codecs. There are restrictions on the protocols you can use (in particular, no UDP) due to security issues, but there's no reason you couldn't extend silverlight to receive standards based RTSP and RTP-over-TCP. The one caveat is you'd need your stack to be in C# (it's all managed code), so Live555 isn't going to help here. AFAIK, there is no decent, open source RTSP stack for managed code, but it's been a while since I looked. Hopefully someone will toss one together (Ross, if you want to make some money...people'd pay). This will be because its not something msft are going to pay for (imagine the licensing costs due to mpeg by msft if that was possible). This isn't the case with Windows 7. MSFT finally bit the bullet and licensed MPEG2, H264 and AAC codecs (thank god, it's about time), and silverlight supports H264/AAC. So these days are rapidly going to be behind us. I should also add that silverlight is vastly preferable to WMP, particularly if you're hosting the player online. Standards or not, that issue is actually caused by MPEG licensing and not MSFT (unless you feel that MSFT is duty bound to pay MPEG for license fees for us?) Apple has always done this. They've been shipping with MPEG2/DVD/H264 for _years_ so why shouldn't I expect the same from MSFT? Writing an rstp plug in for IIS would be interesting Quite frankly, screw IIS/WMS--it'd make more sense to simply start with a server that supports RTSP in a standard compliant way, out of the box (e.g. wowza). There are (IMO) much better options for streaming servers than IIS/WMS, particularly if you want to deliver a codec that doesn't blow (e.g. H264). And WMS, to this day, has atrocious latency issues. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Wed, Mar 24, 2010 at 5:00 PM, Ross Finlayson finlay...@live555.comwrote Well, let me explain a few things to you (you seem confused about why I'm doing this) Actually, I'm less confused than uninterested. Overall, in general, I'm just not particularly interested in proxys (or 'middleboxes' in general). While they're often useful, supporting them is generally not a high priority for me. Are there any other features your library currently ships with that you're not particularly interested in that I should be aware of so I can avoid them in the future? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Mon, Mar 22, 2010 at 6:35 PM, Ross Finlayson finlay...@live555.comwrote: I've set breakpoints in every callback I could find, after my doEventLoop() call, etc. When I kill my internet connection mid-stream, I hit none of these breakpoints. OK, it sounds like you're blocking in your RTSP client ANNOUNCE operation. This will not be a problem in the upcoming RTSPClient restructuring (that will make all RTSP client operations asynchronous). Any idea when this might happen, and do you need any help? I definitely need these changes, so anything I can do to expedite that will be done. OK, so you would need to check for RTCP packets - assuming that Darwin sends them; I don't know whether it does. If so, you could do this using RTCPInstance::setRRHandler() (assuming that Darwin sends RTCP RR packets in response to ANNOUNCE data). I added a handler to check for RR reports, but unfortunately my server does not send them. I verified this on their forums as well (we're not using Darwin, but the general idea is the same). So, I guess my only option is to modify the library to do a per-RTPInterface variable that tracks TCP failure. Would you have any interest in this change if I supplied a patch? Thanks for your help. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Wed, Mar 24, 2010 at 2:45 PM, Ross Finlayson finlay...@live555.com wrote: I should warn you that I consider the DarwinInjector stuff to be deprecated technology, and although I'll probably be upgrading it to do an asynchronous ANNOUNCE, there's no guarantee that it will continue to be supported in the future. We have our own RTSP server implementation, and people should really be using this, rather than using this hack along with some other implementation. Well, let me explain a few things to you (you seem confused about why I'm doing this), and maybe you can recommend something better. We have a device that streams audio/video. This device will run on our customer's private networks (think SOHO type network at your house--dumpy linksys/dlink/netgear/whatever router hooked up to cable/DSL/etc.). To view AV remotely, we have to traverse NAT somehow (customers cannot directly connect to the device behind their NAT router without configuration). We don't want people to have to configure their router (i.e. port forwarding) because the vast majority of people A) do not know how to do this and B) haven't the foggiest clue what port forwarding/networking involves. Furthermore, doing it with multiple devices behind the same NAT is extra cumbersome/complicated/error prone, particularly when you throw DHCP into the mix on their internal network. So, we relay video through a central server that we support and maintain. I use the DarwinInjector to push video to Wowza (http://www.wowzamedia.com/), and that relays the video onto some client elsewhere (note that wowza can also transcode, so it can deliver over rtmp, rtsp, etc). Even when we do get a more sophisticated NAT traversal method, like STUN/ICE/whatever, we're still going to need this relay for the remaining customers for whom STUN/ICE/whatever doesn't work. What alternate options to the DarwinInjector do I have that would accomplish this with Live555? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
Hi Jeremy, When this happens do you, by chance, notice the CPU utilization go close to 100% on your target? I checked, and I don't experience this. Mostly, I just need a way of knowing that stuff is erroring out, but as far as I see, I don't get any feedback. The stream never times out (I'm using a DarwinInjector), none of the callbacks get fired (i.e. ByeHandler/AfterPlaying), etc. At this point I'm thinking I'll have to make code changes to make this work correctly, but maybe Ross will have some feedback. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Mon, Mar 22, 2010 at 11:43 AM, Roberts, Randy randy.robe...@flir.comwrote: Note, I didn’t conditionalize my error handling for specific errno returns…which I probably should have…and, it may be better to pass the status further up, to allow for error handling at a higher, more appropriate layer…Ross may have some ideas here (maybe a client provided error “handler” function could be used). This is basically what I'm looking for--I need the application layer to be informed when TCP communication has gone south so I can take appropriate action. It's not clear to me how to do this anymore. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Mon, Mar 22, 2010 at 11:46 AM, Ross Finlayson finlay...@live555.comwrote: Previously I was watching RTPOverTCP_OK to determine when there was a failure in TCP streaming, but that's since been removed. How can I determine when streaming has ceased because the network has failed (my internet connection goes down, for example)? You would detect this the same way that you would detect it for a UDP stream - e.g., because the server suddenly died. (There's no need for a special hack just for RTP-over-TCP streams.) Okay--what is this same way you speak of? I've set breakpoints in every callback I could find, after my doEventLoop() call, etc. When I kill my internet connection mid-stream, I hit none of these breakpoints. I am using the DarwinInjector, if that changes anything. E.g., you can periodically (i.e., using TaskScheduler::scheduleDelayedTask()) check that new data keeps arriving (into whatever object you're feeding from your RTPSource subclass). There's certainly no need to change any of the supplied LIVE555 Streaming Media code for this.http://lists.live555.com/mailman/listinfo/live-devel This is code that is pushing AV to a server online--unless I'm checking for RTCP stuff, data shouldn't be arriving, should it? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Form hang when running live555MediaServer
On Mon, Mar 22, 2010 at 6:30 PM, steven choong lovestoryho...@gmail.comwrote:
Dear Ross,
I am trying to use live555MediaServer.cpp as a server , I was successfully
compiled the code in VS2008. I use a main form to present the
live555MediaServer, there has a button which triggered the below functions:
public:
void startServer(){
TaskScheduler* scheduler = BasicTaskScheduler::createNew();
UsageEnvironment* env =
BasicUsageEnvironment::createNew(*scheduler);
UserAuthenticationDatabase* authDB = NULL;
RTSPServer* rtspServer;
portNumBits rtspServerPortNum = 554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
if (rtspServer == NULL) {
rtspServerPortNum = 8554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
}
env-taskScheduler().doEventLoop();
}
When the form is running, user click on the button in order to start the
server, it hangs. My question is, Is that a way to prevent the form being
hang while the server is running ?
Unless startServer is on a thread, your doEventLoop() call will block
indefinitely. You need to run Live555 on a dedicated thread. Running it on
the GUI thread is not an option. Read the FAQ section about threading if
you have questions.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Detecting network failure
Previously I was watching RTPOverTCP_OK to determine when there was a failure in TCP streaming, but that's since been removed. How can I determine when streaming has ceased because the network has failed (my internet connection goes down, for example)? In particular, I need to do this with a DarwinInjector instance. Previously I'd check the status of RTPOverTCP_OK every 500 msec; what options do I now have to determine if streaming is failing? Thanks, Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] liveMediaServer in production env
On Tue, Mar 16, 2010 at 4:47 AM, Glen Gray sla...@slaine.org wrote: Hey Guys, I'm looking into whether we can use liveMediaServer in a production environment. At the moment, we extensively use Kasenna servers. But we've a few cost sensitive customers and I'm thinking that liveMediaServer could offer a good alternative. At the moment, one of the benefits of using kasenna is the support utils that accompany the server. At the most basic level, logging and the ability to get a list of playing streams. Is there anything like this available with liveMediaServer or are there open source streaming servers based off the code that offer this ? I think you can definitely get a list of playing streams. For logging, my impression of Live555 thus far is that it's hit-or-miss, and there isn't much granularity to the logging that does happen. Most of it is a result of compile-time switches. I think the primary purpose of Live555 is a light-weight, embedded RTSP server (and also RTP stack). It's generally full featured, but I could see an enterprise user thinking's it's a bit lacking (it's certainly not a Darwin or Wowza--but those products also don't run on a 200 MHZ ARM part either). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 Unicast SPS Packet
On Mon, Mar 15, 2010 at 1:54 AM, Miguel Angel Arcos mar...@a5security.comwrote: Hello developers, I'm working now with a client receiving images from an H264 unicast server. I extract SPS and PPS packet using fmtp_spropparametersets and parseSPropParameterSets. I can see correctly the video data received when I decode. The problem is with the extraction of the resolution. I don't have problems when the server is multicast, I have a parser to do that task correctly. But with unicast if I try the same parser on the SPS packet I can't obtain the values correctly. Any suggestion of where or how I can obtain the resolution with unicast streaming? For unicast, are you sure you're correctly sending the SPS/PPS info in your SDP file? Or is your SPS/PPS info in-stream? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] New LIVE555 release - fixes RTP-over-TCP RTSP commandbug
Does this release also address the RTPOverTCP_OK variable? -Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] New LIVE555 release - fixes RTP-over-TCP RTSP commandbug
On Sun, Mar 14, 2010 at 6:36 PM, Ross Finlayson finlay...@live555.comwrote: Does this release also address the RTPOverTCP_OK variable? Oops - I said the other day that this release would be getting rid of the RTPOverTCP_OK hack altogether. I forgot to do this. However, I'm going to remove it from an upcoming release - so you should just ignore it. Ross, I'm confused--when you say you're removing that hack all together, does this mean we won't have a method for determining when an RTP over TCP sessions has ended (either due to error, or the client disconnecting or other?). Or is there some other method for knowing it's completed now? Basically, I need a method for knowing the stream has ended in the instance of network failure. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTPOverTCP_OK
I have an application that uses multiple instances of Live555 within a single process (each instance has a devoted thread, and I do not share instance data across threads, per the FAQ). However, RTPOverTCP_OK is a global variable so all instances of Live555 share its state. So if one instance has a TCP error then it affects all instances. I have two questions: 1. Is there some other way I should/could be dealing with TCP connectivity issues besides RTPOverTCP_OK? 2. If I were to fix this problem, what would be the best way to go about it? I was thinking of adding fRTPOverTCP_OK to the RTPInterface class, but then I'd need to expose it through other classes (RTPSink and RTCPInstance, from what I can see, which would then be visible from OnDemandServerMediaSubsession). I'd also leave the global in place to be backwards compatible with any existing code. Would you consider this patch if I wrote it? (or would you have a different suggestion?) Thank you, Jeremy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Fix for a possible buffer overflow in SDESItem
On Thu, Mar 11, 2010 at 8:43 AM, Jeremy Noring jnor...@logitech.com wrote:
In RTCP.cpp,
SDESItem::SDESItem(unsigned char tag, unsigned char const* value) {
unsigned length = strlen((char const*)value);
if (length 511) length = 511;
fData[0] = tag;
fData[1] = (unsigned char)length;
memmove(fData[2], value, length);
// Pad the trailing bytes to a 4-byte boundary:
while ((length)%4 0) fData[2 + length++] = '\0';
}
length is 511 bytes, and the additional padding at the end tacks on up to 3
more bytes. However, the buffer to which memory is being written to in
RTCP.hh is declared as:
unsigned char fData[2 + 0xFF]; // first 2 bytes are tag and length
...which is only 257 bytes. It needs to be at least 515 bytes in length
(511+ 2 is 513; padded to before the nearest 4 byte boundary bumps that up
to 515). So that line should change to:
unsigned char fData[2 + 513]; // first 2 bytes are tag and length
Either that, or the upper bound on length in the constructor needs to be
shortened. (to work with 2 + 0xFF, length would need to be no greater than
251)
Thanks,
Jeremy
Actually, on second glance, the only realistic option is to shorten length,
because only a single byte is allotted to the size field in fData[1]. (note
that length is cast to unsigned char). So in RTCP.cpp, I'd change this
line:
if (length 251) length = 251;
-Jeremy
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Possible arithmetic overflow?
In ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Possible arithmetic overflow?
Sorry, I accidentally sent it before I got to post anything. In RTPSink.cpp, unsigned lastReceivedTimeNTP = (unsigned)((lastReceivedTimeNTP_high16) + fractionalPart + 0.5); A 32-bit value is shifted, then cast to 64-bit value (this is because of the parenthesis); I'm not sure if lastReceivedTimeNTP_high gets large enough for this to be an issue, or if this is intended? On Wed, Mar 10, 2010 at 2:10 PM, Jeremy Noring jnor...@logitech.com wrote: In ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Possible arithmetic overflow?
On Wed, Mar 10, 2010 at 3:11 PM, Doug Porter d...@exacq.com wrote: Jeremy Noring jnor...@logitech.com writes: In RTPSink.cpp, unsigned lastReceivedTimeNTP = (unsigned)((lastReceivedTimeNTP_high16) + fractionalPart + 0.5); A 32-bit value is shifted, then cast to 64-bit value (this is because of the parenthesis); I'm not sure if lastReceivedTimeNTP_high gets large enough for this to be an issue, or if this is intended? The round-trip delay would have to be larger than the period of overflow (2^16 s) for this to be a problem.http://lists.live555.com/mailman/listinfo/live-devel Thanks Doug--that clarifies things. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] live555 blocked on a select
On Wed, Feb 17, 2010 at 7:57 AM, Sébastien Escudier sebastien-de...@celeos.eu wrote: If you can track this down some more, please let us know. Ok, so the client is blocked in RTSPClient.cpp - getResponse1 line 2191 in a readsocket call. The comment in the file says : // Keep reading data from the socket until we see \r\n\r\n (except // at the start), or until we fill up our buffer. // Don't read any more than this. and at this point the buffer (what has been read in the socket) is [1] (404 not found, ending with \r\n) So obviously, it won't go any further, because the server won't send anything more, and live555 client is waiting for another \r\n This happens in some rare cases, and most of the time, the same answer (404 not found with no \r\n\r\n at the end) is correctly received and handled by my live555 client. Do you have any idea what is wrong in this case ? I reported the same issue a week or three back; I fixed it the same way you did by adding timeouts to the various readSocket() calls in the RTSPClient implementation. Purportedly this code is undergoing a rewrite, so Ross didn't merge my changes (which is fine by me). I'm not sure how to reproduce the issue 100% of the time, but I know I occasionally see a hang in these select() statements, and it's generally when the RTSP server or internet connection hangs. The timeout resolves the problem. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Really blocking?
2010/2/10 Němec Alexandr a.ne...@atlas.cz Hi all, some days ago somebody (Jeremy Noring?) posted the following issue regarding RTSPClient. When using TCP transmission (-t option in openRTSP) then the client can deadlock when the network goes down. This sounds like a big problem because the client generraly should not deadlock on network problems. I tried to reproduce this behaviour, but with no luck. I used openRTSP code for my quick tests, used the -t option and I started some streams from RTSP servers. Then I destroyed the connection several times (cable disconnect etc.) but I was able to finalize the event loop safely with the watch variable with no deadlocks at all. Could anybody (maybe the original poster) put some light on this issue (how to reproduce etc.) ? I was actually pulling the plug on the RTSP Server, so my network was still good but the server went away, but I'd expect you could reproduce it simply by unplugging your network cable (?). Also, I'm using the RTSP client on Windows, if that makes any difference. That said, I'd only reproduce the hang if the code is in a few areas (any of the select() statements with no timeouts), so it does not reproduce 100% of the time (my guess is maybe one attempt in ten?). I would be interested in whether or not you can reproduce this bug--it's definitely not something that is easy to reproduce, but I'm absolutely positive that I've seen it (multiple times, and in several different select() calls). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] playback only working to localhost
On Sat, Feb 6, 2010 at 10:39 AM, Tom Pepper t...@silocorp.com wrote: The parameter set as I encode and report it: a=fmtp:96 packetization-mode=1;profile-level-id=41;sprop-parameter-sets=AWdNQCmWUgCgFz5cBUIAAAfSAAHUwTtCxbLAAWjrc1I= Something about your sprop-parameter-sets looks wrong--there should be a comma in it to delimit the SPS and PPS sets. How are you forming that? Also, in my experience, wowsa doesn't like having SPS/PPS sent in-stream. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] playback only working to localhost
On Sat, Feb 6, 2010 at 11:34 AM, Tom Pepper t...@silocorp.com wrote:
Jeremy:
Thanks for the quick response. I've had difficulty locating a good source
of information on what the parameter sets should look like, so that's
probably the issue.
MainConcept provides them via h264OutVideoGetParSets(). Here's the code I
use to retrieve them and parse:
// get AVC Parameter Sets
char * parset = (char *) malloc(1024);
int length;
if(h264OutVideoGetParSets(v_encoder, v_settings, (uint8_t
*) parset, length)) {
fprintf(stderr,h264OutVideoGetParSets() failed!);
exit(-1);
}
fprintf(stderr, h264OutVideoGetParSets: %i\n, length);
hexdump(parset, length);
char *b64parset = base64Encode(parset + 4, length - 4); //
skip sync
fprintf(stderr, b64parset: %s, %zu\n, b64parset,
strlen(b64parset));
unsigned int numrecords = 0;
SPropRecord* poo = parseSPropParameterSets(b64parset,
numrecords);
for (unsigned i = 0; i numrecords; ++i) {
fprintf(stderr, decoded [%i] = %s\n, i,
poo[i].sPropBytes);
}
The problem is that you're base64 encoding both SPS and PPS info in one big
block--the two are supposed to be individually base64 encoded, and then
delimited with a comma. In other words, the final entry should look like:
sprop-parameter-sets=spsInBase64,ppsInBase64
On the client side, it splits this string on the comma character and then
decodes each side separately.
It does look like h264OutVideoGetParSets() delimits the output with NAL
start codes (0x0001), so splitting the parameter sets apart shouldn't be
too difficult. If you want to identify SPS and PPS separately, that's a bit
more work to parse the NAL unit headers (see H264 specification if you need
to do this--it's a few lines of bit-twiddling, more or less).
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Fix for deadlock
When streaming over TCP, Live555 can deadlock if it loses the connection to
the server for whatever reason (internet goes down, server has a power
outage, LAN fails, etc.). I tracked the deadlock down to
RTPInterface::handleRead:
while ((curBytesRead = readSocket(envir(), fNextTCPReadStreamSocketNum,
buffer[bytesRead], curBytesToRead,
fromAddress)) 0) {
readSocket has an optional timeout argument that defaults to NULL, which is
to block indefinitely. The problem is if there is some interruption in
service at an unfortunate time, readSocket will block Live555 indefinitely
on a select() statement. My fix for this is to add a timeout:
struct timeval timeout; timeout.tv_sec = 2; timeout.tv_usec = 0;
while ((curBytesRead = readSocket(envir(), fNextTCPReadStreamSocketNum,
buffer[bytesRead], curBytesToRead,
fromAddress, timeout)) 0) {
...I pulled 2 seconds out of the air; I have no idea if that's a good
number. I'd like some feedback on whether or not this change is something
I'll seriously regret, and/or if there are other better options at my
disposal to make sure Live555 continues processing data even in the event of
the server going away.
Thanks,
Jeremy
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Fix for deadlock
On Wed, Feb 3, 2010 at 6:48 PM, Ross Finlayson finlay...@live555.comwrote: Jeremy, I applied your previous patches (to turn 'nonblocking' mode on, then off for the socket if there's a timeout parameter), and it will appear in the next release, but I'm not going to apply this one, because synchronous (blocking) socket reads in RTSPClient will eventually be going away.http://lists.live555.com/mailman/listinfo/live-devel That sounds good. Two follow up questions: 1. Any estimate on when blocking socket reads will get go away, and is there anything I can do to help? 2. Can you think of any potential risks to the aforementioned patch to add a timeout? Thanks again. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] WM-DRM
On Tue, Feb 2, 2010 at 8:39 AM, ziyad sharafudheen ziyad.sha...@gmail.comwrote: Hi, We are using live555 server for VOD streaming currently the media files being in transport stream format. We have a requirement for integrating WM-DRM to protect the VOD over IP. Does live555 works with WM-DRM. How will the encryption be applied: 1. Will it be on the streaming output buffer 2. Or, can live555 stream the packaged media file (encrypted). In this case, WM-DRM rights manager might package the file as a .*asf*format. Will live555 server streams .asf formats. If so how can we apply trick mode on such files. As far as I know, there is no standard RTP payload for WM codecs, and typically implementations will use Windows Media Services, Windows Media Encoder, or the WMFSDK to stream ASF/WMV/WMA content. If you do not need low-latency performance, this is vastly easier than using Live555. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Patch to put RTSPClient socket back to blocking
Here's the patch to set the RTSPClient socket back to blocking if the client submits a timeout (in the event of a timeout, the socket was being set to non-blocking, but the author of that patch forgot to set it back to block). Let me know if you have questions. GroupsockHelper_hh Description: Binary data GroupsockHelper_cpp Description: Binary data RTSPClient_cpp Description: Binary data ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 H264VideoRTPSource
On Mon, Jan 25, 2010 at 3:25 AM, Miguel Angel Arcos mar...@a5security.comwrote: Dear Ross, I'm working with the class H264VideoRTPSource when I recieve RTP data information of an IP Camera and I have some questions. First, If I look my (subsession-(fVideoWidth y fVideoHeight)) and I can't extract video resolution because this values are 0. Then I'm looking to extract that information looking the SPS, Sequence Parameter Set, packets. On the live555 classes I have been looking and I can't find any parser of that data. Is possible extract that information using live555 or I need to search another parser to do that task? Live555 doesn't have a parser for the sequence parameter sets. Writing such a parser isn't too hard, although it's not completely trivial because the SPS info uses exponential golomb encoding (a form of variable length encoding) for many parameters. I'd read the H264 specification if you're interested in parsing it; also read the wiki page on exponential golomb: http://en.wikipedia.org/wiki/Exponential-Golomb_coding (also note that the resolution is inferred from several different values in the SPS set--it isn't just a single value for width/height) ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Blocking socket
On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson finlay...@live555.comwrote: Looking at the original patch, it's pretty clear that the author forgot to set the socket back to be blocking. But considering that this issue has been present for well over a year, I have to wonder whether or not the RTSPClient even needs to be run on a blocking socket. (Ross, you know the most about this, so I'd be interested to hear your take on things). I'm not planning on doing much with the existing RTSPClient code, because this code will soon be significantly overhauled so that it does I/O asynchronously, using the event loop, rather than the current blocking-with-timeout model (which doesn't fit with the event-driven model of the rest of the library's code). This change will also eliminate the need for a timeout parameter (although the existing API will probably kept - as an option - for a while, for backwards compatibility). Fixing RTSPClient is high priority (second only to fixing the problems with RTP-over-TCP). I've had a chance to test this change, and everything still seems to work OK for me (I use the RTSPClient to pull directly from a Live555 on-demand server; I also use the darwin push code, which uses the RTSPClient internally). How do you want the patch? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Blocking socket
2010/1/16 Němec Alexandr a.ne...@atlas.cz
Hi all,
somebody posted a suggestion that the socket (when using timeout in the
RTSP client) must be set back to blocking. Is this already corrected in the
current code release and is it necessary to do so, what are the consequences
when the socket is not set back to blocking?
I wondered the same thing, so I tracked down the change, which seems to have
originated from the VLC project in October, 2008:
http://mailman.videolan.org/pipermail/vlc-devel/2008-October/051390.html
Looking at the original patch, it's pretty clear that the author forgot to
set the socket back to be blocking. But considering that this issue has
been present for well over a year, I have to wonder whether or not the
RTSPClient even needs to be run on a blocking socket. (Ross, you know the
most about this, so I'd be interested to hear your take on things).
FWIW, I haven't tested this patch yet (been busy), but here's the changes
you'd need to revert the socket to blocking. In GroupsockHelper.h and .cpp:
Boolean makeSocketBlocking(int sock);
Boolean makeSocketBlocking(int sock) {
#if defined(__WIN32__) || defined(_WIN32) || defined(IMN_PIM)
unsigned long arg = 0;
return ioctlsocket(sock, FIONBIO, arg) == 0;
#elif defined(VXWORKS)
int arg = 0;
return ioctl(sock, FIONBIO, (int)arg) == 0;
#else
int curFlags = fcntl(sock, F_GETFL, 0);
return fcntl(sock, F_SETFL, curFlags(~O_NONBLOCK)) = 0;
#endif
}
...and in RTSPClient.cpp,
fd_set set;
FD_ZERO(set);
timeval tvout = {0,0};
if (timeout 0) {
FD_SET((unsigned)fInputSocketNum, set);
tvout.tv_sec = timeout;
tvout.tv_usec = 0;
makeSocketNonBlocking(fInputSocketNum);
}
if (connect(fInputSocketNum, (struct sockaddr*) remoteName, sizeof
remoteName) != 0) {
if (envir().getErrno() != EINPROGRESS envir().getErrno() !=
EWOULDBLOCK) {
envir().setResultErrMsg(connect() failed: );
break;
}
if (timeout 0 (select(fInputSocketNum + 1, NULL, set, NULL,
tvout) = 0)) {
envir().setResultErrMsg(select/connect() failed: );
break;
}
}
// If we set our socket to non-blocking, put it back in blocking mode
now.
if( timeout 0 ){
makeSocketBlocking(fInputSocketNum);
}
I'll probably get a chance to try these out sometime next week, on both
Win32 and embedded linux, so I can vouch for those platforms. I have no
idea if the VXWORKS code is correct (I did review it with a coworker who
thought it looked good), and no way of testing that platform.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTSPClient blocking/non-blocking bug?
I was reviewing the code in RTSPClient::openConnectionFromUrl(), and I had a
question about the codepath involving setting a timeout. In particular,
this code:
//Start change for timeout on connect
/*
if (connect(fInputSocketNum, (struct sockaddr*)remoteName, sizeof
remoteName)
!= 0) {
envir().setResultErrMsg(
connect() failed: );
break;
*/
fd_set set;
FD_ZERO(set);
timeval tvout = {0,0};
if (timeout 0) {
FD_SET((unsigned)fInputSocketNum, set);
tvout.tv_sec = timeout;
tvout.tv_usec = 0;
makeSocketNonBlocking(fInputSocketNum);
}
if (connect(fInputSocketNum, (struct sockaddr*) remoteName, sizeof
remoteName) != 0)
{
if (envir().getErrno() != EINPROGRESS envir().getErrno() !=
EWOULDBLOCK)
{
envir().setResultErrMsg(connect() failed: );
break;
}
if (timeout 0 (select(fInputSocketNum + 1, NULL, set, NULL,
tvout) = 0))
{
envir().setResultErrMsg(select/connect() failed: );
break;
}
/*
errno = 0;
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, err, len) 0 || errno
!= 0 )
{
break;
}
*/
//End change for timeout on connect
}
...I see that if timeout 0, then fInputSocketNum is set to a non-blocking
socket (i.e. makeSocketNonBlocking). Shouldn't this get set back to a
blocking socket once this connect attempt is completed?
(it may be that this happens somewhere else, but my quick checks through the
code didn't reveal any such code)
If this is an issue, I have code I can submit that will set the socket back
to blocking.
Thanks!
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] live555 and VLC question
2010/1/8 Němec Alexandr a.ne...@atlas.cz Dear all, we have downloaded the VLC player and we realized the live555 code is used in it (well, we are new to the scene). We studied the VLC code but it is not obvious to us, what parts of live555 streaming media library the VLC player is using. We thought that the VLC player uses live555 code whenever it needs to contact a RTSP server and to receive data via RTP. But there seem to be other code files in the VLC project covering the RTSP and RTP implementations. So what is the relation here? We just want to make this clear to be able to understand both code packages (live555 and VLC correctly). Thanks I haven't looked at VLC, but for a lot of media types in Live555, you have to subclass some generic type and make your own media sinks/sources. So my guess would be they're subclassing Live555 classes for custom protocols, or protocols that often require subclassing (e.g. H264). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] openRTSP 2x
2009/12/20 Němec Alexandr a.ne...@atlas.cz Dear all, I have two questions regarding openRTSP. 1. I have a H264 camera with built-in RTSP server (an IP camera) and I am using openRTSP to receive the video stream. It works nice, I can receive frames of type IDR slices and other coded slices. However, a standard H264 also contains a SPS (sequence parameter set) NAL unit followed by a PPS (picture parameter set) NAL unit followed by the first IDR frame. The IP camera manufacturer confirmed that they include the SPS+PPS header bytes before the very first IDR frame and also before some later IDR frames at regular intervals. As I receive clean frames from live555 library without SPS+PPS I ust want to ask, if there is the possibility to somehow get these bytes, because I want to save them before the start of the stream. I tested the incoming frames and the first byte tells me, that the frames are clean IDR slices and other coded slices (NAL unit types 5 and 1). The SPS and PPS header bytes are missing. They should be populating the sprop-parameter-sets parameter in the SDP exchange with the SPS/PPS info (see RFC3984). Sending the info in-stream is not recommended and makes writing a decent client more difficult. Check the SDP exchange to see if they are correctly setting this; you should see someting like: sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== ...the SPS and PPS info are base-64 encoded, and delimited with a comma. 2. Is there a way to set a custom timeout value for the RTSP client that the client would use for each command like PLAY, TEARDOWN or OPTIONS? I would like to be able to change the timeout and to force the RTSP client to complete a method master when the RTSP server is unavailable. I searched the code and found some timeout parameters, but I am not sure that I am doing the right thing. Thanks very much in advance Alex See the source code to openRTSP (and specifically, the method calls on RTSPc lient); there are several timeouts you can specify. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] QOS message of live555 ?
On Sun, Dec 20, 2009 at 3:01 AM, Kevin.Liu kevin@innosofts.com wrote: The strange thing is that if I transport only audio stream like “mp3 file” the packet lost was very small ,but if I transport both audio and video stream like “mp4,mpg files” the packet loss was really big. And I found that a 6M mpg file only transport 37 seconds (sdp message “ a=range:npt=0-37.160”) but a 5M mp3 file transport 301 seconds in the same network environment. This is not strange, it's perfectly normal. Doing the math, your video file is 1.3 mbit/sec (48 mbit / 37 seconds), while your mp3 file is 132 kbit/sec (40 mbit / 301 seconds), or roughly one-tenth the bandwidth of your video file. Your problem is obvious: your network does not have enough bandwidth to transmit the video in real-time, and you're experiencing packet loss (from the sound of it, you have about 1 mbit/sec of bandwidth). You're experiencing packet loss because your network is insufficient to transmit the video stream, which is _much_ larger than the audio stream. Like Ross said, get more bandwidth or smaller media. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Slow connection problem with RTP over RTSP/TCP
On Thu, Nov 19, 2009 at 2:31 AM, Ross Finlayson finlay...@live555.comwrote: And if the server can detect that the network is to slow or congested to send all of the requested data (by detecting that the network buffers in the OS are full) make an attempt to intelligently send enough data to provide a working, all be it degraded, experience to the client rather than just randomly dropping parts of frames so that nothing may work. Yes, at some point it would be nice to support the IETF's RTP/AVPF profile, and an associated feedback-based retransmission (and/or media rescaling) scheme. But this, of course, is on top of UDP. Trying to implement a loss-mitigation scheme over TCP is retarded. I agree. Furthermore, basically the patch implements a retransmit on the RTP stack level, which is wholly incompatible with any RTP specification I know of. RTP uses application level framing, which means some of the behaviors are specifically not defined, and should be implemented by the application level. If my video stream is live, retransmitting is likely a waste of time because the data is already obsolete. And mostly likely I can only start a stream on keyframe boundaries, so retransmitting some intermediate frame is also a waste of time if there's already been previous loss. (hence application level framing--only the calling application knows what sort of loss mitigation plan it should implement) Question: does Live555 provide a feedback mechanisms for loss, jitter, etc. (basically some way of getting the RTCP stats) so I can tweak the encoder in real-time to fit network conditions? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] problem (?) when outputting raw H264 stream with openRTSP
On Fri, Nov 13, 2009 at 8:30 AM, Alberto Alberici albal...@yahoo.comwrote: In addition: in the produced raw file, I don't see any nal marker (00 00 00 01), even if H264FileSink seems to insert them (I made a small debug.). Why? Well, if this is true then it's unsurprising that the file doesn't play back (for raw H264, start codes must be present for parsing). I am not sure why this wouldn't work, so you'll have to debug it. I'd also make sure your SPS/PPS info is being written at the start of the file. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] an architecture question of livemedia server
On Wed, Oct 21, 2009 at 10:10 AM, Tao Wu lanlan...@gmail.com wrote: Hi, I have an architecture question of livemedia. Livemedia is a single thread program, it uses event to serve multiple video streams. If in one video stream, I called some blocking functions, will it hurt other video streams? For example, assume the server wants to server two video streams, A and B. Both stream A and B's sources are from the hardware encoder, not a file on hard drive. So if stream A VideoStreamer::ContinueReadProcessing reads data from the video sources, it may not get the data immediately when using blocking function calls to the hardware encoder. In the worst case, it can stop for ever because of hardware failure. If that happens, can stream B still function properly when stream A blocked? Short answer: no, you cannot block Live555 in any way and expect good results. Long answer: instead of blocking, consider having your code simply check and see if any data is available. If no data is available, use Live555's event mechanism to schedule another check for data in however long is appropriate. For example, I have a hardware h264 encoder. On my Live555 thread, I merely check and see if there's any available data. If there is, I process it. If there isn't, I use Live555's scheduling to drop back in another 20 milliseconds (or whatever is appropriate). It's polling, yes, but it works just fine. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Stack overflow in QuickTimeFileSink
On Tue, Oct 6, 2009 at 12:55 AM, Sébastien Escudier sebastien-de...@celeos.eu wrote: Quoting Ross Finlayson finlay...@live555.com: I don't seem to get the stack overflow anymore, but something tells me if this records for a while and all of these chunks are kept in memory, then it'll blow up pretty soon. Yes, and unfortunately there's not a lot we can do about this, because of the stupid brain-damaged way in which the .mov (and .mp4) file formats was designed. what do you call for a while ? I don't know .mov files, but for .mp4 files, your file will become way too big before you run out of memory because of chunks and frames informations kept in memory. You should consider splitting your files after a few hours of recording. If you're really serious about writing MP4/MOV files, I would not use Live555 code for that (Live555 is Source-code libraries for standards-based RTP/RTCP/RTSP/SIP multimedia streaming; it is not an MP4/MOV container library). Rather, I'd consider something like mp4v2, or ffmpeg's container code. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 multicast streaming question
On Tue, Sep 29, 2009 at 10:43 AM, Stas Desyatnlkov s...@tech-mer.comwrote: Here is a situation: The streamer is a black box that’s connected to audio and video source. The streamer sends TS with AVC and AAC because the client can only accept TS. The client knows the exact format of the video and audio streams inside TS and wants to connect to the live transmission at any time. The client knows nothing about session establishment protocols (e.g. RTSP). Where exactly in this situation are you using Live555? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 multicast streaming question
On Thu, Sep 24, 2009 at 12:46 AM, Stas Desyatnlkov s...@tech-mer.comwrote: Hi, Its obvious that loss of the SPS or PPS results in a lot of grief in the h264 land. The question is what choice do we have in case of no other means of communication besides RTP? What if the h264 stream is packed inside TS and receiver is not aware of anything else? I guess in case of LAN streaming where packet loss is rare sending SPS/PPS inband is not that bad of an option would you agree? It depends. If you're doing multicast, then sending it in-stream is a bad idea; clients may miss the first sending, which means you'd have to do something weird like insert it when a client connects, or periodically insert it. If you're doing unicast, it would probably work to send it once in-stream. In my experience, some clients expect correct sprop-parameter-set and profile-level-id fields (e.g. quicktime), so not populating them is possibly a deal-breaker. In any event, if you're on a LAN, why would you _ever_ consider not using the associated RTSP session to communicate this information? And what sort of scenario do you have where there is no other means of communication besides RTP? Quite frankly, I can't possibly think of a situation where either of these statements would be true. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Proposed change to DarwinInjector.cpp/.hh
I've been testing with the DarwinInjector to push to a server online for
redistribution, and one thing I noticed is the timeout value for the initial
connection to Darwin isn't exposed, so if a push attempt is made to a server
that's unavailable for whatever reason, DarwinInjector-setDestination()
does not return.
So I exposed the timeout value in the DarwinInjector-setDestination()
method, with a default value of -1 so it's compatible with existing code.
Here's the diff for DarwinInjector.hh:
76c76,77
char const* sessionCopyright = );
---
char const* sessionCopyright = ,
int timeout = -1);
Diff for DarwinInjector.cpp:
112c112,113
char const* sessionCopyright) {
---
char const* sessionCopyright,
int timeout) {
189c190
= fRTSPClient-announceWithPassword(url, sdp, remoteUserName,
remotePassword);
---
= fRTSPClient-announceWithPassword(url, sdp, remoteUserName,
remotePassword, timeout);
191c192
announceSuccess = fRTSPClient-announceSDPDescription(url, sdp);
---
announceSuccess = fRTSPClient-announceSDPDescription(url, sdp,
NULL, timeout);
I didn't see another way to configure the timeout, but if I missed
something, let me know.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Question about a FAQ answer
On Wed, Sep 16, 2009 at 11:48 PM, Ross Finlayson finlay...@live555.com wrote: The Live555 FAQ has this question and answer: Q: For many of the test*Streamer test prpgrams, the built-in RTSP server is optional (and disabled by default). For testAMRudioStreamer, testMPEG4VideoStreamer and testWAVAudioStreamer, however, the built-in RTSP server is manditory. Why? A: For those media types (AMR audio, MPEG-4 video, and PCM audio, respectively), the stream includes some codec-specific parameters that are communicated to clients out-of-band, in a SDP description. Because these parameters - and thus the SDP description - can vary from stream to stream, the only effective way to communicate this SDP description to clients is using the standard RTSP protocol. Therefore, the RTSP server is a manditory part of these test programs. My question is: does this same principle apply to H.264 as well Yes. Thanks. My application consists of an embedded processor running Live555. To allow people to view video remotely, we need to push video to a central server where it is then re-distributed; this is to circumvent NAT/firewalls/etc. For this model, the embedded server has to push video to some central server. Is there any way to do this with Live555 without making some rather radical modifications? And if yes, any suggestions as to a good starting place in the code base to make those modifications? (on a side note, I did tear apart quicktime broadcaster with wireshark, and it seems they're using some weird combination of RTSP ANNOUNCE/RECORD and TCP interleaving to push video to a server over a single port. Is this a common capability of RTSP implementations? Seems like it isn't) As always, Ross, your advice is greatly appreciated. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Question about streaming a H.264 video file via RTP
On Thu, Sep 17, 2009 at 12:13 AM, 12091637 12091...@qq.com wrote: Dear all, I am working with live555 library for H.264 video file streaming via RTP. When I creat ByteStreamFileSource instance to stream *.h264 video file, how can I set PlayTimePerFrame and preferredFrameSize value?How to get the preferredFrameSize and playTimePerFrame parameters base on existing *.h264 file? How to calculate them from the information of *.h264 file. If I set the two parameters to zero, my stream will be incompatible with existing, standards-compliant clients (e.g., VLC,MPlayer). Sometimes VLC will crash when play my stream( rtsp://192.168.10.62/test.h264) To get the preferredFrameSize value, you'll have to parse the h264 bytestream; read the H.264 standard to figure out how to do this (you'll likely need to read the standard to get your streaming working anyway). You cannot get playTimePerFrame from a .h264 file because raw h264 byte streams contain no timing information (H.264 encoders themselves have no notion of time, only successive frames). ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Question about a FAQ answer
The Live555 FAQ has this question and answer: Q: For many of the test*Streamer test prpgrams, the built-in RTSP server is optional (and disabled by default). For testAMRudioStreamer, testMPEG4VideoStreamer and testWAVAudioStreamer, however, the built-in RTSP server is manditory. Why? A: For those media types (AMR audio, MPEG-4 video, and PCM audio, respectively), the stream includes some codec-specific parameters that are communicated to clients out-of-band, in a SDP description. Because these parameters - and thus the SDP description - can vary from stream to stream, the only effective way to communicate this SDP description to clients is using the standard RTSP protocol. Therefore, the RTSP server is a manditory part of these test programs. My question is: does this same principle apply to H.264 as well (i.e. the sprop-parameter-sets and profile-level-idc guys in the SDP exchange?). Can't the sprop-parameter-sets/profile-level-idc be sent in the stream itself, or is a secondary communication line essential to make H.264 (and AMR/MPEG-4/PCM) understandable by a receiving application? Thanks. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Live G711 audio source
Sorry for the constant posts--I solved it. Again, timestamping bug. I changed my code to use the gettimeofday() defined in GroupsockHelper.hh, and everything works, so...pretty clear the problem is in our timestamping class (portable timestamping code == royal PITA). Thanks for all your help, Ross! ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Live G711 audio source
On Wed, Sep 9, 2009 at 5:50 PM, Ross Finlayson finlay...@live555.comwrote:
I believe this because VLC is incorrectly reporting the # of bits per
sample as 16, and that's the only inheritance hierarchy I can see that
clearly communicates such a value. Is that correct?
What RTP payload format are you delivering to the client? u-law (PCMU)?
L8? Or L16? Only the last is 16-bits-per-sample. Once again, look
closely at the WAVAudioFileServerMediaSubsession code for a model.
Here's how I implemented the subsession methods:
RTPSink * LiveG711MediaSubsession::createNewRTPSink(Groupsock
*rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource
*inputSource)
{
char const* mimeType = PCMU;
unsigned char payloadFormatCode = 0;
int sampleFrequency = 8000;
unsigned int numChannels = 1;
return SimpleRTPSink::createNew(envir(), rtpGroupsock,
payloadFormatCode, sampleFrequency,
audio, mimeType, numChannels);
}
FramedSource * LiveG711MediaSubsession::createNewStreamSource(unsigned
int clientSessionId, unsigned int estBitrate)
{
// For G711, our bitrate is always going to be 64kbps
estBitrate = 64;
return LiveG711AudioStreamFramer::createNew(envir(), NULL,
m_mediaSource );
}
The LiveG711AudioStreamFramer is also something I wrote, and
m_mediaSource is the thing that supplies my audio. For the values I
supply to SimpleRTPSink, I basically copied what
WAVAudioFileServerMediaSubsession was delivering for PCMU audio (8000 hz, 1
channel, etc.).
Still not sure what problem I'm having--I see VLC is receiving the audio
stream, but it's dropping all of the data claiming the PTS is out of
range. Going to check and see what the SDP exchange looks like with
openRTSP. Thanks again for all your help.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTP over TCP, pushing
Is it possible for Live555 to push a unicast stream to a server online, and have all the traffic go over TCP? I know Live555 can interleave AV data over the RTCP TCP channel, but I've only seen that for the on-demand configurations; is it possible to push video to a server over the RTCP line? The reason I ask is we want to relay video through a proxy we control to circumvent NAT. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] H264 multicast streaming question
2009/9/10 spopo...@yahoo.com.tw But when I streamed the H.264 file by unicsat method successfully , the sprop-parameter-sets has been set “h264”. Therefore i think the sprop-parameter-sets=h264 does't influence the stream when using multicast method. Is it right? No, that's not right. For the decoder to understand your H.264 stream, it is crucial that the SPS/PPS info is communicated over a reliable protocol. If you are not sending in in the sprop-parameter-sets argument, how are you conveying it? Note that sending it in the actual stream is not recommended (see section 8.4 of RFC3984). Some people mistakenly think their Live555/H264 implementation works, but really they're just conveying SPS/PPS info through the lossy RTP channel, which is strongly discouraged by the RFC: The picture and sequence parameter set NALUs SHOULD NOT be transmitted in the RTP payload unless reliable transport is provided for RTP, as a loss of a parameter set of either type will likely prevent decoding of a considerable portion of the corresponding RTP stream. Thus, the transmission of parameter sets using a reliable session control protocol (i.e., usage of principle A or B above) is RECOMMENDED. Botton line: correctly populate sprop-parameter-sets; you are wasting your time by not doing this. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
