Re: [vdr] multistream support in VDR
On Thu, Jan 3, 2013 at 2:08 PM, Klaus Schmidinger
wrote:
> On 03.01.2013 08:22, Goga777 wrote:
>>
>> Recently in kernel was added full multistream support (DTV_STREAM_ID)
>> https://patchwork.kernel.org/patch/1351421/
>>
>> is there any plans to implement multistream support in vdr ?
>
>
> DTV_STREAM_ID is already used in VDR for DVB-T2.
what about DTV_STREAM_ID for dvb-s2 ?
>>>
>>>
>>> Which parameter would go in there, and where would it come from?
>>
>>
>> parameter "P" in channels.conf for identification of sub-stream
>>
>>
>> WeddingTV;Tivuitalia:11914:HM5S1P2:S31.5E:27500:1026:1027=ita:0:0:4:8572:972:0
>>
>> and small patch from crazycat for VDR 1.7.35
>
>
> Have you tested this and does it actually work?
> I can hardly imagine that, because in
>
> + if (frontendType == SYS_DVBT2 || frontendType == SYS_DVBS2) {
> +// DVB-T2/DVB-S2
> SETCMD(DTV_STREAM_ID, dtp.PlpId());
> }
>
> "frontendType" will never be SYS_DVBS2 because in line 816 this is
> already limited to SYS_DVBT or SYS_DVBT2:
>
> else if (frontendType == SYS_DVBT || frontendType == SYS_DVBT2) {
>
DTV_STREAM_ID is supposed to work with the following:
- DVB-S2 (the only current user as of now. Also to be noted
is that, for any other current S2 demodulator in
the kernel, this will not work)
- DVB-T2
- ISDB-T/S
- DVB-C2
so, it shouldn't be restricted to DVB-T/T2 alone.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multistream support in VDR
On Wed, Jan 2, 2013 at 11:10 PM, Goga777 wrote: >> >> Recently in kernel was added full multistream support (DTV_STREAM_ID) >> >> https://patchwork.kernel.org/patch/1351421/ >> >> >> >> is there any plans to implement multistream support in vdr ? >> > >> > >> > DTV_STREAM_ID is already used in VDR for DVB-T2. >> >> The current DVB-T2 support is with CXD2820. CXD2820 supports only a single >> TS. >> The only demodulators in kernel that supports Multiple Input Stream >> (MIS) are the STV0900 and the STV0903. > > yes. > > But what do you think about cx24116 - is it possible to patch cx24116 > driver/firmware for multistream > support ? As far as I am aware, CX24116 and all Conexant derivatives (including the ones Trident bought from Conexant through NXP, ie TDA10071) do not support Input Stream Identifier or Multiple Input streams. Maybe it might be possible with a new firmware for those devices, but who knows ? Especially when Trident is also dead and the demods and STB business is now with Sigma Designs ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multistream support in VDR
On Wed, Jan 2, 2013 at 10:54 PM, Klaus Schmidinger wrote: > On 02.01.2013 18:20, Manu Abraham wrote: >> >> On Wed, Jan 2, 2013 at 10:34 PM, Klaus Schmidinger >> wrote: >>> >>> On 02.01.2013 16:01, Goga777 wrote: >>>> >>>> >>>> Hi >>>> >>>> Recently in kernel was added full multistream support (DTV_STREAM_ID) >>>> https://patchwork.kernel.org/patch/1351421/ >>>> >>>> is there any plans to implement multistream support in vdr ? >>> >>> >>> >>> DTV_STREAM_ID is already used in VDR for DVB-T2. >> >> >> The current DVB-T2 support is with CXD2820. CXD2820 supports only a single >> TS. >> The only demodulators in kernel that supports Multiple Input Stream >> (MIS) are the >> STV0900 and the STV0903. > > > I'm afraid I don't quite know what "Multiple Input Stream" means. > Can somebody explain this in a few words? According to the specification: 5.1.6 Base-Band Header insertion A fixed length base-band Header (BBHEADER) of 10 bytes shall be inserted in front of the DATA FIELD, describing its format (the maximum efficiency loss introduced by the BBHEADER is 0,25 % for nldpc = 64 800 and 1 % for nldpc = 16 200 assuming inner code rate 1/2). MATYPE (2 bytes): describes the input stream(s) format, the type of Mode Adaptation and the transmission Roll-off factor, as explained in table 3. First byte (MATYPE-1): TS/GS field (2 bits): Transport Stream Input or Generic Stream Input (packetized or continuous). SIS/MIS field (1 bit): Single Input Stream or Multiple Input Stream. It simply means whether there exists a Single TS or a hierarchially modulated multiple TS. Basically, you can have 2 DVB-T streams with the device. If you have multiple streams, then you need to specify the Stream ID for which you need the to filter it out. Something like an IP address and it's Subnet Mask, in network terminology. In effect we are not reading the BBheader directly. So this is a bit clumsy to use. But anyway for simple usage, one can simply set the Stream ID alone. I have not seen any MIS being flagged, except that I was told that it was done only in field trials rather than in the practical world. I was surprised to find someone found that there was 1 or 2 Transponders on some Russian bird which flagged MIS. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multistream support in VDR
On Wed, Jan 2, 2013 at 10:34 PM, Klaus Schmidinger wrote: > On 02.01.2013 16:01, Goga777 wrote: >> >> Hi >> >> Recently in kernel was added full multistream support (DTV_STREAM_ID) >> https://patchwork.kernel.org/patch/1351421/ >> >> is there any plans to implement multistream support in vdr ? > > > DTV_STREAM_ID is already used in VDR for DVB-T2. The current DVB-T2 support is with CXD2820. CXD2820 supports only a single TS. The only demodulators in kernel that supports Multiple Input Stream (MIS) are the STV0900 and the STV0903. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On Wed, Nov 16, 2011 at 6:30 PM, Steffen Barszus wrote: > 2011/11/16 Manu Abraham : >> On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger >> wrote: >>> >>> That is also my understanding of multi frontend devices. >>> If an "adapter" has several "frontends" only one of them can >>> be active at any given time. This has nothing to do with >>> any "explosives" (excuse the pun ;-) and will be implemented >>> in the core VDR code as time permits. Right now I'm cleaning up >>> the "lnb sharing" (aka "device bonding") stuff and will hopefully >>> find more time for VDR development by the end of the year (and >>> thereafter). >> >> If I am following you correctly, >> There is one issue however. If an adapter can have only a single >> frontend, then there will exist another issue: >> >> - Card has dual multi standard frontend(s). >> - Card has CI cards on both the paths (2 CI controllers) >> - Card provides scrambled stream as well as descrambled stream (4 >> simultaneous streams) >> - Card needs to swap between the CI modules to take advantage of the >> different modules, rather than reconnecting antenna inputs/manually >> swapping the CI modules. >> >> Eventually, to handle such a situation: all the nodes exposed to the >> application has to be under the "same" adapter, rather than as 4 >> different adapters, of which 2 of them won't have any frontend or ca >> devices. > > To my understanding the mentioned use case would have - according to > linux-media project logic of how to handle this - would look like > > /dev/dvb/adapter0/frontend0 > /dev/dvb/adapter0/frontend1 > /dev/dvb/adapter0/demux0 > ... > /dev/dvb/adapter0/ca0 > /dev/dvb/adapter1/frontend0 > /dev/dvb/adapter1/frontend1 > /dev/dvb/adapter1/demux0 > ... > /dev/dvb/adapter1/ca0 > > so it would be 2 adapter with 4 frontends. If for some reason they > should be in one adapter how to distinguish between the different > cases ? Maybe i did not understand properly the issue. The very same driver can have 4 real frontends too. By now the issue got complicated too far by the logic mentioned above: So, how will you distinguish between real functional and independant adapters, then (when having multiple adapters) ? Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger wrote: > > That is also my understanding of multi frontend devices. > If an "adapter" has several "frontends" only one of them can > be active at any given time. This has nothing to do with > any "explosives" (excuse the pun ;-) and will be implemented > in the core VDR code as time permits. Right now I'm cleaning up > the "lnb sharing" (aka "device bonding") stuff and will hopefully > find more time for VDR development by the end of the year (and > thereafter). If I am following you correctly, There is one issue however. If an adapter can have only a single frontend, then there will exist another issue: - Card has dual multi standard frontend(s). - Card has CI cards on both the paths (2 CI controllers) - Card provides scrambled stream as well as descrambled stream (4 simultaneous streams) - Card needs to swap between the CI modules to take advantage of the different modules, rather than reconnecting antenna inputs/manually swapping the CI modules. Eventually, to handle such a situation: all the nodes exposed to the application has to be under the "same" adapter, rather than as 4 different adapters, of which 2 of them won't have any frontend or ca devices. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] scan-s2 and dvb-apps
Hi Abbe, On Tue, Feb 23, 2010 at 4:30 PM, abbe normal <1abenor...@gmail.com> wrote: > hi manu > > why would there have to be 2 scan packages couldnt there be one that > does the same for both types of devices... i would think dvb scan > should be able to do anything dvb not just s2 or s or is it asking to > much from it... > > abbe scan does scan of dvb channels as you are aware of. scan-s2 original commit seems to be a derivative of scan, though it is not incremental nor based on patches, but a dump of files instead. This is the part that gave me headaches on how to get scan-s2 merged into scan. I can't simply replace scan with scan-s2, because scan is even better maintained. The other case would be that both scan and scan-s2 would coexist, being the last thing that I would do. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] scan-s2 and dvb-apps
Hi All, Recently, quite some people have been requesting for scan-s2 a simple scan application which has been hacked on top of the scan application as available in the dvb-apps tree, to be integrated/pulled in to the dvb-apps tree, after it's author moved on to other arenas. http://www.mail-archive.com/vdr@linuxtv.org/msg11125.html The idea initially was to have a cloned copy of scan as scan-s2. Now, on the other hand scan-s2 is much more like scan and similar functionality wise too. Considering the aspects, do you think, that it is worthwhile to have a) the scan-s2 application and the scan application as well integrated into the repository, such that they both live together or b) scan-s2 does things almost the same as scan2. scan can be replaced by scan-s2. What are your ideas/thoughts on this ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Looking for new maintainer of scan-s2 application
Hello Alex, On Wed, Oct 21, 2009 at 10:43 PM, Alex Betis wrote: > Hello all, > > I'm leaving the DVB-S world for now due to low available content in my area. > Hence I will not be able to maintain anything related. > > Any one is willing to take the ownership of scan-s2 application? > Do you mind, if I pull scan-s2 into dvb-apps ? Best Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
On Wed, Jan 6, 2010 at 7:52 PM, Oliver Endriss wrote: > Manu Abraham wrote: >> On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger >> wrote: >> > On 06.01.2010 14:22, Tomasz Bubel wrote: >> >> [...] >> >>> - Added support for DVB cards with multiple fontends. Note that this only >> >>> works for DVB cards where each frontend can be used independently of all >> >>> the others on the same adapter. >> >> [...] >> >> Any chance of using using DVB-T frontend on HVR-4000? This card have 2 >> >> separate frontends. And as quoted on >> >> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000: >> >> >> >> "Multiple frontends are supported: DVB-S/S2 and DVB-T appear as >> >> /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 >> >> respectively. >> >> >> >> Due to a hardware limitation, the two frontends cannot be used >> >> simultaneously. However they can be used sequentially within the same >> >> application. The driver handles the mutual exclusion appropriately." >> > >> > Well, that's still a problem. >> > Is there a defined way (via the LinuxDVB driver API) through which VDR >> > can find out whether the frontends can be used independently? >> >> Some more food for thought .. >> >> There is also one more added problem: Say there are two adapters and >> two frontends. I will try to convey the thought as simplest as >> possible by me... >> >> A case in which frontend0 is bound to adapter0 and frontend1 is bound >> to adapter 1 >> >> This would seem like a classical case of having 2 independent >> adapters. But let's analyze it a bit more deeply. The two adapters A0 >> and A1 are on the same physical A (adapter) chip and can send you data >> simultaneously on both the devices. Likewise F0 and F1 can be on the >> same physical F (frontend) chip and can send you simultaneous data to >> both A0 and A1. >> >> Now suppose that you are having F0 and F1 operational: The F chip >> would have a limitation on some parameter, which is based on a >> combination of F0 and F1. If the sum parameter is exceeded on the >> whole F chip, the entire F chip would crash and might need a Reset. >> >> Likewise the same holds good for the A chip too .. >> >> Another case is where you have A0, A1 and F0, F1 on the same chip >> while additionally providing F2 and F3 on virtual A0' and A1'. >> >> But in all cases, the question remains the same. How would the >> application like to handle a situation, when a certain parameter will >> be exceed on the next operation on the next 'Fx' interface ? (If the >> application feels free and does the operation which might cause some >> parameter to exceed, the chip as a whole would not respond, unless >> reset again) >> >> Operations like this might be common on cards having dual, quad and >> hex frontends. The card itself might be able to stream dual, quad and >> hex simultaneous streams. > > Imho limitations or dependencies between different *adapters* are not > acceptable. If a driver maps frontends to different adapters, the driver > pretends that they can be used independent of each other and without > limitations. > > If there are limitations, the frontends must be assigned to the same > adapter. Anything else does not make any sense to me. Ok, I agree to your point. But it all depends on what we define an adapter is: Is the adapter specified by the I2C interface, or is it by the actual number of DMA interface ? In the case of the card that which is mentioned in here, a CX88 PCI card, it neither has dual I2C nor dual DMA. It is just a simple software mutex in the driver alone. But, suppose a device has lets say 13 physical DMA interfaces which can be applied to a total of 18 DMA interfaces, ie at any time the physical chip can do a total of 13 DMA instances at any given point of time. Now, all the DMA transfer for all the 'n' interfaces will be over a single memory interface, say maybe a Dual ported memory or something that way. Eventually there will exist a memory bandwidth on any physical memory. That bandwidth has to be shared between 13 instances. So in reality there will be a given limitation on the bandwidth in use, ie for example, when at any given point of instance, you might be able to do 2 SD streams, while practically it might be possible to handle only a single HD stream, or maybe a HD + SD stream, but might not be possible to handle 2 HD streams, to mention a specific case. For any device that we consider, there is a limitation on the bandwidth that each interface or whatever we might call it. But eventually, I guess maybe it is better for the driver to handle it internally, though it may look rather damned complex, with lot of multiplexing of the DMA and computation of the bandwidth in use. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger wrote: > On 06.01.2010 14:22, Tomasz Bubel wrote: >> [...] >>> - Added support for DVB cards with multiple fontends. Note that this only >>> works for DVB cards where each frontend can be used independently of all >>> the others on the same adapter. >> [...] >> Any chance of using using DVB-T frontend on HVR-4000? This card have 2 >> separate frontends. And as quoted on >> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000: >> >> "Multiple frontends are supported: DVB-S/S2 and DVB-T appear as >> /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 >> respectively. >> >> Due to a hardware limitation, the two frontends cannot be used >> simultaneously. However they can be used sequentially within the same >> application. The driver handles the mutual exclusion appropriately." > > Well, that's still a problem. > Is there a defined way (via the LinuxDVB driver API) through which VDR > can find out whether the frontends can be used independently? Some more food for thought .. There is also one more added problem: Say there are two adapters and two frontends. I will try to convey the thought as simplest as possible by me... A case in which frontend0 is bound to adapter0 and frontend1 is bound to adapter 1 This would seem like a classical case of having 2 independent adapters. But let's analyze it a bit more deeply. The two adapters A0 and A1 are on the same physical A (adapter) chip and can send you data simultaneously on both the devices. Likewise F0 and F1 can be on the same physical F (frontend) chip and can send you simultaneous data to both A0 and A1. Now suppose that you are having F0 and F1 operational: The F chip would have a limitation on some parameter, which is based on a combination of F0 and F1. If the sum parameter is exceeded on the whole F chip, the entire F chip would crash and might need a Reset. Likewise the same holds good for the A chip too .. Another case is where you have A0, A1 and F0, F1 on the same chip while additionally providing F2 and F3 on virtual A0' and A1'. But in all cases, the question remains the same. How would the application like to handle a situation, when a certain parameter will be exceed on the next operation on the next 'Fx' interface ? (If the application feels free and does the operation which might cause some parameter to exceed, the chip as a whole would not respond, unless reset again) Operations like this might be common on cards having dual, quad and hex frontends. The card itself might be able to stream dual, quad and hex simultaneous streams. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers
On Sat, Jan 2, 2010 at 10:06 PM, Timothy D. Lenz wrote: > Problem is, that is just a chip. Any boards out using it? Linux drivers? It is not a single chip. It is a combination of 2 chips. The card will be available soon from Azurewave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR behaviour with wrong NIT
On Sat, Apr 25, 2009 at 7:32 PM, Goga777 wrote:
>> >> And which parameters are the wrong ones?
>> >
>> >
>> > these two parameters are wrong
>> >
>> > Frequency: 18437984 (= 11.95760 GHz) - should be another freq =
>> > 12.380
>> > Kind: 0 (0x00) [= DVB-S] - should be dvb-s2
>> >
>> > also, no any information about roll off factor, that's why vdr substituted
>> > roll off = auto , cx24116 based cards don't
>> > understand roll off = auto.
>> >
>> > Goga
>> >
>> >
>> > fixed ('00'): 0 (0x00)
>> > Modulation_type: 2 (0x02) [= 8PSK]
>> > Symbol_rate: 2506752 (= 26.4000)
>> > FEC_inner: 2 (0x02) [= 2/3 conv. code rate]
>>
>> Well, if VDR is told this is a DVB-S transponder, while in fact it is
>> DVB-S2, I'm afraid there's nothing it can do about that.
>>
>> Have you tried complaining to the provider?
>
>
> yes, sure.
>
> Answer from provider - "please use our official receivers"
>
> @klaus
>
> could you change VDR behaviour if in the NIT the rolloff is missing - is it
> possible to substitute roll off = 35 instead
> of roll off = auto ?
It would be buggy to use Rolloff=35%, when the actual rolloff
information is missing.
In fact this is a bug in the driver, that it can't sensibly use the
rolloff information.
With regards to DVB-S2, the rolloff information is present in the
Stream header (MATYPE)
and the driver is supposed to return back the rolloff information from
the stream header.
According to EN300 468, a DVB-S2, NBC stream will not contain any
rolloff information,
but whereas the information is available in the BBHEADER, which the
demodulator is able
to understand.
In fact this is the job of the device driver and hence the reply from
the provider to use their
receiver, There are 2 options, fix the bug in the driver, or use a
compliant device.
What will you do, if you have a narrow transponder, the same way ?
Regards,
Manu
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
> FF seems to have understandably gone the way of the dinosaur. It has been true for the older FF cards, but there might be a possible new generation/revolution of FF cards, though it was originally considered expensive sometime back. Other than for the FF cards, there are cards (not in retail yet, prototypes right now) which can do Bi-directional DMA to the card for descrambling of the recorded TS using the CAM. Don't know how soon these cards with Bi-directional DMA similar to the Ethernet cards would appear and even if so, might be a while till a driver for the same supports such a feature. (Right now can't say anything more than this, stated this much, so that: if the development can go in a direction similar to what hardware appears) For such cards, a TS format (as broadcast) for recording would be more appealing as a starting point if they were to appear. It might be a bit more time, to know the actual status, but the TS feature might be a still important feature, if that were to happen. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <[EMAIL PROTECTED]>wrote: > >> Alex Betis wrote: >>> On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < >>> [EMAIL PROTECTED]> wrote: >>> >>>> On 22.11.2008 17:25, Georg Acher wrote: >>>>> On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: >>>>>> On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < >>>>>> [EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> Maybe I'm totally missing something here, but I can't figure out how >>>>>>> an application using the S2API driver can tell whether a DVB device >> is >>>>>>> DVB-S or DVB-S2. Can somebody please point me in the right direction >>>> here? >>>>>> I run into the same question when made changes in scan-s2 application. >>>>>> The question I want to ask is why do you really need it? >> >> In a DVB-S2 demodulator, according to ETSI specifications, and according >> to the manufacturers, there are 2 demodulators, A DVB-S demodulator and >> a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths. >> >> With these 2 distinct paths, you need a flag, aka a delivery system >> notation, to select the path as well as a "holder" to hold common >> delivery system specifics. This is the whole difference between >> multiproto and S2API. >> >> S2API depends on a flat concept where it assumes a single demodulator, >> ie the concept of a delivery system doesn't exist there. >> >> Expect more fun when there are newer delivery systems which are going to >> define backward compatibility stuff, ie when vendors do start to >> implement backward compatible stuff in hardware, similar to DVB-S2 >> >> It is just a matter of time, till the more advanced features are >> implemented practically by more broadcasters, rather than the few >> experimental ones. >> >> I guess, there is more to come. >> > Guys, > > Lets not start that fire again, from my experience mostly innocent people > gets hurt from it. It is not about any fire, but about what really is at large. > As someone new to DVB implementation who joined the ride when both S2API and > multiproto are already available I see some benefits and drawbacks in both > of them. From my perspective I see S2API best benefit is the 'API' itself > and its flexibility, while multiproto has its respectful 'flight hours' and > more implemented features. That's probably a matter of time and efforts > while more features will be implemented in S2API that will make everybody > happy. > It was decided already to move to S2API and as I see from the lists and > patches flying around many people are very interested in it. > We probably all agree that S2API is not mature enough for all the cases. The problem is that, once an untested API makes it upstream, it is really hard after that. Don't know how many people realize that ... Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > >> On 22.11.2008 17:25, Georg Acher wrote: >>> On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < [EMAIL PROTECTED]> wrote: > Maybe I'm totally missing something here, but I can't figure out how > an application using the S2API driver can tell whether a DVB device is > DVB-S or DVB-S2. Can somebody please point me in the right direction >> here? I run into the same question when made changes in scan-s2 application. The question I want to ask is why do you really need it? In a DVB-S2 demodulator, according to ETSI specifications, and according to the manufacturers, there are 2 demodulators, A DVB-S demodulator and a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths. With these 2 distinct paths, you need a flag, aka a delivery system notation, to select the path as well as a "holder" to hold common delivery system specifics. This is the whole difference between multiproto and S2API. S2API depends on a flat concept where it assumes a single demodulator, ie the concept of a delivery system doesn't exist there. Expect more fun when there are newer delivery systems which are going to define backward compatibility stuff, ie when vendors do start to implement backward compatible stuff in hardware, similar to DVB-S2 It is just a matter of time, till the more advanced features are implemented practically by more broadcasters, rather than the few experimental ones. I guess, there is more to come. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > >> Maybe I'm totally missing something here, but I can't figure out how >> an application using the S2API driver can tell whether a DVB device is >> DVB-S or DVB-S2. Can somebody please point me in the right direction here? >> > I run into the same question when made changes in scan-s2 application. > The question I want to ask is why do you really need it? > Even if the card is DVB-S2, you have to specify DVB-S delivery system when > you intend to lock on DVB-S channel. > I assume that specifying DVB-S2 delivery for DVB-S card should be rejected > by the driver. > So I don't see a real problem here. The application should follow the > channels file, the "S0" or "S1" parameter that specify the delivery system. Nah, there is an even larger problem: DVB-S2 implies a max Srate = 30MSPS and DVB-S implies max srate = 45MSPS. There are quite a load of nasty quirks like that with the current API. Another one is that, the user application will never know whether a tuning failed or not. Well, most of those application developers did want those quirks and hence we do have them. Interesting, isn't it ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Goga777 wrote: >> After quite a while away from VDR development, I've dedicated >> this weekend to switching VDR to S2API (TS recording will be postponed). >> >> Just two quick questions: >> >> - Where do I find the ultimate, latest, greatest S2API driver source? >> I would assume it is at http://linuxtv.org/hg/v4l-dvb, but with all >> the recent patching and various repositories, I'm unsure... > > imho, http://mercurial.intuxication.org/hg/s2-liplianin/ also good choise. > Igor has implemented some improvements in drivers, that's why with > s2-liplianin possible to work with dvb-s/svb-s2 channels which have high and > low SR. I don't know why these improvements didn't include in v4l-dvb tree. People using some STB0899 versions will have their demodulators burned due to the demodulator running with a too high unsupported clock of 135MHz. The STB0899 is rated to run at a maximum of 99 MHz only. The safe bet is to use http://linuxtv.org/hg/v4l-dvb Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Twinhan 1041 card (stb0899) - femon 1.6.2 gives no signal info
Alex Betis wrote: > On Fri, Nov 21, 2008 at 10:31 AM, Oleg Roitburd <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> 2008/11/21 Alex Betis <[EMAIL PROTECTED]>: >>> Hi, >>> Anyone with stb0899 (Twinhan 1041, TT3200) card can see signal info using >>> femon? >>> Currently it shows no signal info at all. >>> >>> I previously used Twinhan 1034 card and femon wasn't working properly as >>> well. >>> I use Igor's S2API drivers. >>> >>> Thanks. >> it's known feature of driver for stb0899 based cards. Blind flight. ;) >> I have asked in linux-dvb ML last week. >> http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030353.html >> >> But without any answers. :-( >> > Looks like the smart phrase can be applied here as well: > If you want something to be done right, do it yourself :) > > I'll take a look at it in the driver after I'll finish with my VDR main wish > list... IIRC SNR with the STB0899 had been working with the multiproto tree. Regarding the (MB86A16) 1034 has a properly graduated scaling in decibels as it is in my repository. Don't know what's broken elsewhere. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [linux-dvb] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
Halim Sahin wrote: > Hi, > On Do, Sep 25, 2008 at 12:54:58 +0200, Oliver Endriss wrote: >> There are basic democratic rules which must be followed in a community: >> >> (1) Make a proposal > > Yes We have multiproto, since 2006. > > >> (2) Discuss the proposal > > Was done since 2006 > >> (3) Finally, _after_ the discussion: A poll to find a decision. > > Great thing. Why was multiproto not merged after your code review > november 2007 > > I thing Manu wanted to do the s2 stuff himself and did not accept > any community help. http://lwn.net/Articles/297301/ API and core related patches: 31 + 1 patches, total 32 in all. http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/ The people who contributed some way or the other (in the final stages): on the API changes alone. (Not mentioning about the people who initially provided many comments.) Marco Schluessler <[EMAIL PROTECTED]> Arvo Jarve <[EMAIL PROTECTED]> Reinhard Nissl <[EMAIL PROTECTED]> Oliver Endriss <[EMAIL PROTECTED]> Anssi Hannula <[EMAIL PROTECTED]> These folks on a whole, contributed to ~14 of the patches. > Yes I read most of the old mails from last year. > In most cases Manu wrote that multiproto is not ready. > The fact is, that many people are using (not ready multiproto stuff) > since two years. After the code review, it was left for testing. Thanks to the VDR community/Klaus for providing support for the same, so it could be tested in real life. As you can see quite some of the changes came during the test phase, as you can see from the timestamps in the multiproto tree. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and "multiproto" - which driver to use?
Klaus Schmidinger wrote: > I'm in the process of reintroducing the "multiproto" changes > in order to start the 1.7 developer version. > > Since I haven't been following the driver development recently > I was wondering if somebody could tell me which driver is best > to use at this time. > > The one at > > http://jusst.de/hg/multiproto > > is like 4 weeks old, while at Had been away on a vacation, plus some work, hence no recent changes. > > http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod > > there have been recent activities. > I'd like to switch to a driver that works with "multiproto" and > supports Oliver's full ts mod. It shouldn't be hard to use the 2 repositories together, it can be used quite straight forward like this: $ hg clone http://jusst.de/hg/multiproto $ cd multiproto $ hg pull -u http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod After the pull is complete, it will ask you to merge the heads: $ hg merge commit the merge $ hg commit You have both the functionality of both trees in one tree. If that looks hard, i can push a tree which is a result of the above outlined steps. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
Georg Acher wrote: > No support anymore. But most of the issues have been resolved for us. Also > the RMM card uses/needs only a small portion of the chip features. The PCI > communication is based on my shared memory driver with almost no kernel > dependencies, so we have no problems with future kernels. Ah, i see. As long as it works as expected, things do look bright. > The people who designed a complete STB with a standalone DeCypher have much > more trouble now... True. That's quite a significant loss in investment for a STB manufacturer. (Though it is not the first time that a vendor sees such things. At some point of time the SAA716x PCIe chips were also in the same condition, but somehow things got into a better shape, but vendors still afraid of the murky waters) At least they could have revived it by just keeping the development stuff with the Linux developer. Pity, that they took an insane turn. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
Georg Acher wrote: > On Sat, Mar 15, 2008 at 10:45:06PM +0400, Manu Abraham wrote: > >> Is this card still being manufactured, considering that Micronas USA >> closed down and the Decypher has been EOL'd ? > > There are enough chips available... What about support from Micronas for the chip, with regards to firmware fixes etc ? What i heard was that they took everything back from the Linux driver developer for shredding after announcing closure. Yet Micronas was forwarding support requests to him after taking back all sources/info. A pity that so much efforts put in and one fine day it has just vaporized. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
Timothy D. Lenz wrote: > Bball posted on the DVBN forums that he got it working and it works good. > Has a few glitches that can be fixed with new firmware. Is this card still being manufactured, considering that Micronas USA closed down and the Decypher has been EOL'd ? Regards, Manu > > - Original Message - > From: "Igor" <[EMAIL PROTECTED]> > To: "VDR Mailing List" > Sent: Saturday, March 15, 2008 3:22 AM > Subject: [vdr] Extension HD PCI card from ReelMultimedia - what's new ? > > >> Hello >> >> is there any good news about the current status of Extension HD PCI from > ReelMultimedia ? >> Is there a full support for 1080p/1080i by hdmi and YUV output ? >> What about deinterlacing - is it work fine ? >> >> Igor >> >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Hi Patrick, Patrick Boettcher wrote: > Hi Klaus, > > On Sun, 3 Feb 2008, Klaus Schmidinger wrote: >>Should there be a stable version 1.6.0 now, based on what's in >>version 1.5.14, but without DVB-S2 or even H.264 support? > > With H264 support, because some DVB-T channels (at least here in France) > are starting to carry H264-channels, afaiu unencrypted. > > With Multiproto support (DVB-S2), but only if VDR is able to switch to the > current DVB-API provided by standard kernels at compile time. I guess > Multiproto will not be there before 2.6.26 or even later. There is a bunch > of drivers currently not working with Multiproto. Something that was broken with my changes, or was it the merge ? Anything that you would like to point me to ? (ISP is still not back in shape, Internet access is currently in a pathetic state) Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] statistic (was - Multiproto updated Re: [ANNOUNCE] VDR developer version1.5.14)
Igor wrote: > Manu > > will be possibility to receive from driver the raw statistic, too ? > As of now, the STB0899 get's the raw statistics does processing and the processed details are sent to the application. It's possible to get the same, what you mentioned, just that the mentioned ioctl needs to be in there. The relative scale would be just raw statistics (unprocessed) Regards, Manu > Igor > > > -Original Message- > From: Manu Abraham <[EMAIL PROTECTED]> > To: VDR Mailing List > Date: Mon, 28 Jan 2008 22:22:58 +0400 > Subject: Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer > version1.5.14 > >> Morfsta wrote: >>> Manu, >>> >>> Firstly, thanks for all your work - it's appreciated. >>> >>> Is the interface working properly for reading the signal strength, BER >>> and status? >> Currently, there is a small confusion. Most drivers in kernel, just >> report some >> crap as signal strength, snr etc. >> >> For the STB0899, STM helped so much, alongwith i had some help from one >> of the Newtec guys, we were able to get the statistics in some proper form, >> currently a dBm/10 scale is used. >> >> Since this scale is different from the in kernel existing scale of >> randomness >> to a standardized one, currently this change might look a bit nonsense >> to you >> as it will report different signal statistics as reported by the API. >> >> There will be a need to add one more ioctl, where the user can request the >> driver to provide the statistics in a relative scale or an absolute >> scale which >> can be used for measurements too. >> >> The result would be that and end application can display the statistics >> like >> any other commercial STB, in a nice and beautiful way, while being quite >> accurate (depending on the driver) without any hacks or workarounds to be \ >> done in the application >> >> (The statistics that you get is very much device specific and not device >> independant >> and hence is not very easy for a user application to get proper >> statistics as of now) >> >> With the change, all statistics related operations can be implemented >> within the driver >> such that the user is presented with standard and uniform statistics >> across multiple >> devices without the need to do device specific code as done by MythTV >> etc, where it >> looks for specific device drivers (really ugly) >> >>> The rotor plugin doesnt return anything and I can't get anything out >>> of VDR-Femon. >>> >>> Is it working OK with the TT 3200? >> >> The statistics is working with the STB0899, maybe i didn't follow what >> exactly you are >> looking at. If you can detail a bit, it would be much more helpful. The >> STB0899 supports >> TT S2 3200, KNC1 DVB-S2+, KNC1 DVB-S2, Pinnacle PCTV 450e and the >> VP-1041 as of >> now and the same signal related stuff is applicable to all. >> >>> BTW I have a TT3200 on order so I can compare the difference between >>> the two cards soon. >> Currently, the STB0899 is _not_ calibrated for actual statistics. I have >> requested >> Azurewave for some sample devices to be sent to STM for proper >> calibration of the >> LUT's for the statistics. (Most probably, tomorrow or so STM will >> receive the samples >> at Grenoble) > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.5.14
Morfsta wrote: > Manu, > > Firstly, thanks for all your work - it's appreciated. > > Is the interface working properly for reading the signal strength, BER > and status? Currently, there is a small confusion. Most drivers in kernel, just report some crap as signal strength, snr etc. For the STB0899, STM helped so much, alongwith i had some help from one of the Newtec guys, we were able to get the statistics in some proper form, currently a dBm/10 scale is used. Since this scale is different from the in kernel existing scale of randomness to a standardized one, currently this change might look a bit nonsense to you as it will report different signal statistics as reported by the API. There will be a need to add one more ioctl, where the user can request the driver to provide the statistics in a relative scale or an absolute scale which can be used for measurements too. The result would be that and end application can display the statistics like any other commercial STB, in a nice and beautiful way, while being quite accurate (depending on the driver) without any hacks or workarounds to be \ done in the application (The statistics that you get is very much device specific and not device independant and hence is not very easy for a user application to get proper statistics as of now) With the change, all statistics related operations can be implemented within the driver such that the user is presented with standard and uniform statistics across multiple devices without the need to do device specific code as done by MythTV etc, where it looks for specific device drivers (really ugly) > The rotor plugin doesnt return anything and I can't get anything out > of VDR-Femon. > > Is it working OK with the TT 3200? The statistics is working with the STB0899, maybe i didn't follow what exactly you are looking at. If you can detail a bit, it would be much more helpful. The STB0899 supports TT S2 3200, KNC1 DVB-S2+, KNC1 DVB-S2, Pinnacle PCTV 450e and the VP-1041 as of now and the same signal related stuff is applicable to all. > BTW I have a TT3200 on order so I can compare the difference between > the two cards soon. Currently, the STB0899 is _not_ calibrated for actual statistics. I have requested Azurewave for some sample devices to be sent to STM for proper calibration of the LUT's for the statistics. (Most probably, tomorrow or so STM will receive the samples at Grenoble) Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Manu Abraham wrote: > Klaus Schmidinger wrote: >> On 01/28/08 02:49, Manu Abraham wrote: >>> Ludwig Nussel wrote: >>>> Klaus Schmidinger wrote: >>>>> On 01/27/08 16:25, Ludwig Nussel wrote: >>>>>> Klaus Schmidinger wrote: >>>>>>> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and >>>>>>> Reinhald Nissl >>>>>>> for a patch that was used to implement this). VDR now requires >>>>>>> the "multiproto" >>>>>>> DVB driver, e.g. from http://jusst.de/hg/multiproto. >>>>>> Would it be possible to make that optional via compile time define? >>>>> I guess so, but I'm not going to ;-) >>>>> This new driver appears to be stable enough now - at least I've >>>>> been using it for a few days now without problems. >>>> *sigh* messing with kernel stuff sucks. Does a vdr built with the >>>> multiproto headers at least also work on vanilla kernels ie stable >>>> dvb drivers? That way one would only need to use different headers >>>> for building vdr but no extra kernel modules at run time. >>>> >>> AFAICT, the updated headers can be used along with the old drivers >>> without >>> any issues. If not there's an issue with regards to backward >>> compatibility. >>> Can you pleas point out the errors that which you see, when you are >>> using >>> the updated headers and the old drivers ? >> >> The new headers work fine with the old driver - if the application >> still uses the old API. I've tested that first thing before I switched >> to the new API. >> >> However, I don't see how an application actually using the new API >> could work with the old driver. > > In the idea that i had, it would look for the API version and issue the > ioctls > as necessary, similar to what i used in the szap hack. (It was just a > hack, for > some testing as well as demonstrating the API usage) > The hacked szap is here: http://abraham.manu.googlepages.com/szap.c Forgot one thing to mention, The application issues the new ioctls, the dvb-core takes those parameters and converts it into the old format and passes it to the old driver. This way, a driver written the old way will also work, just that it involves a thin layer of translation, also misses some of the newer features introduced. Another major change in the old -> new driver concept is that, the old drivers were all forced to do a stupid software zigzag, even for hardware that doesn't require it. With the new interface, you can define your custom algorithm in the driver itself, such that it performs really well, just similar to properly written drivers, rather than reverse engineered device drivers. If you think that your driver needs to be lean and mean, then the new interface is the way to go. In any case, to make the utmost use of all the features, still you need to know a lot about your hardware, to do that. In fact the more ideas you have, you can implement, unlike the case with the old interface, that even if you know what to do, there was no way to do it, without stripping away quite a lot of fat which will cause another flaming thread for some few years. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/28/08 02:49, Manu Abraham wrote: >> Ludwig Nussel wrote: >>> Klaus Schmidinger wrote: >>>> On 01/27/08 16:25, Ludwig Nussel wrote: >>>>> Klaus Schmidinger wrote: >>>>>> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald >>>>>> Nissl >>>>>> for a patch that was used to implement this). VDR now requires the >>>>>> "multiproto" >>>>>> DVB driver, e.g. from http://jusst.de/hg/multiproto. >>>>> Would it be possible to make that optional via compile time define? >>>> I guess so, but I'm not going to ;-) >>>> This new driver appears to be stable enough now - at least I've >>>> been using it for a few days now without problems. >>> *sigh* messing with kernel stuff sucks. Does a vdr built with the >>> multiproto headers at least also work on vanilla kernels ie stable >>> dvb drivers? That way one would only need to use different headers >>> for building vdr but no extra kernel modules at run time. >>> >> AFAICT, the updated headers can be used along with the old drivers without >> any issues. If not there's an issue with regards to backward compatibility. >> Can you pleas point out the errors that which you see, when you are using >> the updated headers and the old drivers ? > > The new headers work fine with the old driver - if the application > still uses the old API. I've tested that first thing before I switched > to the new API. > > However, I don't see how an application actually using the new API > could work with the old driver. In the idea that i had, it would look for the API version and issue the ioctls as necessary, similar to what i used in the szap hack. (It was just a hack, for some testing as well as demonstrating the API usage) The hacked szap is here: http://abraham.manu.googlepages.com/szap.c > At any rate, the patch from Ulrich Richter should work for people > insisting to use the old driver. > Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/28/08 03:01, Manu Abraham wrote: >> Klaus Schmidinger wrote: >>> On 01/27/08 17:46, Thomas Schmidt wrote: >>>> I really hope that either vdr 1.5.x gets a compile-time-switch to >>>> build and run with the vanilla kernel-sources or even better that the >>>> multiproto-drivers will be merged into the mainline kernel soon. >>> The latter would be the reasonable step to take, IMHO. >>> Having these different DVB driver branches is something that >>> should end as soon as possible. >> The drivers can be merged in to the kernel after quite some tests. >> >> With regards to both the S2 capable drivers there are enough bug >> reports open. I am not of the opinion of merging drivers while open >> bug reports still do exist. (You can look at the linux-dvb ML for the >> same) For both the drivers, many people can say it works for me, but >> not for everyone. >> >> That said, currently the tree is up to v4l-dvb head and the current >> kernel merge window is open for 2.6.25, which will be open for some >> few days more. With the current state, it cannot be merged in for >> 2.6.25. >> >> Most probably we might be able to make it for 2.6.26 if all goes well. >> This requires lot more testing and fixing etc. >> >> The current state of different branches (distributed repositories) was >> the option chosen when Johannes merged the trees and was his >> decision. Most probably, that will remain the same for quite a long time >> to come. > > Just so I understand this correctly: the driver that is currently in > the kernel is *not* able to do DVB-S2, while the driver at > http://jusst.de/hg/multiproto *is* able to do it. And these are the only > two driver versions we're talking about here, right? Umm.. Let me put it this way. Currently in kernel, everything is defined in terms of modulation. This won't hold good with newer stuff coming up. Newer stuff (devices) can have a single modulation type or multiple modulation types (when looking at a single device itself) For example: In kernel as of now, DVB-S is represented by QPSK (This is in fact slightly wrong. DVB-S can use QPSK or BPSK) Next: for DVB-S2 there is no representation as it is for it in kernel (atm), since DVB-S2 can be 32APSK, 16APSK, 8PSK or QPSK Also there is another satellite delivery system called DSS which can use BPSK and or QPSK Another very important aspect is that you can't define DVB-S2 as 8PSK modulation, since there is yet another broadcast system (In the US) which uses DVB-S framing and 8PSK modulation. The important part is that, as you see this has no DVB-S2 framing, but also that instead of the BCH/LDPC for FEC, it uses Turbo Codes. So, as you see in the 3 cases, having a FE_HAS_QPSK is not enough to define a delivery system, whereas you a need a tag for a collective set of modulations, similar to DVB-T (OFDM) where you have different modulations again. So eventually: as you see, you can't access a delivery system by a modulation type. As of now, there are 2 Linux DVB drivers which are DVB-S2 capable * STB0899 (Supports: BPSK, QPSK, 8PSK, 16APSK, 32APSK) * CX24116 (Supports: BPSK, QPSK, 8PSK) (You might remember the old modulation discussions we had a long time back) Two more newer DVB-S2 devices that are expected to be supported under Linux are the STV0900 and the STV0903. Currently, the multiproto tree has the delivery system definitions, such as DVB-S, DVB-S2, .. .. The drivers which make use of these delivery systems, makes use of the API changes held in there. > So, if the kernel driver can't do DVB-S2, it will probably become obsolete > pretty soon, at least for those who want to receive DVB-S2 channels. True. Not only for DVB-S2, There are other stuff coming out, which will need the multiproto API changes, such as for the newer parameters, which are required for DVB-H. Also additionally we have reserved space for more newer delivery systems such as DVB-C2, DVB-T2 (which will be coming out in a few years) also the existing DMB-T/H delivery system can be added in as well, with much ease, without having the old issues that were visited during the API discussion period. Other than this, there are some quirks with the current in kernel API such as with regards to DVB-T, that you can't select a Low priority stream. Also for DVB-H, you will need additional parameters. So eventually, it is high time that the in kernel API needs a face lift. > Maybe making VDR require the "multiproto" driver actually gives this > driver the necessary boost to be sufficiently tested so that it can > be merged into the kernel in the not so far future... ;-) :) Definitely: Lot of testing is required and user complaints to get things moving in the right direction. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/27/08 17:46, Thomas Schmidt wrote: >> I really hope that either vdr 1.5.x gets a compile-time-switch to >> build and run with the vanilla kernel-sources or even better that the >> multiproto-drivers will be merged into the mainline kernel soon. > > The latter would be the reasonable step to take, IMHO. > Having these different DVB driver branches is something that > should end as soon as possible. The drivers can be merged in to the kernel after quite some tests. With regards to both the S2 capable drivers there are enough bug reports open. I am not of the opinion of merging drivers while open bug reports still do exist. (You can look at the linux-dvb ML for the same) For both the drivers, many people can say it works for me, but not for everyone. That said, currently the tree is up to v4l-dvb head and the current kernel merge window is open for 2.6.25, which will be open for some few days more. With the current state, it cannot be merged in for 2.6.25. Most probably we might be able to make it for 2.6.26 if all goes well. This requires lot more testing and fixing etc. The current state of different branches (distributed repositories) was the option chosen when Johannes merged the trees and was his decision. Most probably, that will remain the same for quite a long time to come. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Ludwig Nussel wrote: > Klaus Schmidinger wrote: >> On 01/27/08 16:25, Ludwig Nussel wrote: >>> Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. >>> Would it be possible to make that optional via compile time define? >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. > > *sigh* messing with kernel stuff sucks. Does a vdr built with the > multiproto headers at least also work on vanilla kernels ie stable > dvb drivers? That way one would only need to use different headers > for building vdr but no extra kernel modules at run time. > AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.5.14
Morfsta wrote: >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. >> > > The new driver is fine, but what you might find is that new card and > features being released into the stock v4l mercurial tree aren't being > backported into multiproto - its been fairly static for awhile. I have pushed out a tree which is now a merged version of v4l-dvb and the multiproto trees and is available at http://jusst.de/hg/multiproto (As of now, insufficient tests, after the merge, please test) A point to note is that, in the build (for me 2.6.21) the stk-webcam in the v4l-dvb tree was broken and hence is broken in the updated multiproto tree as well. You will need to disable the stk-webcam build in that tree, in case you are using an older kernel. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto
Reinhard Nissl wrote: > Hi, > > Morfsta schrieb: > >>> Please report the debug output here for further investigation. >> Attached are two files - tuning to the same DVB-T channel using either >> system and the Philips frontend... vdr-1.4.x shows the channel fine, >> 1.5.12 does not. >> >> Hope this helps and thanks again for your assistance. > > Hmm, the translation layer doesn't work correctly. It doesn't > translate new bandwidth value 1 to old bandwidth value 0, > although there exists code to do this translation, and it should > get called as the other translations happen correctly. > > As a result the old driver uses a bandwidth of 7 MHz instead of 8 > MHz. > > While copying the code here to ask for help in searching the bug, > it seems that I found the bug -- a missing break in the DVB-T > case ;-) > > Please try the attached patch. That indeed did fix. Have applied it to the tree. Thanks, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Reinhard Nissl wrote: > Hi, > > Manu Abraham schrieb: > >>> I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use >>> DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a >>> DVB-S2 channels, so is your DVB-S2 cards free. >>> >>> But one should get a way to tell VDR no to try to tune DVB-S2 channels >>> on DVB-S card. >> You can do that. In fact the application should do a DVBFE_GET_INFO. This >> will query >> the capability of that specific driver. Based on the driver capabilities, >> issue a tuning >> request. That way a tune will be attempted only on the capable device. >> >> It is a simple check, though. >> >> Reinhard, >> >> The patched version doesn't look at the device capability flags, before >> issuing a tune ? >> Or is something else wrong/missing ? > > I must admit, I didn't have a look at the source code so far, but > from what I recall, I don't think that it is that easy. I think, > a simple check will only make VDR tell you that the channel in > question cannot be received. > > I've experienced myself that VDR used the DVB-S2 card for a DVB-S > recording and then endlessly tried to switch to a DVB-S2 channel > using the DVB-S card -- obviously without success. How can you ask a DVB-S device to tune to DVB-S2 ? Poor demodulator, it has to do what it is not even capable of. :) > VDR's device selection logic is already quite complex. It has to > deal with FF cards which have so far been used to watch the DVB-S > channels, cards which provide CI interfaces and simple receiver > cards. Moreover it now would have to deal with cards capable of > doing DVB-S2, with or without CI interface respectively. The logic wouldn't be much different. It is the same as requesting a DVB-C device to be tuned to DVB-S. The CI interface doesn't make the hardware look any different. > As I'm only distributing the DVB-S2 part which Marco Schlüßler > provided several months ago, I've contacted him and asked him for > an update. Ok, I will ask Marco on the relevant. Thanks for the feedback. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Morfsta wrote: >> Over here, tests were done on STB0899, STV0299 and TDA10021 based >> all work out of the same multiproto tree (http://jusst.de.hg/multiproto) > > There is something wrong then as it does not tune in vdr-1.5.12. I > have the following DVB-T frontends: - > > [ 9539.157598] DVB: registering frontend 1 (Conexant CX22702 DVB-T)... > [ 9539.197883] DVB: registering frontend 3 (Philips TDA10045H DVB-T)... > > Should the TDA10045H work? If so, perhaps the problem is that VDR is > tuning frontend 1 first which is not supported yet. If the driver what you have in the multiproto tree, if you see it as old, ie: changes have gone into those drivers in between. The easiest thing to get going is: Get the latest tree or whichever for which that demodulator/card is working with. Just overwrite the relevant older files for your driver/card in the multiproto tree (your local copy) That way, the devices which have been newly updated also will work. > How can I go about porting the Conexant to the new interface? Is it > straightforward (i.e. can I compare the code for the TDA10021 based > frontend in v4l-dvb and multiproto and make the changes for the > cx22702 frontend?) > No need to do any porting. The same drivers which worked with the old API will work with the new API too, just that there is a thin translation layer in between. If you need the "shortest call" to those drivers, then you will need to port them to the new API. Till then, you can go ahead with copying the old drivers to the new API tree. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Gregoire Favre wrote: > On Wed, Jan 02, 2008 at 07:32:13PM +0400, Manu Abraham wrote: > >> No, that seems silly. The DVB-S2 card works for DVB-S also. It should be >> able >> to use all the cards. Though you can't ask a DVB-S card to tune to DVB-S2, >> that's all the limitation it poses. > > :-) > > I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use > DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a > DVB-S2 channels, so is your DVB-S2 cards free. > > But one should get a way to tell VDR no to try to tune DVB-S2 channels > on DVB-S card. You can do that. In fact the application should do a DVBFE_GET_INFO. This will query the capability of that specific driver. Based on the driver capabilities, issue a tuning request. That way a tune will be attempted only on the capable device. It is a simple check, though. Reinhard, The patched version doesn't look at the device capability flags, before issuing a tune ? Or is something else wrong/missing ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Gregoire Favre wrote: > On Wed, Jan 02, 2008 at 07:12:52PM +0400, Manu Abraham wrote: > >> Over here, tests were done on STB0899, STV0299 and TDA10021 based >> all work out of the same multiproto tree (http://jusst.de.hg/multiproto) > > Do you mean VDR keep the DVB-S2 card for DVB-S2 channels and use the > others for DVB-S usage ? > No, that seems silly. The DVB-S2 card works for DVB-S also. It should be able to use all the cards. Though you can't ask a DVB-S card to tune to DVB-S2, that's all the limitation it poses. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Morfsta wrote: >> Is there a way to use more than a card with it when only one is DVB-S2 >> capable ? > > I just dropped a mail to Reinhard asking the same question. My > "production" system runs 2 DVB-T cards that currently don't work with > vdr-1.5.12 / multiproto. I would love to start using it full time but > until I can get support for DVB-T then it won't be possible. > > There's two ways you can do this I believe, port the dvb-t driver > properly to the new multiproto tree or modify VDR to fall back to the > old interface to tune the driver if the new one fails. > > I know that it is possible to use the old interface because when I use > vdr-1.4.7 with the multiproto tree it works fine for DVB-T, however I > am not sure where to start coding this into either VDR and I'm not > sure my skills are that hot at the driver level! > > If someone could provide some pointers here, that would be great (Manu > or Reinhard?) Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto) Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: [linux-dvb] en50221_tl_poll: CAWrite failed
Simon Baxter wrote: > Thought I'd try a new thread with this problem as I'm getting no where - and > not sure what else to try. > > I've just added a Irdeto CAM to my TT-1500 Budget DVB-C card and I'm getting > write errors with VDR and with gnutv: > > [EMAIL PROTECTED] gnutv]# dmesg | grep DVB > DVB: registering new adapter (TT-Budget-C-CI PCI). > DVB: registering frontend 0 (ST STV0297 DVB-C)... > dvb_ca adapter 0: DVB CAM detected and initialised successfully > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu > en50221_tl_poll: CAWrite failed > en50221_stdcam_llci_poll: Error reported by stack:-2 > > and > > In /var/log/messages: > Apr 30 19:31:26 media1 vdr: [2774] CAM 1: module present > Apr 30 19:31:28 media1 kernel: dvb_ca adapter 0: DVB CAM detected and > initialised successfully > Apr 30 19:31:28 media1 vdr: [2774] CAM 1: module ready > Apr 30 19:31:29 media1 vdr: [2774] ERROR: can't write to CI adapter on > device 0: Input/output error > > In dmesg: > dvb_ca adapter 0: DVB CAM detected and initialised successfully > dvb_ca adapter 0: DVB CAM detected and initialised successfully > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > I'm running the latest hg v4l-dvb. > > Can anyone suggest anything? Does this look like faulty hardware??? It > does it in 2 different machines. It is indeed not flaky hardware as i wrote earlier. -2 is timeout. It is due to a bug in debiread/write ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
