1394 and compressing analog Re: [mythtv-users] Beginner Question

[Brad Templeton]

On Sun, Dec 19, 2004 at 10:06:19AM -0800, Ian Forde wrote:
> On Sun, 2004-12-19 at 09:20 -0500, Joseph Caputo wrote:
> > What you want to do *may* be possible, as the FCC has required cable 
> > operators to provide an enabled FireWire port that you may use to 
> > capture the digital (MPEG) data that your cable box has decrypted (but 
> > not decoded).  The catch is the content accessed via FireWire will not 
> > be HD... any HD content will have been transcoded down to a lower 
> > resolution (say, 480p).  In any event, Myth does not currently support 
> > capturing video over FireWire.
> 
> Yep - about that - there's a new library called libiec61883 (available
> from www.linux1394.org in subversion) that supports firewire capture.
> I've been testing that capability with massive amounts of assistance
> from Dan Dennedy, it's author.  (He also wrote ddr1394.)  I've gotten it
> to capture HD streams with a sample program that he wrote, so a release
> may be soon forthcoming.
> 
> I've got packages available too, if anyone wants to test the capability.
> 
> What we need now is for someone to take a look at the sample capture
> code included in the package and adapt it for use within Myth.  Anyone?

Actually, I'm more interested in the reverse, having Myth stream the mpeg
to the TV over 1394 or DTVLink as they now call it.

I got some code from the linux 1394 guys that may be on the path to doing
that.  The reports are that dtvlink mpeg streaming is not a lot different
from dv streaming for camcorders, which is what all the past linux
projects have been doing with video.

Also on the plus side, I believe that mpeg includes a bitmap overlay
that can do on-screen-display -- is this what is already done when using
xvmc and OSD?

The one component that would be missing would be menus over firewire.

You would need to write a framebuffer driver which took each frame and
compressed it to dv format or mp2 format and streamed that out.  Though
who knows, perhaps you could fake something with a blank mpeg and the
bitmap overlay?   Alternately, I believe on many TVs they display a
regular analog input until the mpeg comes and they switch to it and back.

For extra credit you would interpret the remote control backchannel so the
tv's remote control controlled myth.

I don't know enough about firewire protocols to make this happen.

----------------------------

The bad news is those firewire streams out of the cable box or satellite
box are going to be encrypted and/or the box will refuse to send them
to any device that doesn't have the authentication codes licenced from
the oligopoly.  (ie. 5C etc.)   You won't get them for an open source
box.

----------------------------

On another note, the original question asked one of the most common
mis-questions when it comes to HDTV.   Analog, uncompressed HDTV could
be captured by an analog "capture card"  but probably not any of the ones
people use for orindary NTSC TV which I doubt have the bandwidth.  Even
if they did have the bandwidth, you would need to convert it to a
compressed form in real-time.   Hardware to do that to mpeg-2 is thousands
of dollars (though it might become cheaper.)

In truth you probably would not use a "capture card" because it would
make far more sense to record DVI, which is already digital, and for
which decoding chips are available.

It's possible you might be able to pull of something less ambitious than
mpeg2 though, but it's hard to figure if it could be done in software
with today's processors.

Without compression the files would of course be giant.   186 megabytes per
second at 8 bit per colour capture.  671 gigabytes per hour.

Yikes...   That is in fact beyond the capacity of your disk drive to write.
You would need dedicated multiple spindles with striping.

However, another option that might be possible is to figure out how much
compression you _could_ pull off in real time with a fast CPU, such as
a 3.4ghz P4.

Say you could do a very basic compression in hardware or software
and get it down to 100 gigs per hour (7 to 1).   Then at least you can
write it to your dedicated disk.   And from there you could start up
a thread on another processor to, in non-real time, compress it to
mp2 or mp4.   You might even take 2 stages, one that is fast but not
quite real time, and another that is slow but much better compression.

Why?  Well, the problem is that if you are spitting out 100 gigs/hour,
it will take a lot of disk space even to temporarily hold an hour.  You
probably can allocate a 400gb disk and hold 4 hours.  Once that's full,
you can't record any more, not until your compression threads can free
up disk space.   So if you have a long event or long movie you can't
record anything else until the next morning.

And of course 400gb disk drives are still somewhat expensive but that
will drop.

Forget about having 2 tuners without having 2 computers, each with a
fast processor, giant disks and encoder card.

It all depends on how much you can pull off with hardware and software
in real time.   And of course if custom hardware arrives that sets you
well on the path.

Other tricks that might make sense include immediately discarding
resolution.  For example, record 1080i at 960x540.  This is still pretty
decent if not of course as sharp as 1080i, and it is 1/4 the raw data,
"just" 167 gb/hour without compression.    For 720p you could cut to 30fps
and chop to 960x540 as well.

As you may know, most HDTVs sold today are 1280x720 anyway, no point in
recording full 1080i.

Of course, this is only for your cable/satellite channels.  Your OTA
channels will come to you in unencrypted QAM or ATSC or DVB.


Finally you could sacrifice a lot -- and drop down to 720x480, 30fps,
which is effectively EDTV.  Most Plama TV owners are happy with that anyway.
It's a DVD.  For that you could get hardware decoder chips cheap (DV for
example) and would just need to add hardware to downsample/interpolate.

There's also HuffyUV (huffman encoded YuV).  I don't know if cheap chips
are available for that.


Any hardware designers out there know if they could make an FPGA
do some basic DVI reception and say a 4 to 1 compression in real time?
That would give you 960x540 in 42 gigabytes per hour, which is now
entirely manageable.