The VideoLAN Forums

We have an Osprey-450 video capture card. It is capable of providing four independent inputs.

I want to multicast each input on a separate channel. I am currently capturing, transcoding, and multicasting one input stream on a multicast UDP channel via the command-line and this works fine. However, as soon as I try and start a second instance of VLC via the command-line, I get an exception. It appears that VLC is designed to only run one instance.

So my question is, how do I manage four separate capture inputs? I have read the streaming documentation; particularly the part about Multiple Streaming. But that is for taking one input stream and providing it on multiple channels. I have multiple inputs that need to be handled separately. How do I do that?

Hi,

VLC is not limited to one instance, maybe only one process can access your capture card (can be the case on linux if your card exports only one device).
To manage several streams in one instance, the magic word is "VLM", you can search this word on the forum and the wiki for its usage.

So theoretically, I should be able to launch four instances of VLC and manage the four separate capture streams that way, correct?

I'm looking at VLM right now and have it running on my own machine just to see what the web GUI looks like. I'm not quite sure how it solves the problem though, since it requires adding new DTT/Satellites/Streams. I'm having a problem with VCL even giving me more than one stream right now...

Yes, you should be able to use four VLC instances. What says debug output?

NB1: VLM ca be used in command-line too, with a VLM config file if you didn't cross this feature.
NB2: DTT/Satellites/Stream and VCL (maybe a mistakenly written "VLM"?) are unknown to me.

I'm not sure what debug output says because it's a Windows crash, so I just get the Windows crash dialog.

Is there a way to set the logging so I can see the debug output?

VLM ca be used in command-line too, with a VLM config file if you didn't cross this feature.

Yeah, I saw that. I've been trying to find some examples. The two samples on the Wiki are pretty simplistic and I didn't want to struggle for a few hours trying to get the syntax right.

NB2: DTT/Satellites/Stream and VCL (maybe a mistakenly written "VLM"?) are unknown to me.

Yeah, I meant VLM.

To get debug on Windows, it shoulf be like this (1): Not sure --logfile is really needed, maybe a default filename will be used.

Hope useful debugs are written before the crash.
1: http://wiki.videolan.org/VLC_command-line_help

Okay, here's what I've got for a command-line and the resulting logfile:

vlc -vvv --file-logging --logfile=errors.log -I --ttl=12 dshow:// vdev="Osprey-450 Video Device 1B" adev="Osprey-450 Audio Device 1B" size="vga" --sout="#transcode{vcodec=h264, vb=4096, scale=1, acodec=mpga, ab=1024, channels=2, audio-sync}:std{access=udp, mux=ts, dst=239.255.12.2222"}

I already have output from Video Device 1A streaming on port 1234, same multicast address and parameters. When I run this command, I get this logfile, and then it crashes:

This is what the logfile looks like on the A1 device (which is successful). What seems weird to me is that it first uses the C1 Video device, and then finally the A1 Video device.

Please, edit your previous posts to embed logs in "code" tags. It will make them and the entire topic much more readable. [/code]

I will read your logs later, maybe someone else will have more time.
_Anthony

I got some of it figured out. I'm using version 0.8.6i. So either the documentation for the DirectShow options is wrong (http://www.videolan.org/doc/streaming-h ... l#id317290) or things have changed with the 0.9.x versions (in which case the documentation might be correct).

What the documentation failed to mention is that you have to prepend the text :dshow- in front of the vdev and adev options. When I looked through the logfile I noticed VLC was using audio from the A1 device, and video from the C1 device, despite what I was specifying. That told me that somehow my command-line options weren't taking.

I fixed my command line and I was able to get two separate instances of VLC working. Thus, I am able to stream two different multicast channels from the box from two different inputs on the Osprey. Which is nice and what I was trying to do.

However, now I have a different problem (and this one may not be so easy to solve).

The way I have things setup is like so (trying to test all four Osprey inputs simultaneously):

I have a DVD player running and the video coming off it is split and plugged into the Osprey's 1A and 1C devices. The audio from the DVD player is plugged into the Osprey's 1A device (not split, so no audio going to C1). I then have a second DVD (DVD-B) player doing the same thing, it's video split and plugged into 1B and 1D, it's audio plugged into 1B only.

So what I should have on the Osprey for available inputs is this:

1A: Video & Audio
1B: Video & Audio
1C: Video
1D: Video

For simple testing purposes I am only trying to display data to the screen, so using the --sout=#display option. No multicasting, just using the DirectShow options

I can display just the video from inputs 1C or 1D no problem (thus I do not specify a :dshow-adev option). I can display video 1C + audio 1A no problem. I can also display video 1D + audio 1B no problem.

If I try and display video 1A + audio 1A, the VideoLAN app opens, but no video displays (I assume the audio is working, but I don't have speakers on the actual server box to tell). Same for video 1B and audio 1B; app opens but no video displayed.

If I try and display just the video for 1A or 1B (again, no :dshow-adev option), it crashes. So there appears to be a serious problem when trying to get video from 1A or 1B.

I do no believe the Osprey is faulty because I can view any combination of inputs with Windows Media Encoder. So if I specify video 1A and audio 1A with WME, it works. If I specify just the video for 1A with WME, it works as well.

I'm at a loss as to why video from 1A and 1B cause VideoLAN to crash.

I don't know anything about capture card, here are just some remarks:
I find "-I" weird without arguments (but VLC seems to find it ok:) ). However, it says an audio mp2 bitrate of 1024 kbps is mad, and that's true :).
Your destination is bad: "dst=239.255.12.2222" -> "239.255.12.42:1234"?

I don't know more about such video device logs or direchshow. Anything interesting in logs VLC write before crashing?

I don't know anything about capture card, here are just some remarks:

Code: Select all

vlc -vvv --file-logging --logfile=errors.log -I --ttl=12 dshow:// vdev="Osprey-450 Video Device 1B" adev="Osprey-450 Audio Device 1B" size="vga" --sout="#transcode{vcodec=h264, vb=4096, scale=1, acodec=mpga, ab=1024, channels=2, audio-sync}:std{access=udp, mux=ts, dst=239.255.12.2222"}

I find "-I" weird without arguments (but VLC seems to find it ok:) ). However, it says an audio mp2 bitrate of 1024 kbps is mad, and that's true .
Your destination is bad: "dst=239.255.12.2222" -> "239.255.12.42:1234"?

I don't know more about such video device logs or direchshow. Anything interesting in logs VLC write before crashing?

What do you specifically find weird about the -I argument by itself? I got that off the documentation on using DirectShow, so that's all I know to do with it. (http://www.videolan.org/doc/streaming-h ... l#id317290). I'm not even sure what it does; I just assumed it was an argument I needed to set for DirectShow to work.

For the audio bitrate, yeah, I was playing around with it. I've got it set to 32 now.

The destination is indeed the second one: 239.255.12.42:1234. Is that a problem?

I'll post another log file shortly.

Here's the command I issued most recently, and the complete error log.

vlc --file-logging --logfile=errorlog.log -vvv -I -ttl=12 dshow:// :dshow-vdev="Osprey-450 Video Device 1A" :dshow-adev="Osprey-450 Audio Device 1A" size="vga" --sout="#transcode{vcodec=h264,vb=4096,scale=1,acodec=mpga,ab=32,channels=2,audio-sync}:std{access=udp,mux=ts,dst=239.255.12.42:2223}"
VideoLAN crashes then and that's all the log produces. I've got to believe there is some minor setting that is different between input device 1A & 1B vs. 1C and 1D. 1C and 1D work. They're all on the same physical card, and WM Encoder has no problems with any of the devices. Something fishy here for sure.

What do you specifically find weird about the -I argument by itself?

"-I" is used to force the main interface to use. "-I telnet" for example ask vlc to not launch GUI but listen like telnet for commands. You can ask for QT4 GUI, wx GUI, http, telnet, ncurses and other interfaces. But never seen it without the following interface name to use. (default is QT4 for legacy 0.9.*)

The destination is indeed the second one: 239.255.12.42:1234. Is that a problem?

Emm. That's not a problem. But before you mistakenly written this address. You did the same around the "-I" I think so I found weird your mistakenly written command-line.

Still in the last post:

vlc --file-logging --logfile=errorlog.log -vvv -I -ttl=12 ...etc

Nevermind.
I can't help you more on your crash, capture cards aren't in my skills.

good luck
_Anthony

Thanks Anthony.

I fixed the crashing. I figured there had to be some difference between capture devices 1A/B and 1C/D. So I opened up the Osprey config in Windows and started looking at the settings for each device. Devices A & B had a screen resize of 16x9. Devices C & D had it set to "square pixels", whatever the means. So I switched A & B to "square pixels" and bingo - no more crashes.

Appreciate the help Anthony!

One more question then: so if I don't set -I option, nothing should change right? Am I okay to not set that option?

-Chris

If you don't set "-I rc" option, default will be to show you QT4 GUI. If you use "-I rc" as said chapter 10, it will trigger a command-line interface suitable to give some commands to VLC (play, pause and more) from the console.
I think one or the other works well, just depends on your needs.

About square pixels weirdness, maybe that's related to 16:9 standard definition hack I have read about somewhere:
In France for example, TV was broadcasted in SD quality (standard definition). It was 4:3 ratio. More and more, it is HD which is 16:9 ratio.
But in the middle, I have read there were "16:9 SD" which is a contradiction. It was non-squared pixels to get 16:9 with SD streams.
I have it very far away in my mind, in case it helps.

Can you prefix the topic with "[fixed]"? It is a good habit to have :)

regards,
Anthony

Thanks Anthony.

I have two more questions if you don't mind:

(1) I am getting a little bit of stuttering and would like to clear that up. Will increasing the buffering improve that? Is there a way to do that? Is it: :dshow-caching=3000? Would that be sufficient to improve the quality?

(2) I think I read somewhere that I can set the number of threads to the number of processors and that may improve quality of my stream. How would I do that?

-Chris

More buffering can help for the beginning of the stream. Of you get latency, the cache will never go faster than the live so a bigger cache is only a later problem in my mind. Once it has been consumed for any odd reason, it doesnt help anymore. 3s is very sufficient i think and means 3 seconds of latency at the beginning (to fill the buffer with a 3s live stream).

Never read about threads setting you written. If you have several processors/CPUs on your computer, you can launch several VLC instances to be sure several streams can be spread accross CPUs.. for the receiver point of view, multi-core capable decoders are needed to use all CPU power in this case. I don't know more.