[Live-devel] A lesson learned: Groupsock

Jan Ekholm jan.ekholm at d-pointer.com
Fri May 16 13:25:17 PDT 2014


Hi,

Just wanted to share a small caveat that's been biting me for several days. It's not
a Live555 bug, but something that's easy to do wrong in any kind of application that
is a bit more complex than the sample apps.

Most of the examples that do multicast streaming have this code:

  const unsigned short rtpPortNum = 18888;
  const Port rtpPort(rtpPortNum);
  Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl);
  rtpGroupsock.multicastSendOnly(); // we're a SSM source

This sets up the Groupsock, there's usually some more, but that's irrelevant. Then the
rtpGroupsock instance is used like this:

  videoSink = H264VideoRTPSink::createNew(*env, &rtpGroupsock, 96);

This is all fine as long as control stays in the same method/function until the streaming
is done! In my case I was setting up the sinks in a method and then returning to my main
loop which handled the Live555 loop. What happens here is that rtpGroupsock is a local
variable passed as a pointer to createNew(). We all know what happens when it goes out
of scope. In my case I didn't see any crashes, only "bad file descriptor" errors for days
that had me debugging all kinds of code. It's not particularly clear when Live555 takes
ownership of something or gives it to your code. Smart pointers would be the way to
go here, of course.

Just in case someone googles for "bad file descriptor", this could help.

-- 
Jan Ekholm
jan.ekholm at d-pointer.com






More information about the live-devel mailing list