Hi,
Have been seeing some errors, where if a timeout occurs in getNextFrame, the
next getNextFrame call will result in an abort() call (due to
fIsCurrentlyAwaitingData being set).
What is the proper behavior in this case:
1) Don’t call getNextFrame again, this source is tainted (don’t believe this is
the case, since timeout may be set to an arbitrary short time).
2) Call stopGettingFrames() to clear the state (this seems like a winner, but I
can’t find any confirmation in the docs).
3) It’s a bug, getNextFrame should clean its state before exiting (maybe?!)
4) Something else that I’ve missed?
Thanks for your help and for the impressive protocol stack!
Z.
—
Sent from Mailbox
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel