AverTV USB HD DVR or Hauppauge USB HD PVR

[gll99]

My aim is to use the device as a computer based time shifting pvr by recording the component 1080i from my cable box to h.264. Right now I record from the svideo out with a pci tuner card but of course it's only sd. I hate it when the originating show is HD but I have to watch the sd capture because I missed the live HD show.

I want to buy either the Avermedia ($200) or the Hauppauge model 1212/1219 ($220) but I can't seem to make up my mind.

http://www.avermedia-usa.com//AVerTV/Product/ProductDetail.aspx?Id=488

http://www.hauppauge.com/site/products/data_hdpvr.html

Any known issues pluses or minuses?

I downloaded the pdf guides.
Some things I've gleaned.

The Avermedia has a hdmi to view the recorded video and the Hauppauge does not.
The Hauppauge has 5:1 audio and the Avermedia has only stereo
They both have component input for analog hd up to 1080i and pass-through out
They both come with the Arcsoft software
The Hauppauge comes with a remote but it can't be used with the included software. The Avermedia doesn't come with the remote but it has the sensor built-in and it can learn a remote.
The Hauppauge uses Wintv for scheduling and the Avermedia has it's own scheduler but they both look about equal.
They both have the infrared extender to send signals from the PC scheduler through the PVR unit to the cable box to control channel changing.
They both use hardware compression to h.264 minimizing cpu usage
They both transfer to the pc via usb 2.0


Side Questions:
1) It's unknown to me whether both units treat the sd signal the same way? ie... do they upconvert to h.264 or do they leave the signal in sd format and capture to sd mpeg2?
2) They both capture and compress using hardware to h.264 but I'm not sure if they are both to the native generic ts format.

btw)
The 5.1 audio is not important for me right now.
I might find the hdmi useful but I also have hdmi/component out on the storing computer so it's not a critical feature.

[PuzZLeR]

I am so going to be tuned in to this thread, since I'm in the same boat as you.

Can I add some questions/comments too? Figured you wouldn't mind.

How do both compare when it comes to PC resources? An ideal solution for many, particularly when it comes to HD and/or analog capture, would be when a stand-alone encoder does most of the work, and only uses the PC for management and storage.

As for SD, I don't think these units would be high quality given that they may use a Baseline version of H.264 which is fit for maybe iPod at best. I don't think they even do MPEG-2. I probably would be prepared to stick with MPEG-2, and the incumbent hardware for SD, when only capturing to SD. Then again, I'd love to know this as well.

As for software that comes with the unit, I wouldn't spend too much time agonizing over this as reviewers in several sites seem unhappy with these apps. There are other tools, like Beyond TV, GB-PVR, etc, that should do an adequate job. As far as my Hauppauge 1950 is concerned, I have even found the quality, believe it or not, slightly better with Beyond TV over WinTV. You can determine this with the AviSynth Interleave() command in preview mode from recordings over a repeating channel. Again, someone may know better.

[jagabo]

The HD PVR captures signals the way they come in (I have one). It doesn't upscale or downscale. A 480i30 input is captured as a 480i30 file. A 720p60 input is captured as a 720p60 file. You have a choice of TS or M2TS containers. All video is h.264 encoded, audio AAC or AC3 encoded. Quality is good at high bitrates. You can select different bitrates. If you don't display the video while capturing almost no CPU is used (all the CPU does is take bits from the USB port and write them to a file). If you display the video while capturing CPU resources will vary depending on whether or not your graphics card supports DXVA. If the graphics card supports DXVA CPU usage is minimal. If not, you'll need a dual core CPU at least.

I think this site still has some samples from the HD PVR:
http://blog.arogan.com/2008/06/hauppauge-hd-pvr-model-1212.html

The Avermedia HD box will not capture HDCP protected sources. So you probably won't be capturing from your cable or satellite box via HDMI. About the only non-HDCP sources are camcorders.

[usually_quiet]

The Avermedia HD box will not capture HDCP protected sources. So you probably won't be capturing from your cable or satellite box via HDMI. About the only non-HDCP sources are camcorders.

The HDMI port on the Avermedia HD USB is for video output. According to the documentation, it's supposed to be connected to a TV or LCD monitor. From what I gather the Arcsoft software is able to play back recorded content, send it to the Avermedia HD USB, and from there it's supposed to go through the HDMI connection to the TV or monitor.

[jagabo]

Ah, I was thinking of the PCIe version.
http://www.amazon.com/Avertv-Definition-Analog-Capture-MTVHDDVRR/dp/B002SQE1O0

[gll99]

@PuzZLeR
Fire away! The more the merrier. I'm particularly interested in these 2 external boxes since they are available locally. I also looked at a couple of pci-E cards but they seem to have many issues plus they depend on software encoding making them cpu intensive.

The HD PVR captures signals the way they come in. It doesn't upscale or downscale. A 480i input is captured as 480i. A 720p input is captured as 720p. You have a choice of TS or M2TS containers. All video is h.264 encoded, audio AAC or AC3 encoded. Quality is good at high bitrates. You can select different bitrates. If you don't display the video while capturing almost no CPU is used (all the CPU does is take bits from the USB port and write them to a file). If you display the video while capturing CPU resources will vary depending on whether or not your graphics card supports DXVA. If the graphics card supports DXVA CPU usage is minimal. If not, you'll need a dual core CPU at least.

The Avermedia HD box will not capture HDCP protected sources. So you probably won't be capturing from your cable or satellite box via HDMI. About the only non-HDCP sources are camcorders.

Thanks for the comments

Apparently the HDMi on the Avermedia is for output only. From what I read it will only play back the files that it captured. I'm assuming this means any files that are in the right container but it could be more restrictive than that. In any case both these devices use the component analog hole to capture.

Are you saying that it can save to M2TS format without involving any additional subsequent cpu processing? I ask because I read somewhere else where someone posted that the software could do real time conversion to mp4, wmv etc... while it is capturing. I take it that this would be more cpu intensive since it involves a format conversion. That is why I was really interested in knowing the true native format of each unit.

As far as format the Hauppage guide only says this:

The format created by the HD PVR is a H.264 .TS file using AAC audio

The Avernedia also makes reference to .ts files in its guide in the section on conversion

You can use ArcSoft MediaConverter to convert your AVerTV USB HD DVR captured .TS files into several formats, including iPhone (.MP4), iPod (.MP4), XBOX 360 (.WMV), PSP (.MP4), PS3 (.MP4), Philips (.WMV), SanDisk (.MOV) playable formats, etc

I'm not too up on the various formats but I do know that when I tested my computer bd reader and made a avchd the files had a .m2ts extension which worked great on my ps3 and my other stand alone blu-ray player. It might be an advantage if the Hauppauge can natively create these files already in the right format. I'm just wondering though if it's done in a post capture step after transfer or is it native to the unit. The documentation doesn't really say this.

[jagabo]

Re: Hauppauge HD-PVR: I believe what comes over the USB port is always a transport stream. The current ArcSoft capture module has presets for PS3 (M2TS), AVCHD (TS), and XBOX360 (MP4). No conversion of the audio and video streams is performed, the h.264 video and AAC/AC3 audio are simply muxed into the desired container. I usually capture with the capture graph method described in ARogan's site. That results in a TS file. Attached is a sample cap with the PS3 preset.

[SHS]

Hauppauge USB HD PVR come with the very same ArcSoft to there no diff in the included software from both Hauppauge or Avermedia in fact there one in same other then the plug-in driver to make use of hardware device, also both of them have very same Hardware Encoder chip just so you know.
How ever Hauppauge has more 3rdparty support.
Now as for the Avertv HD DVR High Definition / Analog Video Capture Card PCIe MTVHDDVRR take note that device is Software Encoding so better build one bad a$$ system for it.
Now if want Hardware Encoder in PCIe you should wait a bit for the Hauppauge Colossus HD-PVR this one is a Hardware H.264/HDMPEG2 Encoder see below to my web site and look on the forum or look on this forum I posted a link.
as for extension type it not something you need worry about it just one vs other has better Compatible like m2ts work better with PS3
The difference in ts vs m2ts is in the packet size. m2ts has an extra 4 byte sequential indexing dword before each sync byte used for seamless branching.

[Cauptain]

AverTV PCI-e version - PS3 HDMI 1080i recording converted to 1080p - Matrox VFW MPEG2 50.000 bitrate.

C2D E6600 + Windows 7 + Virtualdub

[gll99]

I notice that the Avermedia scheduler lets you preset a split on file size during capture and continue on until the end time. Does the Wintv scheduler do that? It doesn't show that option in the Hauppauge guide. It might come in handy when writing to a fat32 drive so as not to go over the 4gb limit or to capture raw video files that will fit on a sl dvd disc.

[jagabo]

I don't think Arcsoft Capture Module supports segmented capture. Though I've never tried it on a FAT formatted drive.

[SHS]

I notice that the Avermedia scheduler lets you preset a split on file size during capture and continue on until the end time. Does the Wintv scheduler do that? It doesn't show that option in the Hauppauge guide. It might come in handy when writing to a fat32 drive so as not to go over the 4gb limit or to capture raw video files that will fit on a sl dvd disc.

Don't ever use that option segmented belive me it bad idea

[gll99]

It looks like a feature of the Avermedia scheduler only. It may not work in a direct manual capture.
My first impression is that the scheduler overlays the Arcsoft capture module and controls the file breaks. I'm guessing that if the Hauppauge has that function it would be part of the WinTV scheduler. I checked the pdf guide images to see if it shows a split function but it doesn't. I was wondering if the version of the guide I have is out of date.

Even though I don't have the device, I was able to d/l and install the scheduler for testing. On further thought I'm wondering if the split occurs after the fact. The fact they call the file "source" in the advanced settings has me wondering.

[gll99]

Thanks for the PS3.m2ts file jagabo it helped me try a few things.

I tested the file on my PS3 and it played fine. I also tried it on one of my Seiki brand BD player but it didn't play. I tested some m2ts files copied from a AVCHD disk created with BD Rebuilder (originally on BD) and they played on both the PS3 and BD player so I wondered what the difference was. Using MediaInfo and BDinfo it seems that both have the same video and audio codecs (AVC and AC-3) but your file is in a Mpeg-ts container while the ones from the AVCHD out of BD Rebuilder are in a BDAV container.

Obviously for compatibility with all my devices I'd prefer the BDAV format since the raw .m2ts would play in my 3 BD players as well as the PS3. If I understand correctly then the video and audio seem to be in the same compression format so if the Arcsoft software can mux them on the fly during capture into the BDAV container I won't have to run an extra step to make compatible captures. If I'm right then it looks like either unit will work so it wouldn't factor into my decision as to which one I'd be buying.

Edit:
btw) SHS made an important comment earlier about the packet size but I wasn't knowledgeable enough to catch that when he wrote it.

You're PS3.m2ts file is really a .ts file with (188 byte packets). I guess whoever created the PS3 template used that as the default. My Seiki BD player needs a .m2ts (192 byte packets). The PS3 can read both types so it's not a problem for it.

The lights went on when I started running a bunch of small test files on the PS3 and BD player after mucking around with the tsDemuxer, tsMuxeR, h264ts_cutter and especially TsRemux which provides that particular piece of information as part of the input file specs.

[gll99]

Just a quick update:

Made a decision and bought the Hauppauge HD PVR 1219 (same as 1212) today. I'll provide some reasons and a bit more info after I've done some testing. So far all I've done is checked the content to make sure everything is in the box and it is.

Here's hoping!

[mobie29]

Another alternative would be TIVO HD. I know it is "old school" but i have compared my downloads and resulting output to dvd and blu ray to Hauppage and the TIVO is better in picture quality and sound.

[LightWeightProducer]

2 cents worth...

The arcsoft capture module can be run independantly of the main software [command line - capturemodule.exe -startr2:"name.ts" -limit:1800 -vinput:1 -cbr:1 -vbaver:8000 -aoutfmt:1 -abindex:512 -folder:"c:\recordings" ]. '1800' = capture time in minutes. The process can be killed to end the capture if operation via a script is desired.

I can't say anything about the Hauppauge USB device, but the Aver USB device cocks up the field ordering when grabbing from a PAL source. Instead of A1A2 B1B2 C1C2 the output video contains A2B1 B2C1 C2D1 (ie, fields are staggered). Even with the Fujitsu encoder 'cranked all the way up' this results in cross field distortions that make re-ordering the fields later on give ugly results.

[Bjs]

1: Both can only record 1080 from sat box's and alike via component in ... not hdmi

2: Only the avermedia devices provides output via hdmi for playback

3: Neither come with a remote (Hauppauge remote is optional only in store)

4: Avermedia device has far greater support (they actual do reply)

5: The avermedia device has far more options when it comes to using alternative software from other vendors.

6: There is nothing wrong with avermedia's incorporated "file split" function ... it simply works.

7: Both have similar system requirements

8: Quality of capture depends on individual systems design and source ... all of my pal captures are flawless ... nstc via local region broadcasters dose display field irregularities ... you must use prefilters to reduce the problem.

[jagabo]

The arcsoft capture module can be run independantly of the main software [command line - capturemodule.exe -startr2:"name.ts" -limit:1800 -vinput:1 -cbr:1 -vbaver:8000 -aoutfmt:1 -abindex:512 -folder:"c:\recordings" ]. '1800' = capture time in minutes. The process can be killed to end the capture if operation via a script is desired.

Do you know the command line to just start the capture module (for interactive use)? I've tried just running the exe (ie, skipping ArcSoft's switcher program) but it gives an error about an incorrect command line then closes.

I can't say anything about the Hauppauge USB device, but the Aver USB device cocks up the field ordering when grabbing from a PAL source. Instead of A1A2 B1B2 C1C2 the output video contains A2B1 B2C1 C2D1 (ie, fields are staggered). Even with the Fujitsu encoder 'cranked all the way up' this results in cross field distortions that make re-ordering the fields later on give ugly results.

I think what you're saying is the broadcast is top field first, but the device captures bottom field first. That shouldn't matter with proper playback. But when looking at still frames on a PC they have to be deinterlaced since each frame contains fields from two different film frames.

Could you provide s small sample? Or a link to one?

[gll99]

You have to be so careful not to comment based on first impressions.

After my first 3 caps (PS3-m2ts, AVCHD-ts. XBOX360-mp4) I would have complained that I made the wrong choice had I not taken time to reflect before coming here to comment. The playback was tearing and in some cases producing a half green scrambled screen. The fault was not with the Hauppauge. I have a borderline 2Core 2.0 and HD playback is fairly cpu intensive. What I didn't realize is that the Arcsoft software's preview mode uses a lot of cpu cycles. When I shut that down the videos played perfectly. While you can stop the preview mode during capture it restarts when the cap is done. From what I've read, I'm not the first to request a pause option on the preview so you don't have to close the capture panel to properly view the captured file.

For those who wonder about the stated computer requirements:
As far as the capture goes this thing doesn't really require a high end system. All the initial encoding is done in the hardware and then the data is transferred over usb to the computer. I tried this unit on my Athlon single core 2.0GHz and the cpu usage was minimal. The issue is more in playback or after the fact processing time if you want to edit the video. If all you want is to capture and then transfer the video to disc or a thumb drive then almost any computer will do. I'm not recommending it but just saying that it will work.

My choice of the Hauppauge over the Avermedia:
I can't knock the Avermedia. It's newer and I just couldn't get enough unbiased reviews to choose it over the Hauppauge. I did have concerns about its "self powered" feature. Somehow I was a bit concerned about an intelligent switch and wasn't sure if that meant all it's power was drawn from the usb port. I like the separate power supply and manual switch of the Hauppauge. The Hauppauge component passthrough is off when the unit is off which I don't prefer. If the Avermedia's passthrough was always active that would have been a strong selling point for me but I couldn't find any info on that. I knew both units would probably function about the same. The price difference was only $20 and the higher priced Hauppauge included a remote and I'm sure one day I'll find a use for it.

Things I've learned:
Whether you choose the PS3 (M2TS) or the AVCHD (TS) format, the Arcsoft software muxes a 188 byte packet .ts file regardless of the extension it is showing. Those files will not play in my USB equipped Blu-Ray players. I'm just learning here but it seems the M2TS label is a misnomer on these outputs. They are really all 188 byte packet .ts files. What it means for me is that if I want the most compatibility I will have to remux every file to a 192 byte packet M2TS type file. Fortunately there are free tools to make this task quick and simple. On my lowly 2Core 2.0GHz it takes about 1 minute per GB to demux and half that time to remux the files. Like I said before, since the PS3 can play both types of files it's not an issue if you only plan on playing them back on the PS3.

btw) After doing a bunch of short caps I tried a longer movie at 1080i from my cable box. The movie length was 109 minutes. Both were variable bit rates with the range set from the average rate to the maximum available. The first was at 5 Mbps to create a file that would eventually be made into a AVCHD on a sd DVDRW 4.7MB disc and the a second cap at 11 Mbps average rate to compare the difference if I wanted to write a dual layer AVCHD disc. Neither have been burned yet but I played them on my computer using PowerDVD that came with my Blu-ray reader. I output the signal to my 46" tv on the hdmi port on the video card. The video plays smoothly without any glitches and the audio is in sync. They are both great quality but the higher bit video looks the best.

Overall, the Hauppauge does what it says and in spite of having to run a few extra steps to make them BD player compatible I'm very happy with the results.

[Brad]

I can't say anything about the Hauppauge USB device, but the Aver USB device cocks up the field ordering when grabbing from a PAL source. Instead of A1A2 B1B2 C1C2 the output video contains A2B1 B2C1 C2D1 (ie, fields are staggered).

I think what you're saying is the broadcast is top field first, but the device captures bottom field first.

That would be A2A1 B2B1 C2C1. I think he's talking about the fields being offset into the next frame like you would get by SeparateFields().Trim(1,0).Weave() in AviSynth.

[jagabo]

I can't say anything about the Hauppauge USB device, but the Aver USB device cocks up the field ordering when grabbing from a PAL source. Instead of A1A2 B1B2 C1C2 the output video contains A2B1 B2C1 C2D1 (ie, fields are staggered).

I think what you're saying is the broadcast is top field first, but the device captures bottom field first.

That would be A2A1 B2B1 C2C1. I think he's talking about the fields being offset into the next frame like you would get by SeparateFields().Trim(1,0).Weave() in AviSynth.

No, I'm describing the same thing you are in your AVS script. Analog video is broadcast as a sequence of fields. If they are broadcast TFF the signal contains (the number is the film frame number, T and B are top and bottom fields from those frames):

1T 1B 2T 2B 3T 3B...

It doesn't matter if they are captured TFF or BFF. As long as the captured video is flagged correctly the final interlaced analog output will be the same.

When a device captures TFF it starts by capturing a top field, then weaves in the next field, a bottom field. In the case of a TFF broadcast the resulting frames will contain a field from each of the original film frames and look like a progressive frame when viewed together:

1T+1B 2T+2B 3T+3B.

When a device captures BFF it starts by capturing a bottom field, then weaves in the next field, a top field. Using the same TFF broacast:

(1T skipped) 1B+2T 2B+3T 3B+4T

Each frame now contains a field from two different film frames and will show comb artifacts when viewed as a frame. But when broadcast as a sequence of fields again it will be back to the original order:

(1T skipped) 1B 2T 2B 3T 3B 4T

[LightWeightProducer]

The device puts fields from adjacent frames together. This is not a case of field ordering being incorrectly flagged. Who ever set up the analogue side of the Aver box probably cocked up the field ident detection settings for the 86h52 and the rather than realising the mistake and fix the issue, kept digging the hole deeper and adjusted the encoder order settings to compensate.

I've notified Aver of the issue. It should be correctable given that the firmware is uploaded at start. All that remains to be seen is will Aver fix it.

[jagabo]

Progressive frames aren't necessarily broadcast top field first. So it's not "wrong" to capture bottom field first. Anyone who captures standard definition analog video with a DV device has the same issue (DV is always BFF). And this only applies to progressive sources. True interlaced video is neither TFF nor BFF but simply an alternating sequence of top and bottom fields.

[usually_quiet]

5: The avermedia device has far more options when it comes to using alternative software from other vendors.

Windows Media Center can be used with both devices, although a 3rd party plug-in is required for either. Sage TV and Beyond TV support the Hauppauge USB HD PVR. I've seen reports of people using the Hauppauge USB HD PVR with GB-PVR / NPVR, as well as Myth TV. Neither should be able to work with Virtualdub or DScaler because they both provide hardware compression only. So, which software supports the AverTV USB HD DVR, but not the Hauppauge USB HD PVR, other than the manufacturer's?

[LightWeightProducer]

Progressive frames aren't necessarily broadcast top field first. So it's not "wrong" to capture bottom field first. Anyone who captures standard definition analog video with a DV device has the same issue (DV is always BFF). And this only applies to progressive sources. True interlaced video is neither TFF nor BFF but simply an alternating sequence of top and bottom fields.

Analogue video (PAL, NTSC etc) is not just a blind sequence of fields transmitted sequentially. There is very much a first field and a second field. As I said before, this is not a case of field order (TFF, BFF). This is a case of the device possibly incorrectly detecting field ident (the most likely cause but there are possibilities, line offsets etc) and the consequences thereof.

People who use DV devices (output frames are BFF) do not experience this problem. Every DV bridge I have come across correctly detects field ident ie, the scan lines in the DV frame are both from the same analogue source frame but the first line is from the bottom field instead of the top field.

They say pictures tell a thousand words. So here's some pictures. Hopefully they put the discussion of the problem to rest.

No amount of in frame field order switching will fix aver.png. The DV (canopus ADVC100) frame of course has BFF, but otherwise is correct - both fields are from the same frame. Apart from field ordering, the source MPEG-2 video appears as dv.png, not aver.png.

The family of devices that correctly detect field ident is large and includes Hauppauge PVR150, HVR2200, Pioneer DVD recorders, Lifeview PCI capture cards, Sky PCIe HD capture cards, etc etc. Its rare to encounter a device that gets it wrong, but the Aver is one of them.

[LightWeightProducer]

Do you know the command line to just start the capture module (for interactive use)? I've tried just running the exe (ie, skipping ArcSoft's switcher program) but it gives an error about an incorrect command line then closes.

CaptureModule.exe /@RecordVideo@

[jagabo]

No amount of in frame field order switching will fix aver.png.

Vaporeon800's AviSynth script above will probably fix that video. It looks like exactly the issue I described. I deal with PAL videos like that all the time. It does happen with DV camcorders. It may be inconvenient but it's not wrong. Can you provide a short sample video?

Your sample image has the chroma channels screwed up but that is probably a result of the way you processed the image, using a program that doesn't handle interlaced chroma properly, like VirtualDub.

CaptureModule.exe /@RecordVideo@

Thanks, I'll try it out.

[LightWeightProducer]

Vaporeon800's AviSynth script above will probably fix that video. And it looks like exactly the issue I described. I deal with videos like that all the time.

His fix is to pull fields in from adjacent frames, which of course will fix it (the telecide function of the decomb avisynth plugin will handle it simply by telling to maintain 'PAL lock'). However it can not fix the interfield distortions (caused by the filtering and also encoder configuration in the Aver box) that will become aparent when the fields are pulled back together. (examples can be provided if its really necessary)

It does happen with DV camcorders.

I can't speak for camcorders. I only have experience with standalone bridges, which to date have exclusively got the field ident right.

It may be in inconvenient but it's not wrong unless the field order is flagged wrong. Can you provide a short sample video?

Of course it plays correctly given that the field ordering et al does result in fields being output at the right time and in the right order. That is not the issue. Feel free to keep offering 'help' but I won't be here to read it. I've got better things to be doing than this.

[jagabo]

Of course it plays correctly given that the field ordering et al does result in fields being output at the right time and in the right order. That is not the issue."

it can not fix the interfield distortions (caused by the filtering and also encoder configuration in the Aver box) that will become aparent when the fields are pulled back together.

That' is a separate problem from whether the two fields come from the same film frame.

(examples can be provided if its really necessary)

I would love to see a sample video so I can see what the problem is. I'd love to be educated on the matter.