Unless you want to run extremely low bitrates (fitting full-length movies on CDs, etc), MPEG4 has very few advantages over MPEG2. In fact, it has quite a few disadvantages.
1) Less hardware support. 95%+ of all DVD players out there do not have MPEG4 capability. But they all have MPEG2 capability, since DVD uses MPEG2. In addition to DVD players, there are numerous MPEG2 hardware acceleration solutions for cheap low-cost low-power frontents, such as the Hauppauge MediaMVP, and the MPEG-2 acceleration capabilities of many Mini-ITX boards, along with hardware IDCT and hardware MoComp found in almost any video card. 2) Lower decoding complexity. Even without the advantage of highly available hardware acceleration, MPEG-2 requires much less CPU power to decode than MPEG-4
MPEG-4 has its advantages, but it's not always the right tool for the job. In the case of PVRs, it is definately not the right tool for the job.
Go buy a Hauppauge PVR-250 and any reasonably supported video card (GeForce 4MX boards are cheap, VERY well supported, and have excellent TV-out capability, as a result they're one of the most reccommended MythTV TV-output boards), and slap them in your choice of stable x86 system, basically any one will do. It'll work, and if you follow Jarod Wilson's MythTV guide with Fedora Core (Google it, it's also linked to from MythTV's site I believe.) it's easy to set up.
I agree the documentation is kind of crappy in some regards for MythTV... Jarod's HOWTO should be linked to in a more prominent location, plus MythTV's lead developer refuses to set up user support forums and/or even link to forums that anyone else sets up, resulting in a mailing list with such high volume that basically no one can keep up with the traffic.:(
If you dump raw unencoded video to your hard drive, you will be stressing its transfer capabilities to their limits and using obscene amounts of hard drive space.
If you encode the video, you lose quality anyway, and NOW you use a decent amount of CPU time to do so.
The hardware MPEG encoders used in these cards are designed specifically for encoding TV signals and do a VERY good job of it, and they have the added bonus of using almost no CPU whatsoever when recording. They also don't strain your hard drive at all, there are people who run 3-4 encoders simultaneously without any problems. In 99% of all situations, the limiting factor on your quality will be the input signal.
"dumb" TV capture cards are for the cheap/poor. Hell, they're not even for the cheap/poor because what you save on the card (getting to be less and less as time goes by - note the $70 price for the cards reviewed) will be made up for by your need to purchase a much more powerful CPU.
I wish I had mod points and there were a "-1 Moron" option...
PVR-250 and 350 work great with MythTV for capture.
MythTV also supports the 350's TV-out capabilities, but it's much harder to get working and less stable, and does not work well for non-MPEG1/2 video. That said, I bought a 350 "just in case" and also because the 350 does FM while the 250 does not.
PVR-150 support is new, the chipset is different than the 250/350 but I believe is functional now, although may be less stable.
ATI and NV MPEG encoder cards are not supported at all under Linux as far as I know.
My one beef with the PVR-350 is that its tuner is pretty crappy compared to what's out there now. I have a MyHD MDP-100 HDTV card which has superior analog tuning capability but no Linux support or MPEG encoding capability. Using the 350's composite-in with an external VCR for tuning also yields superior quality, although the VCR's AGC causes Macrovision-like brightness pulsations when used with weak signals. (The video has much less noise though.) Mostlikely the Macrovision-like brightness pulsations are from the very same AGC circuit that Macrovision exploits.:(
MythTV also supports the HD-3000 HDTV tuner, and I believe 0.17 added support for capturing MPEG2 transport streams from 1394 devices. (Basically, from HD cable boxes with 1394 outputs that are not encrypted.)
a) Cost b) There's a good chance that even the non-RAID capabilities of the controller have been compromised by lack of documentation to write a good driver
Read his post - He's trying to find drive controllers that support 4+ SATA drives but *do not* include hardware raid.
He's not asking how to set up the software, he's asking about hardware that contains the features he needs for software RAID (many ports) but not redundant features that reduce compatibility and/or add significant cost. (hardware/firmware RAID).
The current systems running most of the subway lines are the ORIGINAL systems.
As in installed in 1932 or earlier.
A recent fire in a control room severely disrupted service on 1-2 subway lines, and they are *still* not returned to "normal" service and likely never will be because the damaged systems were so ancient that there is no way to fully repair them.
Unfortunately, upgrading the system is a real bitch because upgrades mean downtime, and downtime is basically not an option for the MTA.
The issue was recently covered in more depth in the latest issue of the IEEE Spectrum.
"I wonder what penalty is incurred by the packet inspection overhead? I betthings run better with a plain-jane nat router and NO filters or rules to slow things down.. "
Not when some moron user forgets to set an upload cap on their BitTorrent/KaZaA/Blubster/etc client.
Then your whole connection goes down the tubes unless you're running some sort of packet prioritization scheme.
A friend of mine had the same experiences with a WRT54G - It would need a reset 3-5 times a day if you were only using the wired connections, for some reason using the wireless capabilities of the switch would cause it to crash within 10-15 minutes or less.
My friend and I suspected it was crappy thermal design. That thing ran WAY too hot, and would explain why using the wireless connection crashed the unit more quickly. (Transmit power amps use/dissipate a decent amount of power.)
It will take more energy to get it spinning initially, but once it's spinning, added mass has NO effect on how much energy is needed to keep something spinning.
Air resistance and other forms of friction are the dominant forces. (Although bearing friction will increase somewhat with heavier platters...)
Almost every recently made cell phone has a USB charging cable available.
An even higher portion of modern PDAs do.
Both the palmOne Treo 600 and 650 smartphones have USB charging cables available for reasonable prices. I'm not quite sure why they don't come with one by default, the "standard" sync cable is kind of crappy.
As to not using standard USB connectors on the phone - They're the wrong form factor. USB connectors are WAY too large, especially considering that numerous other connections (audio I/O, serial I/O) also need to be available, hence requiring a higher-density connector.
I love my BoxWave miniSync. Charges, syncs, and retracts to a tiny little package, and I got it WITH a car USB power adapter for 2/3 the price of any of palmOne's cables.:)
Requantizing audio of a given format to reduce its bitrate is likely to cause less of a problem than switching formats.
Simply put, each format has different criteria on what information is thrown away and what is not. Thus, for example, something that MP3 may keep but AAC throws away will not be present if you transcode from AAC to MP3, IN ADDITION to losing anything that AAC keeps but MP3 throws away. The same holds true in reverse.
On a more serious note - good riddens. Java needs to die a quick and painless death. Unfortunately it'll be a slow and painful (especially for those that are forced to use it) death. Java is the one programming language I've used that I have truly *hated* working with. It's slow, bloated, and has no redeeming qualities to make up for it. It even failed at its goal of "write once, run anywhere" - I don't know how many Windows-only Java applications I've seen, and J2ME is a joke - look at any mobile gaming site and their J2ME games have a different file size for nearly every phone they support.
Unbelievably, despite Python being a scripting language (admittedly one that can be bytecode-compiled) and Java being bytecode-interpreted, my experience has been that every Python app I've used has been far more responsive and memory efficient than anything written in Java I've used. (Java AIM client and its 256M of memory usage anyone?) Add psyco (JIT compilation for Python, x86-only for now) and it's REALLY fast.
It's also pretty easy to interface native code to Python when you need the speed, even easier than using SWIG with Perl
This is basically how the Mattel Power Glove worked. The glove had 2 ultrasonic emitters on it, and then there was an array of 3 ultrasonic receivers that was placed on your TV.
The concept is similar to how GPS works, except that with ultrasound, your clocks don't need to be nearly as accurate and you can use MUCH lower frequencies.
By the way, the stereotypical method of marching you see in some movies (legs lifted high, a very "stiff" kind of march) is NOT a glidestep/rollstep. It's just the opposite, and VERY bad for playing.
Most modern bands go for the glidestep/rollstep to sound better, even though it may not look as flashy. Glidestep/rollstep is very smooth and pretty difficult to tell from normal walking at a distance.
The way people in marching band walk is usually referred to as a "glide step" or a "roll step".
When you have 15-20+ pounds of brass held to your mouth, you want to be moving up and down as little as possible while you march. The bras has this tendency to want to stay in place, resulting in lots of relative motion if you're bouncing.:)
Don't know of any good way to teach/explain roll stepping to someone without actually having them join a marching band.:)
Slashdot Mirror
Unless you want to run extremely low bitrates (fitting full-length movies on CDs, etc), MPEG4 has very few advantages over MPEG2. In fact, it has quite a few disadvantages.
:(
1) Less hardware support. 95%+ of all DVD players out there do not have MPEG4 capability. But they all have MPEG2 capability, since DVD uses MPEG2.
In addition to DVD players, there are numerous MPEG2 hardware acceleration solutions for cheap low-cost low-power frontents, such as the Hauppauge MediaMVP, and the MPEG-2 acceleration capabilities of many Mini-ITX boards, along with hardware IDCT and hardware MoComp found in almost any video card.
2) Lower decoding complexity. Even without the advantage of highly available hardware acceleration, MPEG-2 requires much less CPU power to decode than MPEG-4
MPEG-4 has its advantages, but it's not always the right tool for the job. In the case of PVRs, it is definately not the right tool for the job.
Go buy a Hauppauge PVR-250 and any reasonably supported video card (GeForce 4MX boards are cheap, VERY well supported, and have excellent TV-out capability, as a result they're one of the most reccommended MythTV TV-output boards), and slap them in your choice of stable x86 system, basically any one will do. It'll work, and if you follow Jarod Wilson's MythTV guide with Fedora Core (Google it, it's also linked to from MythTV's site I believe.) it's easy to set up.
I agree the documentation is kind of crappy in some regards for MythTV... Jarod's HOWTO should be linked to in a more prominent location, plus MythTV's lead developer refuses to set up user support forums and/or even link to forums that anyone else sets up, resulting in a mailing list with such high volume that basically no one can keep up with the traffic.
I'm sorry, but NO.
If you dump raw unencoded video to your hard drive, you will be stressing its transfer capabilities to their limits and using obscene amounts of hard drive space.
If you encode the video, you lose quality anyway, and NOW you use a decent amount of CPU time to do so.
The hardware MPEG encoders used in these cards are designed specifically for encoding TV signals and do a VERY good job of it, and they have the added bonus of using almost no CPU whatsoever when recording. They also don't strain your hard drive at all, there are people who run 3-4 encoders simultaneously without any problems. In 99% of all situations, the limiting factor on your quality will be the input signal.
"dumb" TV capture cards are for the cheap/poor. Hell, they're not even for the cheap/poor because what you save on the card (getting to be less and less as time goes by - note the $70 price for the cards reviewed) will be made up for by your need to purchase a much more powerful CPU.
I wish I had mod points and there were a "-1 Moron" option...
PVR-250 and 350 work great with MythTV for capture.
:(
MythTV also supports the 350's TV-out capabilities, but it's much harder to get working and less stable, and does not work well for non-MPEG1/2 video. That said, I bought a 350 "just in case" and also because the 350 does FM while the 250 does not.
PVR-150 support is new, the chipset is different than the 250/350 but I believe is functional now, although may be less stable.
ATI and NV MPEG encoder cards are not supported at all under Linux as far as I know.
My one beef with the PVR-350 is that its tuner is pretty crappy compared to what's out there now. I have a MyHD MDP-100 HDTV card which has superior analog tuning capability but no Linux support or MPEG encoding capability. Using the 350's composite-in with an external VCR for tuning also yields superior quality, although the VCR's AGC causes Macrovision-like brightness pulsations when used with weak signals. (The video has much less noise though.) Mostlikely the Macrovision-like brightness pulsations are from the very same AGC circuit that Macrovision exploits.
MythTV also supports the HD-3000 HDTV tuner, and I believe 0.17 added support for capturing MPEG2 transport streams from 1394 devices. (Basically, from HD cable boxes with 1394 outputs that are not encrypted.)
Who told you to use "noatun" - I've never heard of it.
The two major media players are xine and mplayer - try one of those instead.
As one person once pointed out on IRC, "mplayer would play a turd if you plugged it in correctly to an IDE cable". xine is about the same.
The chipsets in question are minimal-functionality low-performance cards which can't even remotely compete with top-of-the-line chipsets.
:(
Linux support for low-end chipsets has never been lacking. This release isn't news at all.
If you want decent performance and reliability, NVidia's binary-only drivers are still your only option.
a) Cost
b) There's a good chance that even the non-RAID capabilities of the controller have been compromised by lack of documentation to write a good driver
Read his post - He's trying to find drive controllers that support 4+ SATA drives but *do not* include hardware raid.
He's not asking how to set up the software, he's asking about hardware that contains the features he needs for software RAID (many ports) but not redundant features that reduce compatibility and/or add significant cost. (hardware/firmware RAID).
The current systems running most of the subway lines are the ORIGINAL systems.
As in installed in 1932 or earlier.
A recent fire in a control room severely disrupted service on 1-2 subway lines, and they are *still* not returned to "normal" service and likely never will be because the damaged systems were so ancient that there is no way to fully repair them.
Unfortunately, upgrading the system is a real bitch because upgrades mean downtime, and downtime is basically not an option for the MTA.
The issue was recently covered in more depth in the latest issue of the IEEE Spectrum.
"I wonder what penalty is incurred by the packet inspection overhead? I betthings run better with a plain-jane nat router and NO filters or rules to slow things down.. "
Not when some moron user forgets to set an upload cap on their BitTorrent/KaZaA/Blubster/etc client.
Then your whole connection goes down the tubes unless you're running some sort of packet prioritization scheme.
A friend of mine had the same experiences with a WRT54G - It would need a reset 3-5 times a day if you were only using the wired connections, for some reason using the wireless capabilities of the switch would cause it to crash within 10-15 minutes or less.
My friend and I suspected it was crappy thermal design. That thing ran WAY too hot, and would explain why using the wireless connection crashed the unit more quickly. (Transmit power amps use/dissipate a decent amount of power.)
I think the nature of the "tracks" so far proposed for any space elevator precludes the use of any sort of crossovers/switches.
It will take more energy to get it spinning initially, but once it's spinning, added mass has NO effect on how much energy is needed to keep something spinning.
Air resistance and other forms of friction are the dominant forces. (Although bearing friction will increase somewhat with heavier platters...)
Centipetal force isn't the only issue people have to contend with when things spin fast.
Vibration is also an issue - At 30k RPM, things have to be PERFECTLY balanced or the drive will vibrate itself to pieces.
One song I can't get out of my head is bad enough.
TWO???
BASTARD!
Do we want to trust a source that can't even bother to check their articles for typos?
Who is Richard Stahlman???
Almost every recently made cell phone has a USB charging cable available.
:)
An even higher portion of modern PDAs do.
Both the palmOne Treo 600 and 650 smartphones have USB charging cables available for reasonable prices. I'm not quite sure why they don't come with one by default, the "standard" sync cable is kind of crappy.
As to not using standard USB connectors on the phone - They're the wrong form factor. USB connectors are WAY too large, especially considering that numerous other connections (audio I/O, serial I/O) also need to be available, hence requiring a higher-density connector.
I love my BoxWave miniSync. Charges, syncs, and retracts to a tiny little package, and I got it WITH a car USB power adapter for 2/3 the price of any of palmOne's cables.
Requantizing audio of a given format to reduce its bitrate is likely to cause less of a problem than switching formats.
Simply put, each format has different criteria on what information is thrown away and what is not. Thus, for example, something that MP3 may keep but AAC throws away will not be present if you transcode from AAC to MP3, IN ADDITION to losing anything that AAC keeps but MP3 throws away. The same holds true in reverse.
Java is dying!
Sorry, I just couldn't resist.
On a more serious note - good riddens. Java needs to die a quick and painless death. Unfortunately it'll be a slow and painful (especially for those that are forced to use it) death. Java is the one programming language I've used that I have truly *hated* working with. It's slow, bloated, and has no redeeming qualities to make up for it. It even failed at its goal of "write once, run anywhere" - I don't know how many Windows-only Java applications I've seen, and J2ME is a joke - look at any mobile gaming site and their J2ME games have a different file size for nearly every phone they support.
Unbelievably, despite Python being a scripting language (admittedly one that can be bytecode-compiled) and Java being bytecode-interpreted, my experience has been that every Python app I've used has been far more responsive and memory efficient than anything written in Java I've used. (Java AIM client and its 256M of memory usage anyone?) Add psyco (JIT compilation for Python, x86-only for now) and it's REALLY fast.
It's also pretty easy to interface native code to Python when you need the speed, even easier than using SWIG with Perl
This is basically how the Mattel Power Glove worked. The glove had 2 ultrasonic emitters on it, and then there was an array of 3 ultrasonic receivers that was placed on your TV.
The concept is similar to how GPS works, except that with ultrasound, your clocks don't need to be nearly as accurate and you can use MUCH lower frequencies.
Reverse Googlebombing???
Should be TriPod :)
By the way, the stereotypical method of marching you see in some movies (legs lifted high, a very "stiff" kind of march) is NOT a glidestep/rollstep. It's just the opposite, and VERY bad for playing.
Most modern bands go for the glidestep/rollstep to sound better, even though it may not look as flashy. Glidestep/rollstep is very smooth and pretty difficult to tell from normal walking at a distance.
The way people in marching band walk is usually referred to as a "glide step" or a "roll step".
:)
:)
When you have 15-20+ pounds of brass held to your mouth, you want to be moving up and down as little as possible while you march. The bras has this tendency to want to stay in place, resulting in lots of relative motion if you're bouncing.
Don't know of any good way to teach/explain roll stepping to someone without actually having them join a marching band.
It's always been known that a fully random password is more secure.
But it's a bitch to remember, so people use easier-to-guess passwords anyway.
Knowledge of this technique changes nothing. Any crook smart enough to use totally random passwords after this incident probably is already doing so.
Hahah. You know what's funny?
The #1 thing I hate about Rutgers girls? They're snobs. They think that they're so much better than they are.
Meanwhile people up at Cornell were the nicest, friendliest people I've ever met.