We want our PC to send a video stream to an iPad, and we sometimes test by sending to VLC over the local network.<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I'm writing you to ask about #2.  If we can fix #2, then we don't have to fix #1.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So, back to #2, there simply must be some difference in what Live555 sends, between the two cases.</div><div><br></div><div>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.</div>
<div><br></div><div>(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...)</div>
<div><br></div><div>Thanks very much for you help.</div>