[Live-devel] ByteStreamFileSource closing pipe file descriptor

[Ross Finlayson]

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

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