[linux-dvb] Re: Reception performance with Avermedia DVB-T
Martin Stubbs wrote: Attached is the new patch, created as you suggest. thanks, applied. Can you please test whether it works as expected and let us know when you find out anything about the register settings they use in the Avermedia DVB-T driver? Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Steffen Barszus wrote: Am Mittwoch, 19. November 2003 04:15 schrieben Sie: Johannes Stezenbach writes: > Klaus Schmidinger wrote: > > Well, AFAICS this "old hardware" is very widely used, and the > > main platform VDR is designed for. And judging from the download > > volume every new version of the "linvdr" distribution causes > > (according to Mirko Dölle) VDR must be rather popular ;-) So I > > guess this hardware will still be in use for quite a while, and > > I can see no adequate replacement around - but that may be due > > to my lack of market overview... > > The "funny" thing is that you can buy a full av7110 based set top > box for 150 Euro (sometimes cheaper), but the DVB-S/C cards are > still sold for 299 Euro here at Saturn. I would be happy if VDR > were designed to run on hardware which is cheaper and has better > Linux developer support Funny, or rather sad? Considering what the parts on those cards cost, that they are probably cheaper than 4 years ago, and that the cards still cost the same ... The STBs you mention went down from about 500 Euro to 150 Euro in the same time. But the market makes the prices and I guess too many people are still willing to pay that much lacking a better and/or cheaper "full featured" alternative. 299 EUR isn't really the price someone would pay for such a card. More common are prices around 200 EUR. I have asked at such a store and was told that they sell one in a half year. Even this is more than twice the price you have to pay for a modern state-of-the-art DVB card. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Ralph Metzler wrote: Hi, Holger Waechtler writes: > > btw: Klaus, you know that the code responsible for synchronisation > issues in the firmware is at least as complex as the code doing the same > in ffplay.c. So everybody who believes he can fix those problems in the > firmware if he had only the source is as well able to write a software > decoder for VDR. And you know we can't release it. Sorry. Hmm, actually ffplay.c goes a little deeper than the firmware regarding synchronisation. Unless you mean the firmware ROM and video microcode for which we do not have any sources anyway? Are there still any synchronisation issues in the firmware? As mentioned before this sentence was only intended to say that the code it's even simpler to implement a software decoder than to modify the firmware for a particular purpose. Thanks that you confirmed this. :) Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Onno Kreuzinger wrote: I was mainly thinking of df-gp, the first VDR patch I know that worked on the frambuffer (http://df-gp.sourceforge.net/). The first NEWS entry is now about 19 months old. df-gp suffers from exactly the problems i expected, 1st: only Matrox tv-out cards are suffcienty good ($$$), I doubt that is true. second: av-sync is not solved (19 month), IIRC they are using the libmpeg2 DirectFB video provider, video sync is simply not implemented there. As alternative you can install e.g. the experimental mplayer-based video provider which is of higher quality, implements correct sync and can deinterlace on request or you wait until one of the DirectFB maintainers finished the ffmpeg video provider. Andi is working on it. third: de-interlace _is_ an immanent problem not solable without real de-interlacing software, ffmpeg contains a deinterlacer of pretty good quality. Give it a try. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Steffen Barszus wrote: Am Mittwoch, 19. November 2003 02:19 schrieben Sie: Steffen Barszus wrote: Am Dienstag, 18. November 2003 23:16 schrieben Sie: Hi Klaus, don't get me wrong, I appreciate your work. But I'm pretty angry about the situation that VDR is (I don't care whether willingly or not) endorsing these troublesome and expensive beasts since years. We have now at least since about two or three years cheap and good alternatives and there have been efforts to write DirectFB and Xine-backends for VDR but they never found their way into the mainstream source which means nothing else than that they are born dead. Why should they ? The plugin you speak about exists since some months (weeks). In the time i was on the vdr list the xine plugin is the first real approach on having a software display and i have never seen a patch for 1.0.x that tried that. Patches were really successfull even if they were not in main vdr (think of AIO, who is running vdr w/o it ? I guess 50% using it). Further the "solution" you think of has some problems. I was mainly thinking of df-gp, the first VDR patch I know that worked on the frambuffer (http://df-gp.sourceforge.net/). The first NEWS entry is now about 19 months old. I have seen that too. But this project was limited and is still limited to Matrox cards. Is it? If they really used DirectFB as hardware abstraction layer there is no real reason why it should be. And if it is then it's a good reason to spend some time to change this;) I have tried to get a good supported matrox card to no avail (a matrox g400). It may be a good solution, but it is not practicable in reality. If it would work with an ati rage 128 or the like i guess it would had become a lot more popular. Now the Xine-plugin is a lot more flexible than df-gp. Both Xine and MPlayer are somewhat oversized as pure decoders. They are more multimedia player centers than generic decoder libraries like libmpeg2, libmpeg3 and ffmpeg. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: EPG data?
On Wed, 19 Nov 2003, Grant Totten wrote:
> Hi all,
>
> I'm wondering about the EPG (electronic program guide) data that's
> available to me vial Bell Expressvu. I know there's EPG data somewhere
> in the stream, because other (Windows) apps can read it.
>
> I'm under the impression that the EPG data comes down in a "table", and
> the format of this is defined by an ETSI standard. Is that a correct
> impression? (Pardon the newbie questions here ;-)
That's pretty much the size of it.
> Further, I'm under the impression that nobody has implemented the code
> to pull down the EPG data in the linux-dvb drivers. Is this true?
AFAIK that is true. But I don't think this is something you want to put in
the drivers. It should be a separate program or maybe a library.
> Can someone point me to the correct ETSI spec, so I can start reading?
The spec you want for DVB service information is ETSI EN 300 468
> Thanks,
> Grant
I recently added EPG parsing in iTele (well, 'now' and 'next' only, but
the structures are the same). The source code is available at
http://www.defyne.org/dvb/. If you're not a fan of C++ then look away now.
The files in there that you want are DPConnect/Streaming.hpp and the
PacketProcessor::processEIT method in DPConnect/TSHandler.cpp.
I doubt you can use it directly since I gave no thought to endianness
issues. There is also a full DVB and MPEG SI parser called mpsys which may
be of more use to you, although I found its code to be impenetrable. Find
it on google.
But anyway, parsing this stuff is really quite easy ... have fun!
{P^/
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] AverMedia DVB-T problems on Epia M10000
Hi, Trying to get the AverMedia DVB-T card working on a EPIA M1 and have run into a snag. The card will tune using tzap, but dvbstream does output anything. I suspect it is to do with i2c as there is a kernel error stating: i2c-algo-bit.o: bt878 #0 [sw] i2c_write: error - bailout Kernel debug has a lot of messages asking to mail id, board name to [EMAIL PROTECTED] Is there some kernel module options that need to past to bttv.o? I'm running 2.4.23-pre7 with v4l2 patches. Could someone that has it working post the relevent messages for the syslog? I want to do some comparisons. Thanks heaps! -Myles -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] CI not responding. Another 64 bit problem?
A few days ago I had a problem receiving PSI in VDR . it ended up being a problem in the crc32 that assumed long to be 32 bits (in the libsi). All packets were being discarded. It was quite annoying to go from the GUI, debugging and setting breakpoints all the way down :( Now I am facing a similar problem with Link Layer for CI. But unlike the previous problem, I don't have a small sample like test_pes or sscan as guide. Only the full blown VDR... Do you happen to have a small sample/snippet of code to test Link Layer to CI? I could save me going through the whole bunch of layers all over again... A piece of code that just dumps the CI Menu info would be excellent... Thank you, PJ PS: For people familiarized with vdr, I've activated part of the ci log and here is the result: [EMAIL PROTECTED] vdr-1.2.5]# ./vdr Resetting slot 0...ok. Resetting slot 1...ok. Module ready in slot 1 Creating connection: slot 1, tcid 1 OpenSession 00010041 New Resource Manager (session id 1) 1: ==> Profile Enq It stays here forever... it look like never recieving the profile info and so on... Until I hit ^C ... which just adds this: CloseSession 0001 Resetting slot 1...ok. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
On Tue, Nov 18, 2003 at 19:17:01 +0100, Johannes Stezenbach wrote: > I hope you will reconsider if someone actually goes through all the > trouble of defining and implementing a different "standard" format > that you can conveniently just use in VDR. Now that XML exists, there shouldn't be any need to invent yet another complex data file format. I present you the way SWelcom (the tech arm for SanomaWSOY, who own HelsinkiTV) encodes their cable information: http://dvb.swelcom.fi/si.xml It's rather trivial to produce a VDR-type listing from this info, I did this as a quick-and-dirty experiment with Perl, but using the XML parser library is just as simple from C or C++: http://eetis.co.jyu.fi/dvb/ (Unfortunately, there's something a bit wonky about the XML data they generate, it seems that the complete info for multiplex 4 (CINEMA1/2/3 and FASHION channels) never gets there... dunno why?) I would suggest that using a XML config file is the proper way to proceed. Easily expandable syntax, human-editable if required, the syntax tree can be rewritten back out to a file by the software if needed. -- /* * * Otto J. Makela <[EMAIL PROTECTED]> * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 40 7860457, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FIN-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Frozen picture with recent driver version
That might be just unlucky, but let me add the hint that I had always have problems with recordings especially at 2GB and 4GB boundaries. 2hours (and 4hours) is about the time I see myself with breaking recordings at 32bit bytecount wrapping. It's not deterministic however, so hard to track down :-( and sadly I did not see a good candidate in the dvb sources themselves, so it may just as well be bug in the io system of linux itself, or whatever distro specific version is being in use. -- guidoD Martin Holst wrote: Hi I noticed a strange behaviour within DVB-driver from 17.11.: if you watch a channel with vdr the picture gets frozen after some time (sometimes after 2 hours, sometimes after 4 hours, ...) With the DVB-driver from 20.09. I didn't noticed that behaviour. Are there any other people with this "feature"? my system: primary card: hauppauge DVB-s 1.3 (connected with 3,5" CI) secondary card: hauppauge Nexus-s 2.1 kernel 2.4.21 Martin PS: I noticed this behaviour also with the upt-debugging firmware of Klaus and the driver from 20.09., so I think it's a firmware problem... -- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode) -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] EPG data?
Hi all, I'm wondering about the EPG (electronic program guide) data that's available to me vial Bell Expressvu. I know there's EPG data somewhere in the stream, because other (Windows) apps can read it. I'm under the impression that the EPG data comes down in a "table", and the format of this is defined by an ETSI standard. Is that a correct impression? (Pardon the newbie questions here ;-) Further, I'm under the impression that nobody has implemented the code to pull down the EPG data in the linux-dvb drivers. Is this true? Can someone point me to the correct ETSI spec, so I can start reading? Thanks, Grant -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
> That nicely outlines the reason why many people don't like XML: > It's hard to find the interesting information between all those tags. Ok, double tagging is redundand and can clutter important info if seen with old green VT100 terminal, but I have discovered that my editor can do tag highlighting with colors and I immediately understand why even double_tagging in XML can be a good_thing, and I personally never again want to work with any other format... If you are familiar with advanced editors, even emacs and some vi's clones, there's a whole bunch of nice XML higlighting modules that renders the important information in XML VERY visible form, because the XML is standard and therefore editor already knows how to highlight it! Editor can do syntax cheching and automatic identation of XML too!! You are guaranteed to produce clean and syntactically correct file with the text editor. > And to add insult to injury the tag names appear twice for every > little piece of information. Emards proposal looked much nicer, :) > > * > > My opinion would be that you have a hierarchical set of data here, store it > > in a hierarchical format... XML is one variation of this, but pick the > > variation which makes sense to you... > > * Absolutely I agree ... -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
On Wed, Nov 19, 2003 at 10:29:47AM +0100, Gerd Knorr wrote:
> "Nico" <[EMAIL PROTECTED]> writes:
>
> > please, everything but NOT XML: it's uselessly complicated and
> > implies dependencies to external libs, which are rejected by many
> > projects (e.g. mplayer, as far as I'm concerned).
>
> Agreed, every f*cking additional library dependency makes software
> maintainance harder, and I absolutely don't see the point in using XML
> for config data.
But you might see the point of integration of e.g. radio, TV and DVB ?
When dealing with DVB, you definitely need extensible and hierarchical
format. No simple /etc/passwd or /etc/smb.conf database format is sufficient
for the complexity of media sources we currently have in DVB.
A unified and hierarchical data format able to be accessible in path
format with simple (library based) calls like:
tune("dvb-s/ZDF") <-- sat digital tv
tune("dvb-s/Rock FM") <-- sat digital radio
tune("tv/ZDF")<-- terrestrial analog tv
tune("fm/Rock FM")<-- terrestrial analog radio
tune("dvb-c/RAI1")<-- cable digital tv
tune("ZDF") <-- let the database decide wether to go over dvb-s or
terrestrial tv
tune() will pass station name "ZDF" to XML's XPath extension and immediately
obtain all data it needs to tune to certain station name. It will know
is it dvb-s, tv, radio or whatever and it will have tuning parameters
in varables.
XML can give this flexibilty with its XPath access mode
implemented into the library, and its not a bad thing to have...
Also libraries can write updated config file, saving
you from the fuss with locks, fopen(), fgets() etc...
If you are short with development time for yet-another-ascii database
design and config file parsers for your (integrated) xawtv/dvb/radio
applications, you might consider XML as great time-saver doing the
tedious work of writing config parse/update code
Emard
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: channels.conf syntax?
> Notice how this just translates into: > > > hotbird > sat > 1.0 > 1 > 1 > Right, the transformed syntax is just the same, the XML allows us to have organization into data, and it's standard. Even more, XML allows us to expand the format with additional features and you can pass the new XML based format to old application because XML format is DESIGNED for OLD applications accept NEW (eXtended) versions of XML formats without weirdness or even segmentation fault. Having lots of versions around linux environment and with many users even don't understanding the versions, far from expecting them to be up-to-date with latest apps releases, the XML will allow them semless cross-portability, easy to use! I want to go one step forward with the format, and that's why we need XML badly. I want to propose a database for multimedia reception that is common to the whole world. It can be located in a server and updated from everywhere. In this database, all the stations (fm, tv, satellite) with their respective transmitter strengths and geographical locations of the transmitter (or satellite footprint at earth) will be listed. Also for all major cities, the reception quality will be indicated for each transmitter that has signal strong enough that can at least be received by good equipment. User wanting to watch or listen multimedia has to configure minimal: 1) he tells his geographical location (town) he is located 2) list of reception equipment he has: e.g. FM antenna 75 cm, Satellite dish 60 cm pointed to 19.2E with opt. some CI equipment UHF TV antenna pointed 35 deg east 3) cable of some_cable_provider. 4) Finally he tells what minimal signal strength treshold he wants to receive >From those data, there goes simple XSLT transformation of the main XML database, where the big database is converted into user's initial XML file .channels.xml, where is just a subset of stations that are receiveable by his equipment with the given minimal treshold signal quality. Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Frozen picture with recent driver version
Hi I noticed a strange behaviour within DVB-driver from 17.11.: if you watch a channel with vdr the picture gets frozen after some time (sometimes after 2 hours, sometimes after 4 hours, ...) With the DVB-driver from 20.09. I didn't noticed that behaviour. Are there any other people with this "feature"? my system: primary card: hauppauge DVB-s 1.3 (connected with 3,5" CI) secondary card: hauppauge Nexus-s 2.1 kernel 2.4.21 Martin PS: I noticed this behaviour also with the upt-debugging firmware of Klaus and the driver from 20.09., so I think it's a firmware problem... -- GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen! Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle Preise. http://www.gmx.net/de/cgi/specialmail/ +++ GMX - die erste Adresse für Mail, Message, More! +++ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
> Edward Wildgoose wrote: > > > > > > hotbird > > sat > > 1.0 > > 1 > > 1 > > > > That nicely outlines the reason why many people don't like XML: > It's hard to find the interesting information between all those tags. > And to add insult to injury the tag names appear twice for every > little piece of information. Emards proposal looked much nicer, > but... Yes, I completely agree. And it's very verbose (but compresses well!) However, I think that you can also use Attribute syntax to make it look like "a=27" type stuff again? I guess it comes down to whether you want to look at it completely unformatted in an email, or whether you will be using an editor. Many editors, and even many web browsers will make it nice and easy to read, and even allow you to expand and close sections. This perhaps makes up for the slightly unwieldy look A lot comes down to whether *you* will be reading it or the computer. Take the VDR format for example, this certainly isn't too readable, but most people are quite happy with it (well, *I* think it's adequate) > I would prefer a relational model. Depends exactly what you mean. None of the ideas I suggested are properly relational, but I guess the hierarchical view is somewhat relational, at least to the extent that the data is not many to one. Notice for example how the programs "relate" to the mux and the mux to the source. However, we receive an extract of a relational database via an XML feed, and whilst it certainly does work quite nicely, it feels pretty cludgy because we have many to many relationships to model, and so we end up with multiple XML files to avoid repeating data. XML does downward hierarchies very well though in general. I personally don't think XML is particularly revolutionary. At it's simplest its just saying "Look heres a nice generic hierarchical file format, with a defined way to start and end attributes definitions". There are loads of ways of doing this, and I think people waste a lot of time discussing whether XML looks as pretty as some of the other ways. The good thing is that it's fairly standard and so there are loads of tools available to fiddle with it. The bad thing is that XML is pretty verbose and could read a little bit better ...Tough call As someone else said though - lets see the colour of your code...! -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
Edward Wildgoose wrote: > > > hotbird > sat > 1.0 > 1 > 1 > That nicely outlines the reason why many people don't like XML: It's hard to find the interesting information between all those tags. And to add insult to injury the tag names appear twice for every little piece of information. Emards proposal looked much nicer, but... > * > My opinion would be that you have a hierarchical set of data here, store it > in a hierarchical format... XML is one variation of this, but pick the > variation which makes sense to you... > * I would prefer a relational model. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
> Personally I don't understand the passion for XML;
> don't you believe that a structure like the one following (intended as
> an example, not as a proposal) is easier?
>
> [source]
> name=hotbird
> type=SAT
> diseqc_protocol=1.0
> lnb=1
> card=1
>
> [mux]
> name=rai
> source=hotbird
> frequency=11766
> polarization=v
>
>
> [programs]
> name=rai1
> mux=rai
> vpid=160
> apid=80
> .
Neither do I in general. However, note that the file format you suggested
above is basically as hard to parse as an XML subset, without any benefits
such as being easier to use regexp's against for scripting updates, etc.
Notice how this just translates into:
hotbird
sat
1.0
1
1
rai
hotbird
11766
v
I'm not going to argue for either really. From having used both, I find the
microsoft "ini file" style of the first one slightly easier to read, but the
second style much more powerful when you need to nest stuff. For example,
the above example should probably be better coded as:
hotbird
sat
1.0
1
1
rai
11766
v
rai1
etc, etc
Although mentioning XML causes all sorts of tensions, to me there don't
really seem to be more than two ways of doing this anyway - its just the
choice of symbols which changes. It's a bit like saying C, and PASCAL are
different languages... To my eye they do basically the same thing, its just
the symbols which change (eg BEGIN and END instead of { and }, etc)
The two ways are basically:
- Flat file (Microsoft INI file)
- Hierarchical file (Microsoft registry, XML, emacs style files, etc)
The example above could also be rewritten as
source (Hotbird)
{
type=sat
lnb=1
Mux (rai)
{
frequency=11766
etc
program (rai1)
{
program detail...
}
program (rai2)
{
...
{
}
}
The funny thing is that there are number of people who will happily rail
against the mention of XML, but be quite happy to use the example above,
when in reality it's exactly the same file, but we modify the various field
start and termination characters The above should regexp'able from one
form to the other.
However, the XML style file is at least standardised, and you can pick up
any number of code snippets to parse it generically, whereas the other
examples need something writing (not hard).
Ignore the hype. When someone says "lets use XML", just let that mean:
"hierarchical file format with sensible termination characters on each
field". Code it up any way you like, but remember that there are a ton of
prewritten tools people can use if you do write it in a certain fashion.
For example if you save all of these in a text file, then most editors and
web browsers will format and highlight the syntax if you use the XML style
file
*
My opinion would be that you have a hierarchical set of data here, store it
in a hierarchical format... XML is one variation of this, but pick the
variation which makes sense to you...
*
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: Linux DVB API V4 / Audio API
Hi,
I've comitted a new audio.h for the V4 API. So far it
seems that not many people care (PC hardware doesn't need
any of the new features). Anyway, feedback is welcome.
Johannes
(deliberate full quote:)
On Thu, Oct 23, 2003 at 07:16:31PM +0200, I wrote:
> Hi all,
>
> I've collected some requirements for the V4 audio DVB API.
> In V3 we currently have:
>
> demux ---> decoder ---> output/mixer
>
> ^^
> covered by DVB API some other API (e.g OSS)
>
> The V3 audio decoder API also had some ad hoc extensions to support
> DVD playback for the EM8300 and Margi drivers.
>
>
> In V4 we want better support for audio post-processing, mixing
> and output control. Since I think that existing Linux audio APIs
> like OSS and ALSA don't fit well for embedded DVB applications,
> I propose to include the following in the Linux DVB API:
>
>
> demux ---> decoder --> post-proc -> |---|
> | || |
> | |--> | | |-> TV out
> || | |
> |-> decoder --> post-proc -> | mixer |--|-> VCR out
> | | |
> ext -> decoder --> post-proc -> | | |-> head phones
> | |
> pcm -> post-proc -> |---|
>
>
> ^^.^...^ S/P-DIF out
>
>
> We have the following devices:
>
> o audio decoder
> - decodes audio PES or ES in various formats
> (MPEG-1, MPEG-2, mp3, AC3, ...)
> - performs synchronization to the STC (lip-sync)
> - input can be from demux, from external input (I2S or SPDIF)
> or memory
> o audio post processor
> - performs 5.1 to stereo downmix
> - performs 2ch to 5.1 Dolby Prologic decoding
> - stereo to 3D stereo (SRS, virtual Dolby)
> - dynamic compression
> - ...
> o mixer and output control
> - possible input signals are all decoder outputs, all
> post-proc outputs and external PCM inputs
> - generates different mixes for each output, including
> volume and balance control
> - may include bass/treble control, equalizer or similar
> - may include a test tone generator ("beep")
> o S/P-DIF output
> - this is a separate device so it can be connected at
> various points in the signal path
> - S/P-DIF output may be synched to the STC (lip-sync)
>
>
> A possible simplification which would not sacrifice functionality
> for current hardware would be to integrate decoder and post-processor
> into one device. That means it won't be possible to have more than one
> post-processor per decoder.
>
> A post-proc can support a number of different modes, and in each
> mode there will be a distinct set of parameters. If a decoder
> does not use a post-proc the mode will simply be set to "none".
> Similarly, to feed PCM to a post-processor (or directly to
> the mixer) one would set the decoder to "pass though". This can
> also be used for PCM playback from memory.
>
> If the hardware has more decoders than post-processors they are
> assigned dynamically, and the attempt to enable a post-processor
> for a decoder may return EBUSY.
>
> Output from the decoder may be mono, stereo oder 5.1ch, and
> one can only select a matching post-processor mode.
>
> The outputs from the decoders and post-processors are fed
> into the mixer (so the mixer can e.g. output 5.1 on main
> and a stereo downmix on headphones).
>
> The S/P-DIF output device can be connected at various points
> in the signal path to output an undecoded stream or a PCM audio
> stream. If the output signal is PES from the demux it
> can be synced to the STC.
>
> Sample rate conversion is handled implicitely by the driver.
> The API only allows to specify input sample rates and output
> sample rates. If a rate conversion along the signal path is
> not supported by the hardware, an error code will be returned.
>
> The ioctls for the decoder + post-prcessor, mixer and spdif
> output device are defined in audio.h.
>
>
> I'm currently not sure how to proceed. The basic device
> structure might work for a variety of DVB audio systems,
> but the differences between audio HW are so large that
> it is difficult to have a generic API to manage all possible
> paramters.
> Also, the mixer could get awfully complicated because
> actual HW has many restrictions on internal signal routing.
>
> o we could try to define paramter sets for common functionality
> (e.g. 5.1 to stereo downmix or Dolby Prologic are common
> post-processors and would have common paramter sets), and leave
> everything else for private extensions;
> I'm inclined to go that way.
> o or we try to have a generic inferface with lots of capabilities etc.
> (sounds nice, but how?)
>
>
> Please comment.
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: FF cards alter PTS'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Holger Waechtler wrote: | | ... | Modern fanless Mainboards like the VIA Epia boards in the Hush-box have | much more CPU power and also some MPEG decoder helper functionality | speeding up the DCT on the CPU die (or was it on the graphics chip?). | MythTV has some experimental support for this feature IIRC. | | just my 2 cents, WRT a new STB (so not speaking about ricycling old HW!) with no moving part and cheap: the EPIA-M: ~ http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 has: - - fanless CPU - - 1 PCI slot (for a budget card..) - - a CLE266 north bridge who supports MPEG2 HW decoding and actually there's an effort to reverse engineer the "binary module" from via: ~ http://www.ivor.it/cle266/ ~ http://crp.pwp.blueyonder.co.uk/MPEG/details.html ~ http://forums.viaarena.com/messageview.cfm?catid=28&threadid=47219 her newer sister EPIA-TC has a CF slot and a 12V DC power onyl to make it a completely no-moving-part solution: ~ http://www.viavpsd.com/product/Download.jsp?motherboardId=201 disclaimer: i'm not involved in any way in VIA and other party businesses! ;-) bye andrea venturi -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/u5zOi/RI2aqk3sERAjesAJ9XPc8QPf7yh4JBSZm7avFBB/MeqQCfRzvB 6Ol8G3eGooB7sF9eSaeIV2E= =Vuf8 -END PGP SIGNATURE- -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'? [reply-to]
first sorry Holger, for sending that last pm, it was intended for the list, please ignore it, my writing was not suitable for public anyways, sorry once more. The list should have reply-to "[EMAIL PROTECTED]". This happened to me so many times. All the other lists do that. Regards, -- Alexandre CONRAD Research & Development tel : +33 1 30 80 55 00 fax : +33 1 30 56 50 20 TLV 6, rue de la plaine 78860 - SAINT NOM LA BRETECHE FRANCE -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Hi, first sorry Holger, for sending that last pm, it was intended for the list, please ignore it, my writing was not suitable for public anyways, sorry once more. Holger Waechtler schrieb: Steffen Barszus wrote: Am Dienstag, 18. November 2003 23:16 schrieben Sie: Hi Klaus, don't get me wrong, I appreciate your work. But I'm pretty angry about the situation that VDR is (I don't care whether willingly or not) endorsing these troublesome and expensive beasts since years. We have now at least since about two or three years cheap and good alternatives and there have been efforts to write DirectFB and Xine-backends for VDR but they never found their way into the mainstream source which means nothing else than that they are born dead. Why should they ? The plugin you speak about exists since some months (weeks). In the time i was on the vdr list the xine plugin is the first real approach on having a software display and i have never seen a patch for 1.0.x that tried that. Patches were really successfull even if they were not in main vdr (think of AIO, who is running vdr w/o it ? I guess 50% using it). Further the "solution" you think of has some problems. xine-plugin has actually a brother xinelibout-plugin which does use the xine lib directly, so no need to start xine manualy, only X must be configured to autostart and auto login a normal user (yack, like win9x). both do work as expected, allthough some osd limmitations still apply due to resolution differences, but you can't use an old pc(too slow or too noisy), you will need to buy a new one, don't leave that out of the calculations, when speaking of cheap. I was mainly thinking of df-gp, the first VDR patch I know that worked on the frambuffer (http://df-gp.sourceforge.net/). The first NEWS entry is now about 19 months old. df-gp suffers from exactly the problems i expected, 1st: only Matrox tv-out cards are suffcienty good ($$$), second: av-sync is not solved (19 month), third: de-interlace _is_ an immanent problem not solable without real de-interlacing software, which is cpu intensive and seldomly found as easy to use lib.(consider that dvb mpeg2 can even be mixed mode 50hz and 25hz in one picture, sometimes used on sky-news) At the end i don't think it is vdr that people let buy the FF cards, but i don't want to speak about the real reasons here on the list ... If i say that the long-time number one application under win was relying on FF cards too i guess you know what i mean. At least they managed to write a software decoder and OSD library, at least the skystar2 cards have been used now a long time for the purpose you're talking about. which in turn relies on ds-filters not "found" easily, or am i wrong? Holger Regards Onno -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
[EMAIL PROTECTED] wrote: Niklas Peinecke writes: Nico wrote: Personally I don't understand the passion for XML; I do; You can use many standard transformation tools for XML, those tools can parse-and-generate something else, including your samba format, but you can't get back from samba to xml. It's called XSLT (eXtensible Stylesheet Language Transformation). Believe me, it's short to code, powerful and saves lots of effort and energy. don't you believe that a structure like the one following (intended as an example, not as a proposal) is easier? It's nice, but [source] name=hotbird type=SAT diseqc_protocol=1.0 lnb=1 card=1 [mux] name=rai source=hotbird frequency=11766 polarization=v [programs] name=rai1 mux=rai vpid=160 apid=80 . If you want to parse this very clean you end up just with the same SAX like interface you would have with a XML solution. But above you can't parse with sax, nor can you apply xsl transformation unless (I Propose this) you rewrite it minimally to comply with XML, thus I think the correct universally parseable format would be this: Emard Well done, IMO this shows clearly, that XML doesn't need to look like the mess that WORD (ugh!) produces. Please note that XML 1.0 demands to have exactly _one_ root element, so it should read: [...your text...] Niklas -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
Niklas Peinecke writes: Nico wrote: Personally I don't understand the passion for XML; I do; You can use many standard transformation tools for XML, those tools can parse-and-generate something else, including your samba format, but you can't get back from samba to xml. It's called XSLT (eXtensible Stylesheet Language Transformation). Believe me, it's short to code, powerful and saves lots of effort and energy. don't you believe that a structure like the one following (intended as an example, not as a proposal) is easier? It's nice, but [source] name=hotbird type=SAT diseqc_protocol=1.0 lnb=1 card=1 [mux] name=rai source=hotbird frequency=11766 polarization=v [programs] name=rai1 mux=rai vpid=160 apid=80 . If you want to parse this very clean you end up just with the same SAX like interface you would have with a XML solution. But above you can't parse with sax, nor can you apply xsl transformation unless (I Propose this) you rewrite it minimally to comply with XML, thus I think the correct universally parseable format would be this: name="hotbird" type="SAT" diseqc_protocol="1.0" lnb="1" card="1" /> name="rai" source="hotbird" frequency="11766" polarization="v" /> name="rai1" mux="rai" vpid="160" apid="80" . /> Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: dvb-kernel bugs
usually yes, but as I wrote earlier it seems it doesn't work for skystar2 Manu Abraham wrote: To get a full TS dump, I believe dvbstream -f 8192 >file.ts gives a full TS dump. Regards, Manu On Wednesday 19 November 2003 17:38, you wrote: BTW it seems that the full TS dump isn't implemented in ss2 driver. This explains some oddities I had noticed. Wolfgang you could try a trick with dvbstream: dump 6 existing pids + 8192, such as dvbstream -f ... -o pid1 pid2 pid3 pid4 pid5 pid6 8192 > file.ts does it dump the full TS? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: dvb-kernel bugs
To get a full TS dump, I believe dvbstream -f 8192 >file.ts gives a full TS dump. Regards, Manu On Wednesday 19 November 2003 17:38, you wrote: > >>BTW it seems that the full TS dump isn't implemented in ss2 driver. > > > >This explains some oddities I had noticed. > > > >Wolfgang > > you could try a trick with dvbstream: > > dump 6 existing pids + 8192, such as > > dvbstream -f ... -o pid1 pid2 pid3 pid4 pid5 pid6 8192 > file.ts > > does it dump the full TS? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: dvb-kernel bugs
> > >If anything goes wrong (like the wind blowing the dish away), I have > > >to restart the driver: if it was szap -r and catting /dev/dvb/ad.. > > >to mplayer, this doesn't work anymore: no data (restarting the pipe > > >doesn't help either) > > > > what does mplayer say? > > > Nothing: it waits for input > > Wolfgang This could be mplayer's fault. What happens if you do "cat /dev/dvb/adapter0/dvr0 > tmp.ts" ? Get your personal e-mail for FREE at http://www.moldovacc.com -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: BroadLogic DVB-S card supported ?
Hi, The coship dvb card also uses the same chipset. They still manufacture the card, eventhough they are having bad sales. As per my knowledge neither the DVB driver nor the dvb-kernel supports this card at present. Regards, Manu On Wednesday 19 November 2003 16:29, you wrote: > Hello all, > Does the DVB driver support a DVB-S BroadLogic 2030 PCI card ? Broadlogic > discontinued driver development for Linux, leaving only a driver for an > "old" 2.4.18 (Redhat 7.3 stock kernel). What modules to load ? Other > drivers to search etc. > Thanks in advance, > > Alex > > > - > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: dvb-kernel bugs
BTW it seems that the full TS dump isn't implemented in ss2 driver. This explains some oddities I had noticed. Wolfgang you could try a trick with dvbstream: dump 6 existing pids + 8192, such as dvbstream -f ... -o pid1 pid2 pid3 pid4 pid5 pid6 8192 > file.ts does it dump the full TS? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: dvb-kernel bugs
On Mon, Nov 17, 2003 at 11:55:31PM +0100, Nico wrote: > > > >Hmh: that's a problem. Perhaps, it is as broken as it used to be? > >If anything goes wrong (like the wind blowing the dish away), I have > > > > such a wind? > Strong enough for my dish: I'm not allowed to install a dish at my flat, so I'm using a removable dish on the balcony which isn't installed very solidly ;-) > >to restart the driver: if it was szap -r and catting /dev/dvb/ad.. > >to mplayer, this doesn't work anymore: no data (restarting the pipe > >doesn't help either), using my dvbts 0x2000, which is supposed to dump > > > what does mplayer say? > Nothing: it waits for input > BTW it seems that the full TS dump isn't implemented in ss2 driver. > This explains some oddities I had noticed. Wolfgang -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Reception performance with Avermedia DVB-T
Holger,
On Tuesday 18 November 2003 23:23, Holger Waechtler wrote:
> Hi Martin,
>
>
> Your patch did not applied for me, there have been too many conflicts.
> Can you please generate it using
>
> $ cvs -q diff -pu
>
> again? btw: your code looks good but the Kconfig file should contain the
> comment how to extract the firmware, too. The TDA10046 entry is a good
> example.
>
> Many thanks,
>
> Holger
>
Attached is the new patch, created as you suggest.
MartinIndex: linux/drivers/media/dvb/frontends/Kconfig
===
RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/frontends/Kconfig,v
retrieving revision 1.14
diff -u -3 -p -p -u -r1.14 Kconfig
--- linux/drivers/media/dvb/frontends/Kconfig 13 Oct 2003 04:11:27 - 1.14
+++ linux/drivers/media/dvb/frontends/Kconfig 19 Nov 2003 12:42:56 -
@@ -155,3 +155,19 @@ config DVB_TDA1004X_FIRMWARE_FILE
wget http://www.technotrend.de/new/215/TTweb_215a_budget_20_05_2003.zip
unzip -j TTweb_215a_budget_20_05_2003.zip Software/Oem/PCI/App/ttlcdacc.dll
mv ttlcdacc.dll /etc/dvb/tda1004x.bin
+
+config DVB_SP887X_FIRMWARE_FILE
+string "Full pathname of sp887x firmware file"
+depends on DVB_SP887X
+default "/etc/dvb/sc_main.mc"
+help
+ This driver needs a copy of the Avermedia firmware. The version tested
+ is part of the Avermedia DVB-T 1.3.26.3 Application. This can be downloaded
+ from the Avermedia web site.
+ If the software is installed in Windows the file will be in the
+ /Program Files/AVerTV DVB-T/ directory and is called sc_main.mc.
+ Alternatively it can "extracted" from the install cab files but this will have
+ to be done in windows as I don't know of a linux version of extract.exe.
+ Copy this file to /etc/dvb/sc_main.mc. With this version of the file the first
+ 10 bytes are discarded and the next 0x4000 loaded. This may change in future
+ versions.
\ No newline at end of file
Index: linux/drivers/media/dvb/frontends/sp887x.c
===
RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/frontends/sp887x.c,v
retrieving revision 1.5
diff -u -3 -p -p -u -r1.5 sp887x.c
--- linux/drivers/media/dvb/frontends/sp887x.c 11 Nov 2003 12:30:36 - 1.5
+++ linux/drivers/media/dvb/frontends/sp887x.c 19 Nov 2003 12:42:56 -
@@ -1,11 +1,39 @@
+/*
+ Driver for the Microtune 7202D Frontend
+*/
+
+/*
+ This driver needs a copy of the Avermedia firmware. The version tested
+ is part of the Avermedia DVB-T 1.3.26.3 Application. If the software is
+ installed in Windows the file will be in the /Program Files/AVerTV DVB-T/
+ directory and is called sc_main.mc. Alternatively it can "extracted" from
+ the install cab files. Copy this file to /etc/dvb/sc_main.mc.
+ With this version of the file the first 10 bytes are discarded and the
+ next 0x4000 loaded. This may change in future versions.
+ */
+#define __KERNEL_SYSCALLS__
+#include
+#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
+
#include "dvb_frontend.h"
#include "dvb_functions.h"
+#ifndef DVB_SP887X_FIRMWARE_FILE
+#define DVB_SP887X_FIRMWARE_FILE "/etc/dvb/sc_main.mc"
+#endif
+
+static char *sp887x_firmware = DVB_SP887X_FIRMWARE_FILE;
#if 0
#define dprintk(x...) printk(x)
@@ -39,7 +67,7 @@ struct dvb_frontend_info sp887x_info = {
FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_RECOVER
};
-
+static int errno;
static
int i2c_writebytes (struct dvb_frontend *fe, u8 addr, u8 *buf, u8 len)
@@ -75,7 +103,7 @@ int sp887x_writereg (struct dvb_frontend
/**
* in case of soft reset we ignore ACK errors...
*/
- if (!(reg == 0xf1a && data == 0x000 &&
+ if (!(reg == 0xf1a && data == 0x000 &&
(ret == -EREMOTEIO || ret == -EFAULT)))
{
printk("%s: writereg error "
@@ -112,8 +140,9 @@ u16 sp887x_readreg (struct dvb_frontend
static
void sp887x_microcontroller_stop (struct dvb_frontend *fe)
{
+ dprintk("%s\n", __FUNCTION__);
sp887x_writereg(fe, 0xf08, 0x000);
- sp887x_writereg(fe, 0xf09, 0x000);
+ sp887x_writereg(fe, 0xf09, 0x000);
/* microcontroller STOP */
sp887x_writereg(fe, 0xf00, 0x000);
@@ -123,8 +152,9 @@ void sp887x_microcontroller_stop (struct
static
void sp887x_microcontroller_start (struct dvb_frontend *fe)
{
+ dprintk("%s\n", __FUNCTION__);
sp887x_writereg(fe, 0xf08, 0x000);
- sp887x_writereg(fe, 0xf09, 0x000);
+ sp887x_writereg(fe, 0xf09, 0x000);
/* microcontroller START */
sp887x_writereg(fe, 0xf00, 0x001);
@@ -135,6 +165,7 @@ static
void sp887x_setup_agc (struct dvb_frontend *fe)
{
/* setup AGC parameters */
+ dprintk("%s\n", __FUNCTION__);
sp887x_writereg(fe, 0x33c, 0x054);
sp887x_writereg(fe, 0x33b, 0x04c);
sp887x_writereg(fe, 0x328, 0x000);
@@ -152,8 +183,6 @@ void sp887x_setup_agc (struct dvb_fronte
}
-#include "sp887x_firm.h"
[linux-dvb] Re: channels.conf syntax?
Nico <[EMAIL PROTECTED]> writes: > - c++ doesn't always fit well with existing projects, and especially > it creates dependencies to gcc versions > (upgrading g++ is still a nightmare ) xawtv is written in plain C, thus any C++ library is out of question for me. Gerd -- You have a new virus in /var/mail/kraxel -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] BroadLogic DVB-S card supported ?
Hello all, Does the DVB driver support a DVB-S BroadLogic 2030 PCI card ? Broadlogic discontinued driver development for Linux, leaving only a driver for an "old" 2.4.18 (Redhat 7.3 stock kernel). What modules to load ? Other drivers to search etc. Thanks in advance, Alex Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard
[linux-dvb] Re: channels.conf syntax?
Nico wrote: The problems (as I see them) are: - a samba style file, as Gerd suggested, is much more easy to write, read, parse, fix by hand and understand It's not; only if you worked more with samba (or windows) than with XML. Otherwise it's pretty much the same. - c++ doesn't always fit well with existing projects, and especially it creates dependencies to gcc versions (upgrading g++ is still a nightmare ) Agreed. I chose C++ because I simply like it (it's like having both Java and C at once), but the code is not so much C++. You could transfer it to C with maybe a day work. Personally I don't understand the passion for XML; don't you believe that a structure like the one following (intended as an example, not as a proposal) is easier? [source] name=hotbird type=SAT diseqc_protocol=1.0 lnb=1 card=1 [mux] name=rai source=hotbird frequency=11766 polarization=v [programs] name=rai1 mux=rai vpid=160 apid=80 . If you want to parse this very clean you end up just with the same SAX like interface you would have with a XML solution. Anyway, there just has to be an agreement what to use, then it doesn't matter that much what format (C-struct,XML,init...) you use. The good thing with XML is that you have tons of apps that you can use with your data (no, not just text editors). I just offered my code because I thought VDR uses C++ anyway(?). Niklas -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
Hi,
I don't think things have to be made compicated, just to incorporate XML.
Moreover C++ is a burden. I believe things have to be made small and simple
(KISS). Small is really beautiful !!
Regards,
Manu
On Wednesday 19 November 2003 14:39, you wrote:
> On Wed, 19 Nov 2003, Jamie Honan wrote:
> > ... much good stuff elided ...
> >
> > > Which means to scan the range +/- 150kHz around each frequency (unless
> >
> > Isn't it +/- 125 Khz?
>
> Whoops, yeah, that too... Ahem. (not so good at this working from memory
> thing - at least I got channel 6 right :) [Pretty sure it's +/- 17
> Hz for the UK too...]
>
> > I was going to use something like this, in scconf format:
> >
> > tune_possibilities Australia {
> > type = "TV";
> > offsets = 0,-125,125;
> > bandwidth = "7Mhz";
> > frequencies = 177500, 184500, 191500, 198500, 212500, 219500,
> > 226500, 529500, 536500, 543500, 550500, 557500, 564500, 571500, 578500,
> > 585500, 592500, 599500, 606500, 613500, 620500, 627500, 634500, 641500,
> > 648500, 655500, 662500, 669500, 676500, 683500, 690500, 697500, 704500,
> > 711500, 718500, 725500, 732500, 739500, 746500, 753500, 760500, 767500,
> > 774500, 781500, 788500, 795500, 802500, 809500, 816500;
> > }
>
> M, pretty and compact. XML is neither of those things.
>
> > I've started documenting scconf. Here is my tongue-in-cheek
> > introduction:
>
> ...
>
> > Why doesn't it have X, why don't you use XML?
> > =
> >
> > Maybe it should. Maybe XML is the answer. Maybe a database is more
> > appropriate.
>
> Just because you use XML doesn't mean you need to link against a huge
> library. In my day job we use XML to describe game objects, model node
> hierarchies, settings files, etc. - pretty much anything that isn't a big
> block of binary data, i.e. a texture or a triangle array. We make minor
> changes to file formats quite a bit, usually for adding features.
>
> To parse the XML, we started off with linking against an XML parsing
> library (I think it was Xerces - this was in 2000 or 2001 'tho). It was
> huge and slow. So we decided to write our own and stick to a subset of
> XML: No attributes in tags and only one text string associated with each
> tag (which must come before any child tags).
>
> This made the parsing of the file really fast and easy, and the code to do
> it is very small. But it still meant we can edit and verify our files with
> any XML editor, since it is still legal XML (although vim/Notepad remains
> the most popular editor :)
>
> > It's all a trade-off. You choose. This is only a document.
>
> I think if you agree to use a subset of XML, you can write your own parser
> with no more difficulty than you would for any other file format, while
> keeping all the benefits and fuzzy goodness of XML :) [Although I note
> that scconf has data types built in, which is not the case with XML]
>
> > Jamie
>
> {P^/
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: channels.conf syntax?
The problems (as I see them) are: - a samba style file, as Gerd suggested, is much more easy to write, read, parse, fix by hand and understand - c++ doesn't always fit well with existing projects, and especially it creates dependencies to gcc versions (upgrading g++ is still a nightmare ) Personally I don't understand the passion for XML; don't you believe that a structure like the one following (intended as an example, not as a proposal) is easier? [source] name=hotbird type=SAT diseqc_protocol=1.0 lnb=1 card=1 [mux] name=rai source=hotbird frequency=11766 polarization=v [programs] name=rai1 mux=rai vpid=160 apid=80 . Nico Niklas Peinecke wrote: Gerd Knorr wrote: "Nico" <[EMAIL PROTECTED]> writes: please, everything but NOT XML: it's uselessly complicated and implies dependencies to external libs, which are rejected by many projects (e.g. mplayer, as far as I'm concerned). Agreed, every f*cking additional library dependency makes software maintainance harder, and I absolutely don't see the point in using XML for config data. Gerd Well, if the library dependancy is a problem I could donate my own lightweight (450 lines of code) XML parser. It's pure C++, one class only, SAX like API (easy to use, no overhead), quite verbose on errors and maybe pretty fast (finite automata based). If anybody is interested, please contact me. Btw. XML is not complicated. You don't have to use all the mumbo jumbo extensions (dtd, schema, namespace and what else) and can only use it as simple as html. Niklas -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
On Wed, 19 Nov 2003, Jamie Honan wrote:
>
> ... much good stuff elided ...
>
> > Which means to scan the range +/- 150kHz around each frequency (unless
>
> Isn't it +/- 125 Khz?
Whoops, yeah, that too... Ahem. (not so good at this working from memory
thing - at least I got channel 6 right :) [Pretty sure it's +/- 17
Hz for the UK too...]
> I was going to use something like this, in scconf format:
>
> tune_possibilities Australia {
> type = "TV";
> offsets = 0,-125,125;
> bandwidth = "7Mhz";
> frequencies = 177500, 184500, 191500, 198500, 212500, 219500,
> 226500, 529500, 536500, 543500, 550500, 557500, 564500, 571500, 578500,
> 585500, 592500, 599500, 606500, 613500, 620500, 627500, 634500, 641500,
> 648500, 655500, 662500, 669500, 676500, 683500, 690500, 697500, 704500,
> 711500, 718500, 725500, 732500, 739500, 746500, 753500, 760500, 767500,
> 774500, 781500, 788500, 795500, 802500, 809500, 816500;
> }
M, pretty and compact. XML is neither of those things.
> I've started documenting scconf. Here is my tongue-in-cheek
> introduction:
>
...
>
> Why doesn't it have X, why don't you use XML?
> =
>
> Maybe it should. Maybe XML is the answer. Maybe a database is more
> appropriate.
Just because you use XML doesn't mean you need to link against a huge
library. In my day job we use XML to describe game objects, model node
hierarchies, settings files, etc. - pretty much anything that isn't a big
block of binary data, i.e. a texture or a triangle array. We make minor
changes to file formats quite a bit, usually for adding features.
To parse the XML, we started off with linking against an XML parsing
library (I think it was Xerces - this was in 2000 or 2001 'tho). It was
huge and slow. So we decided to write our own and stick to a subset of
XML: No attributes in tags and only one text string associated with each
tag (which must come before any child tags).
This made the parsing of the file really fast and easy, and the code to do
it is very small. But it still meant we can edit and verify our files with
any XML editor, since it is still legal XML (although vim/Notepad remains
the most popular editor :)
> It's all a trade-off. You choose. This is only a document.
I think if you agree to use a subset of XML, you can write your own parser
with no more difficulty than you would for any other file format, while
keeping all the benefits and fuzzy goodness of XML :) [Although I note
that scconf has data types built in, which is not the case with XML]
> Jamie
{P^/
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: channels.conf syntax?
Gerd Knorr wrote: "Nico" <[EMAIL PROTECTED]> writes: please, everything but NOT XML: it's uselessly complicated and implies dependencies to external libs, which are rejected by many projects (e.g. mplayer, as far as I'm concerned). Agreed, every f*cking additional library dependency makes software maintainance harder, and I absolutely don't see the point in using XML for config data. Gerd Well, if the library dependancy is a problem I could donate my own lightweight (450 lines of code) XML parser. It's pure C++, one class only, SAX like API (easy to use, no overhead), quite verbose on errors and maybe pretty fast (finite automata based). If anybody is interested, please contact me. Btw. XML is not complicated. You don't have to use all the mumbo jumbo extensions (dtd, schema, namespace and what else) and can only use it as simple as html. Niklas -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: FF cards alter PTS'?
Am Mittwoch, 19. November 2003 04:15 schrieben Sie: > Johannes Stezenbach writes: > > Klaus Schmidinger wrote: > > > Well, AFAICS this "old hardware" is very widely used, and the > > > main platform VDR is designed for. And judging from the download > > > volume every new version of the "linvdr" distribution causes > > > (according to Mirko Dölle) VDR must be rather popular ;-) So I > > > guess this hardware will still be in use for quite a while, and > > > I can see no adequate replacement around - but that may be due > > > to my lack of market overview... > > > > The "funny" thing is that you can buy a full av7110 based set top > > box for 150 Euro (sometimes cheaper), but the DVB-S/C cards are > > still sold for 299 Euro here at Saturn. I would be happy if VDR > > were designed to run on hardware which is cheaper and has better > > Linux developer support > > Funny, or rather sad? > Considering what the parts on those cards cost, that they are > probably cheaper than 4 years ago, and that the cards still cost the > same ... The STBs you mention went down from about 500 Euro to 150 > Euro in the same time. > But the market makes the prices and I guess too many people are still > willing to pay that much lacking a better and/or cheaper "full > featured" alternative. 299 EUR isn't really the price someone would pay for such a card. More common are prices around 200 EUR. I have asked at such a store and was told that they sell one in a half year. Steffen -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
"Nico" <[EMAIL PROTECTED]> writes: > please, everything but NOT XML: it's uselessly complicated and > implies dependencies to external libs, which are rejected by many > projects (e.g. mplayer, as far as I'm concerned). Agreed, every f*cking additional library dependency makes software maintainance harder, and I absolutely don't see the point in using XML for config data. Gerd -- You have a new virus in /var/mail/kraxel -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
... much good stuff elided ...
> Which means to scan the range +/- 150kHz around each frequency (unless
Isn't it +/- 125 Khz?
I was going to use something like this, in scconf format:
tune_possibilities Australia {
type = "TV";
offsets = 0,-125,125;
bandwidth = "7Mhz";
frequencies = 177500, 184500, 191500, 198500, 212500, 219500,
226500, 529500, 536500, 543500, 550500, 557500, 564500, 571500, 578500,
585500, 592500, 599500, 606500, 613500, 620500, 627500, 634500, 641500,
648500, 655500, 662500, 669500, 676500, 683500, 690500, 697500, 704500,
711500, 718500, 725500, 732500, 739500, 746500, 753500, 760500, 767500,
774500, 781500, 788500, 795500, 802500, 809500, 816500;
}
I've started documenting scconf. Here is my tongue-in-cheek
introduction:
scconf system
=
The scconf system is a handy system library for handling
scconf files.
Why should anyone care about scconf format?
It is a handy format for short pieces of structured
data.
Handy because:
- it is readable, which makes support easy
- it is easy to parse and write
- it is extensible, you can add fields without breaking things
It isn't
- XML, so it doesn't need xml parsing
- suitable for large amounts of data, like a database or text files
It doesn't have
- anything else but data. No locking, no threads etc.
It has heirarchical data blocks, it has lists.
Similar, but different:
- .ini files. scconf is block structured, has lists
- sexp. sexp resembles lisp with it's use of parenthesis. sexp
has modes for binary. scconf really doesn't have binary
- xml. xml is more complete, but requires a lot of overhead
- yaml. yaml is larger
Why doesn't it have X, why don't you use XML?
=
Maybe it should. Maybe XML is the answer. Maybe a database is more
appropriate.
It's all a trade-off. You choose. This is only a document.
Jamie
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: FF cards alter PTS'?
Am Mittwoch, 19. November 2003 02:19 schrieben Sie: > Steffen Barszus wrote: > > Am Dienstag, 18. November 2003 23:16 schrieben Sie: > >>Hi Klaus, > >> > >>don't get me wrong, I appreciate your work. But I'm pretty angry > >>about the situation that VDR is (I don't care whether willingly or > >>not) endorsing these troublesome and expensive beasts since years. > >> > >>We have now at least since about two or three years cheap and good > >>alternatives and there have been efforts to write DirectFB and > >>Xine-backends for VDR but they never found their way into the > >>mainstream source which means nothing else than that they are born > >>dead. > > > > Why should they ? The plugin you speak about exists since some > > months (weeks). In the time i was on the vdr list the xine plugin > > is the first real approach on having a software display and i have > > never seen a patch for 1.0.x that tried that. Patches were really > > successfull even if they were not in main vdr (think of AIO, who is > > running vdr w/o it ? I guess 50% using it). Further the "solution" > > you think of has some problems. > > I was mainly thinking of df-gp, the first VDR patch I know that > worked on the frambuffer (http://df-gp.sourceforge.net/). The first > NEWS entry is now about 19 months old. I have seen that too. But this project was limited and is still limited to Matrox cards. I have tried to get a good supported matrox card to no avail (a matrox g400). It may be a good solution, but it is not practicable in reality. If it would work with an ati rage 128 or the like i guess it would had become a lot more popular. Now the Xine-plugin is a lot more flexible than df-gp. > > At the end i don't think it is vdr that people let buy the FF > > cards, but i don't want to speak about the real reasons here on the > > list ... If i say that the long-time number one application under > > win was relying on FF cards too i guess you know what i mean. > > At least they managed to write a software decoder and OSD library, at > least the skystar2 cards have been used now a long time for the > purpose you're talking about. > > Holger Its just a few months old and it was recommended till the end to get a FF card. Steffen -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
On Mon, 17 Nov 2003, Chris Samuel wrote:
> > Anyway, the main problem is that there are too many different formats.
> > It would be nice to agree on a standard format and have a simple library
> > to support it. I would like to know how other DVB software authors think
> > about that.
>
> I'm not an author, just a user, but I'd strongly suggest considering
> using XML as a format. It's vaguely readable by humans, well supported
> and extensible.
FWIW I used XML for the equivalent of channels.conf in iTele on the Mac.
It was the obvious thing to do since everything like this is in XML on OS
X, and Apple has nice libraries for reading and writing it.
As Jamie said, it's very hierarchial, so I put information at the highest
level it can go. But when I read it out, I don't care what level it's at,
I just start at the deepest one and work my way up until I find the
parameter I'm looking for. In that way you can put common settings up high
but still override them at a lower level for certain cases if you need to.
Also I separated out the static regional tuning parameters from the
user/station settings. The station settings are stored as preferences
using Apple's APIs for Preferences (also ends up as XML). These tend to
change quite frequently (esp in Australia) so it makes no sense to try to
distribute a file to keep up with them - rather they are updated each time
the user tunes to a program on that frequnecy.
The user prefs are generated for the first time (and later if the user
chooses to look for new 'channels') by scanning all the entries defined in
the static file. Since the prefs are auto-generated in this way, there is
no advantage to maintaining the hierarchy from the static file and so it
is flattened into a list of 'hardware' settings. The program IDs and names
are stored as an array within the entry for its frequency. Similarly, the
stream element info is stored as an array within its program entry.
In Mac OS X, the kernel actually has utilities (yes, in C++!) for doing
stuff with XML, and it is easy to pass an block of XML to a driver in a
system call. So as far as extracting data from XML to send to drivers,
that is actually left to the drivers themselves to look for parameters
they are interested in.
This has a number of advantages. Firstly, the userspace software doesn't
have to know about or understand all the parameters that the drivers need,
all it has to do is pass them a block of XML. You can add parameters that
special drivers need, or switch between terrestrial/satellite/cable
settings without the userspace software knowing how to fill in all those
structures. Also, the absence of a parameter can be interpreted as 'do
your best', very much like XXX_AUTO in linux-dvb.
The contents of the static file are derived from the legal broadcasting
requirements for each region (I haven't got to satellites yet, maybe this
wouldn't work for them), so that it is reasonably static. So for Australia
there's a list of channels that can have digital broadcasts on them, i.e.
7MHz spacing of VHF 6-12, followed by UHF 28-68 (or whatever it is).
Common parameters like ' 7' go into the top level of the XML
file, and parameters specific to a channel like ' 17750'
go into the XML node for each channel.
The one parameter that iTele does know about is frequency, and if present
it can also scan around a centre frequency, so at the top level of the
static XML file is:
15
15
Which means to scan the range +/- 150kHz around each frequency (unless
overridden by a specific channel definition) in steps of 150kHZ. i.e. for
VHF channel 6 it tries 17735, 17750 and 17765 when attempting
to tune it. If it finds one with signal it stops looking on that channel
(and that is the one that ends up being written into the prefs).
> Just my 2p worth.
>
> Chris
I hope that was useful.
If you're interested the current version of the list is found at
iTele.app/Resources/tunerLocationParams.plist inside the latest iTele
package from www.defyne.org/dvb/. You may need a Mac to mount the disk
image ... sorry about that, in the middle of setting up a live CVS
repository right now. Also in the next version I'm going to make it update
the file from the web (one call in Mac OS X ...
NSDictionary * myDict = [NSDictionary dictionaryWithContentsOfURL:[NSURL
URLWithString:@"http://www.defyne.org/dvb/locationTunerParams.plist";]]
... weird Objective-C but hey :)
{P^/
btw XML is just illustrative. Apple uses a format along the lines of:
BandwidthMHz
7
...
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: New project - BudgetTV is running now!
Emard So you have it running? From: Emard <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Ivan Gerasimov <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: [linux-dvb] Re: New project - BudgetTV is running now! Date: Wed, 19 Nov 2003 00:12:38 +0100 > "graze" was in the very first "midnight_on_14112003" > version and for 10 min. only. I saw the graze too :)). However the budget based viewer/recorder is the great thing :) Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject. _ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now! http://join.msn.com/?PAGE=features/es -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
Johannes Stezenbach <[EMAIL PROTECTED]> writes: > Anyway, instead of bashing VDR or the other exisiting channel list > formats, let me state the goal I am pursueing (sparked off by > a recent posting by Jamie Honan): I would like to define a standard > format for DVB channel lists and input configuration, which would > be backed up by a tiny C library so it is usable by potentially > every Linux DVB program out there. > I would like to hear some opinions if that goal is worthwile > or if we should stop right here. I'd like to see that happen. As you might have guessed from looking at xawtv's config file format I actually like the samba-like style, i.e. like this ... [station id] frequency = ... audio_pid = 23 video_pid = 42 ... ... because it is easy to read (for humans, without counting colons ;) and also easy to parse. But I don't care that much how that format actually looks, it should just be the same for everyone. Sticking with the current vdr format (which seems to be the de-facto standard right now) would be fine too. > VDR currrently does not have the concept of favorites lists, and thus > the sort order of the channels.conf is important. That should be fixed. The shared channels.conf should just have the tuning information and nothing else. Gerd -- You have a new virus in /var/mail/kraxel -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: channels.conf syntax?
> > I'm not an author, just a user, but I'd strongly suggest considering > > using XML as a format. It's vaguely readable by humans, well supported > > and extensible. > > Agreed, we better think now about far future and use XML. > > Of course when I speak of XML, I want to say the format with > good structure reflecting physical structure of DVB-C/S/T and > the good tagging. > > Emard > > please, everything but NOT XML: it's uselessly complicated and implies dependencies to external libs, which are rejected by many projects (e.g. mplayer, as far as I'm concerned). -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
