[Live-devel] OnDemandRTSPServer working with File as File source but not File as Pipe

[temp2010 at forren.org]

We want our PC to send a video stream to an iPad, and we sometimes test by
sending to VLC over the local network.

The video stream gets into linked-in Live555 code via ByteStreamFileSource,
but in two different ways.  One way is from a file on disk (File as File).
 The other way is through a named pipe (File as Pipe).

Both File as File and File as Pipe look great on VLC over the lan.  But to
the iPad, the File as File looks great but the File as Pipe is very blocky,
as if compression info is missing or whatever.

This tells me two things:  (#1) it seems VLC may be more robust and
forgiving than our iPad app, as expected; and (#2) there's some difference
in what Live555 sends (perhaps presentation time?) depending on whether the
stream came from File as File or File as Pipe.

I'm writing you to ask about #2.  If we can fix #2, then we don't have to
fix #1.

In detail (sorry, but there's no other way for the quick turn we need this
week), Live555 InputFile.cpp already had a hood in it for filename "stdin".
 We tentatively added a hook for "pipe".  Thus, we can easily switch
between File as File (real filename) or File as Pipe (hooked "pipe"
filename). This also means that the ONLY difference in the code base from
this point all the way out to the iPad is this tiny difference.  One would
expect the output and iPad behavior to be the same... but it's not.

Meanwhile, the actual stream being sent INTO the Pipe is simultaneously
written to a raw h.264 file, and on later tests, it's that raw h.264 that's
being read in the File as File case.  Therefore, the content of the stream
in both cases should be indistinguishable.  We tried File as Pipe, and we
got the blockiness.  We then took that very raw h.264 file just written,
and ran again with File as File, and we did NOT get the blockiness.

So, back to #2, there simply must be some difference in what Live555 sends,
between the two cases.

Do you have any clue at all as to what this difference might be, and what
we might do to get rid of it?  My guess is something about presentation
time, but I'm so ignorant on this stuff in general that I don't trust my
own guess.

(Once we figure it out, we can write alternate InputFile.cpp and
ByteStreamFileSourcesource.cpp (and on up the rather long derivation chain)
in order to return InputFile.cpp to it's pre-pipe-hook content.  But it's
too wasteful to do that first, in case this strategy fails to ever work at
all...)

Thanks very much for you help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130221/4df1802a/attachment.html>