[linux-dvb] HD capture

[linux-dvb] HD capture

[James Klaas]

There was a discussion over on the mythtv-users forum on HD capture
that devolved into another discussion, but there was an article on
converting your HD-DVDs to Blue-Ray
(http://howto.wired.com/wiki/Convert_Your_HD_DVDs_to_Blu-Ray).  They
pointed to a HDMI/component/composite capture card at
http://www.blackmagic-design.com/products/intensity/.

While I wouldn't expect this to be supported anytime soon, has anyone
even looked at this?

James

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[Steven Toth]

James Klaas wrote:
> There was a discussion over on the mythtv-users forum on HD capture
> that devolved into another discussion, but there was an article on
> converting your HD-DVDs to Blue-Ray
> (http://howto.wired.com/wiki/Convert_Your_HD_DVDs_to_Blu-Ray).  They
> pointed to a HDMI/component/composite capture card at
> http://www.blackmagic-design.com/products/intensity/.
> 
> While I wouldn't expect this to be supported anytime soon, has anyone
> even looked at this?

Hey James,

I'm not aware of a driver but I'd _really_ like to see one. I would do a 
driver but I can't afford the hardware.

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[CityK]

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.

V4L API's current facilities may not even extend far enough for such 
applications anyway .... I'm not certain, nor really qualified to 
comment (so someone with a more authoritative opinion should be listened 
to/consulted), but I expect that this would be rather pioneering with 
the current API and, hence, would require some additions/extensions to 
be made before such tasks could be realized.

> There was a discussion over on the mythtv-users forum on HD capture
> that devolved into another discussion, but there was an article on
> converting your HD-DVDs to Blue-Ray
> (http://howto.wired.com/wiki/Convert_Your_HD_DVDs_to_Blu-Ray).  They
> pointed to a HDMI/component/composite capture card at
> http://www.blackmagic-design.com/products/intensity/.
>
> While I wouldn't expect this to be supported anytime soon, has anyone
> even looked at this?

- By chance, in that discussion on the mythtv-users forum to which you 
refer, did any of the contributers/posters search that m/l's own 
archives in respect to the Intensity? If not, then in this thread ( 
http://www.gossamer-threads.com/lists/mythtv/users/223410#223410 ) you 
will see that Blackmagic reportedly expressed some openness towards the 
idea of Linux support. I haven't heard of anything further on the matter 
than that ... that doesn't mean that there hasn't been anything else 
said, and perhaps there is indeed some follow up ... I don't know ... 
but either way, that will require some searching, and that I leave as an 
exercise for someone else.

- in regards to whether anyone around here has looked at this, I don't 
think any of the regulars ever have ... let alone ever considered it ... 
most people wouldn't even be aware of it (and the other existing 
alternatives ) ... in addition, it would be new territory, and likely a 
difficult development process ... so if there is anyone working on that 
device, or looking at it, its likely they are not directly associated or 
involved around here.

- in addition to BM's Intensity and Intensity Pro, there are a few other 
"cheaper" solutions that are available. This thread on Doom9 (and 
despite its title) makes mention of them and provides examples of some 
of them in use: http://forum.doom9.org/showthread.php?p=1044824#post1044824

- as far as I know, the more expensive professional and prosumer 
solutions (i.e the AJA xena's, BM Decklinks, Accustreams, Bluefish444 
cards etc etc) do have Linux support ... albeit, it is through 
proprietary SDKs or developed inhouse by the production studios using 
such products . There was a brief discussion about these on the V4L 
mailing list a few years ago; see/read through this thread: 
http://marc.info/?l=linux-video&m=115374256412690&w=2

- lastly, did that MythTV-users thread mention the forthcoming Hauppauge 
HD-PVR (component input) ? ... given that the LinuxTV developer rank 
does include a couple of guys from Hauppauge, and given that both of 
them have made mention of that device, and given Hauppauge's stance on 
Linux support is very positive, I'd be willing to bet that the chances 
of open/publicly available support for this device materializing are 
far, far greater than any of the other devices mentioned 
above.....though, bear in mind there are, of course, never any 
guarantees or certainties, nor am I speaking on the behave of anyone.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[James Klaas]

First, let me say that This is not in my near term purchase plans, but
I was mostly curious to know the possiblities of support of this (or
something like it) long term. This is the thread that got me
interested in asking
http://www.gossamer-threads.com/lists/mythtv/users/317435.

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,
etc.  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.

On 2/21/08, CityK <CityK@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?

>  V4L API's current facilities may not even extend far enough for such
>  applications anyway .... I'm not certain, nor really qualified to
>  comment (so someone with a more authoritative opinion should be listened
>  to/consulted), but I expect that this would be rather pioneering with
>  the current API and, hence, would require some additions/extensions to
>  be made before such tasks could be realized.

>  > There was a discussion over on the mythtv-users forum on HD capture
>  > that devolved into another discussion, but there was an article on
>  > converting your HD-DVDs to Blue-Ray
>  > (http://howto.wired.com/wiki/Convert_Your_HD_DVDs_to_Blu-Ray).  They
>  > pointed to a HDMI/component/composite capture card at
>  > http://www.blackmagic-design.com/products/intensity/.
>  >
>  > While I wouldn't expect this to be supported anytime soon, has anyone
>  > even looked at this?
>
>
> - By chance, in that discussion on the mythtv-users forum to which you
>  refer, did any of the contributers/posters search that m/l's own
>  archives in respect to the Intensity? If not, then in this thread (
>  http://www.gossamer-threads.com/lists/mythtv/users/223410#223410 ) you
>  will see that Blackmagic reportedly expressed some openness towards the
>  idea of Linux support. I haven't heard of anything further on the matter
>  than that ... that doesn't mean that there hasn't been anything else
>  said, and perhaps there is indeed some follow up ... I don't know ...
>  but either way, that will require some searching, and that I leave as an
>  exercise for someone else.

That particular thread did not mention the Intensity.  But it did
mention the HD-PVR at one point at least.

>  - in regards to whether anyone around here has looked at this, I don't
>  think any of the regulars ever have ... let alone ever considered it ...
>  most people wouldn't even be aware of it (and the other existing
>  alternatives ) ... in addition, it would be new territory, and likely a
>  difficult development process ... so if there is anyone working on that
>  device, or looking at it, its likely they are not directly associated or
>  involved around here.
>
>  - in addition to BM's Intensity and Intensity Pro, there are a few other
>  "cheaper" solutions that are available. This thread on Doom9 (and
>  despite its title) makes mention of them and provides examples of some
>  of them in use: http://forum.doom9.org/showthread.php?p=1044824#post1044824
>
>  - as far as I know, the more expensive professional and prosumer
>  solutions (i.e the AJA xena's, BM Decklinks, Accustreams, Bluefish444
>  cards etc etc) do have Linux support ... albeit, it is through
>  proprietary SDKs or developed inhouse by the production studios using
>  such products . There was a brief discussion about these on the V4L
>  mailing list a few years ago; see/read through this thread:
>  http://marc.info/?l=linux-video&m=115374256412690&w=2
>
>  - lastly, did that MythTV-users thread mention the forthcoming Hauppauge
>  HD-PVR (component input) ? ... given that the LinuxTV developer rank
>  does include a couple of guys from Hauppauge, and given that both of
>  them have made mention of that device, and given Hauppauge's stance on
>  Linux support is very positive, I'd be willing to bet that the chances
>  of open/publicly available support for this device materializing are
>  far, far greater than any of the other devices mentioned
>  above.....though, bear in mind there are, of course, never any
>  guarantees or certainties, nor am I speaking on the behave of anyone.
>

Thank you all for the information.  I had no idea it would spark such
a lively discussion.

James

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[CityK]

James Klaas wrote:
> On 2/21/08, CityK <CityK@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....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....DVB 
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.   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)
- 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: 
http://www.linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs

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,
> 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:
http://forum.doom9.org/showthread.php?p=916752#post916752

- Compressed, on the other hand, is CPU Intensive

> 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...

The neat thing about the forthcoming Hauppauge device is that:
- its analog (component) input ... thereby removing potential DRM 
considerations
- and in addition to performing the ADC, the chip utilized is also a 
encoder, compressesing using h.264/AVC   .... this completely removes 
all the other issues

- so long as the quality is acceptable,  this should be a nice solution 
for most end users .... but it will, of course, not meet the needs of 
prosumers/professional, who would still want to be using an uncompressed 
or loselessly compressed solution, so that they can perform editing etc.


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[Manu Abraham]

CityK wrote:
> James Klaas wrote:
>> On 2/21/08, CityK <CityK@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.

> DVB 
> 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 
such devices,
except for a vanilla TV out interface. Such devices feature a generic 
framebuffer
under the Video subsystem (not to be confused with V4L), where devices 
might
be handled.

For V4L to work with devices that way, it will need to copy more from 
the other
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 
different tangent.

> - 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: 
> http://www.linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs
> 
> 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,
>> 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:
> http://forum.doom9.org/showthread.php?p=916752#post916752
> 
> - 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) 
since
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 
solutions at
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 
little concern,
but the main concern is about the virtual instruments implemented in 
software such
as decks and other things and so on.

A broadcast professional, never has the time to learn or work with 
applications
stuck together with plaster. He just wants to get things done in the 
minimal time
for something to be aired. He doesn't care about the cost, nor the OSS 
philosophy,
but just about time involved in it.

Generally Linux makes a dent where cost is involved, but at the High end 
where cost
is not a subject, yet to see Linux, even if something exists, that will 
be completely
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 
users also
educated only on specific applications that run on them.


Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[CityK]

Manu Abraham wrote:
> CityK wrote:
>> 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.

This is true, but the context was in regards to the DVB API.   In any 
case, I had made mention_of/alluded_to ASI & SPI later on.

>
>> 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.

Very true ... my focus/thought was on the end user at the time of 
writing ... but we should not loose sight of the complete picture -- 
which of course involves the broadcast delivery chain

>
>> DVB 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.

I don't follow.

>
>> 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 such devices,
> except for a vanilla TV out interface. Such devices feature a generic 
> framebuffer
> under the Video subsystem (not to be confused with V4L), where devices 
> might
> be handled.
>
> For V4L to work with devices that way, it will need to copy more from 
> the other
> 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 
> different tangent.

While the move to multi-purpose, single IC devices is inevitable, the 
processing stages for the varying applications which the IC will perform 
(i.e. demodulation, encoding, ADC, etc)  remain the same ... I don't see 
how V4L would be cut out of the block ... unless, of course, that means 
DVB means to expand its capabilities and/or absorbing some of those 
currently handled by V4L

> 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) since
> 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 solutions at
> 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 
> little concern,
> but the main concern is about the virtual instruments implemented in 
> software such
> as decks and other things and so on.
>
> A broadcast professional, never has the time to learn or work with 
> applications
> stuck together with plaster. He just wants to get things done in the 
> minimal time
> for something to be aired. He doesn't care about the cost, nor the OSS 
> philosophy,
> but just about time involved in it.
>
> Generally Linux makes a dent where cost is involved, but at the High 
> end where cost
> is not a subject, yet to see Linux, even if something exists, that 
> will be completely
> proprietary, nothing OSS.
>
> ...[snip]...
>
> 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 
> users also
> educated only on specific applications that run on them. 

What you've said about the broadcast/tv_studio industry is absolutely 
true.  But such capture devices do not really have a place in them anyway.

These devices do, however, have a very large relevance to, and home 
within, the movie and production studios; and in those  environments, 
quite contrary to what you have written, the Penguin rules the roost.   
It is true that, in those industries, users aren't employing these 
devices with open APIs such as V4L-DVB (and I made mention of this in 
one of the prior messages), but nonetheless, these devices are very much 
so being fully utilized under Linux.  A nice little summary can be found 
here:
 
http://www.linuxmovies.org/index.html

And here's a practical example, from a few years back, that is of some 
notoriety (first 4:4:4 10 bit):

http://linuxdevices.com/news/NS8217660071.html

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[Manu Abraham]

CityK wrote:
> Manu Abraham wrote:
>> CityK wrote:
>>> 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.
> 
> This is true, but the context was in regards to the DVB API.   In any 
> case, I had made mention_of/alluded_to ASI & SPI later on.
> 
>>
>>> 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.
> 
> Very true ... my focus/thought was on the end user at the time of 
> writing ... but we should not loose sight of the complete picture -- 
> which of course involves the broadcast delivery chain
> 
>>
>>> DVB 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.
> 
> I don't follow.

Generally people think that since we deal with demods alone mostly, people
think that is the start and that is the end. (Meant on a very general level)

>>> 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 such devices,
>> except for a vanilla TV out interface. Such devices feature a generic 
>> framebuffer
>> under the Video subsystem (not to be confused with V4L), where devices 
>> might
>> be handled.
>>
>> For V4L to work with devices that way, it will need to copy more from 
>> the other
>> 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 
>> different tangent.
> 
> While the move to multi-purpose, single IC devices is inevitable, the 
> processing stages for the varying applications which the IC will perform 
> (i.e. demodulation, encoding, ADC, etc)  remain the same ... I don't see 
> how V4L would be cut out of the block ... unless, of course, that means 
> DVB means to expand its capabilities and/or absorbing some of those 
> currently handled by V4L

The in between stages will be masked out by larger stages which will wrap
around them, thereby you don't see those small basic controls. As you see
compared to the old days, you don't have that micro level controls anymore
these days. Those are getting phased out at a reasonable pace, with more
hardware doing those functionality of manual control. (features getting
packed in to make look like something different)

For example, When there is so much integration at such a stage, you feel
silly including something gigantic for something too silly. In such a 
case for
example of a TV output, you might not even need something that complex,
for such a small feature. (to cite as a crude example, maybe a bad example,
but i hope you get the idea)

>> 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) since
>> 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 solutions at
>> 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 
>> little concern,
>> but the main concern is about the virtual instruments implemented in 
>> software such
>> as decks and other things and so on.
>>
>> A broadcast professional, never has the time to learn or work with 
>> applications
>> stuck together with plaster. He just wants to get things done in the 
>> minimal time
>> for something to be aired. He doesn't care about the cost, nor the OSS 
>> philosophy,
>> but just about time involved in it.
>>
>> Generally Linux makes a dent where cost is involved, but at the High 
>> end where cost
>> is not a subject, yet to see Linux, even if something exists, that 
>> will be completely
>> proprietary, nothing OSS.
>>
>> ...[snip]...
>>
>> 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 
>> users also
>> educated only on specific applications that run on them. 
> 
> What you've said about the broadcast/tv_studio industry is absolutely 
> true.  But such capture devices do not really have a place in them anyway.

Once i was looking at a cheaper capture card/device for the broadcast arena.
One of the devices that i was pointed to was around 40,000 - 200,000 
Euro. In
the broadcast scenario, encoders/capture devices are used quite a lot, 
though
it is not mandatory, as some of the devices output HD-SDI for eg. In 
this example
you still have uncompressed video where encoding is still necessary. The 
features
on such devices are well out of the scope to be integrated into a 
general purpose
API. In many cases there is no API even, but just read/write. The API 
comes in due
to the user/kernel split. In most cases, it doesn't make much sense to copy
streams in and out of kernel and hence a generic API doesn't fit for those
applications which require performance. As time passes by, we will see 
more of this
issue.


> These devices do, however, have a very large relevance to, and home 
> within, the movie and production studios; and in those  environments, 
> quite contrary to what you have written, the Penguin rules the roost.

There are some areas where Linux excels such as distributed computing,
an example is Cinelerra. But that wasn't what i was trying to express, 
it is
a different thing altogether. eg. you have a certain piece of eqpt. The 
eqpt.
manufacturer provides a plugin to an existing standard application. In such
cases you are tied to that and this happens to be the standard thing.

> It is true that, in those industries, users aren't employing these 
> devices with open APIs such as V4L-DVB (and I made mention of this in 
> one of the prior messages), but nonetheless, these devices are very much 
> so being fully utilized under Linux.  A nice little summary can be found 
> here:
> 
> http://www.linuxmovies.org/index.html
> 
> And here's a practical example, from a few years back, that is of some 
> notoriety (first 4:4:4 10 bit):
> 
> http://linuxdevices.com/news/NS8217660071.html
> 

I am not saying there aren't any, but as i said there are intermittent 
links, many
places constituting, but the percentage of OSS drivers/apps in the whole 
chain
is very small, to say the penguin rules the roost. A mistake many Linux 
fans make
(including myself) when there is a small breeze thinking it's a tornado 
(It is like
running after a moving bus, still there exists a too large gap after 
running so long ...
The bus is moving too, maybe much faster than what you can run)

Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[hermann pitton]

Hi.

Am Samstag, den 23.02.2008, 03:35 +0400 schrieb Manu Abraham:
> CityK wrote:
> > Manu Abraham wrote:
> >> CityK wrote:
...
> >>
> >> For V4L to work with devices that way, it will need to copy more from 
> >> the other
> >> 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 
> >> different tangent.
> > 
> > While the move to multi-purpose, single IC devices is inevitable, the 
> > processing stages for the varying applications which the IC will perform 
> > (i.e. demodulation, encoding, ADC, etc)  remain the same ... I don't see 
> > how V4L would be cut out of the block ... unless, of course, that means 
> > DVB means to expand its capabilities and/or absorbing some of those 
> > currently handled by V4L
> 
> The in between stages will be masked out by larger stages which will wrap
> around them, thereby you don't see those small basic controls. As you see
> compared to the old days, you don't have that micro level controls anymore
> these days. Those are getting phased out at a reasonable pace, with more
> hardware doing those functionality of manual control. (features getting
> packed in to make look like something different)
> 
> For example, When there is so much integration at such a stage, you feel
> silly including something gigantic for something too silly. In such a 
> case for
> example of a TV output, you might not even need something that complex,
> for such a small feature. (to cite as a crude example, maybe a bad example,
> but i hope you get the idea)
> 

Maybe some facts in between, instead of pure advertising.

If you have that, sold per every single device painfully.
http://search.ebay.de/ws/search/SaleSearch?sofocus=bs&satitle=dvb+ci&sacat=-1%26catref%3DC5&fbd=1&catref=C6&fscl=1&sorefinesearch=1&flt=9&from=R14&nojspr=y&pfid=0&fswc=1&few=&saprclo=&saprchi=&fss=1&saslop=1&sasl=b.e.t.t.e.r.s.h.o.p.p.i.n.g&fls=4%26floc%3D1&sargn=-1%26saslc%3D0&salic=77&saatc=77&sadis=200&fpos=&fsct=&sacur=0&sacqyop=ge&sacqy=&sabfmts=0&fobfmt=1&saobfmts=insif&ga10244=10425&saslt=2&ftrt=1&ftrv=1&sabdlo=&sabdhi=&saaff=afdefault&afan=&afmp=&fsop=1%26fsoo%3D1&fcl=3&frpp=50

You still need something like this.
http://cgi.ebay.de/Neu-CAM-CI-MODUL-AlphaCrypt-Light-mit-Software-1-12_W0QQitemZ370000642816QQihZ024QQcategoryZ77740QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

And still have exactly nothing.

If it stays like that, this will likely have some new owners soon,
but teach me better.

Cheers,
Hermann








_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[Manu Abraham]

hermann pitton wrote:
> Hi.
> If it stays like that, this will likely have some new owners soon,
> but teach me better.
>

Unfortunately, i updated my mail filters which had tagged all your mails as
junk, to spam status.

Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HD capture

[hermann pitton]

Am Samstag, den 23.02.2008, 11:09 +0400 schrieb Manu Abraham:
> hermann pitton wrote:
> > Hi.
> > If it stays like that, this will likely have some new owners soon,
> > but teach me better.
> >
> 
> Unfortunately, i updated my mail filters which had tagged all your mails as
> junk, to spam status.
> 

Unencrypted HD currently has the sole function to sell subscriptions.

Not to say it, _is_ spam.

Cheers,
Hermann





_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb