[vlc] Re: New Streaming Problem

[Les LaZar]

Ah, a ray of hope.  Could you please be more specific?  Exactly what vlc
commands must I enter on the server side and the client side to accomplish
this?

As a reminder, my system consists of two Via C3 1GHz processors with 256MB
ram connected to each other over a 100MBs ethernet LAN.  There are no other
systems contending for LAN bandwidth.  Video input is from a Win TV Go card
(bt878) that is supported by v4l.  Output is through the integrated video
controller on the Via EPIA MB (CLE266) using the generic VESA driver under
Fedora Core 1.

Thanks for any suggestions.  It wold be a big plus if this would work with
the C3's.

Les

----- Original Message ----- 
From: "Paul Rae" <PRae at aminocom.com>
To: <vlc at videolan.org>
Sent: Thursday, March 25, 2004 7:58 AM
Subject: [vlc] Re: New Streaming Problem


> Your problem is your trying to transcore the stream, you dont stand a
chance of doing that on the via hardware.
>
> Stream the raw mpeg, things should work then
>
> -----Original Message----- 
> From: vlc-bounce at videolan.org on behalf of Les LaZar
> Sent: Wed 3/24/2004 3:04 PM
> To: vlc at videolan.org
> Cc:
> Subject: [vlc] Re: New Streaming Problem
>
>
>
>
> ----- Original Message -----
> From: "Benjamin PRACHT" <bigben at via.ecp.fr>
> To: <vlc at videolan.org>
> Sent: Wednesday, March 24, 2004 1:19 AM
> Subject: [vlc] Re: New Streaming Problem>>
> >>[00000203] access_output_udp private debug: packet has been sent too
late
> (234051)
>
>
>
> > What is the server ? That could ba a lack of CPU power...
>
> It does indeed appear to be a processing speed issue.  The original
> server-side command, copied from the HOWTO, included the parameter
> ":size=640x480".  In this case, while a 640x480 window was indeed opened
on
> the client side, only the top portion of the camera image was displayed.
> The remainder of the window displayed a block or two of solid color.
> Leaving the size parameter out of the server-side command caused the image
> size to default to a smaller value (320x240 I believe).  Only in this case
> did I get a single complete frame from the server displayed on the client.
>
> The server and client are both 1GHz Via C3 processors running Fedora Core
1.
> Each system has 256MB ram.  Currently I have not patched the video display
> drivers on either end to optimize for the Via EPIA integrated video, so
the
> generic VESA driver is being used.  When running in local mode (vlc -vvv
> v4l:/dev/video0:norm=ntsc:channel=1) the video image is displayed OK with
> some latency (500-600ms) and a less than 30fps frame rate apparently.
>
> I presumed I could change the bit rate parameters in the vlc command to
> reduce the data rate, but my initial experiments yielded no postive
> change....so I am back to seeking expert advice.
>
> I was under the impression that 1GHz CPU speeds should be sufficient for
> streaming a single video/audio channel at decent quality.
>
> Thanks,
>
> Les
>
> >
> > --
> > $(echo "BigBen")
> >
> > Oui je quote, et alors ?
> >
> > --
> > This is the vlc mailing-list, see http://www.videolan.org/vlc/
> > To unsubscribe, please read http://www.videolan.org/support/lists.html
> > If you are in trouble, please contact <postmaster at videolan.org>
> >
> >
>
>
> --
> This is the vlc mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://www.videolan.org/support/lists.html
> If you are in trouble, please contact <postmaster at videolan.org>
>
>
>
>   ɚXb y m 0 zZ+ s {.n +W i m 0 zZ+ .+b  ! {k {ey
r i --z
>
>


-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html
If you are in trouble, please contact <postmaster at videolan.org>