Ross,
To answer your earlier question, I get error code 10038 on Windows, and I
suppose 10054 is very possible.
I agree a hook like a virtual function in the UsageEnvironment is a good
solution. And I want to add to the requirement that it could have some
mechanism to communicate where the so
Thanks for the fix. And I will take your advise and use a different
email account when I post a new issue. For the moment, I am running
into another senario of a runaway RTP-over-TCP session, and it is
preventing me from testing your last fix.
The problem is in the SocketDescriptor::tcpRead
I pretty much agree with this. What I'll probably do (in some future
release) is change the calls to "abort()" to some new virtual
function (of the "UsageEnvironment" class) called "internalError()"
(or something). The default implementation of this might still be to
call "abort()", but devel
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
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 in
Hello,
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, ...).
Regards,
John Tam
Hello,
Thanks for the fix. And I will take your advise and use a different email
account when I post a new issue. For the moment, I am running into another
senario of a runaway RTP-over-TCP session, and it is preventing me from testing
your last fix.
The problem is in the SocketDescript
Sorry, But I dont get any information regarding specific src streaming
or api documentation...
Grumble...
http://www.live555.com/liveMedia/faq.html#doc
Also, because you asked about streaming MPEG-4 video, note the
"testMPEG4VideoStreamer" (multicast) and "testOnDemandRTSPServer"
(unicast) d
Sorry, But I dont get any information regarding specific src streaming
or api documentation...
On Sun, 2010-09-05 at 21:41 -0700, Ross Finlayson wrote:
> > I am new to live555. I want to stream my own mpeg4 encoded stream. Is
> >there any api documentation so i can integrate the live 555 libr
