Thanks. If I already have all the codecs, then when I attempted MPEG1 I had done something else wrong, and for MPEG4 and WMV2 my stream of warnings about buffer overflows or not reading the header of each frame must also be my fault somehow. But I'm using examples from the Wiki as best I can. One of the various pages I have referenced is
here, and making changes based on their example (like "access=udp,url=224..." instead of "udp=224...") and your corrections to the code I posted previously (dshow-size and the colons), here is my most recent attempt:
Code: Select all
D:\Programs\VLC\vlc.exe -vvv -I rc --ttl 12 dshow:// :vdev="Sony Digital Imaging Video2" :adev="USB オーディオ デバイス" :dshow-size="640x480" --sout='#transcode{vcodec=mp4v,vb=800,scale=1,fps=15,acodec=mpga,ab=32,channels=1}:duplicate{dst=display{noaudio},dst=standard{access=udp,mux=ts,url=224.0.0.1,port=1234}}'
I tried the dshow-chroma suggestion, but I got the error: 'The capture device "Sony Digital Imaging Video2" does not support the required parameters.' I was emboldened to try a larger size, and it seems to work okay. I'm still getting a spew of warnings, but they are all about the audio, not the video, like "audio drift is too big", "PTS is out of range", "buffer is late", etc. But I can hear the audio on the server's speakers, so I'll ignore those for now.
But I still can't get anything on the client. I used the GUI, selected Media->Open Network Stream..., then selected UDP and typed "224.0.0.1" in the Address spot, and made sure the port was 1234 (which it always is). Nothing happens, and even with verbosity at 2, there are absolutely no messages. From the command line (from the correct directory, I typed "vlc -vvv -I rc udp://@224.0.0.1:1234"), I get information in the rc window, but I can't figure out how to capture the text in order to share it in the forum (right-click does nothing in that window - it must be really special). I don't have the patience to type everything, but there are no failure-sounding entries, it sounds like it found the multicast, and the last thing it says is "pre buffering". But nothing else ever happens.
The weird color problem has become off-topic, as I have discovered that it is not related directly to VLC or settings, but for the sake of readers who might be curious... It turns out that it was going on all along with this camera (on USB, that is - Firewire is fine, as this is actually a very good camera) - I just didn't notice it at first because it was sitting on my desk in such a way that the only colorful item in its view was a green cable. Also, a little webcam that comes on this netbook doesn't have the problem. And it's not a problem with memory or something on the netbook - I installed the Sony driver on another computer and tested, and it had the same problem. I don't know if the camera itself is sending the weird color shifts when connected to USB, or if the driver is screwing it up somehow. I've never seen anything like it - even if I could have used your dshow-chroma suggestion, I seriously doubt that anything could properly fix this kind of thing "in post". The camera is no longer in production (over 5 years old), so I suspect that if I call Sony, I'll be on hold for 30 minutes and then they'll say, "Sorry, we can't help you," in the politest Japanese they can muster (which is pretty impressive - you would be amazed how thick Japanese politeness language can get!). So... we'll have to find another camera before we'll have a working system (or use a computer that has Firewire, but we had hoped to keep this small and simple by using the netbook that isn't already being used for something else). Actually, I have started looking at "network cameras", those devices designed for use as security cameras that have their own WiFi built in, plus software for the other end that can not only view the video but even control the camera (pan, tilt). Their built-in mic is probably not very good (with my camera we had planned to plug into the church's PA system for really good sound) and they don't zoom much if at all, but it might be a simple solution that doesn't need a computer attached to the camera, and it costs less than getting a new camcorder.
Back to the topic at hand. I still want to get VLC streaming working - if network cameras turn out to be unsatisfactory I'll still need to use VLC (with a different camera or a computer that has Firewire), and it would be good to have this skill in my pocket anyway. I look forward to any other ideas you have about why my client can't see the stream and/or other corrections to my command syntax.