Archived from groups: alt.comp.periphs.webcam (
More info?)
On Wed, 13 Oct 2004 16:03:50 -0400, "Thom" <Thom@no.invalid>
wrote:
>Si Ballenger <shb*NO*SPAM*@comporium.net> wrote:
>
>> On Wed, 13 Oct 2004 13:21:01 -0400, "Thom" <Thom@no.invalid>
>> wrote:
>
>>>As an aside? I'm wondering why you're using "server push", as
>>>opposed to "client pull", especially since you keep mentioning the
>>>word video.
>>>
>>>Anyone and everyone please correct me if I'm wrong, but I am under the
>>>assumption that allowing the client to "pull" the video (streaming or
>>>otherwise) is much more reliable and resource-saving than "pushing"
>>>it.
>
>> Not a good assumption. There is very little difference between
>> the push and pull operation. Push may be a little faster and more
>> efficient than pull. Push sets a constant connection between the
>> server client. Pull has to open and close the connection for each
>> frame sent.
>
>Even for streaming video? My cam for instance. Are you saying that since
>I'm allowing people to "pull" the stream, that they are opening and closing
>a connection every 1/8th of a second given that I'm "sending" at about 8fps?
>Not saying you're wrong. Just saying my logs don't support that theory, and
>I don't understand.
If you are talknig about MS media encoder and media player, then
the connection is not necessarly an http based web connection.
They are specialized server/client applications that aren't using
http protocal to transfer data. It is probably more similar to a
java based "push" webcam setup than a "pull", where the
connection between the applications is kept open. Normal "web"
pages don't maintain a connection between the web server and the
web brouser after the page is downloaded. Be sure you understand
just what constitutes a "frame" in your particular application.
Various compression schemes only send the pixels that have
changed from the previous captured frame by a certian amount,
making for less data sent and faster "frame rates", but giving
the video a bit of waveyness. Media encoder and ivista use this
type of compression. Applications like webcam32 capture a frame,
jpg compress the whole frame, and send it to the brouser. The
"frame rate" is slower and blockier, but generally each frame is
clearer.
>>>When you set up to "push" video, you're sending the info whether
>>>anybody's looking at it or not, right?
>>
>> Wrong, ftp is what sends data when nobody is watching. Push/pull
>> only sends data when a client is watching.
>
>OK. Then, if you'd be so kind? Please explain. You say "Push/pull" as
>though they amount to the same thing. The webcamworld website
>www.webcamworld.com begs to differ. And I quote:
>----------------
>Client pull:
>
>This method is the most used by WebCam users to show single snapshots of
>whatever the WebCam points to. It is the most easy method to set up, and the
>one that works perfectly for dial-up style Internet connections. It also
>won't take much bandwith from your connection, so you're still able to surf
>the Web, get e-mail, IRCing and many more things while your WebCam snaps
>shots. Thus, you won't be able to serve video feeds with this method.
>
>This method is usually accomplished with an FTP connection that sends the
>last shot captured by the WebCam to your ISP's hard drive or site hosting
>your web pages.
Note that webcamworld above is talking about using a dialin
connection to the net. Below is one of my server pull test pages
on a cable connection. See if it supplys a video feed. The java
in the web page request a new image as soon as one is downloaded,
similar to clicking the page reload button on your brouser.
http://www.geocities.com/zoomkat/wc2000.htm
>Server push:
>
>This is the most resource-consuming method, and thus, the least implemented.
>But it is also the most live method, as it will allow the users to view
>real-time video streams coming directly from your WebCam. It has its obvious
>limitations; to mention some:
>
>a.. It requires a high bandwith connection to be at least a bit live.
>b.. You must put a limit to the video stream for each user connecting to it.
>c.. A dial-up connection is almost useless to apply this method.
>d.. Firewall based networks can have limited the access to this kind of
>method.
>e. Only the most recent browser versions support Server push
>-------------
>
>>>When you set up to "pull" video, that means there's not much going on
>>>(bandwidth-wise) unless someone makes a connection, no?
>>
>> True, but the same is true for push.
>
>That's not the way I understand the above. And again. I'm not saying
>you're wrong. I'm just saying I don't follow you. Perhaps the information
>above is outdated?
The info does seem to be somewhat dated and simplified. The below
test page uses the server push setup. As I understand it, the
http connection is maintained and the java applet has the server
send another frame as soon as the previously sent one is
downloaded.
http://www.geocities.com/zoomkat/ezservo1.htm
Facebook
Twitter
Instagram