The VideoLAN Forums

My apologies if this has been addressed and my imperfect search technique just failed to bring it up.
Through honest error, I have an ATI eHomeWonder video capture card, intended for use only with Microsoft Windows XP Media Center Edition, installed in a computer running XP Service Pack 2. When I was running previous versions of VLC I found that I was, intermittently, able to pipe video in from my LaserDisc player, through the composite or S connectors on the dongle, and view it on VLC by forcing "directShow input" under "Network streams" -- with the caveat that composite in would show the VBI at the top of the screen, and cut off a corresponding number of lines at the bottom.
I decided to move up to version 0.8.1 of VLC, and was delighted to find the explicit support of capture devices. Unfortunately, with everything at the default settings, when I try to view the video [which is generated as a high-bitrate MPEG stream by the card] my CPU usage goes up to 100% and the image goes from OK through trashy to black screen. I don't have the vaguest idea what to do, and I thought that [rather than experiment at random] I would ask to find out if anyone else has had similar experiences, and what their solutions have been.
The VBI appears at top, as I noted before, whatever input I use. Also with "device properties" checked in the Open Capture Device dialogue, it opens that box twice in a row.
It also generates a huge pile of errors and warnings. Using the S-Video input, on a static picture [frame 6629 of PILA-1133A, Tenchi standing in front of the cave, if anyone cares], the following appears:
I apologise for the long code dump, that represents about 3.5 seconds from initialisation to black-screen and then I manually stop the playback.

Could you try the development version of VLC ? (see http://www.videolan.org/~videolan for nightly builds)
Support for PVR cards is broken in 0.8.1 but has been fixed a few weeks ago.

Thanks, I'll try that.

Problem: that link brings up "error 404" and not the regular VideoLan 404 message, either.

The machine hosting the nightly builds is down.
Try this instead: http://people.via.ecp.fr/~ipkiss/vlc-0. ... -win32.zip

Thanks.
This version will run, not well per se -- which is undoubtedly as much my not having fooled with the settings enough, and encoder junk, as anything else -- but watchably, for about 45 minutes before it starts freezing up with similar messages to those above. It uses basically 100% of CPU resources which is OK since I am not doing anything else; memory usage is not much.

Hmmm, that doesn't look too good.

You could try to play with the --dshow-caching option (increase it to something like 1000) or the --cr-average option (1000 would be a good value to try as well).

Running in non-overlay mode, to get a screencap, was very unstable -- it shut down twice in a few minutes, and twice the "Video" pulldown menu in the GUI went from its usual feature to only giving me the "Video Track" subitem.
Of course I think a part of my problem is that I need to actually install this version instead of just running it from its present location; the Install script did not auto run, and my attempt to download the programme referenced in the file comments -- which appears, anyway, to be the tool for writing rather than opening -- has not met with success so far.

Tried increasing the dShow caching value. It played for more than an hour without freezing up; on the other hand when I went to close the program it shut down abnormally - at least Windows told me "VLC has encountered a problem and needs to close". Fine by me, but a little inelegant!
Of course, since I pick off the audio from the LD to reciever directly there is a full second-plus delay in the picture with respect to sound, so I would hardly want to do this regularly. I wonder what the effect would be of forcing the cache value lower?
Another thing: when opening from the capture device, I get [with the "device properties" option set] the "video properties" box twice, the "stream properties" box twice though stream option is not set [all options are greyed out], and the "device properties" box once at the end.

I was experiencing massive errors when trying to watch a directshow stream off my Motorola digital cable STB but with this new version BAM! Works beautifully!

Thanks guys!

I would like to add something though, especially now that I have played with it for a bit.

VLC seems to be very, very unstable when capturing my Firewire video. Numerous occasions it will simply restart my computer. No warning, no blue screen just bam restart.

I have also noticed that if two instances of VLC run at the same time (lets say the first time I hit exit, it didn't exit properly) and then try and force quit the vlc.exe it will do the same thing, restart my computer.

Seems like it's just a stability thing, so I am assuming in future versions it will be a lot more stable.

Cheers,

1. When bringing in video via composite or S, I must select M-NTSC-J to avoid viewing the VBI as a green bar across the top of the picture, even on material which I know uses the American 7.5 IRE setup.
2. When bringing in video via composite or S, I see the front and back porches of the horizontal retrace interval as black bars on each side of the picture [which is thus slightly distorted from its proper 4:3].
3. When I close VLC now I am getting each time the error message, that is has "encountered a problem and needs to close". Before I increased the dShow caching value this did not occur, I am considering changing this setting again.

Having now actually installed version 0.8.2-svn-20050102, I observe the following. My sources are: composite, DAGE "six fifty" monochrome television camera; S-video, Pioneer CLD-D704 playing back David Bowie "Ashes to Ashes" CD-V video part. Both of these should be American standard NTSC, though I have yet to check for setup with the O-scope.

1: On composite: selecting "M_NTSC" causes me to see the VBI as a green bar at the top of the screen, and the horizontal blanking at each side as a black bar, thicker on the left hand side of the screen. Stopping playback causes the VLC to shut down, with the standard "VLC has encountered a problem and needs to close" Windows popup.
2: On composite: selecting "M_NTSC_J", VBI is not shown, but horizontal blanking is still in evidence, as above. Stopping playback a fter a few seconds does not cause VLC shutdown; starting it again brings the video in a window separate from the VLC main interface [video appears in this interface in the first instance], and stopping playback of this causes shutdown as above.
3: On S-Video: selecting "M_NTSC", VBI is not shown, but horizontal blanking is, as above. Stopping playback causes shutdown as above.
4: On S-Video: selecting "M_NTSC_J", VBI is not shown, but HBI is as above. Stopping and restarting, although it does detach the video window as above, does not appear to shut down VLC. After stopping, the "Open Capture Device" dialogue has no effect [hitting OK just causes it to disappear, with no action performed].
5: On all inputs: with "Device Properties" checkbox in the "open capture device" dialogue checked, "Tuner Properties" not checked, "Stream Output" not checked, "Tuner Properties" and "Stream Properties" dialogues each open twice before "Device Properties" dialogue is displayed. Hitting "Cancel" in any of these dialogues has little effect -- the next dialogue is proceeded to just as if "OK" had been selected, with the difference that the options in "Stream Properties" dialogue are available instead of inactive, and the video eventually displays. ["Ashes to Ashes" is strange-looking enough without trying to display it as B_PAL!]

I want to stream video to a file -- largely because I want to make a few VCDs for personal purposes, but also so that I can upload a file containing Closed Captions for the reference of the VLC developers!
The problem is as follows:
If I stream to a file the MPEG2 TS generated by the capture card, without any changes, as follows: , what results -- no matter what extension I use for it, apparently -- is readable by VLC but not any other application. Some say "file type not supported"; others say that the file, about 200 MB for 5 minutes, has size 0x0, length 0:00:00, and 0 audio channels; and so on.
If I try to transcode it, as for instance: , VLC shuts down as soon as I finish confirming that I really do want to open the capture device, and creates the file at the location I specified, with a size of zero bytes.
For reference, I have tried other combinations of switches than those described above, with the same type of results; I have not tried streaming to a network because I do not have access to such a thing.

If I re-encapsulate the file as .MOV [I have not so far had too much success with other formats, need to make a few more tries], I can then transcode after a fashion. Roxio VCD creator tries to open the .MOV and says things like: Audio bitrate 1, Video bitrate 1, speed 45 fps. To transcode I have to enable "synch to audio track" under stream_out_transcode or the video plays back at an accelerated rate, I guess film frames [24 fps] being played back at video rate [30 fps]. Unfortunately this option is incompatible with "Deinterlace" -- with both chosen, there is no audio!

>To MPEG 1: Something strange happens. VLC opens the clip and plays fine, but the timer exaggerates by an enormous factor: a 5-minute clip claims to be 360 hours, and of course plays at the enormous speed of 4320 minutes per minute! Depending which part of the WinAmp window you look at, it is either 45 or 22,500 minutes long, but again plays fine except at the beginning, when the picture and sound stutter while the framerate supposedly falls from some arbitrarily high value to about 30 fps. Windows Media player says 369:26:51 and video shudders, although I'm not sure about the cause of that, but the playback clock runs at normal speed and stops where it should.

>To MPEG 4: Plays beautifully, at least in VLC, except that with the option for synching audio and video set there is no audio. I thought I was getting audio before...

On a side note, VLC's MPEG 1 decoder works much better than those of other applications, on the files I generated at least! While the others generated noticable picture degredation in such a way that the key frames were obvious, the picture with VLC was smooth.

Here are the messages I get when transcoding the MPEG2 file, with .MOV encapsulation, into MPEG4. It looks pretty normal to me.

Here are the messages during playback of the .MP4 file created in the above procedure, which plays back the video a third or so faster than the audio, with the result that the video stops playing about a minute and a half before the audio stops [on a 5 minute video].