hi, i am a newbie. and i don't know how to multicast video using vcl.
I tried it in school, we are lan network here.
i choose open a local file, and stream it on a udp 219.224.141.88:1234 output. (my ip is just 219.224.140.88, i wrong here? )
i use a vcl on my classmates' computer whose ip is 219.224.141.87, i choose retrive udp from 219.224.140.88:1234.
but nothing happened, who warmhearted can tell me what's wrong i made?
thank you for read this and i am sorry about my poor english.
i appriciat you very much if u can understand what i am saying:)
i didn't write things of English for such a long time
How to do a multicast? thank you!
If you want to multicast, on the server you need to type in a multicast address in the space next to "UDP". You do not need to actually change the PC's IP address -- multicast addresses act like TV or radio frequencies, general-use addresses.
Try typing in 239.20.30.40 (port 1234 is fine).
On your friend's PC, select Open Network Stream, then UDP multicast, and type in 239.20.30.40 in the address field (again, port 1234 is OK).
The other general streaming method is point-to-point. If you just want to send from your Server PC to your friend's PC, on the server type in your friend's address in the space next to UDP (e.g., type in 219.224.141.87). Then, on your friend's PC, select the first UDP option -- the one with no address field next to it, click OK, and he/she should be connected. (when receiving a stream, the first option is specifically there for point-to-point mode, where the server is targeting the client's IP address)
Multicast is something you might want to avoid, unless you have a good idea of how it works. It sends packets everywhere, unless network administrators have put in blocks. The point-to-point stream only opens a connection between the server and the specific, intended, client.
Try typing in 239.20.30.40 (port 1234 is fine).
On your friend's PC, select Open Network Stream, then UDP multicast, and type in 239.20.30.40 in the address field (again, port 1234 is OK).
The other general streaming method is point-to-point. If you just want to send from your Server PC to your friend's PC, on the server type in your friend's address in the space next to UDP (e.g., type in 219.224.141.87). Then, on your friend's PC, select the first UDP option -- the one with no address field next to it, click OK, and he/she should be connected. (when receiving a stream, the first option is specifically there for point-to-point mode, where the server is targeting the client's IP address)
Multicast is something you might want to avoid, unless you have a good idea of how it works. It sends packets everywhere, unless network administrators have put in blocks. The point-to-point stream only opens a connection between the server and the specific, intended, client.
Thank you very much for your kind answer!
Can you tell me why choose the multicast address 239.20.30.40?
Does it have relationship with my ip?
If I choose to multicast to 239.20.30.40, which range of the ip can receive the video stream?
If I am in another lan area, ip as 10.0.0.xx which multicast address should I output to?
Thank you!
Can you tell me why choose the multicast address 239.20.30.40?
Does it have relationship with my ip?
If I choose to multicast to 239.20.30.40, which range of the ip can receive the video stream?
If I am in another lan area, ip as 10.0.0.xx which multicast address should I output to?
Thank you!
http://www.cisco.com/univercd/cc/td/doc ... tm#xtocid1
Gives some background information on multicast addresses and how it works. From it: "all IP multicast group addresses will fall in the range of 224.0.0.0 to 239.255.255.255" They act as "party lines" -- any number of PCs can listen in to the data being transmitted by a server on one of those addresses. There are certain addresses reserved for special things in that address range, as noted in the Cisco document.
Also, from the Cisco document:
"The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so those local multicast boundaries can be defined. This also allows for address reuse among these smaller domains. "
In other words the 239.x addresses are generally the "right" ones to use for local multicast activities. 239.20.30.40 is a random choice by me -- I know it's in the proper range of multicast addresses.
Generally, PCs "know" about the multicast addresses, that they are okay to listen to, if commanded. For instance, where I work we are on a 144.219.x.y network segment -- I can still listen to a 239.20.30.40 multicast (assuming anyone is serving data on that address in my office LAN).
So, even though I am on a 144.219.x.y LAN segment, and my own PC has an IP address of 144.219.whatever, if I want to multicast I would send the data out on an address between 220.x.x.x and 239.x.x.x, because those are the official multicast addresses. Other PCs on the LAN, with IP addresses in the 144.219.x.x range, would be able to "tune in" to data being served by me.
If it's "another LAN area", meaning something that is distant from where the server PC is located, you would need routers or other devices connecting the LAN segment where your PC is located with the other, client, PCs. You would then need to have UDP multicast enabled on the routers in the middle.
You cannot UDP multicast stream over the Internet itself (should not try to) -- ISPs generally have UDP multicast streaming turned off, so that millions of people don't all try to flood the limited number of multicast addresses with their home Webcams. That's where point-to-point comes into play, specifically sending the UDP stream to an intended, single, client -- this is the version where you would actually plug your friend's IP address into the UDP address field on your VLC server.
Note, VLC can actually use point-to-point UDP for multiple clients -- look at the VLC documentation for how to start up a stream to several individual IP addresses at the same time.
Gives some background information on multicast addresses and how it works. From it: "all IP multicast group addresses will fall in the range of 224.0.0.0 to 239.255.255.255" They act as "party lines" -- any number of PCs can listen in to the data being transmitted by a server on one of those addresses. There are certain addresses reserved for special things in that address range, as noted in the Cisco document.
Also, from the Cisco document:
"The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so those local multicast boundaries can be defined. This also allows for address reuse among these smaller domains. "
In other words the 239.x addresses are generally the "right" ones to use for local multicast activities. 239.20.30.40 is a random choice by me -- I know it's in the proper range of multicast addresses.
Generally, PCs "know" about the multicast addresses, that they are okay to listen to, if commanded. For instance, where I work we are on a 144.219.x.y network segment -- I can still listen to a 239.20.30.40 multicast (assuming anyone is serving data on that address in my office LAN).
So, even though I am on a 144.219.x.y LAN segment, and my own PC has an IP address of 144.219.whatever, if I want to multicast I would send the data out on an address between 220.x.x.x and 239.x.x.x, because those are the official multicast addresses. Other PCs on the LAN, with IP addresses in the 144.219.x.x range, would be able to "tune in" to data being served by me.
If it's "another LAN area", meaning something that is distant from where the server PC is located, you would need routers or other devices connecting the LAN segment where your PC is located with the other, client, PCs. You would then need to have UDP multicast enabled on the routers in the middle.
You cannot UDP multicast stream over the Internet itself (should not try to) -- ISPs generally have UDP multicast streaming turned off, so that millions of people don't all try to flood the limited number of multicast addresses with their home Webcams. That's where point-to-point comes into play, specifically sending the UDP stream to an intended, single, client -- this is the version where you would actually plug your friend's IP address into the UDP address field on your VLC server.
Note, VLC can actually use point-to-point UDP for multiple clients -- look at the VLC documentation for how to start up a stream to several individual IP addresses at the same time.
-
vik
multicast
I'm trying the windows based VLC and hopefully if I get some results I'm gonna try seriously to multicast several TV channels through a 100Mbits fast ehernet in a campus LAN.
The matter is that although I can effectively capture TV progrmas and then see them on my own PC there is no way to multicast them out.
I tried the debbuger and It just says:
main private error Cannot add this stream
main packetizer error cannot create packetizer output
main private error cannot add this stream
main packetizer error cannot create packetizer output
No matter which options, address,method,port or format of the stream.
I tried also sending a file instead a capture and it ain't work either.
Does anyone think it is a problem related to the operating system? the TCP/IP stack?
Thanks
The matter is that although I can effectively capture TV progrmas and then see them on my own PC there is no way to multicast them out.
I tried the debbuger and It just says:
main private error Cannot add this stream
main packetizer error cannot create packetizer output
main private error cannot add this stream
main packetizer error cannot create packetizer output
No matter which options, address,method,port or format of the stream.
I tried also sending a file instead a capture and it ain't work either.
Does anyone think it is a problem related to the operating system? the TCP/IP stack?
Thanks
-
Guest
me too
hi!
I'm trying to do the same, I'm trying to multicast a TV channel throught a LAN in a campi. but I need to make a diferent schedule and I had some problems with dinamic programation of the schedule, it need to be simple for a person add and remove the movies from the schedule.
can anyone send-me a mail? (contavac (at) hotmail (dot) com) I'm working whith GNU/linux (vlc or vls I didn't resolved yet) server and a lot of vlc (windows and linux) clients.
thanks.
I'm trying to do the same, I'm trying to multicast a TV channel throught a LAN in a campi. but I need to make a diferent schedule and I had some problems with dinamic programation of the schedule, it need to be simple for a person add and remove the movies from the schedule.
can anyone send-me a mail? (contavac (at) hotmail (dot) com) I'm working whith GNU/linux (vlc or vls I didn't resolved yet) server and a lot of vlc (windows and linux) clients.
thanks.
Vik --
" I can effectively capture TV progrmas and then see them on my own PC" Do you mean that you can do a local "play", using VLC to view the audio and video? If yes, you're really close.
Have you selected Transcoding Options? You have to do that, in order to get the "raw" directshow input from your TV tuner into a packet format that can be sent over Ethernet. The defaults are fine if you have decent BW, just make sure you check both the Video and Audio boxes down in the bottom of Step 2 of the Streaming Wizard.
For purely test purposes, you can open two sessions on your local PC, one doing the serving, the other doing the receiving.
"on a campus LAN". You may be running into a classic problem where the LAN routers have been configured to not pass multicast address (those in the 224.0.x.x to 239.255.x.x address space). Either try what I mention in the preceding paragraph, else try setting up a second PC right next to the Server, physically connected to the same switch (I use little cheapo switches for test purposes), see if it's working OK in that environment.
The above paragraph applies where I work, a multi-building "campus" with 100Base-T and fiber between buildings -- the edge routers between buildings do not pass multicast. Actually, where I work we use enterprise-grade managed switches -- the actual switches are set to block multicast.
(you need buy-in from network administrators to do multicast -- they like to make sure that only approved things are done with their gear)
" I can effectively capture TV progrmas and then see them on my own PC" Do you mean that you can do a local "play", using VLC to view the audio and video? If yes, you're really close.
Have you selected Transcoding Options? You have to do that, in order to get the "raw" directshow input from your TV tuner into a packet format that can be sent over Ethernet. The defaults are fine if you have decent BW, just make sure you check both the Video and Audio boxes down in the bottom of Step 2 of the Streaming Wizard.
For purely test purposes, you can open two sessions on your local PC, one doing the serving, the other doing the receiving.
"on a campus LAN". You may be running into a classic problem where the LAN routers have been configured to not pass multicast address (those in the 224.0.x.x to 239.255.x.x address space). Either try what I mention in the preceding paragraph, else try setting up a second PC right next to the Server, physically connected to the same switch (I use little cheapo switches for test purposes), see if it's working OK in that environment.
The above paragraph applies where I work, a multi-building "campus" with 100Base-T and fiber between buildings -- the edge routers between buildings do not pass multicast. Actually, where I work we use enterprise-grade managed switches -- the actual switches are set to block multicast.
(you need buy-in from network administrators to do multicast -- they like to make sure that only approved things are done with their gear)
-
Frater Kork
- Blank Cone
- Posts: 41
- Joined: 20 Feb 2004 00:52
The buy-in is pretty simple if you are the network admin 
I am working on getting VLC up and running as a distributed broadcast solution in my WAN/LAN environment as well.
However, in order to keep some degree of control over the streams going through my WAN routers i have decided to run unicast(udp) transports from the main video server to VLC relays sitting in each major LAN.
All the relays do is basically listening to one UDP port and streaming the content to a local multicast address, no transcoding or anything, so I can have pretty old machines just echoing data.
The Video server is another story... Transcoding eats a lot of CPU, especially if the source is DVD or DV cam.
Scheduling is quite primitive yet, I just use the built in shedule function in Win2K server to call batch files running whatever media is slated to broadcast at that specific time.
Clients PC:s need no VLC install since that is is put on local file server shares, all the users need is a shortcut with a call to the shared vlc.exe and a command line telling it to listen to a specific multicast address...
It works pretty ok, though it is still a bit flaky and the clients take some time to start up. Wonder if there ever will be a VLS for win32?
Lots of trivial problems that need straightening out until it becomes a proper service, like how the hell do I tell the streaming VLC app to close once the media is done? Or after a specific time?
Anyway, Its a wonderful *FREE* app that beats the pants off anything offered by gigants like Microsoft and Cisco.
Cheers Mates!
I am working on getting VLC up and running as a distributed broadcast solution in my WAN/LAN environment as well.
However, in order to keep some degree of control over the streams going through my WAN routers i have decided to run unicast(udp) transports from the main video server to VLC relays sitting in each major LAN.
All the relays do is basically listening to one UDP port and streaming the content to a local multicast address, no transcoding or anything, so I can have pretty old machines just echoing data.
The Video server is another story... Transcoding eats a lot of CPU, especially if the source is DVD or DV cam.
Scheduling is quite primitive yet, I just use the built in shedule function in Win2K server to call batch files running whatever media is slated to broadcast at that specific time.
Clients PC:s need no VLC install since that is is put on local file server shares, all the users need is a shortcut with a call to the shared vlc.exe and a command line telling it to listen to a specific multicast address...
It works pretty ok, though it is still a bit flaky and the clients take some time to start up. Wonder if there ever will be a VLS for win32?
Lots of trivial problems that need straightening out until it becomes a proper service, like how the hell do I tell the streaming VLC app to close once the media is done? Or after a specific time?
Anyway, Its a wonderful *FREE* app that beats the pants off anything offered by gigants like Microsoft and Cisco.
Cheers Mates!
Frater --
For what you describe, given that you're network and Win2K Scheduler savvy, you could create multiple copies of the top-level vlc.exe program on the server -- call them vlc1.exe, vlc2.exe, vlc3.exe...
Use a separate copy for each of the streams that you want to send, vlc1.exe launching video 1, vlc2.exe launching vlc2.exe,...
Use one of the free process killer apps as a one-line command file, launched off of Scheduler, to kill the individual streams when you want to. Examples apps are process203.zip or the pstools.zip set from sysinternals -- the pskill app of pstools can accept a program name as the input for process-to-kill.
I'm pretty comfortable using the AT command, and frankly the Windows scheduler functionality isn't half bad.
Good luck!
For what you describe, given that you're network and Win2K Scheduler savvy, you could create multiple copies of the top-level vlc.exe program on the server -- call them vlc1.exe, vlc2.exe, vlc3.exe...
Use a separate copy for each of the streams that you want to send, vlc1.exe launching video 1, vlc2.exe launching vlc2.exe,...
Use one of the free process killer apps as a one-line command file, launched off of Scheduler, to kill the individual streams when you want to. Examples apps are process203.zip or the pstools.zip set from sysinternals -- the pskill app of pstools can accept a program name as the input for process-to-kill.
I'm pretty comfortable using the AT command, and frankly the Windows scheduler functionality isn't half bad.
Good luck!
-
Frater Kork
- Blank Cone
- Posts: 41
- Joined: 20 Feb 2004 00:52
Return to “VLC stream-output (sout)”
Who is online
Users browsing this forum: No registered users and 6 guests