Re: mythtv and digital tv
Jarod Wilson wrote: On Thu, 2008-07-24 at 21:17 -0400, Ben Scott wrote: On Thu, Jul 24, 2008 at 6:36 PM, Frank DiPrete [EMAIL PROTECTED] wrote: I like the HDHomeRun card ... Just to make sure it's clear, the HDHomeRun isn't a card, it's an external box (about the size of a cigar box). It uses a wall-wart type power supply transformer. If the card had hardware encoding it would be perfect. Encoding or decoding? For digital broadcast -- be it cable or ATSC OTA -- the stream is already encoded and compressed as part of the transmission process. There's no need for an encoder. The HDHomeRun is digital only; it doesn't even have an NTSC tuner. So, to the best of understanding, the HDHomeRun has no use for a hardware encoder. The HD-5500 does have an NTSC tuner; I don't know if it has a hardware encoder or not. It does not. Its only much more recently that cards with both digital and analog support also included a hardware encoder for the analog side. The only one I know for sure actually works under linux is the Hauppauge WinTV HVR-1600 though. For decoding, I believe you'd still be able to use the small quiet diskless box frontend. The one thing I'm not sure about is: I expect not all hardware decoders are created equal. It may be the decoder in your front-end box can't handle this new-fangeled high-def stuff. Definitely a concern. It takes a heck of a lot more for decoding HDTV than SDTV. Although not nearly so much as it used to. My frontend is a mere core duo 1.66 with intel gma950 graphics, and it handles the job just fine. Small quiet diskless often implies a Via processor though... Which may or may not be enough, depending on the video chipset, the openchrome driver, and the options mythtv was built with... The frontent is a via 1G. Current mpeg playback takes about 25% of the cpu. myth / xorg is using the openchrome driver. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
Ben Scott wrote: On Thu, Jul 24, 2008 at 6:36 PM, Frank DiPrete [EMAIL PROTECTED] wrote: I like the HDHomeRun card ... Just to make sure it's clear, the HDHomeRun isn't a card, it's an external box (about the size of a cigar box). It uses a wall-wart type power supply transformer. If the card had hardware encoding it would be perfect. Encoding or decoding? Encoding on the backend where the card goes. http://www.pchdtv.com/hd_5500.html The HD-5500 Hi Definition Television PCI Card is an universal PCI 2.2 compliant card. The card receives NTSC, ATSC and Cable/QAM Signals and converts them to digital streams which are transported across the PCI bus. Display and MPEG2 decoding are done on the host computer For digital broadcast -- be it cable or ATSC OTA -- the stream is already encoded and compressed as part of the transmission process. There's no need for an encoder. The description isn't clear about writing the streams to disk. The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac but the term digital streams isn't defined on the site. I'll check some mythtv sites about this card to see what is involved. The HDHomeRun is digital only; it doesn't even have an NTSC tuner. So, to the best of understanding, the HDHomeRun has no use for a hardware encoder. The HD-5500 does have an NTSC tuner; I don't know if it has a hardware encoder or not. Presumably, if you're buying an HD-5500, the plan is to switch to digital TV, so NTSC shouldn't matter. Also true. I would not be using an ntsc tuner. For decoding, I believe you'd still be able to use the small quiet diskless box frontend. The one thing I'm not sure about is: I expect not all hardware decoders are created equal. It may be the decoder in your front-end box can't handle this new-fangeled high-def stuff. The only prediction I have here is probably OK. playback of the recordings I make today (ntsc analog to mpg2/aac at 48K sampling - file is a bout 2G per hour) takes 25% of the via cpu while using the mpeg decoder chip. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
I'm guessing he would need to upgrade the frontend boxes. When I attempt to play my records from HDHomeRun on an Athlon 2800+ box w/nvidia fx 5200 card the mythfrontend process consumes about 80-90% cpu. If I do anything else on the box it's all over and the playback gets jittery. Going all digital/HD is expensive :) On Thu, Jul 24, 2008 at 9:17 PM, Ben Scott [EMAIL PROTECTED] wrote: For decoding, I believe you'd still be able to use the small quiet diskless box frontend. The one thing I'm not sure about is: I expect not all hardware decoders are created equal. It may be the decoder in your front-end box can't handle this new-fangeled high-def stuff. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Notes from PySIG, 24 July 2008: Improvisation and Intro to Python
Seven attendees made it to the July 2008 meeting of the Python Special Interest Group, despite the heavy rains. Due to some last-minute conflicts, our planned speaker, Ray Côté, had to take a rain check for a future meeting, but cookies were made and we resolutely carried on. There were two first-time attendees, one with a novice level of knowledge of Python and the second very little. Lead by the PySIG leader, Bill Sconce, we launched into an improvised session introducing Python and talking about its power, range and flexibility, comparing it with other languages, heckling Ben Scott, demonstrating several IDEs, talking about procedural scripting and object-oriented programming, showing off some working code, migrating database applications from proprietary platforms, and much, much more. A good time was had by all. Great thanks to Janet for a delightful variety of cookies, to Bill for not only running the meeting and providing the projector but also bringing the milk, to all for participating, and to the Amoskeag Business Incubator for providing the fine facilities. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
On Fri, 2008-07-25 at 07:11 -0400, Frank DiPrete wrote: Ben Scott wrote: On Thu, Jul 24, 2008 at 6:36 PM, Frank DiPrete [EMAIL PROTECTED] wrote: I like the HDHomeRun card ... Just to make sure it's clear, the HDHomeRun isn't a card, it's an external box (about the size of a cigar box). It uses a wall-wart type power supply transformer. If the card had hardware encoding it would be perfect. Encoding or decoding? Encoding on the backend where the card goes. http://www.pchdtv.com/hd_5500.html The HD-5500 Hi Definition Television PCI Card is an universal PCI 2.2 compliant card. The card receives NTSC, ATSC and Cable/QAM Signals and converts them to digital streams which are transported across the PCI bus. Display and MPEG2 decoding are done on the host computer For digital broadcast -- be it cable or ATSC OTA -- the stream is already encoded and compressed as part of the transmission process. There's no need for an encoder. The description isn't clear about writing the streams to disk. The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac but the term digital streams isn't defined on the site. I'll check some mythtv sites about this card to see what is involved. Digital streams definitely means mpeg2 here. HDTV (and all digital video) over the air and on cable in the US is always mpeg2, encoded as such as the head end. Digital tuner cards more or less simply tune into a broadcast mpeg2 transport stream and dump it to disk. For decoding, I believe you'd still be able to use the small quiet diskless box frontend. The one thing I'm not sure about is: I expect not all hardware decoders are created equal. It may be the decoder in your front-end box can't handle this new-fangeled high-def stuff. The only prediction I have here is probably OK. playback of the recordings I make today (ntsc analog to mpg2/aac at 48K sampling - file is a bout 2G per hour) takes 25% of the via cpu while using the mpeg decoder chip. Depends heavily on the generation of your video controller... Many of the unichrome video chipset mpeg2 decoders can't handle larger than 720x480 streams. I forget which one is which anymore, but the first-gen one on an EPIA M1 board definitely doesn't cut it (I have one). I believe unichrome pro II definitely *should* be able to, others, not sure.. -- Jarod Wilson [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re:
What keyboard does the OS think you have? mark On Thu, Jul 24, 2008 at 12:09 PM, John Abreau [EMAIL PROTECTED] wrote: I've got a server that's been giving strange errors lately. Most noticeably, when I login, I get several errors of the form -bash: [: =: unary operator expected I've traced these to files under /etc/profile.d, and on further testing I find that the offending lines are using backquotes, e.g. if [ `/usr/bin/id -u` = 0 ] ; then When I try to use backquotes on the command line on this server, I get no output. Even stranger, if I have a suspended vi job, then running something in backquotes terminates the vi process: $ vi foo ^Z [1]+ Stopped nvi foo $ echo `echo bar` [1]+ Terminated nvi foo If I do this on my other systems, I get $ echo `echo bar` bar and the vi job does not terminate. I've tried googling for these symptoms, but so far I haven't found a match. Has anyone else run across this odd behavior? What could be causing it? The server with the broken behavior is running CentOS release 5.2, and bash is bash-3.2-21.el5. -- John Abreau / Executive Director, Boston Linux Unix IM: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
VHS capture to MPEG?
I've got a number of VHS tapes I'd like to convert to MPEG2. I have a Pinnacle USB2 PRO (150e model). It has svideo, component and antenna inputs. It's got a remote and IR input. From what I've been reading, there is support in Linux for this thing. I have a VHS to hook up to it also. It came with some capture software that consumes all resources on a Celeron 1GHz with 2 GB RAM. I have a Pentium 4m (2GHz?) running Ubuntu Heron (8.10?). It can see the 150e. I don't want to do a MythTV setup just to capture 2-3 tapes. Any recommendations on software capturing? I know members have opinions :-) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VHS capture to MPEG?
This doesn't answer your question, but it's along the same thread an I thought it was funny: http://www.thinkgeek.com/electronics/video/a956/ On Fri, Jul 25, 2008 at 10:06 AM, Tom Buskey [EMAIL PROTECTED] wrote: I've got a number of VHS tapes I'd like to convert to MPEG2. I have a Pinnacle USB2 PRO (150e model). It has svideo, component and antenna inputs. It's got a remote and IR input. From what I've been reading, there is support in Linux for this thing. I have a VHS to hook up to it also. It came with some capture software that consumes all resources on a Celeron 1GHz with 2 GB RAM. I have a Pentium 4m (2GHz?) running Ubuntu Heron (8.10?). It can see the 150e. I don't want to do a MythTV setup just to capture 2-3 tapes. Any recommendations on software capturing? I know members have opinions :-) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ -- Travis Roy ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VHS capture to MPEG?
On Fri, Jul 25, 2008 at 10:06 AM, Tom Buskey [EMAIL PROTECTED] wrote: I've got a number of VHS tapes I'd like to convert to MPEG2. I have a Pinnacle USB2 PRO (150e model). It has svideo, component and antenna inputs. It's got a remote and IR input. From what I've been reading, there is support in Linux for this thing. I have a VHS to hook up to it also. It came with some capture software that consumes all resources on a Celeron 1GHz with 2 GB RAM. I have a Pentium 4m (2GHz?) running Ubuntu Heron (8.10?). It can see the 150e. I don't want to do a MythTV setup just to capture 2-3 tapes. Any recommendations on software capturing? I know members have opinions :-) I haven't done much in the way of video capture in awhile (and sadly I used to do it mostly in Windows). Your device seems to be a support Video4Linux capture device, and there are a number of both command line and GUI apps for recording (the Video4Linux wiki lists a number of them: http://www.linuxtv.org/v4lwiki/index.php/TV_Recording ). If you had some editing you wanted to do as well, you could use Cinelerra to do the capture and then editing as well ( http://cinelerra.org/docs.php ). A lot of this stuff is available in Ubuntu, either do a apt-cache search thing I'm searching for or you can search the Ubuntu package repositories on the web as well: http://packages.ubuntu.com/ -Shawn ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
On Fri, Jul 25, 2008 at 7:11 AM, Frank DiPrete [EMAIL PROTECTED] wrote: Encoding or decoding? Encoding on the backend where the card goes. If you're capturing digital TV (OTA or cable), no encoding is needed. The stream is already encoded, digitized, compressed, folded, spindled, and mutilated. This doesn't mean encoding is done on the host CPU; it means there's no encoding to do, period. This is *why* there's a big push to switch over to digital TV, even for standard definition channels. Digital TV uses a lot less bandwidth than analog NTSC, because it's compressed. They can fit something like six standard definition digital channels into the bandwidth consumed by one NTSC analog channel. The only way the host CPU would be doing any encoding would be if you wanted to transcode to a different format, e.g., for a player that doesn't do MPEG, or something like that. The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac ... ATSC is MPEG-2 video and AC-3 audio. I've read digital cable is basically ATSC with different modulation and a few extra tweaks. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
Quoting Ben Scott [EMAIL PROTECTED]: The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac ... ATSC is MPEG-2 video and AC-3 audio. I've read digital cable is basically ATSC with different modulation and a few extra tweaks. Correct. Cable uses QAM modulation (instead of VSB-8, which is what gets used for over-the-air ATSC transmission). The data stream is effectively the same as you'd get for over-the-air digital, MPEG-2 transport stream. The biggest difference is that cable companies can choose to encrypt their QAM, which means you either need a cablebox or a device with a cablecard. As far as I know no device usable by mythtv directly can use a cablecard without having yet another Digital-Analog-Digital conversion. So for example, for SD you could have mythtv control a cablebox and then read it in via a PVR-250. For HD you could effectively do the same but use an HD-PVR box. But if your cable company is really nice (RCN no longer falls under this category) then they don't encrypt your QAM and you could just plug an HD-Homerun directly into your cable. *sighs* -- Ben -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VHS capture to MPEG?
On Fri, Jul 25, 2008 at 12:02 PM, Shawn O'Shea [EMAIL PROTECTED] wrote: On Fri, Jul 25, 2008 at 10:06 AM, Tom Buskey [EMAIL PROTECTED] wrote: I've got a number of VHS tapes I'd like to convert to MPEG2. I have a Pinnacle USB2 PRO (150e model). It has svideo, component and antenna inputs. It's got a remote and IR input. From what I've been reading, there is support in Linux for this thing. I have a VHS to hook up to it also. It came with some capture software that consumes all resources on a Celeron 1GHz with 2 GB RAM. I have a Pentium 4m (2GHz?) running Ubuntu Heron (8.10?). It can see the 150e. I don't want to do a MythTV setup just to capture 2-3 tapes. Any recommendations on software capturing? I know members have opinions :-) I haven't done much in the way of video capture in awhile (and sadly I used to do it mostly in Windows). Your device seems to be a support Video4Linux capture device, and there are a number of both command line and GUI apps for recording (the Video4Linux wiki lists a number of them: http://www.linuxtv.org/v4lwiki/index.php/TV_Recording ). Exactly what I'm looking for. Hook up the device, start the VHS player, start capturing to a file. If you had some editing you wanted to do as well, you could use Cinelerra to do the capture and then editing as well ( http://cinelerra.org/docs.php). I've looked at a bunch. I also have apps for Windows and MacOSX that I can use. Transcoding, editing and pushing to DVDs are not my issue. A lot of this stuff is available in Ubuntu, either do a apt-cache search thing I'm searching for or you can search the Ubuntu package repositories on the web as well: http://packages.ubuntu.com/ Now that I know what I'm looking for. Thanks! ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
1Gb ramdisk in RHEL3
I'm trying to persuade an RHEL3.9 PAE kernel running on a machine
with 4GB RAM to let me create a ~1Gb ramdisk and the results
are, um, vexatious.
I start the kernel with the requisite ramdisk_size=nKb where I've
tried various values of n like 100 and 1048576. After the
kernel boots I say:
dd if=/dev/zero of=/dev/ram1 bs=1k count=n
...and dd reports success writing to the device. I then say:
mkfs.ext2 /dev/ram1
...followed by:
fsck.ext2 -f /dev/ram1
...and I see this:
e2fsck 1.32 (09-Nov-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/ram1: 11/131072 files (0.0% non-contiguous), 4127/262144 blocks
...and everybody appears to be happy. If I generate a hexdump
of the device I see the expected sort of glop:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 - etc...
0400 00 00 02 00 00 00 04 00 33 33 00 00 E1 EF 03 00
33..
0410 F5 FF 01 00 00 00 00 00 02 00 00 00 02 00 00 00
0420 00 80 00 00 00 80 00 00 00 40 00 00 00 00 00 00 [EMAIL
PROTECTED]
0430 AC 49 8A 48 00 00 20 00 53 EF 01 00 01 00 00 00 .I.H..
.S...
0440 AC 49 8A 48 00 4E ED 00 00 00 00 00 01 00 00 00
.I.H.N..
0450 00 00 00 00 0B 00 00 00 80 00 00 00 00 00 00 00
0460 02 00 00 00 01 00 00 00 BC 85 6E EC 56 B1 46 65
..n.V.Fe
0470 95 AA CA CB 96 52 24 C7 00 00 00 00 00 00 00 00
.R$.
0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0490 - etc...
04e0 00 00 00 00 00 00 00 00 00 00 00 00 AE 55 AB 2B
.U.+
04f0 F2 6D 49 80 90 BE 4A BC 8B 3D 5F C4 02 00 00 00
.mI...J..=_.
0500 00 00 00 00 00 00 00 00 AC 49 8A 48 00 00 00 00
.I.H
0510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0520 - etc...
1000 02 00 00 00 03 00 00 00 04 00 00 00 F7 7D F5 3F
.}.?
1010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1020 02 80 00 00 03 80 00 00 04 80 00 00 FC 7D 00 40
.}.@
1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1040 00 00 01 00 01 00 01 00 02 00 01 00 FE 7D 00 40
.}.@
1050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1060 02 80 01 00 03 80 01 00 04 80 01 00 FC 7D 00 40
.}.@
1070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1080 00 00 02 00 01 00 02 00 02 00 02 00 FE 7D 00 40
.}.@
1090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10a0 02 80 02 00 03 80 02 00 04 80 02 00 FC 7D 00 40
.}.@
10b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.
.
.
...but when I then say:
mount /dev/ram1 /mnt/test
...I immediately see this:
mount: wrong fs type, bad option, bad superblock on /dev/ram1,
or too many mounted file systems
...whereupon the same fsck command now says this:
e2fsck 1.32 (09-Nov-2002)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/ram1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 device
...and the hexdump now shows this:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: 1Gb ramdisk in RHEL3
OK, the ramdisk story is looking a bit better now. First, the tmpfs trick is definitely cool and worth remembering but isn't what we're looking for because some of what makes it cool also makes it unsuitable for our purposes. In particular, tmpfs has close ties to the kernel's buffer cache so files in tmpfs may actually be on backing store and since we're investigating a ramdisk solution to get some low-latency characteristics that makes tmpfs unsuitable for our purpose. Too bad, because rigging tmpfs is easier than rigging a ramdisk. The key to getting the [EMAIL PROTECTED]@!!! ramdisk to be usable was figuring out that ext2 and the ramdisk device driver had to agree on block size. The default for ramdisk is 1k and the default for ext2 is 4k. At first I tried to specify ramdisk_size=1048576 and ramdisk_blocksize=4096 on the kernel commandline (units are Kb for the former and bytes for the latter) and all would have been well. except that the machine in question boots from an initrd and the ext2 filesystem therein was already specified as using 1k blocks and the kernel panic'd when it failed to mount the initrd due to that mismatch. So, since I don't feel like rebuilding the initrd's filesystem with 4k blocksize I had the ramdisk fall back to the default 1k and told mkfs.ext2 to build the filesystem in the ramdisk using a 1k blocksize, thus: dd if=/dev/zero bs=1024k count=1048576 of=/dev/ram9 mkfs.ext2 -b 1024 /dev/ram9 mount /dev/ram9 /mnt/test ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: 1Gb ramdisk in RHEL3
Michael ODonnell writes: OK, the ramdisk story is looking a bit better now. First, the tmpfs trick is definitely cool and worth remembering but isn't what we're looking for because some of what makes it cool also makes it unsuitable for our purposes. In particular, tmpfs has close ties to the kernel's buffer cache so files in tmpfs may actually be on backing store and since we're investigating a ramdisk solution to get some low-latency characteristics that makes tmpfs unsuitable for our purpose. Too bad, because rigging tmpfs is easier than rigging a ramdisk. The key to getting the [EMAIL PROTECTED]@!!! ramdisk to be usable was figuring out that ext2 and the ramdisk device driver had to agree on block size. The default for ramdisk is 1k and the default for ext2 is 4k. At first I tried to specify ramdisk_size=1048576 and ramdisk_blocksize=4096 on the kernel commandline (units are Kb for the former and bytes for the latter) and all would have been well. except that the machine in question boots from an initrd and the ext2 filesystem therein was already specified as using 1k blocks and the kernel panic'd when it failed to mount the initrd due to that mismatch. So, since I don't feel like rebuilding the initrd's filesystem with 4k blocksize I had the ramdisk fall back to the default 1k and told mkfs.ext2 to build the filesystem in the ramdisk using a 1k blocksize, thus: dd if=/dev/zero bs=1024k count=1048576 of=/dev/ram9 mkfs.ext2 -b 1024 /dev/ram9 mount /dev/ram9 /mnt/test If you're using a ramdisk for purposes other than booting, make sure you have backported this fix if you are running a kernel older than 2.6.24: if you don't, your ramdisk blocks will disapear once you use all the ram in the system and the kernel needs to free memory http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5d0360ee96a5ef953dbea45873c2a8c87e77d59b -- Dave ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
Jarod Wilson wrote: On Fri, 2008-07-25 at 07:11 -0400, Frank DiPrete wrote: Ben Scott wrote: On Thu, Jul 24, 2008 at 6:36 PM, Frank DiPrete [EMAIL PROTECTED] wrote: I like the HDHomeRun card ... Just to make sure it's clear, the HDHomeRun isn't a card, it's an external box (about the size of a cigar box). It uses a wall-wart type power supply transformer. If the card had hardware encoding it would be perfect. Encoding or decoding? Encoding on the backend where the card goes. http://www.pchdtv.com/hd_5500.html The HD-5500 Hi Definition Television PCI Card is an universal PCI 2.2 compliant card. The card receives NTSC, ATSC and Cable/QAM Signals and converts them to digital streams which are transported across the PCI bus. Display and MPEG2 decoding are done on the host computer For digital broadcast -- be it cable or ATSC OTA -- the stream is already encoded and compressed as part of the transmission process. There's no need for an encoder. The description isn't clear about writing the streams to disk. The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac but the term digital streams isn't defined on the site. I'll check some mythtv sites about this card to see what is involved. Digital streams definitely means mpeg2 here. HDTV (and all digital video) over the air and on cable in the US is always mpeg2, encoded as such as the head end. Digital tuner cards more or less simply tune into a broadcast mpeg2 transport stream and dump it to disk. For decoding, I believe you'd still be able to use the small quiet diskless box frontend. The one thing I'm not sure about is: I expect not all hardware decoders are created equal. It may be the decoder in your front-end box can't handle this new-fangeled high-def stuff. The only prediction I have here is probably OK. playback of the recordings I make today (ntsc analog to mpg2/aac at 48K sampling - file is a bout 2G per hour) takes 25% of the via cpu while using the mpeg decoder chip. Depends heavily on the generation of your video controller... Many of the unichrome video chipset mpeg2 decoders can't handle larger than 720x480 streams. I forget which one is which anymore, but the first-gen one on an EPIA M1 board definitely doesn't cut it (I have one). I believe unichrome pro II definitely *should* be able to, others, not sure.. crap! I have an M1K super valuable info. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VHS capture to MPEG?
Tom Buskey wrote: I've got a number of VHS tapes I'd like to convert to MPEG2. I have a Pinnacle USB2 PRO (150e model). It has svideo, component and antenna inputs. It's got a remote and IR input. From what I've been reading, there is support in Linux for this thing. I have a VHS to hook up to it also. It came with some capture software that consumes all resources on a Celeron 1GHz with 2 GB RAM. I have a Pentium 4m (2GHz?) running Ubuntu Heron (8.10?). It can see the 150e. I don't want to do a MythTV setup just to capture 2-3 tapes. Any recommendations on software capturing? I know members have opinions :-) Looks like there will be a pvr-250 card with hardware mpeg encoding on board available soon here. All you'd have to do is load the ivtv driver and firmware for the card, hook up the vcr to the input, tune the card to the input, hit play then cat /dev/video0 my_vhs_file.mpg ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
Ben Scott wrote: On Fri, Jul 25, 2008 at 7:11 AM, Frank DiPrete [EMAIL PROTECTED] wrote: Encoding or decoding? Encoding on the backend where the card goes. If you're capturing digital TV (OTA or cable), no encoding is needed. The stream is already encoded, digitized, compressed, folded, spindled, and mutilated. This doesn't mean encoding is done on the host CPU; it means there's no encoding to do, period. This is *why* there's a big push to switch over to digital TV, even for standard definition channels. Digital TV uses a lot less bandwidth than analog NTSC, because it's compressed. They can fit something like six standard definition digital channels into the bandwidth consumed by one NTSC analog channel. The only way the host CPU would be doing any encoding would be if you wanted to transcode to a different format, e.g., for a player that doesn't do MPEG, or something like that. The goal is to write mpeg2 files to the server for playback like the pvr-250 does via its encoder. I'd like to believe that the term digital streams means mpg2/aac ... ATSC is MPEG-2 video and AC-3 audio. I've read digital cable is basically ATSC with different modulation and a few extra tweaks. -- Ben Thanks again - I checked to make sure that mythtv 0.20-2 compiles with the dvb option to support the card and it does. Now whether I can use the card to receive the programming is another story. Seems to be shrouded in mystery. Thanks to this thread I now know that my frontend via M1K will choke on playback even if I can receive the signal. arg. - denotes pirate project. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: mythtv and digital tv
On 7/25/08, Frank DiPrete [EMAIL PROTECTED] wrote: Thanks to this thread I now know that my frontend via M1K will choke on playback even if I can receive the signal. As I understand it, that would only apply to high-definition programming. If you capture only standard-definition programming, the M1K will still be able to play it back, same as it does now. I think. I have an HD-5550 I'm not using at the moment. (One of my many half-completed projects.) You can borrow it for testing if you like, so long as you give it back to me in the same condition. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
NH LoCo mailing list
At last, our mailing list is up. If anyone here is interested in getting involved with the Ubuntu New Hampshire LoCo Team, or getting announcements/etc related to it, it's an open list. Just click over to https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-nh Ubuntu LoCos are local teams within the Ubuntu project who advocate, build community, write translations, distribute CDs (including remix distros), etc within the Ubuntu project. They're ment to collaborate, not compete, with LUGs. More info: https://wiki.ubuntu.com/LoCoFAQ https://wiki.ubuntu.com/LoCoWorkingWithOtherGroups https://wiki.ubuntu.com/LoCoTeamRunning ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
