[streaming] Re: Problems streaming certain MPEGS [ComputerAssets#42]

[Jesse Burson]

> -----Original Message-----
> From: Jean-Paul Saman [mailto:jean-paul.saman at planet.nl] 
> Sent: Tuesday, October 07, 2003 1:49 PM
> To: streaming at videolan.org
> Subject: [streaming] Re: Problems streaming certain MPEGS 
> [ComputerAssets#42]
> 
> 
> Jesse Burson wrote:
> 
> What vlc commandline options do you use?

I've been using the wxwindows GUI, but the command line equivalent would
be

--sout '#std{access=udp,url=225.1.1.1:2001}'

That's it; I'm not doing anything else.  I'm running VLC the same way
for the files that work and the files that don't.
I've just tested the CLI to be sure that the GUI wasn't doing anything I
didn't know about.  Within a couple of seconds, ~1000 UDP packets sent
to 225.1.1.1:2001 by the multicasting machine were picked up by one of
the clients.

> Do you use the --ttl 2 commandline option of vlc?

No.  But all machines are directly connected to the switch; shouldn't a
TTL of 1 suffice in that case?  And even if not, why would the switch
receive some files and not others if the problem were caused by TTL?  In
other words, why would VLC potentially decrement the TTL of a packet
*depending on the file*?  (is it even possible, with the network stack
of a normal PC OS, to have a packet not get to its first hop due to
TTL?)

> Are all the video files encoded in the same manner? 

I doubt it.  The ones that don't work are random test files from the
Internet.  VLC does play them all locally, and it uses its MPEG decoder
to do so.

> Could you 
> send a log 
> from VLC's output for one of the succeeding files and one of 
> the failing 
> files, please.

Absolutely (sent in private email).  Thank you.

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