Note and learn to cook her favourite recipes! My Mum did this for my Grandma as did Grandma before her. It still brings a smile when I cook something I enjoyed visiting 'Oma' as a small child. Its a nice bit of family history/tradition too... the recipes are hand-written and some have fun stories ('the day your Dad ate 2 whole cakes') associated with them.
Actually, this is probably rather BAD for Bavaria. This is just plain old-fashioned pork-barrel politics.
There's already an adequate modern suburban rail connection to the Airport. Furthermore the distance between Munich central and the Airport is not terribly large and road transportation links are excellent (Munich is not a terribly large city). Not only could you get 80% of the benefits simply laying dedicated conventional track but due to the good road links there's not that many people interested in taking public transport to the Airport in the first place. ESPECIALLY the business/wealthy folk who might be interested in paying a premium over the Suburban railway.
The damn thing is going to be nasty Albatross hanging around the necks of myself and the rest of Bavarias taxpayers.
EU Law != Utterances of Member of European Parliament on poluist-theme-du-hour.
Murmoring from MEP's is even less significant than cant from congressmen since it is national governments (through the council of ministers) who have ~80% of the power in EU. MEPs (when the politics gets rough or involves money) also mostly take the the whip of national parties.
I've been there on the other side of a situation like this at a large European based semiconductor manufacturer.
Basically, the real 'motivation' for not supporting this kind of stuff is usually corporate inertia and bureaucracy. 99% of the time there is no IP really to protect. However, 'the system' slaps an NDA on everything by default and although field application engineers and tech. marketing are be assigned to the visible customers theres no-one officially tasked with supporting sales-via-FOSS. Result: even if there's goodwill (which is surprisingly often) nothing happens.
It is absolutely normal for the Intel's of this world to simultaenously pay people to evangelise and support FOSS whilst at the same time product-divisions stone-wall. There are simply other (internal) agendas at work than getting the product out. In short-hand: not related to this years' job objectives? No action! No bonus or visibility? Spare-time effort only.
I think it is noticeable that the businesses that responded effectively in the case of the Wireless drivers were the smaller, hungrier, more genuinely market/customer driven operations. Fortunately, in the longer-term the Marvell's of this world do tend to rip the lazy corps. a new one even in more conventional customer relationships. The underlying culture of an organisation (genuinely customer driven or just talk) *will* show through. Alas it's a slow process...
I work for a large CE company that is using Linux for a major TV-related project.
This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.
Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.
Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....
The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.
In short Linux is a fine information processing/network O.S. for embedded or general-purpose systems. Its very far from ideal for one-off embedded/control applications.
Don't forget that LCD panels are connected to the video-processing / panel control IC(s) via a nice digital unencrypted LVDS interface. Hook up an LVDS receiver to a PCI express FPGA prototyping board and stream the GBytes to a HD array. Four modern SATA drives are plenty and with a good dual-core CPU or your FPGA you could even do a spot of simple lossless compression to save a few pennies on disks.
Now you have a wonderful 'digital Master' for your professional pirating disk authoring activities.
Me, for myself I couldn't be bothered... how many films do I want to watch more than once anyway? If the disks are too expensive to rent... I just don't rent 'em and go ride my Motorbike instead;-)
I'm professionally involved in this area (I build TFF controllers). An interesting aspect of this problem is that 'ghosting' (technically: motion blur) is not predominantly caused by slow switching on modern
panels.
Below around 10mSec reponse time (which is what good TV panels achieve) the primary cause is the fact that TFT-LCD's are sample-and-hold display devices not stroboscopic (flash and then dark) like CRTs. You could achieve 1mSec response and still not deal with the issue.
There are two technological fixes. One is to flash the backlight (actually you only flash stripes in the backlight but that's another story) or you increase the frame-rate. Increasing the frame-rate costs big-time silicon since you need motion-compensation to calculate the intermediate frames decently. Hence the interest in flashing/scanning backlight solutions.
Personally I too am not convinced about flashing. However I know the Philips research in this area is relatively sophisticated (flashing more when ambient light is low and its less noticeable etc etc).
1. The German system at least isn't an experiment goes live this year. It is (currently) GPS/cellphone based.
2. Its for collecting truck Tolls on Freeways.
3. The (main) reason its there is the Problem that currently German taxpayers pay for the Freeways but a goodly precentage of the trucks carving the Asphalt are in transit from and to outside Germany.
4. The easy option of simply taxing Truck fuel doesn't work since the trucks easily have the range to fuel more or less where they please.
I work designing LCD controllers. This one is really easy to answer.
1. Size matters. The costs of an LCD 'glass' like a chip die rise rapidly with physical size. Not only do you get less from a given blank but your yield falls too.
2. UXGA stand-alone displays are expensive to control. The market demands a big display act like a CRT even if it isn't. This means you need to be able to do frame-rate conversion, which because UXGA panels are highly timing sensitive requires a fancy low-volume high-cost controller IC with an SDRAM frame buffer. High-speed AVI and DVI interfaces cost too.
3. Laptop displays ain't as good colourwise or luminance wise!
4. The base cost means low volume means even more cost...
In short, forget price gouging. A UXGA laptop display is simply much much cheaper to manufacture than a standalone UXGA panel.
Actually, at higher bit rates and resolutions MPEG 4 rarely delivers more than about 10% compression gains over MPEG-2 when you compare similar profiles. Its no panacea. Most of its advanced features really only bite for subsampled images.
7-Mbps MPEG-4 HDTV will look like your typical 1Mbps DiVX. O.k. for free but hardly Artefact free.
I work in this area... actually, just about all the big panel makers (including LG/Philips!) are looking at this. The research is most definately still going on, though its now moved on to the "Development" stage. All I can say is people I know in Philips are funding quite a bit of R&D in around "front of display" image processing (addressing essentially all the points people have mentioned here).
The improvement is pretty drastic in older panels but unfortunately the newer panels reduce the gains a *lot* (they're faster anyway). Combine this with big cost hits (you currently need a custom chip with a frame buffer between scaler and timing control or a new timing controller) and this simply won't appear in manstream priced panels.
It will go mainstream, but when it does it will be integrated earlier in the pipeline where you *already* have a frame buffer anyway - in the graphics controller or for LCD/TV capable monitors in an integrated scaler/timing controller.
Sadly, all MPEG standards are VERY heavily patent-encumbered (Patent-buried might be a more apt way of putting it). Worse, the MPEGLA (MPEG Licensing Authority) appears to have zero interest in supporting open-source implementations of MPEG video standards.
I contacted MPEGLA because I'm the author of an MPEG-1/2 encoder (http://mjpeg.sourceforge.net) and I wanted to lay the groundwork for an official Debian distro. The official response was "everyone who *distributes* an MPEG encoder
must obtain a license from MPEGLA and pay $4 unit". This is fine and actually quite reasonable(ish) for a hardware vendor. For an open-source project... forget it. Queries regarding the possibility of users buying licenses from MPEGLA which would enable them to legitimately receive the open-source encoder of their choice were met with stony silence.
Since M$ bundling of their codec more or less precludes any commercially viable closed-source MPEG-4 codecs I think we can safely conclude MPEG-4 is dead dead dead as a mainstream platform in the PC space. Informal derivatives (the DivXes) of course will carry on, but I think its safe to assume no-one will be broadcasting or pressing disks in those formats.
If you think "decent video quality" is available at sub-ISDN data-rates (
MPEG-4 can support useful *low-quality* video down to very very low data-rates. It can also support the broadcast of synthetic multi-media imagery (texture mapped heads, 3D scenes) at low(ish) bit-rates. However, at Broadcast TV quality video (loosely the range between VCD and SVCD) its benefits over MPEG-1/2 are pretty modest (MPEG's own trials suggest 10-15% on bit-rate). I.e. you can get a VCD quality feed at around 1Mbps, but below that it just won't go.
At the "DVD: quality level (full resolution interlaced video, multi-channel audio) its benefits over MPEG-2 are neglible and there are even some drawbacks.
Lavtools has been superceded by the mjpegtools project (of which the current version of lavtools
are a part).
This already is a sourceforge project and does indeed act as bug for MJPEG video stuff. Adding properply integrated PVR time-shift is the last major chunk of functionality to be done.
Doing PVCR (and more) using cheap MJPEG hardware
is the goal of the mjpeg tools project (the follow-on to "lavtools") http://mjpeg.sourceforge.net. The only thing thats missing in the current release is time-shift functionality. The rest (record playback, editting, cropping and scaling and decent speed/quality MPEG encoding is in place.
I have a machine setup pretty much as you describe except it is rather bigger. The spec you describe is pretty low-end to make this stuff work well. MJPEG recording and playback using DC10+/buz etc use very little CPU but the problem is that if you ever want to do time-shifting then you have to be able to do both at once. In practice that means software playback as the hardware can't play and record at the same time. To do this at full quality needs a rather beefier CPU than you've got. I'd say 450Mhz P-III is a realistic minimum. Similarly, if you want to MPEG encoding you really want a faster CPU if you want to compress to SVCD or DVD formats in a sensible amount of time.
Finally, 6G is just plain too small for realistic MJPEG based D-VCR use. I use 30 and its a bit tight when I want to record a movie in DVD quality.
Real-time DVD profile MPEG-2 compression is undoubtedly possible. mp1e is nice example of what can be done if speed is your primary goal. Even the MPEG encoder I'm working on (main emphasis on quality not speed) http://mjpeg.sourceforge.net will happily do real-time VCD MPEG-1 at decent quality. The latest multi-thread patches would put SVCD within reach of high-end dual CPU machines.
However, to get real-time compression you have to make serious speed/quality trade-offs. Getting really good MPEG fast requires a lot of search for good motion compensation vectors. Getting good motion compensation for interlaced video sources requirs a lot of field combinations to be tried out. The fast algorithms just don't produce terribly good results. Similarly the fastest DCT algorithm's aren't the most accurate and so on. None of the available free encoders comes close to doing good DVD profile MPEG in real-time. I don't know but I doubt "even" the Windows ones can do a more than o.k. job in real-time on a single CPU in real-time. This is especially true if you're trying to do audio compression and multiplexing as well.
Aside: good quality MPEG compression of video requires high quality low-noise sources. The results obtainable from less-than-studio-level analogue sources at high levels of compression may disappoint. If resources won't cover a hardware encoder (KFIR-1 based boards are only a few hundred bucks) you're probably way short in the video source department.
The responses to this article (technical issues aside) demonstrate most slashdotters are definately a long way from home when they stray into non US politics. About what you'd expect from a bunch of youthfull US techies actually. A few clues guys...
(1) UK govts. are too scared of the motorist lobby to even talk about dropping speed limits to US levels or charging tolls on congested highways. Now theyre going to push through expensive and flaky speed-governors. Not in this universe they won't.
(2) Speeding enforcement in UK and US. Well in my personal experience where the UK may have the odd camera-case-with-no-camera (wet film) in it the US has unbelievable numbers of Cops lurking behind every bridge. I kid you not its a real shock how much speeds are enforced in the US and how rigorously. Cops like flies on a log...
(3) Schemes like this regularly surface. Civil servants have to do something to keep looking busy and one way they do it is by researching absurd schemes for ministers to ignore.
(4) We took it up the A** from King George so "we" (same people of course) take any old illiberal nonsense. Yeah right and we all say "Gor blimey" in a Dick-van-Dyke accent every two minutes. Beside the fact that even in that day power in the UK already resided in Parliament this is 2000. The Reform acts were passed 150 years ago, the hereditaries are checking out of the upper house and the human rights act has come into force.
Check into the history of Margaret Thatchers poll tax if you want some idea of how quiet and supine the UK public is.
No Particular problem doing this. Just get hold of a decent capture card and MPEG encoder software. There's several about. However, without a hardware encoder it will be slooooow. From my own programming experience I doubt it is possible to MPEG good interlaced full resolution TV at more than about 3 frames/sec on a current CPU.
Also, don't expect the quality to be the same as a properly mastered DVD. The problem is the low signal/noise ratio of consumer sources like laserdisc - it interferes with compression. You either need to bump up the data-rate or filter or take a quality hit.
Well I was wondering when the first revision of this kind of the MPEG "benchmark" would come out. MPEG encoding/decoding is dominated by 2 or 3 very tight loops.
Which CPU looks good will depend far more on which architecture you optimised for than any inherent strengths weaknesses. Case in point. The P4 suddenly looks "bad" when Tom switched to stack F.P. based iDCT routine. Well this frankly is mere luck. You don't need F.P. to do an accurate iDCT. If the FlaskMPEG guys had used a good MMX iDCT (it *is* possible!) istead the P4 would have stood there like the MPEG CPU to end all others.
Instead its suddenly a lemon.
Acutally, I personally think Intel blew it with the decision to go to a super-long pipe. Quite a few codes *are* branchy and not all branches can be predicted. Period. The P4 always will be a brittle performer. Good on f.p. crunching with SSE and some kinds of "multimedia" stuff. A total lemon for other codes. Given the current trend to off-load a shed-load of the f.p. work to GPU's I think Intel made a bad call...
However they do deserve kudos for finally having the courage to side-line the horrible stack f.p. and put their effort into SSE2 instead (with far better potential). It think we'll see some really good f.p. numbers as the SSE2 compiler support cuts in.
A couple of comments seem to generalised hopelessly (usually on the basis of the UK system) about Europe. The European systems are basically, at least as diverse from each other as from the US.
E.g. in Germany, there is *no* such thing as a Bachelors (a full "Diplom" is Masters level and takes proportionately long to study). In the UK courses are 3 year bachelors that presuppose a high degree of specialisation in pre-university study. The French system is in some way intermediate, but has many of its own peculiarities.
At the "grad school" level. In the UK sciences people do a Ph.D intesively full-time, but (if they're serious) tend to "post-doc" for 2 or 3 years. Furthermore, in the sciences there is marked trend to insisting people take a masters before starting their Ph.D.
In Germany, people typically Ph.D part-time on funded teaching and research posts and take a loooong time. Even then, they would need to take a "Habilitation" before taking on a proper professorship. Apples and Oranges folks...
Personally, my take is that by far the biggest impact on a nation as a whole is pre-18 education. By then the battle is won or lost. IMHO The UK and US are actually more on the losing rather than winning side. This was something that has been painfully obvious in the UK but has been masked by other differences in the US (immigration, a large and competitive domestic market, sensible Govt. research support, not being flattened or bankrupted in WW-II).
I've used the NTL package from Linux more or less continuously for 3 months now. Works fine (even with it being used via diald to connect on demand from my home network).
Basically, once you've connected the official way under Win9x for that first registration call (it rings up a dedicated server not the normal dial-in number) and got the passwords etc you can bin the NTL 'ware. Stick the relevant info in your dial-up config and away you go. All very jolly.
Well, I suppose you couldn't expect better from a Journo, but the whole piece was absurdly old-media-centric.
Lets do the arithmetic. Its seems 45 B$ is spent on TV advertising p.a. in the US. Around $450 per household. Thus paying for "commercial" TV (actually: advertising supported TV). Call it $300 p.a. for actual TV content.
Fact: who actually wants to watch ads? Only loonies who enjoy being lied to. Indeed many people (e.g. TiVo buyers) are willing to *pay* and apply personal effort to skip them.
Fact: TiVO and similar technologies make it trivial to skip Ads.
Conclusion: Advertising supported TV is no longer a viable business model in the medium-term future
'cos people will skip them.
Fact: the (compulsorary) shift to digital media will make highly selective subscription TV services viable for the first time.
Fact: networks no longer own the majority of TV bandwidth (medium term even the internet is a delivery medium - especially for time-shifted subscription-based viewing).
Conclusion: the networks expect to shift to a pure subscription based model.
All that "big brother" stuff is pure nonsense. The marketing choice facing the networks is to chase subscription-TV $ or to invest big $ up-front for "free" idiot-boxes that track viewers interests an intersplice Ads every 15 min and then chase Ad $.
For households with the $300 p.a. (max) to avoid the ads and intrusion this *has* to be a no-brainer. The only takers will be low income households (oh the delight of advertisers...) and people who're stripping the ads anyhow (more delighted advertisers).
In short: advertising supported TV is dead it just doesn't know it yet. Buy production company stock now and watch the big networks buy up all the true assets of the TV industry - the shows and the "creatives" who make 'em.
The Ad industry - I'm sure they'll find some dummies someplace to talk nonsense to somehow - but who gives a poop? At last the TV industry will focus on its job - near real-time distribution of audio-visual entertainment and get out from under the wing of marketing.
This is a fascinating discovery, but it is nowhere near anything that "could revolutionise the energy industry". When we read the small print it turns out they are getting 3 milli-litres (cc) of hydrogen *gas* per hour per litre of culture.
This is an absurdly small amount. Orders of magnitude less than you could produce using photovoltaics and an electrolysis cell.
The real problem with most bio-mass energy projects is getting decent energy density. The most practical (so far) involve using high-yield crop plants to produce oil and/or feedstock for methane fermentation.
You can buy rape-seed diesel oil in Germany that is produced sort-of economically (tax-breaks) in this way. Makes your snazzy new turbo-diesel car smell like an old-fashioned UK fish-and-chip shop (Greasy Spoon kitchen for our US cousins);-)
Slashdot Mirror
I'm surprised not to have seen this...
Note and learn to cook her favourite recipes! My Mum did this for my Grandma as did Grandma before her. It still brings a smile when I cook something I enjoyed visiting 'Oma' as a small child. Its a nice bit of family history/tradition too ... the recipes are hand-written and some have fun stories ('the day your Dad ate 2 whole cakes') associated with them.
No. Only the old ICE-1 and ICE-2 stuff uses the old fashioned configuration. ICE-3 uses the between-wagon configuration.
The stuff exported to China is of even later design than ICE-3 (its a while since DB made a big ICE buy).
Actually, this is probably rather BAD for Bavaria.
This is just plain old-fashioned pork-barrel politics.
There's already an adequate modern suburban rail connection to the Airport.
Furthermore the distance between Munich central and the Airport is not terribly large and
road transportation links are excellent (Munich is not a terribly large city).
Not only could you get 80% of the benefits simply laying dedicated conventional track but
due to the good road links there's not that many people interested in taking public transport to the Airport in the first place. ESPECIALLY the business/wealthy folk who might be interested in paying a premium over the Suburban railway.
The damn thing is going to be nasty Albatross hanging around the necks of myself and the rest of Bavarias taxpayers.
Andrew (from Munich)
What is it about Slashdot...
EU Law != Utterances of Member of European Parliament on poluist-theme-du-hour.
Murmoring from MEP's is even less significant than cant from congressmen since it is
national governments (through the council of ministers) who have ~80% of the power in
EU. MEPs (when the politics gets rough or involves money) also mostly take the the
whip of national parties.
'nuff said.
Andrew
I've been there on the other side of a situation like this at a large European based semiconductor manufacturer.
Basically, the real 'motivation' for not supporting this kind of stuff is usually corporate inertia and bureaucracy. 99% of the time there is no IP really to protect. However, 'the system' slaps an NDA on everything by default and although field application engineers and tech. marketing are be assigned to the visible customers theres no-one officially tasked with supporting sales-via-FOSS. Result: even if there's goodwill (which is surprisingly often) nothing happens.
It is absolutely normal for the Intel's of this world to simultaenously pay people to evangelise and support FOSS whilst at the same time product-divisions stone-wall. There are simply other (internal) agendas at work than getting the product out. In short-hand: not related to this years' job objectives? No action! No bonus or visibility? Spare-time effort only.
I think it is noticeable that the businesses that responded effectively in the case of the Wireless drivers were the smaller, hungrier, more genuinely market/customer driven operations.
Fortunately, in the longer-term the Marvell's of this world do tend to rip the lazy corps. a new one even in more conventional customer relationships. The underlying culture of an organisation (genuinely customer driven or just talk) *will* show through. Alas it's a slow process...
Andrew
This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.
Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.
Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....
The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.
In short Linux is a fine information processing
Don't forget that LCD panels are connected to the video-processing / panel control IC(s) via a nice digital unencrypted LVDS interface. Hook up an LVDS receiver to a PCI express FPGA prototyping board and stream the GBytes to a HD array. Four modern SATA drives are plenty and with a good dual-core CPU or your FPGA you could even do a spot of simple lossless compression to save a few pennies on disks.
... I just don't rent 'em and go ride my Motorbike instead ;-)
Now you have a wonderful 'digital Master' for your professional pirating disk authoring activities.
Me, for myself I couldn't be bothered... how many films do I want to watch more than once anyway? If the disks are too expensive to rent
Below around 10mSec reponse time (which is what good TV panels achieve) the primary cause is the fact that TFT-LCD's are sample-and-hold display devices not stroboscopic (flash and then dark) like CRTs. You could achieve 1mSec response and still not deal with the issue.
There are two technological fixes. One is to flash the backlight (actually you only flash stripes in the backlight but that's another story) or you increase the frame-rate. Increasing the frame-rate costs big-time silicon since you need motion-compensation to calculate the intermediate frames decently. Hence the interest in flashing/scanning backlight solutions.
Personally I too am not convinced about flashing. However I know the Philips research in this area is relatively sophisticated (flashing more when ambient light is low and its less noticeable etc etc).
Andrew
2. Its for collecting truck Tolls on Freeways.
3. The (main) reason its there is the Problem that currently German taxpayers pay for the Freeways but a goodly precentage of the trucks carving the Asphalt are in transit from and to outside Germany.
4. The easy option of simply taxing Truck fuel doesn't work since the trucks easily have the range to fuel more or less where they please.
I work designing LCD controllers. This one is really easy to answer.
1. Size matters. The costs of an LCD 'glass' like a chip die rise rapidly with physical size. Not only do you get less from a given blank but your yield falls too.
2. UXGA stand-alone displays are expensive to control. The market demands a big display act like a CRT even if it isn't. This means you need to be able to do frame-rate conversion, which because UXGA panels are highly timing sensitive requires a fancy low-volume high-cost controller IC with an SDRAM frame buffer. High-speed AVI and DVI interfaces cost too.
3. Laptop displays ain't as good colourwise or luminance wise!
4. The base cost means low volume means even more cost...
In short, forget price gouging. A UXGA laptop display is simply much much cheaper to manufacture than a standalone UXGA panel.
Actually, at higher bit rates and resolutions MPEG 4 rarely delivers more than about 10% compression gains over MPEG-2 when you compare similar profiles. Its no panacea. Most of its advanced features really only bite for subsampled images.
7-Mbps MPEG-4 HDTV will look like your typical 1Mbps DiVX. O.k. for free but hardly Artefact free.
I work in this area... actually, just about all the big panel makers (including LG/Philips!) are looking at this. The research is most definately still going on, though its now moved on to the "Development" stage. All I can say is people I know in Philips are funding quite a bit of R&D in around "front of display" image processing (addressing essentially all the points people have mentioned here).
The improvement is pretty drastic in older panels but unfortunately the newer panels reduce the gains a *lot* (they're faster anyway). Combine this with big cost hits (you currently need a custom chip with a frame buffer between scaler and timing control or a new timing controller) and this simply won't appear in manstream priced panels.
It will go mainstream, but when it does it will be integrated earlier in the pipeline where you *already* have a frame buffer anyway - in the graphics controller or for LCD/TV capable monitors in an integrated scaler/timing controller.
Andrew
I contacted MPEGLA because I'm the author of an MPEG-1/2 encoder (http://mjpeg.sourceforge.net) and I wanted to lay the groundwork for an official Debian distro. The official response was "everyone who *distributes* an MPEG encoder
must obtain a license from MPEGLA and pay $4 unit". This is fine and actually quite reasonable(ish) for a hardware vendor. For an open-source project
Since M$ bundling of their codec more or less precludes any commercially viable closed-source MPEG-4 codecs I think we can safely conclude MPEG-4 is dead dead dead as a mainstream platform in the PC space. Informal derivatives (the DivXes) of course will carry on, but I think its safe to assume no-one will be broadcasting or pressing disks in those formats.
At the "DVD: quality level (full resolution interlaced video, multi-channel audio) its benefits over MPEG-2 are neglible and there are even some drawbacks.
Lavtools has been superceded by the mjpegtools project (of which the current version of lavtools
are a part).
This already is a sourceforge project and does indeed act as bug for MJPEG video stuff. Adding properply integrated PVR time-shift is the last major chunk of functionality to be done.
See http://mjpeg.sourceforge.net
Doing PVCR (and more) using cheap MJPEG hardware
is the goal of the mjpeg tools project (the follow-on to "lavtools") http://mjpeg.sourceforge.net. The only thing thats missing in the current release is time-shift functionality. The rest (record playback, editting, cropping and scaling and decent speed/quality MPEG encoding is in place.
I have a machine setup pretty much as you describe except it is rather bigger. The spec you describe is pretty low-end to make this stuff work well. MJPEG recording and playback using DC10+/buz etc use very little CPU but the problem is that if you ever want to do time-shifting then you have to be able to do both at once. In practice that means software playback as the hardware can't play and record at the same time. To do this at full quality needs a rather beefier CPU than you've got. I'd say 450Mhz P-III is a realistic minimum. Similarly, if you want to MPEG encoding you really want a faster CPU if you want to compress to SVCD or DVD formats in a sensible amount of time.
Finally, 6G is just plain too small for realistic MJPEG based D-VCR use. I use 30 and its a bit tight when I want to record a movie in DVD quality.
Andrew
However, to get real-time compression you have to make serious speed/quality trade-offs. Getting really good MPEG fast requires a lot of search for good motion compensation vectors. Getting good motion compensation for interlaced video sources requirs a lot of field combinations to be tried out. The fast algorithms just don't produce terribly good results. Similarly the fastest DCT algorithm's aren't the most accurate and so on. None of the available free encoders comes close to doing good DVD profile MPEG in real-time. I don't know but I doubt "even" the Windows ones can do a more than o.k. job in real-time on a single CPU in real-time. This is especially true if you're trying to do audio compression and multiplexing as well.
Aside: good quality MPEG compression of video requires high quality low-noise sources. The results obtainable from less-than-studio-level analogue sources at high levels of compression may disappoint. If resources won't cover a hardware encoder (KFIR-1 based boards are only a few hundred bucks) you're probably way short in the video source department.
(1) UK govts. are too scared of the motorist lobby to even talk about dropping speed limits to US levels or charging tolls on congested highways. Now theyre going to push through expensive and flaky speed-governors. Not in this universe they won't.
(2) Speeding enforcement in UK and US. Well in my personal experience where the UK may have the odd camera-case-with-no-camera (wet film) in it the US has unbelievable numbers of Cops lurking behind every bridge. I kid you not its a real shock how much speeds are enforced in the US and how rigorously. Cops like flies on a log...
(3) Schemes like this regularly surface. Civil servants have to do something to keep looking busy and one way they do it is by researching absurd schemes for ministers to ignore.
(4) We took it up the A** from King George so "we" (same people of course) take any old illiberal nonsense. Yeah right and we all say "Gor blimey" in a Dick-van-Dyke accent every two minutes. Beside the fact that even in that day power in the UK already resided in Parliament this is 2000. The Reform acts were passed 150 years ago, the hereditaries are checking out of the upper house and the human rights act has come into force.
Check into the history of Margaret Thatchers poll tax if you want some idea of how quiet and supine the UK public is.
Andrew
There are actually a whole bunch of relevant projects underway. The pieces are coming together! Some that haven't been mentioned....
http://www.linuxtv.org (Digital TV hardware based goodies and more)
http://mjpeg.sourceforge.org (MJPEG capture, playback, MPEG-1/2 encoding )
Andrew
No Particular problem doing this. Just get hold of a decent capture card and MPEG encoder software. There's several about. However, without a hardware encoder it will be slooooow. From my own programming experience I doubt it is possible to MPEG good interlaced full resolution TV at more than about 3 frames/sec on a current CPU.
Also, don't expect the quality to be the same as a properly mastered DVD. The problem is the low signal/noise ratio of consumer sources like laserdisc - it interferes with compression. You either need to bump up the data-rate or filter or take a quality hit.
Well I was wondering when the first revision of this kind of the MPEG "benchmark" would come out. MPEG encoding/decoding is dominated by 2 or 3 very tight loops.
Which CPU looks good will depend far more on which architecture you optimised for than any inherent strengths weaknesses. Case in point. The P4 suddenly looks "bad" when Tom switched to stack F.P. based iDCT routine. Well this frankly is mere luck. You don't need F.P. to do an accurate iDCT. If the FlaskMPEG guys had used a good MMX iDCT (it *is* possible!) istead the P4 would have stood there like the MPEG CPU to end all others.
Instead its suddenly a lemon.
Acutally, I personally think Intel blew it with the decision to go to a super-long pipe. Quite a few codes *are* branchy and not all branches can be predicted. Period. The P4 always will be a brittle performer. Good on f.p. crunching with SSE and some kinds of "multimedia" stuff. A total lemon for other codes. Given the current trend to off-load a shed-load of the f.p. work to GPU's I think Intel made a bad call...
However they do deserve kudos for finally having the courage to side-line the horrible stack f.p. and put their effort into SSE2 instead (with far better potential). It think we'll see some really good f.p. numbers as the SSE2 compiler support cuts in.
Andrew
A couple of comments seem to generalised hopelessly (usually on the basis of the UK system) about Europe. The European systems are basically, at least as diverse from each other as from the US.
;-)
E.g. in Germany, there is *no* such thing as a Bachelors (a full "Diplom" is Masters level and takes proportionately long to study). In the UK courses are 3 year bachelors that presuppose a high degree of specialisation in pre-university study. The French system is in some way intermediate, but has many of its own peculiarities.
At the "grad school" level. In the UK sciences people do a Ph.D intesively full-time, but (if they're serious) tend to "post-doc" for 2 or 3 years. Furthermore, in the sciences there is marked trend to insisting people take a masters before starting their Ph.D.
In Germany, people typically Ph.D part-time on funded teaching and research posts and take a loooong time. Even then, they would need to take a "Habilitation" before taking on a proper professorship. Apples and Oranges folks...
Personally, my take is that by far the biggest impact on a nation as a whole is pre-18 education. By then the battle is won or lost. IMHO The UK and US are actually more on the losing rather than winning side. This was something that has been painfully obvious in the UK but has been masked by other differences in the US (immigration, a large and competitive domestic market, sensible Govt. research support, not being flattened or bankrupted in WW-II).
Email me back in 20 years if I'm wrong
Andrew
I've used the NTL package from Linux more or less continuously for 3 months now. Works fine (even with it being used via diald to connect on demand from my home network).
Basically, once you've connected the official way under Win9x for that first registration call (it rings up a dedicated server not the normal dial-in number) and got the passwords etc you can bin the NTL 'ware. Stick the relevant info in your dial-up config and away you go. All very jolly.
Andrew
Well, I suppose you couldn't expect better from a Journo, but the whole piece was absurdly old-media-centric.
Lets do the arithmetic. Its seems 45 B$ is spent on TV advertising p.a. in the US. Around $450 per household. Thus paying for "commercial" TV (actually: advertising supported TV). Call it $300 p.a. for actual TV content.
Fact: who actually wants to watch ads? Only loonies who enjoy being lied to. Indeed many people (e.g. TiVo buyers) are willing to *pay* and apply personal effort to skip them.
Fact: TiVO and similar technologies make it trivial to skip Ads.
Conclusion: Advertising supported TV is no longer a viable business model in the medium-term future
'cos people will skip them.
Fact: the (compulsorary) shift to digital media will make highly selective subscription TV services viable for the first time.
Fact: networks no longer own the majority of TV bandwidth (medium term even the internet is a delivery medium - especially for time-shifted subscription-based viewing).
Conclusion: the networks expect to shift to a pure subscription based model.
All that "big brother" stuff is pure nonsense. The marketing choice facing the networks is to chase subscription-TV $ or to invest big $ up-front for "free" idiot-boxes that track viewers interests an intersplice Ads every 15 min and then chase Ad $.
For households with the $300 p.a. (max) to avoid the ads and intrusion this *has* to be a no-brainer. The only takers will be low income households (oh the delight of advertisers...) and people who're stripping the ads anyhow (more delighted advertisers).
In short: advertising supported TV is dead it just doesn't know it yet. Buy production company stock now and watch the big networks buy up all the true assets of the TV industry - the shows and the "creatives" who make 'em.
The Ad industry - I'm sure they'll find some dummies someplace to talk nonsense to somehow - but who gives a poop? At last the TV industry will focus on its job - near real-time distribution of audio-visual entertainment and get out from under the wing of marketing.
Andrew
This is a fascinating discovery, but it is nowhere near anything that "could revolutionise the energy industry". When we read the small print it turns out they are getting 3 milli-litres (cc) of hydrogen *gas* per hour per litre of culture.
;-)
This is an absurdly small amount. Orders of magnitude less than you could produce using photovoltaics and an electrolysis cell.
The real problem with most bio-mass energy projects is getting decent energy density. The most practical (so far) involve using high-yield crop plants to produce oil and/or feedstock for methane fermentation.
You can buy rape-seed diesel oil in Germany that is produced sort-of economically (tax-breaks) in this way. Makes your snazzy new turbo-diesel car smell like an old-fashioned UK fish-and-chip shop (Greasy Spoon kitchen for our US cousins)