• Announcements

    • Scorchie™

      Upgrade   07/22/2016

      Welcome to Version 4.  You will need to log back in with your Display Name and/or Email Address.  If you don't know this, please issue a password or account reset to obtain the details you need. Some posts will appear "broken" (links, quote text, et al).  The forum is rebuilding all content which will take some time to complete.  Once this is done, the "missing" posts should also hopefully reappear. Should you encounter problems and wish to discuss, please post here:  


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About FyKnight

  • Rank
    AV Forum Member

Contact Methods

  • Website URL
  • ICQ
  1. Those are the interfaces to the linux DVB driver model. IIRC frontend0 lets you control the 1st frontend on the card - you can tell it to tune a specific frequency/bandwidth, query it for signal strength, etc. The demux0 node is one you can use to get actual data out - you tell it what PIDs you're interested in and it'll give TS packets with those PIDS to you. For most cards nowadays the demuxing (demultiplexing of the MPEG2 Transport Stream) happens in the kernel and is done by the driver, not the card. Only devices that have a limited pipe to the computer (like USB1.1 boxes) do the demuxing on the device itself. And with your card the BT878 RISC instruction set is a bit too primitive to express a filter like that. When I say 'you tell it' above I mean that you open the device and send it a specific ioctl. For reading the demuxed (filtered) stream I think you just use read. But yeah, if you want to get into this side of it instead of using an app that opens those nodes itself, it'd be best to ask on the linux-dvb list like rumpole says.
  2. The BT878 is the biggest chip on the card, near the PCI bus. All it is doing on that card is buffering the MPEG stream coming from the frontend, and DMAing it across the PCI bus to your RAM. Oh and it has an interface for the card's I2C bus so you can control the other chips. As rumpole says, it does a whole lot of other stuff which isn't used at all in a digital TV design. It's not even that well suited for digital TV... so I guess it must be popular because it's cheap! The 'frontend' is a bit of a nebulous term, but generally (in linux-dvb anyway) it's the useful bit after that PCI bridge chip: the demodulator and the tuner. The demodulator is a smaller chip that does the actual work, usually sitting on the board near the tin box. Sometimes it's inside the tin box. Internally it's often a DSP-derived design. The tuner is the circuits inside the tin box that take the RF signal from the air, and shift a chunk of it (7 MHz here) down to a workable frequency, that the demod can do its magic with. As for what the components on that card specifically are, have a look on the linuxtv wiki. Although once you load the bt878 driver (if it has the DVB part compiled in) it should auto-detect the card, print it out, and load the appropriate frontend driver.
  3. Cool, the other thread about the VPG coming soon threw me off. Well I'm still happy anyway! btw For others discovering this thread, the EPG seems to go out 24 hours.
  4. I was idly flicking through channels just then, when I noticed that ABC HDTV had a whole lot more entries in its EPG that just Now and Next. I ran to get my paper TV guide, and sure enough, it's all correct! How long has this been happening? I haven't been watching much TV lately, so it could have been weeks AFAIK... but no thread here so maybe I'm the first to notice it? Of course, ABC HDTV isn't always the same as normal ABC (and it sure ain't HDTV ) but this is good enough for me. Or at least it's a great start! I can't see how far out it goes because I haven't implemented a scroll bar in that window of iTele yet, but it appears to go at least until 7:30 next morning.
  5. Well, I don't have Windows. The Windows software that ships with pretty much every DVB device, regardless of its quality, is useless to me. But I still have to pay for it.That's why I think it's great that a vendor is offering a device without software costs included. Mac users like myself don't want that software anyway.
  6. Right, that was the answer I was looking for . So those who can't use DigiTV (Linux people and in future probably Mac people ) may as well get the slave version, assuming they don't want the remote control. This could be really good!
  7. So, I'm confused, what's the physical difference between the master and the slave? Apart from the lack of a remote control receiver on the slave... ... which wouldn't account for that difference in price.Is there any reason that people who don't care about remote controls (or maybe have a non-Nebula 'master' device already) can't just use a slave device standalone?
  8. So, what did that 'soon' mean Renura? If there's someone you know working on it I could do with some pointers! So far (tonight) these are the layers I've bashed down through: - normal DVB-T/H modulation, thank goodness - normal MPEG-2 transport stream, excellent - services with only DVB data elementary streams - multiprotocol encapsulation style DVB data (tables mechanism!), with IP stuffed into MAC field - IPv6 datagrams under that - UDP datagrams ... and it looks like there are a few more to go! With all that overhead I'm surprised that there's any room for the multimedia or what have you that it's transporting. I've found some UDP packets where the next layer is RDP (after much searching and no help from 'strings'). In general I can't find much in the way of specs, only lots of docs suggesting ways that it could be done in :-). Also I found another type of stream with (seemingly) a different protocol wrapping up the data. It's not a DVB object/data carousel but it sure is full of files! Here's one of them: <HTML> <HEAD> <TITLE></TITLE> <STYLE type="text/css"> BODY { margin: 0px; padding: 0px; } </STYLE> </HEAD> <BODY> <div align="center"> <img src="foxf.jpg" width="100%" height="100%" border=0> </div> </BODY> </HTML> And here's another that you might recognise: (Click here if image doesn't display above) I did find something else 'tho that makes me think the chances of displaying the big streams are pretty small: SECURITY_FILE_VERSION: 3 [INFO] IPDC policy file. [POLICY] sa ipdc_encrypted_in = { esp encrypt_alg 2 } inbound local FF15:0:0:0:0:0:80:0 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF80:0 protocol 17 = { ipdc_encrypted_in() } inbound = { } outbound = { } So, anyone got any pointers or ideas? Especially linux people who had a head-start with the MPE stuff?
  9. OK, the high level organisation of a transport stream is not like that of a DVD. You can put the same info that's in a transport stream into a program stream, but DVDs don't work that way. On a DVD, you have various info files that describe the titles, chapters, buttons, etc. The info isn't put into the actual VOBs. In a transport stream, there is only one stream, so it all has to live in there. The top-level structure is the PAT = program association table. That has a list of all the programs available in the stream. Each program is described by its own PMT = program map table. That description lists all the substreams that make up the program. i.e. video, choice of audio, teletext/subtitles, whatever. Different programs can share substreams for sure. It also has other info about it like content, rating, and other small pieces of data. Now, PIDs. A PID is just a packet id. Every TS packet has a packet id that identifies what substream/table it is part of. It's like a port in TCP/IP (if that helps). The PAT is always found on PID 0x000. It lists which PID each PMT is found on. In the PMT, it lists which PID each substream is found on. A service id is a number to remember a program by (it's found in the PAT). It's supposed to be static, so that even if the substreams and/or PMT changes PIDs, the logical identifier of the program is still the same. So your prefs for 7 HD Digital stay with that channel even if another program is inserted before it in the PAT (or whatever). VLC is probably displaying the Service ID whereas Project X is displaying the PID of the PMT. (Which is not very helpful actually... multiple PMTs can be found on the same PID, especially in satellite broadcasts.) Project X probably only uses the program identified by the first PMT it finds. Because it can only handle one program at a time. Thus it ignores all the others. OK, hope that answered all your questions.
  10. Kenneth, I haven't released the updated drivers yet but I'll prolly do so this weekend. Send me an email if you want them earlier. Also, it would be great if you'd post stuff like that issue with the driver on my forums, so that 1. I can see it more easily, and 2. We do not hijack this thread with Mac stuff . Renura, No worries, my pleasure!
  11. I have a real tinyUSB2 now, and I can confirm that it works fine with my driver and a dodgy antenna, if that is what people are wondering about . I plugged it straight into the back of a Mac without using an extension cable... it's slightly too big to pretend it's a dongle, but it is light enough to just hang off the port there without me worrying about it damaging anything. You get used to it being there . It gets warm when in use but not too warm. And my driver takes care to power it down when it's not in use so it doesn't waste laptop batteries. There was actually a bug where the driver would not boot the device on recent model Macs... in fact I was surprised to see Kenneth had no problems there! Anyway, I just fixed that bug an hour or so ago (strictly speaking, it was a bug in the OS, but I have worked around it) so AFAIK there's no driver issues any more. Oh, and yeah, I can watch and record HD with it fine. Of course. This is on a 1.8GHz iMac G5. To answer Kenneth's questions: - HD is saved exactly the same way as SD is saved. In MPEG2-PS modelled on the format that the Technotrend windows software saves its recordings in. - If you can record SD you can record HD (hard-disk speed permitting). - There's no codecs involved, it's just remultiplexed from TS to PS. - Whether or not windows players like the format is another matter. It is in spec, and MPlayer should like it. I intend to change the recording format to vobs like on a DVD soon anyway. You can remux files with ProjectX and other tools if you've already made recordings. - You can use MPlayer as your viewer as a workaround for the stretched channels until I fix the internal viewer. I just set the window to the size ffmpeg tells me so I don't know what's going on with it but it shouldn't be hard to fix. Also, there is hope for your iBook yet Kenneth. Last week I reverse engineered the API to Apple's hardware IDCT layer: http://www.defyne.org/forums/viewtopic.php?t=438. It's like DXVA on windows and XVMC on linux. Various tester results here: http://www.defyne.org/forums/viewtopic.php?t=440. This is mainly aimed at getting Australian HDTV on low-end Mac minis, but iBooks will benefit also. Haven't figured out how to convince it to do 1080i yet.
  12. Hi, I just finished the Mac driver for this device. I've gotta say it's been the smoothest driver I've ever written... I sat down to make a start on it about 4 hours ago and now I'm all done The remote control isn't supported yet, and nor are USB1.1 connections (not that they're any good for HDTV anyway). I'll probably do a pass on a whole lot of remote control drivers at some stage when I've nutted out a common framework for them. Anyway, you guys don't care about that.... hmmm what do you care about? The tuner module is the cutest little thing. It's the same 'form factor' as the usual tuner modules you get on PCI cards, but it's all shrunk down to about half size on each dimension... it's a baby one I'm going to put it through its paces a bit more next week, but so far it all looks good. So there you go, one of the few digital TV products that's going to hit the streets with Mac support from day one. In fact it'll be perfect for all those people trying to make an HTPC out of a Mac mini. Now we just have to encourage renura to make 'day one' arrive soon!
  13. What's the point, they just won't work Pure marketing hype as far as I'm concerned <{POST_SNAPBACK}> Well according to Mac users of the Cinergy T2 the little aerials do actually work, but not well enough that you wouldn't use a proper one whenever you have the choice. Of course they're all Europeans so we will have to wait and see how it fares here.
  14. One Mac driver author reporting for duty, sah!If this thing's going be available in Australia for less than AU$200 then I'm interested! OK let's see... Zarlink demod, the fully featured MT352 I presume (with wicked-fast blind scan mode). Samsung tuner, maybe a TDTC9251DH01C, but they're all the same anyway. Cypress USB interface, all depends on the firmware of course. Maybe it'll hide the I2C bus from the PC so the driver never needs to talk to those chips. Well I won't bother trying to import any of the TerraTec Cinergy T2s then. They'd work out at around AU$145 before tax and whatnot.And maybe a driver for this will get all the people who want a driver for the DVICO USB box off my back! (Assuming that it comes out some time soon not like the Nebula DigiTV USB thingy.) So, yes, Renura, how about those specs then?
  15. I have it on good authority that the (userspace) DVB API on the Mac looks like this: class MMInputDevice : public MMInput { public: static MMInputDevice * withIndex( int index = 0 ); void release(); virtual UInt32 identifier() const; virtual UInt32 activate(); virtual void deactivate(); virtual TuningParams tuningSpace() const; virtual bool tune( NSDictionary * params ); virtual DataKind dataKind() const; // DVB, ATSC, etc virtual bool fill( bool go ); UInt32 retrieve( void * & data, UInt32 & length ); virtual void situation( UInt32 & progress, UInt32 & strength, UInt32 & quality ); virtual void statistics( UInt32 & blobsTotal, UInt32 & blobsErrors ); ... }; Activate activates the device. Tune tunes to a frequency (bandwidth, code rate, etc.), fill starts filling the RAM buffer, and retrieve gets any data added to the buffer since the last call. You can also get info on the current tuning situation and historical statistics. The internal driver structure uses the standard Apple IOKit framework (which has nothing to do with BSD), but there would probably be no Mac support were it not for the information in the open source linux drivers. [plug]http://www.defyne.org/dvb/[/plug] {P^/