[Live-devel] HTTP Live Streaming

Pak Man Chan parkchan1960 at gmail.com
Thu Oct 24 01:53:12 PDT 2013


On Thu, Oct 24, 2013 at 2:51 PM, Ross Finlayson <finlayson at live555.com>wrote:

> 1. Replies to HTTP GET requests are sometime truncated. As an example,
> curl http://serverip/somets.ts will sometimes result in only part of the
> playlist
>
>     I've traced this to fNumBytesToStream is not being initialized when
> created in handleHTTPCmd_StreamingGET, this caused doGetNextFrame to
> sometimes ended prematurely.
>
>
> Are you sure??  If you are referring to the "fNumBytesToStream" variable
> in the "ByteStreamMemoryBufferSource" class, then note that this variable
> is checked only if "fLimitNumBytesToStream" is set, and in that case
> "fNumBytesToStream" will always be set (see
> "ByteStreamMemoryBufferSource.cpp", line 55).
>
> I'm not saying that there can't be a bug in this code, but if there is, I
> don't think it's what you're describing.
>
>
I missed the check on "fLimitNumBytesToStream". In this case, should
"fLimitNumBytesToStream"  be initialized to False? It is some non-zero
value when testing the code.


> 2. When streaming is in progress and client disconnected in the middle of
> a transfer, mediaServer will keep trying sending to the disconnected client
> in TCPStreamSink::processBuffer and will not respond to further requests.
>
>
> I don't see how that can happen, because the socket is non-blocking.  If
> the client disconnects, then the call to "send()" should return (with less
> than the expected number of bytes written).  At that point, the server
> won't try "send()"ing to the socket again until it becomes writable again
> (which won't ever happen if the client has disconnected).
>
>
Thanks for the clarifications, I've looked further and found that send() is
returning -1, with errno being set to EPIPE. The problem is in "select" in
BasicTaskScheduler::SingleStep still indicating a writable socket even when
it is disconnected. Is this a libc problem? I'm working on Fedora 17 if
that matters.


Thank you.
Park.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131024/ceca9591/attachment.html>


More information about the live-devel mailing list