VideoHelp Forum
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 32
Thread
  1. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Hi,
    I am new to capturing video on PC, and my first attempt seems to have failed so I'd like some help and advice, possibly all I need is a better capture device.

    What I did so far was buy Diamond HD Game Capture USB device (GC500), and the best software I found for live recording and encoding was OBS. However, using that software or any other I managed to get working with ~60 fps (with whatever deinterlacing methods that keeps each field as a full frame), I get on and off choppy video, whether looking at it live or recording. What I mean is that it looks fine and smooth for a few seconds, then it looks like the fps drops and gets choppy for a few seconds, and back to smooth again, and so on. Once in a while there's also a little "stuttering" (out of order frames). Since this was the case on 3 different computers and various software (even learned how to use graphedit+avisynth to work with the capture card), I think the card is not able to properly grab every field. The source input is a camera (Sony CVX-V18NS), and it looks perfectly fine on the monitor it is normally connected to. I've sent Diamond a support ticket, but I think my best bet is to return the card and try a different one.

    So what do you think the problem is? I would have assumed NTSC sources send some kind of signal so that the capture card (or whatever else) knows when to capture/display each field. Is that not the case, is doing this properly "difficult"? What I'm getting at is: can I manage to do this without getting a much more expensive capturing device? Any suggestions of what device is known to do 60 fps capture from NTSC source without problem? How about Hauppauge USB-Live2? I'd prefer to stay under $100 if any of these devices can manage. Note that with OBS, the PC can easily encode directly with x264vfw at a satisfactory quality and compression ratio for my needs, at 720x480, 60 fps.

    Any help or tips greatly appreciated!
    Last edited by zorgkang; 13th Apr 2014 at 14:23.
    Quote Quote  
  2. Member
    Join Date: Jun 2012
    Location: USA
    Search Comp PM
    According to their website, that card only puts out 720x480 30fps NTSC or 720x576 25fps pal. All you're doing with your software is uprezzing with no actual gain in resolution.
    Quote Quote  
  3. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    NTSC is 720x480 at 29.97 FRAMES per seconds, but it's interlaced so there's twice that many FIELDS per second. So the original temporal resolution is ~60 Hz and that's the important thing I want. Yes the effective vertical resolution is then halved, but that's ok, I prefer to keep the temporal resolution. So the question is: what do they mean by NTSC 30 fps. I think this is the standard way to say NTSC, and it should imply they are able to properly capture the 60 fields per second. Do you disagree?

    Oh and since I AM able to see smooth 60 Hz at least part of the time (as I said a few seconds smooth, then a few seconds choppy), they do capture the fields separately and not doing some hardware deinterlacing prior to serving it to the computer.
    Quote Quote  
  4. Member
    Join Date: Jun 2012
    Location: USA
    Search Comp PM
    Wait a minute.. Re-reading your post -- buried in the middle, if you're capturing DVCam you should be using firewire. Period. All the other stuff is just messing you up.
    Quote Quote  
  5. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    None of the devices I've mentioned have firewire. Please explain.
    Quote Quote  
  6. Member
    Join Date: Jun 2012
    Location: USA
    Search Comp PM
    DVCam is always firewire -- so that's not really what you have, I guess.

    Your system is choking on the real-time encoding. But you already know that Could be any of the components. Not much help here, I'm afraid. Maybe someone else will chime in.
    Quote Quote  
  7. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    I said what camera I use, and it used to be plugged into a DV tape recorder with a big DVCAM symbol on it... I thought that meant the camera was DVCam, but maybe not. Edited that word out. Anyway, it outputs NTSC through an S-Video cable so I need a capture device with S-Video input. And also as I said, encoding is not the issue, as the same thing happens while viewing the stream live and not doing any encoding, on 3 different computers with decent specs, and barely using any CPU. Hopefully, someone with a little more insight can help too.
    Quote Quote  
  8. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Although... If the DV tape recorder has firewire or other output meant for a computer, maybe I could use that. I'll have to check tomorrow when I'm at work. If it has firewire though, would I need drivers, or would it be directly available to recording software like OBS?

    Edit: Searched online and I'm pretty sure the deck I have is: Sony DSR-11. Pic of connectors. After further research, looks like that DV IN/OUT plug is i.link = firewire. So, looks like all I need is a cable and drivers and/or sofware to capture that. Looks like a good avenue to explore. Provided the deck outputs live and not just when playing a tape!
    Last edited by zorgkang; 13th Apr 2014 at 14:48.
    Quote Quote  
  9. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Update: yup the tape deck had firewire, and drivers for it installed automatically from Windows Update (which is good because they don't seem to be available otherwise). And it streams live. And OBS sees it. So all very good so far. Now, although it looks much better than the capture card did, I still get regular fps drops, maybe 10% of the time (2 seconds every 20 or so). I haven't tried different computers this time, but I'm still confused as to what the cause of this is. CPU usage is minimal when only viewing the stream. I assume firewire 400 has enough bandwidth for streaming full NTSC intact, so this again beckons: is there a bottleneck, and if so where could it be? Or is it just because it is hard to grab frames/fields in sync with an analog NTSC source?
    Quote Quote  
  10. The symptoms you describe are usually hard drive related. A background process wakes up occasionally and performs I/O, screwing up the real-time video capture.

    http://forum.videohelp.com/threads/104098-Why-does-your-system-drop-frames

    DV capture via firewire is nearly foolproof. Try using WinDV or DVIO.
    Last edited by jagabo; 15th Apr 2014 at 23:11.
    Quote Quote  
  11. Duplicate post removed.
    Quote Quote  
  12. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Thanks jagabo, I'll have a look at these software. But would the hard drive really be involved when only viewing the stream live? In any case, I'll try turning off most services and such, but I'm not sure... looked a bit too regular. I'll let you know how this turns out.
    Quote Quote  
  13. Lone soldier Cauptain's Avatar
    Join Date: Jan 2006
    Location: Brazil
    Search Comp PM
    Hi zorgkang,

    Your card is alternative version from Roxio Game Capture.

    To record at 480p@60, try AmarecTV. Its can record 480i + deinterlaced double speed, result in 60fps progressive using VFWX264.

    Correct field order is TBF + YUY2 colorspace.

    Try and reply.
    Claudio
    Quote Quote  
  14. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Thanks Cauptain, I had tried that as well with the same result as described initially: alternating between smooth and choppy. Note that thanks to the tip by smrpix, I realized my DV deck had firewire and worked better than the capture card, so I've returned the Diamond card. I'll be concentrating on making the DV deck work as best as possible.
    Quote Quote  
  15. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Originally Posted by jagabo View Post
    DV capture via firewire is nearly foolproof. Try using WinDV or DVIO.
    Both work perfectly without any dropped frames and the video looks smooth. I was playing the captured files with Zoom player using LAV video decoder which is able to deinterlace to 60 fps (hardware and software options) without any dropped frames or issues. Only thing is that it generates about 200MB/min and would require transcoding afterwards.
    Quote Quote  
  16. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Originally Posted by jagabo View Post
    The symptoms you describe are usually hard drive related. A background process wakes up occasionally and performs I/O, screwing up the real-time video capture.
    Turned off everything I could (services, network, etc.) and no change in OBS or Avisynth. And since recording DV directly as you suggested is fine at 200MB/min, I really don't think it's a hard drive issue. But then I don't know what the problem is.

    Any other idea on how I could encode the DV stream live with x264, deinterlaced at 60 fps?

    And if not, are there good (free) transcoders out there that would deinterlace decently at 60 fps before encoding in x264? Actually just figured out how to get HandBrake to do this (selecting Bob and setting the output frame rate at 59.94). Any other suggestion?
    Quote Quote  
  17. Member turk690's Avatar
    Join Date: Jul 2003
    Location: ON, Canada
    Search Comp PM
    Originally Posted by zorgkang View Post
    Originally Posted by jagabo View Post
    The symptoms you describe are usually hard drive related. A background process wakes up occasionally and performs I/O, screwing up the real-time video capture.
    Turned off everything I could (services, network, etc.) and no change in OBS or Avisynth. And since recording DV directly as you suggested is fine at 200MB/min, I really don't think it's a hard drive issue. But then I don't know what the problem is.
    How many hard drives does that computer have? If it only has one then it's indeed a hard drive issue.
    Stop feeling suicidal just because he unfriended you on fezbuk.
    Quote Quote  
  18. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    I'm sorry but do you have logical arguments to support that? I don't see how that could be the case since 1) how is the hard drive even involved when only previewing the stream live and not encoding or writing it to disk? And 2) I can capture fine in DV at 200MB/min and encoding with x264 results in 20 times less data to write, so why would the drive suddenly not cope?
    Quote Quote  
  19. Lone soldier Cauptain's Avatar
    Join Date: Jan 2006
    Location: Brazil
    Search Comp PM
    Originally Posted by zorgkang View Post
    And if not, are there good (free) transcoders out there that would deinterlace decently at 60 fps before encoding in x264? Actually just figured out how to get HandBrake to do this (selecting Bob and setting the output frame rate at 59.94). Any other suggestion?
    Avisynth QTGMC script + Ripbot264/TX264 to better deinterlaced or MEGUI using YADIF BOB. Boths will give 480p@59.94

    Code:
    YourSource("video.avi")   # DGDecode_mpeg2source, FFVideoSource, AviSource, whatever your source requires
    QTGMC( Preset="fast" )    # "Placebo", "Very Slow", "Slower", "Slow", "Medium", "Fast", "Faster", "Very Fast", "Super Fast", "Ultra Fast" & "Draft" 
    SelectEven()              # Add this line to keep original frame rate, leave it out for smoother doubled frame rate
    Claudio
    Quote Quote  
  20. I know you are no longer using the Diamond Capture card but just FYI:

    If your hard drive has fallen from DMA mode to PIO mode you will have high CPU usage whenever disk I/O is taking place. That could cause the jerky problems you are seeing. Check your CPU usage at idle. It should be at 0 percent with an occasional bump to 1 or 2 percent. Watch for spikes when your jerky video problem happens.

    Video capture is a real-time process. Every 1/60 second a new video field arrives (or every 1/30 second a new frame arrives) and must be processed. If the computer is off doing something else for that 1/60 second that field will be dropped. As an example, a computer that is running at 100 percent CPU usage for half a second, then 0 percent CPU usage for half a second, alternating between the two, will show 50 percent CPU usage in Task manager. But during that half second where the CPU usage is 100 percent there will be no spare CPU cycles available to the capture program and it will drop 30 fields.

    Until you get your captures working properly you should not perform any filtering during video capture. Capture as YUY2 (or other YUV 4:2:2 subsampling) and compress with a fast lossless codec like Huffyuv. Once you have that working perfectly you can start attempting to filter while capturing. But keep in mind that the more you do while capturing the more likely you are to drop frames.

    VirtualDub (and possibly some other capture programs) has a problem with some capture devices where the preview and capture get jerky if its audio playback setting is enabled. Disabling audio playback will take care of that (you can still capture audio, you just can't listen to it while capturing).

    If a capture/display program uses a rewind buffer (ie, you can pause and/or rewind the video to see something again) it will be using the disk for that rewind buffer. So disk I/O is taking place even if you are only watching the video.

    Regarding AviSynth+QTGMC and MeGUI: if you aren't editing the video you can simply mux the original audio with the resulting video. That way there will be no loss of audio quality.
    Quote Quote  
  21. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Those are good points, thanks jagabo, and most of it still applies to capturing from the DV deck. I didn't have time today, but I'll try to look in more detail at the resources being used to see if the disk and/or CPU are more busy than I thought. I don't think either OBS or graphedit+avisynth would have a rewind buffer, but maybe they use a buffer anyway... I'll see.
    Quote Quote  
  22. Originally Posted by zorgkang View Post
    Those are good points, thanks jagabo, and most of it still applies to capturing from the DV deck.
    Yes. The biggest difference is that firewire capture isn't much more than an un-managed file transfer. The compressed data on the video tape is simply transferred to the computer where it's wrapped in an AVI container.

    Originally Posted by zorgkang View Post
    I don't think either OBS or graphedit+avisynth would have a rewind buffer, but maybe they use a buffer anyway... I'll see.
    That combination won't be buffering on the hard drive, only in DRAM. Unless you run out of physical memory and start swapping virtual memory on the hard drive.
    Quote Quote  
  23. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Originally Posted by jagabo View Post
    Yes. The biggest difference is that firewire capture isn't much more than an un-managed file transfer. The compressed data on the video tape is simply transferred to the computer where it's wrapped in an AVI container.
    Sure, but when streaming it live, it still only arrives at 29.97 fps and the computer has to deal with the data as it arrives. So there are still issues with filtering/encoding that stream live that I hope to figure out and resolve.

    Originally Posted by jagabo View Post
    That combination won't be buffering on the hard drive, only in DRAM. Unless you run out of physical memory and start swapping virtual memory on the hard drive.
    Which is what I was expecting, but it's still dropping frames (and plenty of free memory). Even viewing the stream from graphedit (using LAV decoder that does allow yadif x2, or hardware deinterlacing) is not smooth. Maybe the problem in those cases is that the viewer is trying to display the frames too soon, as they come in, so even if the CPU doesn't get too busy, it's not able to process them in time? Maybe a (bigger) buffer would be needed.

    Anyway, as it is a long weekend here, I won't get back to this until Monday!
    Quote Quote  
  24. Member turk690's Avatar
    Join Date: Jul 2003
    Location: ON, Canada
    Search Comp PM
    Originally Posted by zorgkang View Post
    I'm sorry but do you have logical arguments to support that? I don't see how that could be the case since 1) how is the hard drive even involved when only previewing the stream live and not encoding or writing it to disk? And 2) I can capture fine in DV at 200MB/min and encoding with x264 results in 20 times less data to write, so why would the drive suddenly not cope?
    Valid points. But wintel laughtops and PCs, especially branded ones out of the box, are not designed to capture and edit video. They are filled with bloat-, mal-, and trashware that automatically get installed the first time they are powered on. They are to ostensibly help user get on with his fezbuk, tweety, and a whole lot of other trashy activities that passes for social networking. Some of these programs are obvious; others not. Those that are obvious you can probably uninstall or change in msconfig, but windoze has a lot going on under its hood that are not easy to tell. jagabo has said as much in posts above. Windoze deviously, purposely, needfully, blatantly performs a lot of disk I/O, never mind that you are not viewing a file on that drive but merely streaming it. Another is pagefile.sys was a neat feature in the days when memory was expensive, but it's still there nowadays even when memory is cheap as a hedge in case user installs less. Windoze default dynamically resizes this virtual memory, and can wreak havoc with capturing. 6GB and less nowadays is firmly on the side of the kvetch, and with rafts of programs and files and activity going on in that single wretched hard drive, dropped frames are to be expected.
    I have always advocated for at least two single-controllered hard drives in any computer that is to be used for capturing, editing, rendering video of any framerate or resolution, and have duly said so in several older posts. One hard drive is for the OS and programs, the other is for captured, rendered, and output files. This is just one way of getting out of whatever windoze does willy-nilly in the main drive :C that may or may not be obvious, but is interfering with whatever it is you are trying to do with video. Professionals do it this way, and is a de-facto feature in their setups. Newbies and beginners less so, and will question it, which is silly, considering hard drives are not as expensive as they are now compared with a few years back. This has to be emphasized because would-be editors run and splurge after the latest i7 processor, graphics card, and Z88 mobo but turn all of those advantages on its head by using a single measly hard drive, never mind that it's the latest OCZ 256GB SSD (which, if apart from having the OS in it is also used for capturing, may present a potentially more scary scenario). Tweaking your editing/capturing program can only help so much.
    Laughtops, out of the box, are designed to browse and send and receive email, not much more. With its one dinky hard drive, it's a very tall order using it to capture and edit video. Desktops are better in that it's easier to add hard drives to it. Note that it has to be SATA, not USB. Why that is, read older posts I have replied to.
    Stop feeling suicidal just because he unfriended you on fezbuk.
    Quote Quote  
  25. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Ok... but I dare say that I know Windows fairly well, and when I say that I made it "clean", I mean I disabled pretty much every non essential services, and there are NO other programs running (hidden, malware or otherwise). I even disable the network adapter and all things that are useless without a network (network printer drivers for example). This is a lab computer, so it was pretty clean to start with. While I agree that it's easy to pile up crap on a Windows system, I disagree that it's not easy to deal with and to have a decently clean system when you know what you're doing. So while it is a fair concern, I really don't think there is any "third party" interrupting or interfering here. The page file is a valid point, I'll check how it's set, but it wouldn't be resizing every few seconds, and it can be made static or even turned off. And again, disk usage is not relevant here (unless there is disk buffering as jagabo pointed out).

    I will put a second drive in there anyway because for now the best solution is to capture directly in DV format in an AVI file and transcode later. And that will require a lot of storage space. So you don't have to push that any more, but I'll still be looking for a way to bob deinterlace and encode the DV stream to H.264 in real-time.
    Quote Quote  
  26. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    So I'm now trying VirtualDub in capture mode. I can see the raw DV stream fine. However, I'm missing something because it looks like I could apply a deinterlace filter and then compress with x264vfw, but I get the error that the encoder doesn't support the source image format. I tried adding a filter to convert to YUV, but I'm not sure the filters are applied (the Overlay or Preview display always shows the raw interlaced feed). I've seen YouTube doing capture and converting in 2 steps, or in one step but with screen capture instead of DV source. Is what I want not possible? Any tips? Thanks again to everybody!
    Quote Quote  
  27. Give it up. Capture DV as 30i. Then run a good, slow deinterlacer like QTGMC(). Or for film sources an inverse telecine like TFM().TDecimate() You'll be glad you did.

    Originally Posted by zorgkang View Post
    I get the error that the encoder doesn't support the source image format.
    Video -> Color Depth -> Output Format to Compressor/Display -> 4:2:0 Planar YCbCr (YV12)
    Quote Quote  
  28. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Thanks, I'll look for that setting tomorrow, but a lot of the settings under Video gave me messages like "not supported by the capture source" or something like that, while in capture mode in VirtualDub. I don't want to give up yet though. As far as I can tell, this should be doable. It's just a matter of finding a way to "connect" the components together... Note that I'm not concerned that much with video quality (so I really don't need QTGMC or the like), my only concern is to keep the time resolution. This is for recording subjects in neuroscientific experiments, I only need to see if and precisely when they move.
    Quote Quote  
  29. Member
    Join Date: Apr 2014
    Location: Canada
    Search Comp PM
    Looks like direct DV capture from VirtualDub doesn't allow to do anything but save the DV stream as is. None of the filters and settings are applied.

    I was however, able to get what I wanted in a weird way: A GraphEdit file with the DV capture device connected to a DV decoder, then an AviSynth file with directshowsource(file.grf, ...), and opening the .avs file in VirtualDub. Then configuring x264vfw encoding and selecting output to file within the codec settings page, and finally running File | Run video analysis pass in VirtualDub. That actually creates a smooth 60 fps compressed file of the live DV stream like I wanted. With this setup, I can do deinterlacing either in LAV decoder (set in GraphEdit), in AviSynth, or in VirtualDub. Didn't seem to make a difference in terms of processing speed or smoothness of the output.

    Unfortunately, this is far from user friendly, and it also has the inconvenience of doing something weird at the start, probably because it attempts to read from the start of the "file" which is the .avs live stream. To avoid it getting bad, I have to reopen the .avs file and then start recording ("Run analysis pass") immediately.

    I was not able to do it in a more sensible way, like using capture mode with DV source or avisynth-capture-script-source, the latter looks like it should work, but somehow only captures 1fps and drops the rest... I also couldn't get the "external encoder" feature to work. Maybe I'll ask about this on the VirtualDub forum.

    But at least this shows that the problem is software. My system can handle this no problem (the above "working" method uses 15-20% CPU). If there was a simple way to connect properly these 3 things: the DV capture, LAV decoder, and x264, then it should work nicely.
    Quote Quote  
  30. Most people want to capture DV without any processing as that's an exact copy of the digital data on the tape. That's why all the DV capture tools simply save the compressed stream in an AVI file.
    Quote Quote