> I have an RTSP server application that uses a woefully out-of-date version of
> live555. I’m in the process of updating to the latest version of live555 and
> have come across an API change that puzzles me.
>
> Basically, I have a thread that generates H.264 video and feeds it through a
> pipe to a ByteStreamFileSource instance in the RTSP thread. The
> ByteStreamFileSource instance is created by an OnDemandServerMediaSubsession
> subclass that passes the pipe’s read file descriptor into the
> ByteStreamFileSource through its createNew() function. ByteStreamFileSource
> used to have a constructor and createNew() parameter called deleteFidOnClose
> that let me manage the file descriptor. That parameter has now gone away and
> the ByteStreamFileSource instance closes the file descriptor in its
> desctructor.
>
> Because of this change, when a DESCRIBE message is received and a temporary
> OnDemandServerMediaSubsession subclass object (and thus ByteStreamFileSource
> object) is created and destroyed, it ends up closing the read end of my pipe.
> This means that when the actual objects are created after the SETUP message,
> my other thread gets broken pipe errors when it tries to write to the pipe.
I forget the specific motivation behind this API change (which occurred back in
2011), but I suspect it had to do with wanting to make sure that open files are
never left lying around once the “ByteStreamFileSource” object is closed.
> I’m able to get around this by checking for a clientSessionId of 0 in my
> SubclassOnDemandServerMediaSubsession::createNewStreamSource() function. In
> this case I don’t use the real file descriptor, but this seems like a hack to
> me. Is there a better way to prevent my file descriptor from getting closed
> before I want it to?
Not that I can tell, because closing the “ByteStreamFileSource” object now
always closes the fid. (Again, I’m not sure why the “deleteFidOnClose”
parameter got removed, but there must have been a good reason for this at the
time :-)
An alternative would be for you to actually handle the ‘broken pipe’ signal in
your other thread, by tearing down its end of the pipe. (And, then, you’d get
to create the pipe a second time, for the ‘real’ (i.e. “clientSessionId != 0”)
stream.) In fact, you probably want to do this signal handling anyway, to
handle the case when the ‘real’ stream gets closed - e.g., if your last RTSP
client does a RTSP “TEARDOWN” on it. Since you need to do this anyway, you
might as well do it also for the “clientSessionId == 0” case, if it’s not too
inefficient to do so.
As an aside, you could, if you wish, eliminate the ‘broken pipe’ signal by
calling our
ignoreSigPipeOnSocket() (defined in
“groupsock/include/GroupsockHelper.hh”)
function on the socket (i.e., at the LIVE555-thread end of the pipe). But in
your case, you probably don’t want to do this, unless you have some other way
of telling your non-LIVE555 thread that it needs to close its end of the pipe.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
