[linux-dvb] HD capture
abraham.manu at gmail.com
Fri Feb 22 21:31:34 CET 2008
> James Klaas wrote:
>> On 2/21/08, CityK <CityK at rogers.com> wrote:
>>> James Klaas wrote:
>>> > HD capture ...... HDMI/component/composite
>>> Whether it be done through an analog connection (eg. component) or
>>> digital connection (eg. HDMI/DVI/SDI), it all falls under the realm of
>>> the V4L subsystem, not DVB.
>> Is that because it purports to capture the streams without
>> compression? Or does that have more to do with a lack of a tuner?
> To be specific, its because the DVB API is about the reception of a
> Digital Video Broadcast, and those are made in form of a Transport
> Stream modulated onto a RF carrier....
DVB isn't completely about a RF carrier. It is used in the studios,
(interconnectivity) at the production levels (studios) as DVB-ASI as well.
consequently, anything DVB entails
> a receiver....second thing to note is that, although the terminology
> "capture" is widely used in reference to digital applications just as
> much as it is with analog, it is a misnomer when it comes to DVB....
There are DVB-ASI transmitters too.
> devices are essentially network interfaces ... they are entirely akin to
> your computer's modem --- both have a receiver that acquires an RF
> siganl and then demodulates the underlying information of interest off
> that carrier wave.
This is true for DVB demods, not otherwise. Generally we see a lot of DVB
demods, but doesn't mean it is just that alone.
> There is little difference between downloading a
> file from kernel.org, or Mircosoft, or from where ever, and saving that
> file to your hard disk, as there is to tuning to ABC, or PBS, or
> whatever station, and saving the TS or the underlying program stream
> (multiplexed within the TS) to your harddisk.
> So, turning to the examples quoted above:
> - Component: an analog signal that has nothing to do with DVB ... sure,
> you can build a DVB device that includes the facilities to capture
> component (and other analog sources) ... and by capture here, its meant
> that ADC has to be done first to convert the analog to a digital
> bitstream and then place it into a particular container format and save
> to disk.... but that aspect has nothing to do with DVB, and hence is
> covered by other subsystem (V4L)
many newer DVB devices will switch over to a "one single package concept"
where it will be one chip for all, in such cases, no V4L will exist for
except for a vanilla TV out interface. Such devices feature a generic
under the Video subsystem (not to be confused with V4L), where devices
For V4L to work with devices that way, it will need to copy more from
subsystems such as Video, DVB and ALSA since V4L alone is not any specific
"real" subsystem pertaining to something in real life. V4L just
originated as a
means to tune Analog TV cards under Linux, which later went in a
> - HDMI: an uncompressed RGB or YUV digital bitstream ... not applicable
> to DVB ... sure, you can build a DVB device that includes the facilities
> to capture that digital bitstream...and by capture here, its meant that
> the stream is placed it in a particular container and saved to disk
> (either uncompressed or, if you so choose, with a codec -- either a
> lousy one or a loseless one) .... but that aspect has nothing to do with
> DVB, and hence should be covered by another subsystem (V4L)
> - DVI: same as HDMI
> - SDI (and in this case, you'd be interested specifically in HD-SDI, in
> SMPTE 372M): another uncompressed digital bitstream interface protocol
> ... comments are the same as the others
> In fact, speaking of what V4L would/should cover, see the first
> paragraph here:
> About the only thing otherwise related to the DVB API would be the
> highly related DVB-ASI or SPI. Questions about extending the DVB API to
> include coverage of those were raised last year when Manu solicited
> suggestions on progression of the API; if you're really interested, see
> this lengthy thread here:
> http://marc.info/?l=linux-dvb&m=118989203715847&w=2 )
>> Partly what piqued my interest is there has been a great deal of talk
>> about how capturing HD streams without compression is very difficult
>> without very high end components, very expensive capture cards etc,
> - Uncompressed is actually not very CPU intensive, but it is (a) HIGHLY
> bandwidth intensive and, consequently, (b) GIGANTICALLY_EXPENSIVE
> storage wise .
> It is very easy to describe both the bandwidth and, hence, storage
> considerations --- mathematically, for the video portion, its simply a
> Fn(frame size (i.e. resolution), frame rate, subsampling (i.e. 4:4:4,
> 4:2:2,...), and bit depth). To completely describe the rate, you can
> factor in the overhead requirements of the file container which you use,
> though its contribution to the total is entirely negligible compared to
> that of essence's.
> For an example of how to apply that knowledge to real world examples,
> read through from this post:
> - Compressed, on the other hand, is CPU Intensive
At these levels, the hardware to be used is much proprietary and Linux won't
make much of a dent, where the users are quite used to their production
environments with other OS and applications (such as Viz RT for example)
there isn't anything quite near or usable to this under Linux, nothing
DVB or V4L
will be seen in the public, though there (are/might be) some proprietary
some intermittent stages, but nothing that will have a whole Linux
concept in such
areas of usage
In such cases the hardware and hardware device drivers are of very
but the main concern is about the virtual instruments implemented in
as decks and other things and so on.
A broadcast professional, never has the time to learn or work with
stuck together with plaster. He just wants to get things done in the
for something to be aired. He doesn't care about the cost, nor the OSS
but just about time involved in it.
Generally Linux makes a dent where cost is involved, but at the High end
is not a subject, yet to see Linux, even if something exists, that will
proprietary, nothing OSS.
>> It was surprising to me that you could in fact find something
>> like this for less than $1000. With a card like this, it would be
>> conceivable to create a HD capture system for well under a $1000.
> Computers are getting more powerful, and components are getting
> cheaper....still, there are more things to consider then meets the eye
> -- as that Doom9 thread alludes to, depending upon whether your trying
> uncompressed or compressed, there are storage considerations, sustained
> transfer rates to consider, codec issues, maybe digital restrictions
> management issues (with an interface like HDMI), processor considerations...
For large applications, storage isn't much of a concern, as the users
such as studios
have extremely large video servers, explicitly used for the same
purpose. Little to be
heard about Linux in this area where Windows and Mac systems rule. The
educated only on specific applications that run on them.
More information about the linux-dvb