Re: [Live-devel] Live555 EventLoop crash

On Thu, Dec 22, 2011 at 6:12 AM, Jeff Shanab 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

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.com>wrote: > 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 mu

Re: [Live-devel] Live555 EventLoop crash

On Wed, Dec 14, 2011 at 1:27 PM, Ross Finlayson wrote: > 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

Re: [Live-devel] Jeremy Noring's problem with RTP-over-TCP

On Fri, Nov 25, 2011 at 12:21 AM, Ralf Globisch wrote: > @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

Re: [Live-devel] Jeremy Noring's problem with RTP-over-TCP

On Thu, Nov 24, 2011 at 1:25 PM, Ross Finlayson wrote: > 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

Re: [Live-devel] older source archives

On Thu, Nov 24, 2011 at 5:39 AM, Steffen Sledz wrote: > It seems that at 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 > OpenEmb

Re: [Live-devel] Segmentation fault in DelayQueue::removeEntry(DelayQueueEntry*)

On Fri, Nov 4, 2011 at 7:10 AM, Ross Finlayson wrote: > Looking at the code here > http://www.live555.com/liveMedia/doxygen/html/DelayQueue_8cpp-source.html I > see this: > > 00153 > > void Del

Re: [Live-devel] MP4 file creation

Try this: http://code.google.com/p/mp4v2/ On Wed, Aug 10, 2011 at 8:37 PM, wrote: > Arg...is FFMPEG/LibAV the best library to write an MP4 file? > Thx > /K > > > --- On *Wed, 8/10/11, Ross Finlayson * wrote: > > > From: Ross Finlayson > Subject: Re: [Live-devel] MP4 file creation > > To: "LIVE

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

Re: [Live-devel] Problem with RTP over TCP

On Thu, Jul 21, 2011 at 1:06 AM, Ross Finlayson wrote: > 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 se

Re: [Live-devel] Problem with RTP over TCP

On Wed, Jul 20, 2011 at 4:41 PM, Ross Finlayson wrote: > ** > > 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

Re: [Live-devel] Problem with RTP over TCP

On Wed, Jul 20, 2011 at 11:15 AM, Jeremy Noring 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 t

Re: [Live-devel] A new server extension for streaming to iPhones and iPads

On Sun, Jul 17, 2011 at 9:23 PM, Ross Finlayson wrote: > 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

[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

Re: [Live-devel] Symbian Client having issues with Live555 based server

On Sun, Jan 16, 2011 at 3:31 PM, Ross Finlayson wrote: > In such cases server should just respond by OK 200 or 451 >> >> RTSP/1.0 451 Parameter Not Understood >> > > Hmmm. The RTSP 1.0 spec lists "451" as being an error code only for > "SETUP", although the RTSP 2.0 spec lists it as being an err

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

Re: [Live-devel] Why no file testH264VideoToDarwin. cpp

On Tue, Jan 4, 2011 at 1:16 AM, Ross Finlayson wrote: > 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 comme

Re: [Live-devel] Slight authentication change

On Wed, Nov 17, 2010 at 3:23 PM, Ross Finlayson wrote: > > 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," a

Re: [Live-devel] Slight authentication change

On Wed, Nov 17, 2010 at 1:37 PM, Ross Finlayson wrote: > 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(NU

Re: [Live-devel] Slight authentication change

On Wed, Nov 17, 2010 at 1:07 AM, Ross Finlayson wrote: > 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 authenti

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

Re: [Live-devel] Question about a resizing filter

On Mon, Nov 15, 2010 at 3:11 PM, Ross Finlayson wrote: > 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

Re: [Live-devel] Question about a resizing filter

On Mon, Nov 15, 2010 at 2:16 PM, 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

Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 12:07 PM, Larry Cui wrote: > Jeremy Noring, > > Windows Firewall default state is ON. > > After Off the firewall, streaming is ok. > > With my implementation, only video packet and SPS and PPS are sent out, > there is no SEI packet. VLC plays wel

Re: [Live-devel] H264 over RTP/RFC 3984

On Mon, Oct 25, 2010 at 11:37 AM, Larry Cui 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

Re: [Live-devel] H264 over RTP/RFC 3984

On Wed, Oct 20, 2010 at 3:12 PM, Larry Cui 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 el

Re: [Live-devel] RTSP Server.

On Fri, Oct 8, 2010 at 5:15 AM, Sukhbir Singh wrote: > Hi All, > > I need to know that how many simultaneous RTSP Client requests can be > handled by mediaServer (RTSP Server for .m4e files)? > > Depends on your server hardware, how much bandwidth you have, and the bitrate of your .m4e files, so y

Re: [Live-devel] Newbie with a DirectShow headache

On Thu, Oct 7, 2010 at 5:47 PM, Ross Finlayson wrote: > Ah, yeah--I forgot about that. For H264, you really need to write some >> code to parse the SPS/PPS information that's present in the SDP exchange >> > > Note that we already provide code to do this parsing; you don't need to > write it your

Re: [Live-devel] Newbie with a DirectShow headache

On Thu, Oct 7, 2010 at 12:12 PM, John Orr 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

Re: [Live-devel] Newbie with a DirectShow headache

On Thu, Oct 7, 2010 at 9:12 AM, iain 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 t

Re: [Live-devel] segmentation fault (core dumped)

2010/9/6 Aranganathan Sankaradoss > 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

Re: [Live-devel] Graceful handling of socket error

On Wed, Sep 8, 2010 at 2:58 PM, Ross Finlayson wrote: > 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 legiti

Re: [Live-devel] segmentation fault (core dumped)

2010/9/6 Aranganathan Sankaradoss > 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?

Re: [Live-devel] dump h264 video problem

On Thu, Jul 29, 2010 at 1:14 PM, Ross Finlayson wrote: > 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

Re: [Live-devel] Problems using Windows Media Player

On Tue, Jul 20, 2010 at 6:45 PM, Jimmy Zhang 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@lis

Re: [Live-devel] Problems using Windows Media Player

On Tue, Jul 20, 2010 at 5:37 PM, wrote: > > Hi, > > I'm testing/evaluating the Live media server with the VLC Media Player and > Windows Media Player, but I can't seem to get anything to play on WMP even > though the same stream plays correctly using VLC. I'm streaming from the > local host by

Re: [Live-devel] How to contribute code?

On Thu, Jun 24, 2010 at 9:00 AM, BONNEAU Guy 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 >

Re: [Live-devel] How to contribute code?

On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson wrote: > 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

Re: [Live-devel] How to contribute code?

On Fri, Jun 18, 2010 at 7:18 AM, Ross Finlayson wrote: > 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 sou

Re: [Live-devel] RTSP server hang

On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson wrote: > 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

Re: [Live-devel] RTSP server hang

On Sun, Jun 13, 2010 at 7:16 PM, Ross Finlayson wrote: 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

[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((unsi

Re: [Live-devel] livemedia lib throughput speed limitations

On Fri, May 21, 2010 at 3:43 PM, Tao Wu wrote: > If I want to stream a file very fast and reasonably reliable, what is best > direction to go? > Use RTP over TCP. Also, it sounds like you're not interested in "streaming" a file but "transferring" a file, in which case you could get away with us

Re: [Live-devel] Getting the JPEG payload from a JPEG file

On Thu, May 20, 2010 at 3:17 AM, Andy Bell 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 > hav

Re: [Live-devel] Crash in RTSPServer.cpp

On Tue, May 11, 2010 at 4:42 PM, Jeremy Noring wrote: > On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring wrote: > >> On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: >> >>> >>> It would be nice to find a simple, repeatable sequence of client >>>

Re: [Live-devel] Crash in RTSPServer.cpp

On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring wrote: > On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: > >> >> 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 >>

Re: [Live-devel] Crash in RTSPServer.cpp

On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson wrote: > > 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 overlapp

Re: [Live-devel] Crash in RTSPServer.cpp

On Wed, Apr 21, 2010 at 4:44 PM, Ross Finlayson 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" subcl

Re: [Live-devel] need H264 RTP streaming tutorial

On Fri, Apr 30, 2010 at 9:21 AM, Charlie X. Liu wrote: > > 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

Re: [Live-devel] Regarding getting H264

On Wed, Apr 21, 2010 at 7:12 AM, Nilesh Kuber 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

[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::handleAlternativeRequestByt

Re: [Live-devel] XVid + Live555

On Fri, Apr 16, 2010 at 1:04 AM, Clemens Arth 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

Re: [Live-devel] SegmentQueue::enqueueNewSegment() overflow

On Thu, Apr 15, 2010 at 3:13 AM, wrote: > > 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 t

Re: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...

On Fri, Apr 2, 2010 at 1:10 AM, Ross Finlayson wrote: > 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

Re: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...

On Thu, Apr 1, 2010 at 7:06 PM, Ross Finlayson wrote: > 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. >> > > Thi

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 wrote: > I doubt you could do anything to get ms

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

Re: [Live-devel] Detecting network failure

On Wed, Mar 24, 2010 at 5:00 PM, Ross Finlayson wrote > 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 > gen

Re: [Live-devel] Detecting network failure

On Wed, Mar 24, 2010 at 2:45 PM, Ross Finlayson 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 fu

Re: [Live-devel] Detecting network failure

On Mon, Mar 22, 2010 at 6:35 PM, Ross Finlayson wrote: > 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 "ANNOUN

Re: [Live-devel] Form hang when running live555MediaServer

On Mon, Mar 22, 2010 at 6:30 PM, steven choong wrote: > > > 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: > > pu

Re: [Live-devel] Detecting network failure

On Mon, Mar 22, 2010 at 11:46 AM, Ross Finlayson wrote: > 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 go

Re: [Live-devel] Detecting network failure

On Mon, Mar 22, 2010 at 11:43 AM, Roberts, Randy wrote: > 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 ha

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 time

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

Re: [Live-devel] H264 Unicast SPS Packet

On Mon, Mar 15, 2010 at 1:54 AM, Miguel Angel Arcos wrote: > 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 whe

Re: [Live-devel] liveMediaServer in production env

On Tue, Mar 16, 2010 at 4:47 AM, Glen Gray 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

Re: [Live-devel] New LIVE555 release - fixes RTP-over-TCP RTSP commandbug

On Sun, Mar 14, 2010 at 6:36 PM, Ross Finlayson wrote: > 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 u

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

On Fri, Mar 12, 2010 at 10:39 PM, Ross Finlayson wrote: > I'm currently modifying the "RTPInterface" code (to fix the longstanding > failing-to-receive-RTSP-commands-when-RTP-over-TCP-is-used bug). As part of > these modifications, I'm removing the "RTPOverTCP_OK" hack altogether, > because its u

[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

Re: [Live-devel] Fix for a possible buffer overflow in SDESItem

On Thu, Mar 11, 2010 at 9:16 AM, Doug Porter wrote: > Jeremy Noring writes: > > > > 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

Re: [Live-devel] Fix for a possible buffer overflow in SDESItem

On Thu, Mar 11, 2010 at 8:43 AM, Jeremy Noring 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

[Live-devel] Fix for a possible buffer overflow in SDESItem

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 bo

Re: [Live-devel] Possible arithmetic overflow?

On Wed, Mar 10, 2010 at 3:11 PM, Doug Porter wrote: > Jeremy Noring writes: > > > > In RTPSink.cpp, > > > > unsigned lastReceivedTimeNTP > > = (unsigned)((lastReceivedTimeNTP_high<<16) + fractionalPart + 0.5); > > > > A 32-bit v

Re: [Live-devel] Possible arithmetic overflow?

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 wrote: > In > ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mail

[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] 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 : > // Ke

Re: [Live-devel] openRTSP and corrupt streams

On Fri, Feb 12, 2010 at 1:03 AM, Brenner Rene wrote: > Hello all > > I would like to record with openRTSP a stream from a h264 camera for a > certain amount of time say 5 minutes. Now when I hard-switch off the system > I assume the stream end is corrupt. Is there a tool or library which scans > t

Re: [Live-devel] Really blocking?

2010/2/11 Němec Alexandr > So was I. > I also made the RTSP server unavailable by disconnecting the cable from the > *server*, so the client's network interface was running ok. Moreover, I also > made my tests on Windows, so I think test conditions are the same. I now > made 20 trials of disconne

Re: [Live-devel] Really blocking?

2010/2/10 Němec Alexandr > 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 bec

Re: [Live-devel] playback only working to localhost

On Sat, Feb 6, 2010 at 11:34 AM, Tom Pepper 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

Re: [Live-devel] playback only working to localhost

On Sat, Feb 6, 2010 at 10:39 AM, Tom Pepper 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 sho

Re: [Live-devel] Fix for deadlock

On Wed, Feb 3, 2010 at 6:48 PM, Ross Finlayson wrote: > 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 > (block

[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(), fNextTCPReadStreamSo

Re: [Live-devel] WM-DRM

On Tue, Feb 2, 2010 at 8:39 AM, ziyad sharafudheen wrote: > 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

[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: Bi

Re: [Live-devel] H264 H264VideoRTPSource

On Mon, Jan 25, 2010 at 3:25 AM, Miguel Angel Arcos wrote: > 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

Re: [Live-devel] Blocking socket

On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson wrote: > 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 ev

Re: [Live-devel] Blocking socket

2010/1/16 Němec Alexandr > 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 ba

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

Re: [Live-devel] live555 and VLC question

2010/1/8 Němec Alexandr > 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

Re: [Live-devel] openRTSP 2x

2009/12/20 Němec Alexandr > 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 st

Re: [Live-devel] QOS message of live555 ?

On Sun, Dec 20, 2009 at 3:01 AM, Kevin.Liu 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

Re: [Live-devel] Shared memory

On Fri, Dec 18, 2009 at 4:36 AM, gabrieledel...@libero.it < gabrieledel...@libero.it> wrote: > Hi, > I have implemented a client RTSP that record the stream in 2 buffer files. > > So I have implemented a server RTSP that read from the buffer files. > > I want > know if it's possible create a wrapp

Re: [Live-devel] Slow connection problem with RTP over RTSP/TCP

On Thu, Nov 19, 2009 at 2:31 AM, Ross Finlayson wrote: > 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 >> workin

Re: [Live-devel] problem (?) when outputting raw H264 stream with openRTSP

On Fri, Nov 13, 2009 at 8:30 AM, Alberto Alberici wrote: > > 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

Re: [Live-devel] an architecture question of livemedia server

On Wed, Oct 21, 2009 at 10:10 AM, Tao Wu 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 ex

Re: [Live-devel] Stack overflow in QuickTimeFileSink

On Tue, Oct 6, 2009 at 12:55 AM, Sébastien Escudier wrote: > Quoting Ross Finlayson : > > > >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 un

  1   2   >