How to capture a raw MPEG stream?

[TlatoSMD]

I'm asking for a friend here who only has a small laptop with little CPU power. What he's trying to do is capture from a small MPEG-2 converter connected via USB. Because the CPU is so slow, any on-the-fly compression results in dropped frames and loss of A/V synchronicity.

So, how to directly capture a raw MPEG stream without re-compressing? No script-based solutions please. All he needs is a GUI with a record button.

[Asmodian]

Usually a usb MPEG-2 capture device does the MPEG-2 compression in hardware and its software just copies the data.

Which device is it?

[jmac698]

You can try http://www.shspvr.com/smf/index.php?topic=7680.0

Also you would usually use VirtualDub, but I've had troubles recording mpeg2 cards with it. I can see the video in preview, but recording only causes a green screen (which indicates a file of 0's). It's because the preview graph is different from the capture graph, and VD doesn't support recording from the preview graph. Another way to do it is by making your own capture graph. See graphedit and search for "how to capture with graphedit".

[TlatoSMD]

Usually a usb MPEG-2 capture device does the MPEG-2 compression in hardware

Exactly, and that's what we're trying to exploit here by capturing the raw stream. With most capturing tools, you either re-compress the stream to a codec that you specify before capturing, or if you don't specify any codec, it will usually capture to uncompressed RGB.

What we need is a way to just capture the raw data instead. I have no idea what device he has.

You can try http://www.shspvr.com/smf/index.php?topic=7680.0

That looks like just another script tool. You see, with the two of us I'm the expert because I've heard words such as "mplayer" or "AVIsynth" before and can give him other people's bat files to drag his files on for compression after capturing, but even I need countless days of live support to perform even the most simple tasks with these $§%&#ing scripts because their usual documentations were last updated 10 years ago! So none of the commands from the documentations ever work anyway (having been removed and replaced years ago), and when you try and get support for the script tools, most people refuse to talk to you because you're "an amateur" for not using Linux like they do and which they consider as "the only professional OS there is".

[jmac698]

I've used it, it works fine. It's not a script tool, it's a command line tool, but you can wrap the options in a batch file and the client can just double click it. However, you need to pre-set the recording time. You'd have to set it up for his system first.

Anyhow, you could try iuVCR, also the WinTV that came with my mpeg2 card works fine for recording raw mpeg2, it's the whole point of the software that came with the tuner, so I don't know why that's not working for you.

[TlatoSMD]

I've used it, it works fine. It's not a script tool, it's a command line tool, but you can wrap the options in a batch file and the client can just double click it. However, you need to pre-set the recording time. You'd have to set it up for his system first.

And that's exactly what I have no clue about, no matter if you call it a "script" or a "command line". It's all the same to me really. Blame the programmer sites for never having updated their documentations since the year 2000, and the support crews for never talking to me because I'm not using Linux! All the bat files I have are such that advanced users have sent me out of pity and charity. That's what it's been like for me for 10 years now with these "scripts" or "command lines".

[TlatoSMD]

Okay, we've tried 5 different programs today, and none of it worked. :angry:

VirtualVCR just refuses to run on Windows7.

All we had to find out how WinTVCap works was the readme to the GUI, and all the readme told us was to "fill the path to WinTVCap into the GUI". Without any exe, we tried to figure out where to "fill it in" for an hour or two, and then we gave up.

iuVCR didn't work because it only did 320x240 at max. And the audio was out-of-synch after capturing in such a way that not even shoving the audio back and forth within the timeline worked, because audio and video were running at different speeds. Yes, even when telling the damn thing not to recompress. So obviously it was *NOT* simply capturing the raw stream.

iuVCS did capture at 640x480 at least, but it had the same audio problems.

WinTV didn't work because it only works with Hauppauge graphic cards. Not detecting any Hauppauge software, it just refused to install.

We then went to a large electronics chain for a cinch-to-DV A/D converter for something like 30 Euros, because I know that DV is native enough to Windows that there are programs such as WinDV to simply capture a raw DV stream. But all that happened was that they sent us back and forth between the computer department and the TV department because none of them had ever heard words such as "cinch", "CBAS", or "DV" before and had no clue whatsoever what in the world we wanted. "You want something to do with video? Go to the TV depart." - "You want something with a USB out? Go to the computer dept.!"

My friend kept looking there for standalone DVD burners because he knows how they work (so he wanted to just feed the TV signal into one of them and record that), but we couldn't find any standalone DVD burner below 280 Euros!

[Asmodian]

We really need to know which device you are trying to use to offer any help.

All the standard information about windows batch files from 2000 should still be correct if you did want to go that route.

[TlatoSMD]

This is it: http://www.amazon.de/LogiLink-Audio-Video-Grabber-USB/dp/B0013BXFLG/ref=sr_1_1?ie=UTF8&qid=1344541118&sr=8-1

This is a pretty similar tool sold to the US (same tool, different label?): http://www.amazon.com/EasyCAP-Audio-Capture-Surveillance-Dongle/dp/B000Z4AQFU/ref=sr_1_4?ie=UTF8&qid=1344541580&sr=8-4&keywords=video+grabber

Analogue cinch in, realtime MPEG stream out. We can watch the TV signal just fine and all in-synch on the laptop with that, but whenever we try to capture anything from that, all we get is audio that's totally out-of-synch and generally running at a different speed than the video. He says that's what it does even with the capturing software that came with the thing. I'm pretty sure we could get this to work just smoothly if there was a way to get VirtualVCR running on Windows7, as VirtualVCR has an internal synch where the audio is dynamically re-sampled as needed for the video.

[manolito]

Usually a usb MPEG-2 capture device does the MPEG-2 compression in hardware and its software just copies the data.
I think this is your problem. Only the better USB grabbers have a built in hardware Mpeg2 encoder, the cheaper ones rely on the included software to encode to Mpeg2 in real time during the capture process. And this only works if the computer has enough horse power.

The solution for a weaker computer is to capture to the AVI format (using the Huffyuv or MJPEG codec, maybe Lagarith). This compresses only slightly (no more than 1:10), but it does not put much load on the computer. The resulting AVI file is quite big, but it is also very edit-friendly (it has only I-frames).

This AVI of course must be converted to Mpeg2 afterwards (if your target format is DVD).

Which software for grabbing? Unfortunately this turns out to be mostly trial and error. If the software which comes with the grabber (I believe it is Ulead) lets you specify a recording format and codec, it is well worth a try. A/V sync should not be a problem if the grabber handles the audio. If the audio is handled by the sound card, then you need a grabbing software which can sync audio and video on the fly by dynamically resampling the audio.

The two applications I am familiar with who do correct A/V sync are VirtualVCR and VirtualDub. IMO VirtualDub is far superior to VirtualVCR when it comes to A/V sync. But this might be different on different machines, you just have to try...

If you want to go the VirtualDub route and you have problems setting it up, let me know.


Cheers
manolito

[jmac698]

I have a usb device with built-in mpeg2 encoder, and virtualdub refuses to capture it, it comes through as green, but I don't know the solution except graphedit, which would be hard for them.
You've spent enough effort; maybe another capture device is warranted.

[TlatoSMD]

The solution for a weaker computer is to capture to the AVI format (using the Huffyuv or MJPEG codec, maybe Lagarith). This compresses only slightly (no more than 1:10), but it does not put much load on the computer. The resulting AVI file is quite big, but it is also very edit-friendly (it has only I-frames).

Memory is not an issue here. I figured that the constant asynchronicity was due to the fact the laptop had to do real-time encoding, which was why I asked about programs that could capture a raw MPEG stream, as that's what the grabber outputs.

Anyway, would DV also be fast? It's the usual codec we work with. All the capture programs we used so far had the ability to set codec and container.

This AVI of course must be converted to Mpeg2 afterwards (if your target format is DVD).

No, we were just trying to go with the raw MPEG stream because that's what the grabber gives us. I'm gonna give him an x264 bat to drop the eventual files on, no matter what codec they are as long as they'll be in-synch once and for all!

A/V sync should not be a problem if the grabber handles the audio. If the audio is handled by the sound card, then you need a grabbing software which can sync audio and video on the fly by dynamically resampling the audio.

Problem with both his tiny grabber and my own Canopus ADVC300 is that none of them can process audio, no matter what you do their output is just silent. (FYI: When I told the "expert" at the electronics store about my Canopus ADVC as an example of what "A/D video converter" means, he asked, "What is a Canopus?" *facepalms*)

The two applications I am familiar with who do correct A/V sync are VirtualVCR and VirtualDub. IMO VirtualDub is far superior to VirtualVCR when it comes to A/V sync.

I've been working with VDub for close to 10 years, but problem is that it doesn't have any dynamic audio-resampling option as VirtualVCR does.

[jmac698]

There's special sync versions of virtualdub, try this one
http://www.virtualdub.net/

[GrofLuigi]

I've been working with VDub for close to 10 years, but problem is that it doesn't have any dynamic audio-resampling option as VirtualVCR does.
:eek: :eek: :eek:

http://i.imgur.com/G0jHA.png

[manolito]

@jmac698 and TlatoSMD

Sorry guys but your information about VirtualDub is terribly out of date.

I've been working with VDub for close to 10 years, but problem is that it doesn't have any dynamic audio-resampling option as VirtualVCR does.

Then you must be using a 10 year old version of VDub... The option to correct A/V sync dynamically during capture has been introduced in VDub many many years ago.

http://www.bilderload.com/bild/234807/vdub8TFM9.png (http://www.bilderload.com)

I still use an old version of VirtualDub from 2007 (v. 1.6.19), and at this time the A/V sync feature had already been there for quite some time.


No, we were just trying to go with the raw MPEG stream because that's what the grabber gives us
I doubt this statement. The product info you posted is a strong indication that this grabber does not have an internal hardware Mpeg2-encoder.


Cheers
manolito


//Edit//
GrofLuigi beat me by 5 minutes...:o

[TlatoSMD]

Looks like VDub has changed a lot since I've last used the capturing mode around 2005. After that, I exclusively went with WinDV and VirtualVCR.

I doubt this statement. The product info you posted is a strong indication that this grabber does not have an internal hardware Mpeg2-encoder.

Well, it's what it says on the box, in the amazon ad ("Formate: MP3, MPEG 1,2,4, DIVX"), and what we get when telling the capturing program to use no compression is either .mpeg or an MPEG codec inside an AVI container (yes, I know it's perverse, but it's what happens!).

[manolito]

Well, it's what it says on the box, in the amazon ad ("Formate: MP3, MPEG 1,2,4, DIVX")
And now you believe that the grabber has internal hardware encoders for MP3, all MPEG levels plus DivX? Dream on...

What does it cost you to just check out if grabbing with VDub works or not? Install the driver for the grabber so it shows up in device manager, install the Huffyuv or MJPEG codec and a current version of VirtualDub. Check if the grabber appears under "Device", under "Video" you may have to switch from "Overlay" to "Preview" depending on the converter chip used by the grabber. Select the video compressor (Huffyuv) and the frame size. Check if you can get audio through the grabber input, if not, connect audio to the soundcard and select the soundcard as the audio input in VDub. Do not use any audio compression, select raw PCM at 48/16. Adjust the "Timings" window according to my screenshot, and for a weak computer you should activate "Hide Display on Capture".

And let us know how it goes...:p


Cheers
manolito

[TlatoSMD]

And now you believe that the grabber has internal hardware encoders for MP3, all MPEG levels plus DivX? Dream on...

Well, out of those, MPEG is most likely, right? And it's gotta be *SOME KIND* of hardware encoder, because all that gets fed into it is an analogue video signal.

[manolito]

Well, out of those, MPEG is most likely, right? And it's gotta be *SOME KIND* of hardware encoder, because all that gets fed into it is an analogue video signal.
Not at all...

Before USB based video grabbers became popular, you had to use a TV tuner card (or a dedicated capture card without a TV tuner) to capture analog video content. An alternative were "VIVO" graphics cards (VIVO = Video in - Video out).

These cards used a dedicated A/D converter chip. In the old days this was mostly a Brooktree (later bought by Conexant) chip (BTxxx or CXxxx), later Philips took over with their SAA chips. Most of these PCI cards did not have a hardware encoder. They output a raw digital video stream, and the recording software had to deal with it.

Recording the raw stream without any compression did mostly not work because the I/O bus could not handle these bitrates. Converting to MPEG in real time during recording also was problematic because the computers did not have enough muscle to handle this task in real time.

So the method of choice to record these streams was to use a lossless (or slightly lossy) codec like Huffyuv or MJPEG. This did reduce the data rate enough so the I/O bus could handle it, and the encoders did not put too much load on the CPU at the same time.

OK, so much for the history lesson. But today's cheaper USB video grabbers still use very much the same technology. You only find built-in hardware encoders in the more expensive grabbers, the cheap ones all rely on the bundled software to convert the video stream to MPEG in real time. Since today's computers are much more powerful than they were only a couple of years ago, many people can get away with this. But it seems like your friend's notebook is not powerful enough to handle this, so my advice is to use the old school method for grabbing.



Cheers
manolito

[TlatoSMD]

Most of these PCI cards did not have a hardware encoder. They output a raw digital video stream, and the recording software had to deal with it.

I suppose by "raw digital video", you mean uncompressed RGB or YCbCr, huh? That's a data rate of circa 400Mbit/s, whereas the effective rate in practice of USB 2.0 maxes out at 320Mbit/s (160 of the theoretical 480Mbit/s spec are constantly in use for device management and not available for data transfer). And I kinda doubt that these tiny things are equipped with USB 3.0, or that manufacturers would expect many users being equipped with USB 3.0 buses.

So, uncompressed RGB on a USB device that's most likely USB 2.0 or lower? I don't see it happening.

[manolito]

From the Wikipedia:
The video capture process involves several processing steps. First the analog signal is digitized by an analog-to-digital converter to produce a raw, digital data stream. In the case of composite video, the luminance and chrominance are then separated; this is not necessary for S-Video sources. Next, the chrominance is demodulated to produce color difference video data. At this point, the data may be modified so as to adjust brightness, contrast, saturation and hue. Finally, the data is transformed by a color space converter to generate data in conformance with any of several color space standards, such as RGB and YCbCr

From the BrookTree BT848 data sheet:
Multiple YCrCb and RGB pixel
formats supported on output

Capturing is normally done in the YUY2 4/2/2 format. To calculate the data rate you can use several data rate calculators on the web:
http://web.forret.com/tools/video_fps.asp
or
http://www.dvs.de/support/calculators/data-rate-calculator.html

You will notice that the resulting data rate both for NTSC and PAL is well below the USB2 bandwidth.


Cheers
manolito


//Edit//
I found another intersting link which might help to convince you that most USB video grabbers do not have an internal hardware encoder:
http://www.terratec.net/en/products/video/hardware-encoding.html
You can see that only 1 device (Grabster AV 450 MX) offers hardware encoding. Terratec is one of the few companies who do not publish misleading specs for their video grabbers.

[Asmodian]

Actually RAW YUV 4:2:2 at 720x480@30fps or 720x576@25fps is only ~158.2 Mbps.

[Mounir]

assuming your cpu (dual core minimum) is strong enough the best realtime mpeg2 software encoding app i have ever used was made by intervideo called Windvr3

never record on the system disk but on another disk internal or external (internal,sata better) otherwise expect frame drops a/v desync etc..

The only problem is that your recordings will be deinterlaced on the fly