HDMI Input Card

[lobosrul]

Stanger, unless you have a hardware decoder card, all analog cards use software encoding. SD encoding takes very little procesing power. By my math a 720p resolution has around 3x the number of pixels as an 640x480. However that doesnt mean the data stream isnt 10000 times larger.

Also, read my edit from the post above.

As I stand now, sattellite might not be an option for me D: If it was id just go with the r5000. And every new channel comcast has added lately is 5C'd. Im afraid one day every channel but the locals might be.

Oh one last point. I do mpeg-4 encoding and watch TV at the same time all the time. The encoder generally doesnt use all my system resources.

[blade]

Originally Posted by lobosrul

Stanger, unless you have a hardware decoder card, all analog cards use software encoding. SD encoding takes very little procesing power.

Completely untrue. Decoding has absolutely nothing to do with encoding. Also most everyone uses hardware encoders such as the PVR150/250/500, ATI 550, etc...

[Mark SS]

A top end PC (i.e. recent dual core) would probably manage to encode an uncompressed HD video stream to MPEG2. As a rough guide, I have an SDI capture card in my HTPC (capturing from SDI Sky box) which uses a software encoder that chugs along at around 20% CPU on my 4200x2. Pixel count for HD is 5x that of SD (720x576 vs 1920x1080) so in theory it could be done. My understanding of colour space encoding is currently close to zero so I don't know if the differences in SD/HD here would make much difference. I'm also assuming (probably incorrectly) that there would be a linear increase in CPU usage as pixel count increases.

As a quick test I setup graphedit to realtime encode the SDI stream to Xvid/Mp3 and this required 30% CPU. Not an xvid expert by any stretch of the imagination so this was with the default settings the filter presented. That said, it was pretty good quality on playback.

[stanger89]

Originally Posted by lobosrul

Stanger, unless you have a hardware decoder card, all analog cards use software encoding.

Don't confuse encoding with decoding, but yes, all analog cards without a hardware encoder are using software.

What confuses many is "software" vs "hardware" HD cards. In the case of ATSC cards, the "software" vs "hardware" refers to decoding, vs NTSC (SD) cards where those terms refer to encoding.

HD is not encoded when it is recieve, by either "software" or "hardware" HD cards, they all work the same, they just save the MPEG-2 bitsream.

SD encoding takes very little procesing power.

Doesn't mean it works well.

By my math a 720p resolution has around 3x the number of pixels as an 640x480.

3x the pixels and 2x the framerate, or 6x the pixels/second. 1080i is 6x the pixels, and the same framerate, also 6x the pixels/second.

However that doesnt mean the data stream isnt 10000 times larger.

Uncompressed HD, 24bpp, is about 1.5Gbps. (600GB/hr)
Uncompressed SD, 24bpp, is about 0.25Gbps (100GB/hr)

Or 6x as large.

Also, read my edit from the post above.

And how much power will it take to do that compression? I venture it will almost max out even the top-end machines, that or it will only nominally reduce sizes.

And if you reduce the quality much, you might as well just capture the SD and be done with it.

The question is, will any of those be compatible with SageTV as a capture device?

Probably not. First Sage doesn't (or barely) supports software encoding. Second, I wouldn't expect them to release WDM drivers for it, and finally I doubt Sage will make any effort to support the card, as it would be a very problematic product.

As I stand now, sattellite might not be an option for me D: If it was id just go with the r5000. And every new channel comcast has added lately is 5C'd. Im afraid one day every channel but the locals might be.

That's basically the general concensus. Right now, you're extremely lucky if you've got anything but locals in the clear.

Oh one last point. I do mpeg-4 encoding and watch TV at the same time all the time. The encoder generally doesnt use all my system resources.

Consider a few points, playback is rather trivial, especially SD, if you've got hardware accelleration. Second, you're doing non-realtime encodes, and those aren't hurt if their processing is interrupted.

Realtime capture is much different, I don't know if you ever had to deal with recording SD without hardware encoders, but I did, and it sucked. HD recording today (uncompressed HD recording) is about where SD recording was before Hauppauge released the first hardware encoder card (the WinTV PVR-PCI, which I still have). Recording SD in those days was painful, I remember my computer could barely capture full-resolution SD in MPEG-2, and you had to be careful not to do anything on the PC to interrupt the recording as that would mess it up.

I maintain, that until we have a card with HD inputs and an onboard hardware HD encoder, recording uncompressed HD for PVR use is completely impractical.

[lobosrul]

Originally Posted by stanger89

I don't know if you ever had to deal with recording SD without hardware encoders, but I did, and it sucked.

Im still not entirely sure I'm on the same page as you are here. I have an ATI HDTV Wonder. I thought the reason it's so cheap is the lack of hardware encoders. SD works flawlessly BTW (yes I realize the HD stream is already encoded, I cant believe I said differently before).

Actualy, circa 1998 is when I bought my first TV Tuner. Also an ATI, and very cheap. It worked (but not without problems) on a 300mhz K6-2 and 64MB of ram. I eventualy had to throw it out because it absolutely would not work with Win2k, and there was no way I was going back to Win 98.

If HD encoding is truely only 6 times more intensive than SD encoding, then I find it entirely feasible that my current machine could handle it. 2x3200 MHZ 64-bit with SSE2 etc, 2 GB of DDR2 versus a 300mhz K6-2 is far far greater than a 6x improvement.

And if not, then surely one of the Intel Quadros that we'll see in a few months can.

[shish]

What really kills the "linear scaling" estimations for going from SD to HD encoding is that a standard uncompressed SD 640x480 frame comes in around 900 KB/frame while an uncompressed HD frame tends to be at least 3 MB (often more). The larger frame causes most processors to take a cache hit (store part of the frame in the system memory) as opposed to being able to store the whole frame in the L2 cache. This will be the primary problem with using a software based encoder. However, the rate at which processors are improving (quad core coming soon) and memory bandwidth is ever increasing, so you never know what tomorrow will hold...

[lobosrul]

Well I do have 2 MB of total L2 Cache (1MBx2). Sounds like one may need 4 MB.

[stanger89]

Originally Posted by lobosrul

Im still not entirely sure I'm on the same page as you are here. I have an ATI HDTV Wonder. I thought the reason it's so cheap is the lack of hardware encoders. SD works flawlessly BTW (yes I realize the HD stream is already encoded, I cant believe I said differently before).

Lack of hardware decoders. For example the MyHD, which is much more than the HDTV Blunder, is more because it has a Janus hardware decoder on board. The MyHD does not have a hardware encoder (like the Conexant CX23146 on the PVR-150).

Actualy, circa 1998 is when I bought my first TV Tuner. Also an ATI, and very cheap. It worked (but not without problems) on a 300mhz K6-2 and 64MB of ram.

OK, but was that for recording? I had an ATI TV Wonder and while you could record with it, it took most of the system resources, and wasn't very robust.

If HD encoding is truely only 6 times more intensive than SD encoding, then I find it entirely feasible that my current machine could handle it.

Probably more than 6x more intensive.

2x3200 MHZ 64-bit with SSE2 etc, 2 GB of DDR2 versus a 300mhz K6-2 is far far greater than a 6x improvement.

Well just for the heck of it, I re-encoded an HD TS file I have to MPEG-2 19.2Mbps CBR in TMPGEnc. It took 2:06 to encode 0:26 of video. That's about 1/5 realtime, and on an Athlon 64 X2 4200 (2.2GHz x2), and yes, TMPGEnc is mutlithreaded. I was pegged during the encoding.

Granded there's some performance to be had by eliminating the decoding part, but we still need about a 5x increase in CPU power to make realtime HD encoding practical.

And if not, then surely one of the Intel Quadros that we'll see in a few months can.

Maybe.

[Mark SS]

Originally Posted by shish

The larger frame causes most processors to take a cache hit (store part of the frame in the system memory) as opposed to being able to store the whole frame in the L2 cache.

Hadn't considered that aspect which of course makes perfect sense.

[Bryann]

I had a thought tonight but I'm probably dead wrong since my understanding the inner working of HDTV electronics is rather limited.

HDTVs that have built-in mpeg2 decoding take care of de-interlacing, converting resolutions, detecting aspect ratio, etc. Since this card has HDMI output, would it be possible to output an mpeg2 stream to the television through this card and let it (your HDTV) deal with making it display properly without the need for decoders, overscan, etc. on an HTPC? It should be possible assuming that the TV can decode an mpeg2 stream coming in via HMDI. You'd just need that card to output in mpeg2 and have Sage simply pass the signal through. Essentially, you're just delaying exactly the same signal it would get from CableCard or what-not. I assume it would work since they'd logically have planned (assuming they used logic) to accept HDMI or DVI mpeg2 streams from STBs to the HDMI ports on the TV.

Am I ignorant or is this the ultimate no muss, no fuss HDTV output solution we're all looking for?

[Mark SS]

The card in question is for capturing the raw uncompressed video stream being output from your receiver (e.g. satellite box), not an mpeg2 stream. To be any use in a PVR we need to compress that stream using a video encoder (mpeg2 or preferably mpeg4) so we can store and then replay it later.

The HMDI socket on any television is there to accept and display an uncompressed stream. Any decoding hardware built into a set is to decode the stream from for example Freeview.

[stanger89]

HDMI caries raw video, not MPEG-2.

[Bryann]

Ignorance wins!

[lobosrul]

Stanger, TMPGEnc is a notoriously slow encoder (at least thats what I read yesterday). Theres absolutely no rational explanation of why its slower than encoding to h.264.

Bryann, this might be the ultimate solution, but its definantly NOT no fus, unless the card has a hardware encoder on it (I really really dont think so), or it has some very efficient software encoders built in that sage can use. HOWEVER, after playing around with graphedit yesterday, I believe this is quite possible.

I put together a graph that decoded an mpg then re-encoded it using SageTV's encoders, then re-decoded it and used graphedits (built in?) playback. (Thanks for the idea Mark).

I used a 720p source file (mpg); after tweaking the settings in SageTV's decoder I had ALMOST completely smooth playback, but the quality suffered. I also tested out a standard def file, it played back smoothly, about a 25% load.

Also remember, I was decoding everything twice, and could only use the NVIDIA decoders for the final decode (without crashing). The first set of decoders (i had the best luck with GPL MPEG) put about a 10% load on my system themselves.

I did some searching and found what I think is a much faster decoder than SageTV: http://www.cinemacraft.com/eng/index.html , the "Basic" version has a free trial and is $58, I dont know what magic the other ones do, but they are over a grand. The downside is it only outputs to 720x576. I will try them out this afternoon and post a screencap of graphedit.

Im not entirely sure this will be feasible on my AMD 4400+, but for someone with a fast Intel Core2 Duo it should be. And a few months from now with a quad core I think it definantly will be.

[Bryann]

Yeah, what I meant by no-fuss was finding a way to let the TV handle all the de-interlacing, up/down conversion, overscan, aspect ratio, etc. where you know it's handled to your satisfaction instead of doing it on the HTPC. Why rely on various decoders to handle that stuff instead of your TV which is perfectly capable? It's already built in there, might as well utilize it. I just don't know enough to figure out how to do it.

[lobosrul]

Bryann, the TV is decoding an ATSC (for OTA broadcasts) stream. Its turning a relativly small stream into a MONSTROUS one, 24 bits (or 3 bytes) for every single pixiel one Red, one Green, and one Blue.

Think of the difference between a JPEG picture and a bitmap. Now imagine 60, 1280x720 bitmaps a SECOND. The HDMI output is that raw output.

Many cable boxes can now send that encoded stream (QAM???) thru firewire right to your computer, and sage can use that stream just fine. However many channels are 5C'd. This means if on the other end of the firewire cable the cable box doesnt see an "approved device" it doesnt send a signal over if a copy protect bit is set.

Something at the end of the HDMI stream has to re-encode the massive stream back to something reasonable (an MPEG2 is sort of a standard). Atleast for recording, if all you wanted was playback then... well you should bypass the computer completely. Im not sure a standard disk could even handle the stream, its that big. And even with a whole TB you could only hold maybe 90 minutes of raw video.

I cant believe the card doesnt do some sort of encoding by default, or it wouldnt even be useful to someone just wanting to edit HDV. Unless they were a profesional, in which case theyd probably be using SDI.

Correct my if im wrong Stanger.

[Bryann]

I know all about firewire capture, that's what I use. What I'm talking about is finding a way to take advantage of the TVs built-in processing features such as de-interlacing, detecting/adjusting aspect ratio, overscan, etc.

[lobosrul]

I just read on a forum the card supposedly has hardware downconversion. Im guessing the stream would still be larger than ATSC but if its in the neiborhood of 50mb/s (22 GB/Hour) it would be usable.

[stanger89]

Originally Posted by lobosrul

Stanger, TMPGEnc is a notoriously slow encoder (at least thats what I read yesterday). Theres absolutely no rational explanation of why its slower than encoding to h.264.

Slow, but it's an example, and I don't think it's slower than x264.

I put together a graph that decoded an mpg then re-encoded it using SageTV's encoders, then re-decoded it and used graphedits (built in?) playback. (Thanks for the idea Mark).

I tried the same thing, 1080i ts -> Sage splitter -> Sage decoder -> Sage Encoder -> Sage Decoder -> Renderer, plus the audio path.

My Athlon 64 X2 4200 is nowhere close to smooth, I see one frame every second or so. And you really need to have the audio portion in there, otherwise it's very hard to tell if it's maintaing framerate or not.

Also remember, I was decoding everything twice, and could only use the NVIDIA decoders for the final decode (without crashing). The first set of decoders (i had the best luck with GPL MPEG) put about a 10% load on my system themselves.

Well the benchmark should be simultaneous decode and playback, so it's not that out of line. Removing one decoder and replacing the second decode with a file writer, is a very good approximation of what's involved in timeshifting (or recording while playing something else). However even this doesn't really help any. You can see no video this way, but you can hear audio, and it's far from smooth.

Remember though, we need enough power so that we can easilly capture plus have enough headroom so that other operations don't interrupt the recording.

Also consider that the standard HD format is almost universally 1080i, not 720p. That's 62Megapixels/sec for 1080i vs 55 Megapixels/sec for 720p. So that's a bit worse than your 720p tests.

Many cable boxes can now send that encoded stream (QAM???)

QAM modulation carries the MPEG-2 transport stream over the cable line. Firewire just sends the MPEG-2 transport stream directly (kind of like streaming over a network).

thru firewire right to your computer, and sage can use that stream just fine. However many channels are 5C'd. This means if on the other end of the firewire cable the cable box doesnt see an "approved device" it doesnt send a signal over if a copy protect bit is set.

Something at the end of the HDMI stream has to re-encode the massive stream back to something reasonable (an MPEG2 is sort of a standard). Atleast for recording, if all you wanted was playback then... well you should bypass the computer completely. Im not sure a standard disk could even handle the stream, its that big.

With the new 750GB drives, you could probably record 1-2 hours, depending on if it's 24bit RGB or 12-16bit YUV video over HDMI.

And even with a whole TB you could only hold maybe 90 minutes of raw video.

Worst case scenario is about 600GB for one hour of 1080i.

I cant believe the card doesnt do some sort of encoding by default, or it wouldnt even be useful to someone just wanting to edit HDV. Unless they were a profesional, in which case theyd probably be using SDI.

At $250, there's no way it's god an encoder on board. Even the $1000 Decklinks don't have that, at least I don't think they do.

Correct my if im wrong Stanger.

Nope, basically right.

I just read on a forum the card supposedly has hardware downconversion. Im guessing the stream would still be larger than ATSC but if its in the neiborhood of 50mb/s (22 GB/Hour) it would be usable.

But if you're going to record downconverted HD, what's the point in going through all the trouble of doing this, you might as well just capture the already downcoverted S-Video.

Yes it can capture HD, and yes it's inexpensive. However, best case, you're going to have to build/buy a top of the line PC, we're talking probably 4 cores, be it a core quatro, or dual dual-cores, and lots of HDD space. And even then, at best, you're just over the threshold.

I just think a lot of people see this "inexpensive" card capable of getting their hopes up way too far.

[Mark SS]

http://tomshardware.co.uk/2006/09/10...uk/page10.html

24 seconds of 1920x1080 mpeg2 encoded to H.264 came in at 109 seconds on one of the new Core2 Quadros which has 2x4mb L2 cache.

Wishful thinking indeed.