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

temp2010 at forren.org temp2010 at forren.org
Sat Feb 23 03:00:40 PST 2013


Ross,

Thanks.

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.

...

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.

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.

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).

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

On Fri, Feb 22, 2013 at 5:31 AM, Ross Finlayson <finlayson at live555.com>wrote:

> 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.
>
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130223/4fdcfc54/attachment.html>


More information about the live-devel mailing list