Ross,<div><br></div><div>Thanks.</div><div><br></div><div>We got it working. You are correct about the bursty transmission. I'll add your buffering comment to our work task list, to keep it in mind for when we may need it in the future.</div>
<div><br></div><div>...</div><div><br></div><div>To assist others in figuring out their own problems, I'll mention that my remote associate on the actual hardware finally pointed out that the iPad was processing random frame counts per second, not always 30. This led to noticing a debug message output stream available from VLC, that was frequently claiming "picture is too late to be displayed (missing ???ms)", where "???ms" varied from 30ms to 300ms. The iPad random frame counts and the VLC too late messages didn't occur when using File as File. So this was the smoking gun. It was also repeatable for me locally.</div>
<div><br></div><div>We found that running out of processor horsepower was the cause. We stripped a bunch of temporary stuff out of the program, including three unused potential stream connections from OnDemand..., plus compiled in Release mode rather than Debug mode (VS2012). An additional cause was the amount of memory given to the pipe. Increasing it from 4K to 300K was also necessary. This is Windows 7 and we have no choice about it. Fortunately, it is working well now. Note that the File as Pipe case uses more horsepower because of the real activity feeding the pipe, activity that's not consuming horsepower in the File as File case.</div>
<div><br></div><div>Regarding buffering, we need to run as short a latency as possible, so I'm hesitant to bump up the buffering in the iPad (software my remote associate wrote, not me, although I have iOS programming experience).</div>
<div><br></div><div>So, in terms of my original post, (#1) it must be that VLC handles the bursty data better than the iPad, very likely related to buffering, and (#2) the difference in what Live555 sends was about info being late due to insufficient horsepower<br>
<br><div class="gmail_quote">On Fri, Feb 22, 2013 at 5:31 AM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><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>
</blockquote><div><br></div></div>No, the difference is not the frames' presentation times, because they are derived from the input H.264 data, which should be the same in both cases.</div><div><br></div><div>The difference is likely that reads from the pipe - and thus transmissions over the network - are not happening smoothly. I.e., you are probably reading a large chunk of data from the pipe, then waiting a long time (for more data to become available in the pipe), then reading a large chunk of data from the pipe, etc. Because of these 'bursty' reads from the pipe, network transmission (of RTP packets) is also happening in a 'bursty' fashion.</div>
<div><br></div><div>Your receiving application *should* be able to handle this OK, if it does reasonable buffering of incoming data (i.e., data that has just been read from the "RTPSource" object). But the fact that it's not handling this OK (but VLC does) suggests that your receiving player (on the iPad) is not buffering incoming data enough before decoding/rendering it. That is the first thing that you should fix (because bursty/jittery data can happen in many environments).</div>
<div><br></div><div>However, you should also fix whatever is causing reads from your pipe (i.e., on your server) to be so bursty. Because I don't know anything about your server OS, I can't help you here. But if you are running Windows (which often has a notoriously coarse process-switching granularity), then please stop. In this day and age, Windows is simply not a serious OS for running server applications.</div>
<span class="HOEnZb"><font color="#888888"><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">Ross Finlayson<br>
Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span>
</div>
<br></font></span></div><br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br></div>