I have no way of knowing how expensive the part it, but even if we grant that it is expensive, it is just replacing the de-code chip. It will not be an addition to the parts-list, but replacement. The delta is not going to be that horrific.
You clearly only have a single TV in one room,and it must be a 60"... I have an 32" HDTV that "does 1080i" (marketing speak) onto 1366x766 screen. I want real 1080i. I can't get it without replacing the TV. I want 1080p... cannot get it without replacing the TV. Supposedly, the next thing is 3D. Again it will involve replacing the TV. If the processor is sized to the capabilities of the display, then chances are that when you decide you need to upgrade a box, the TV needs to go too.
You refer to the TV as the expensive part, with a long lived standard. That was the case in analog days, but looking at the list of improvements above, one can rapidly ascertain that TV standards are getting fluid now too. Is your ten year old HDTV still good? Most likely it was CRT based, consumed about 10x the power of tv's today, and cost about as much as a decent motrocycle.
a Dynex 19" HD LCD TV @ BestBuy is 149$. granted, it only does 720p, but tell me again how much money we are saving with a 200$ STB? If we have a 400$ STB, will the TV do better than 720p?
The idea that TV is the expensive component applies only to a Home theater setup. Most people have smaller vision systems scatterred througout the house, and in those cases, you are at least doubling the cost.
I agree with you that just having an ethernet port will not magically produce interoperability, but it will be a step in the right direction, and is a pre-condition for inter-operability to occur down the road.
It doesn't really matter whether there is an STB with a computer in front of every TV, or the TV incorporates STB functionality. What matters is that shunting raw video around is a legacy of the days when go-go dancing was all the rage.
Show me the consumer device with the HD capable encoder. Seriously, are you even reading what I write?
yes, but I'm afraid you are not returning the courtesy. The chipset spec already sent describes reading from HDMI and encoding, for example, to write to a disk on a PVR.
You claim we cannot afford another transition... for HD-TV, we have had composite, VGA, DVI, HDMI 1.x, y, and z. this in about ten years. many of those "standards" have multiple connector types and sizes. Just add one more connector to the back, and let the others die over time.
You are constantly referring to ''a cheap box'' The problem is that it is never one cheap box, but usually five. The problem I am trying to get around is that fixed function boxes are more expensive when you need five of them. And those fixed function boxes do not interoperate intelligently anyways. On the other hand, if it really is just one cheap box, and it does inter-operate with the TV and any cable provider, and the internet, and surveillance systems, and various brands of home automation... well then I accept that it's a moot point. However, if it's so standard and interoperable, economics would dictate it would be cheaper to include it in the TV after a while...
The reason we have STB's is because there are no standards for these devices, and the application specific connectors are a symptom of the problem.
It's hard to get hard data of what chipset is in what product. However, it was all over the tech news last winter that Samsung went with Broadcom chipsets for the BD players...
STB's originated when TV's were analog, electro-mechanical devices. when stuff was analog, fixed function and hard-coded, so to speak, they made sense. These days, when everything has a microprocessor in it already, it's hard to see the added value, for the consumer, of an extra box, with an extra power supply, containing an extra processor, requiring an extra remote control, just to run some software that could run on the tv anyways.
From a technical perspective, the STB function is a software one, that could run on an arbitrary CPU. It would be cheaper for the consumer to run it on an existing cpu that is needed anyways, the one in the tv. For example, folks are supposed to be able to get air-Cards from the cable provider to make virtual STB's in their TV's.
I don't want a PVR, and sling box, and a NAS, and a disk player, and a VCR, and a computer, and some weirdo video switching between them. I don't disagree that boxes can be made to meet all these functions. One can do all these functions in software instead, with practically no hardware. It would be cheaper once we got there. It would be better to have fewer connections, fewer protocols, and far more flexibility. All these gizmos are going to have encoding/decoding h/w anyways, that's most of what they do. Using a general purpose network lets us easily add flexible control layers that would require heavy duty investments to do in an application specific way, and so would never be economically viable. I gave some examples of the sorts of things that would be possible, they would probably emerge over time. With an application specific standard, there is no room for that, you have to bake it in from day 1.
Today, I have five computers and two televisions, and I view tv shows on any screen that is handy. for my purposes, I need a PC beside any television. That bugs me, because I know that there is a perfectly decent processor in there, usually running Linux. A TV should be a display device, with the ability to accept a number of inputs, and select a sub-set of them to display at any given time, or even all of them. Cheaper ones could be able to work with 1 input, a little more, for 2 inputs, 4 inputs, resolution, 1080i, 1080p, etc... There is plenty of room for product differentiation.
The flexibility from an IP interface is way better over the long term. That's why you see the surveillance cameras going IP at source, why you see professionals transforming raw output into compressed video on the camera itself, etc... It is happenning slowly, I just wish it would hurry up.
The conexant chips you linked... B) don't support HD resolution...
from the third chip in the original linked document (the one labelled "HD encoder"):
BCM7043 HD/SD AVC/MPEG Video/Audio Encoder and Transcoder/Transcaler/Transrater
The BCM7043 is a real-time high definition H.264/AVC, MPEG-2, and MPEG-4SP encoder and transcoder that is designed for use in cable, satellite, IP and terrestrial set-top boxes, home media centers, personal digital video recorders and HD DVD, Blu-ray, and DVD player/recorders. The BCM7043 is able to perform real-time high definition H.264/AVC and MPEG-2 encoding from the BCM7043's HDMI input (HD and SD) or ITU-R BT.656 input (SD). Additionally, the BCM7043 is capable of transcoding up to four SD streams simultaneously and one stream at up to six times the real-time rate.
The part is several years old. Granted, it doesn't mention 1080p directly, but it does mention HD and BD,and... "encoding from the HDMI input" which means it capable of taking precisely the high bandwidth flow you are describing, and encoding it real-time. It has to do that to work in a PVR storing something received via HDMI input on disk.
The reason why HDMI doesn't have functional addressing is because if you go down that road, you have to create a full general purpose networking stack to make it useful, and that will just result in re-inventing IP badly.
If folks instead spent probably less effort designing a standard adaptive encoding method, perhaps using delta's when the images are relatively static to maximize fidelity, and only moving to MPEG when the images are sufficiently dynamic to warrant it, or even better, negotiating the compression protocols available (so more expensive displays could support a wider variety of algorithms.) and firmware could be flashed to improve displays after sale.
You ask why bother with network connected displays? You point out that devices already exist to send video over networks. They exist because there is demand for this functionality. Such a scheme would achieve this functionality at lower cost (fewer separate boxes.), be more flexible, and has a lot of potential for future improvements:
network interfaces for tuning. Rather than using myriad in-compatible IR protocols, can use IP standard methods, so you can use any laptop to browse the program guide,and change the channel on the main screen when you've made up your mind. Sure, you can do this now, but it would be cheaper, simpler, and more elegant if you didn't need IR blasters etc... to do it.
network interfaces for device monitoring... how much life is left in the backlight? Vchip on steroids, authentication to restrict access to channels, or time of day access.
bi-directionality... pvr functionality...The tuner in the TV could be used as a source to output over the network to a NAS.
multi-plexing: A single gigabit input could handle: Set-top satellite box, PVR, BD, surveillance cameras,etc... Software switching could display any subset of all available inputs. Is one connector cheaper than having seven inputs on a display? Ever not have enough inputs into a single device?
multi-casting: surveillance cameras could multi-cast, so a PVR would record the video while displays could show it in real-time, while a web server could have it ready for other uses.
multi-casting: maybe more than one person wants to see who is at the front door on the camera there.
multi-casting: more than one screen can view
a single show
multi-screen/multi-player game consoles: a next gen console could drive more than one monitor, and generate a specific view for each player.
meta-data, augmented content... could access the internet for program guide info. Most TV's have built-in processors now, an integrated web browser is practically a gimme. Cableco's could use this for phone home functions as well.
The behavior of the Sink after detecting an error is implementation-dependent. However, Sinks should be designed to prevent loud spurious noises from being generated due to errors. Sample repetition and interpolation are well known concealment techniques and are recommended.
You wouldn't need to read many IEEE 802.whatever documents see just how far computer networking is from the design of HDMI. It is an entirely distinct use case.
Finally, HDMI provides timing guarantees that are totally absent in Ethernet. Devices are made cheaper through accurate timing (your TV doesn't need a larger high speed buffer for instance.) Recently so-called "Data Center Ethernet" has emerged to address this so that Ethernet can be used in latency sensitive applications. HDMI had this baked-in on day #1.
This sounds exactly like bell-heads a decade ago. talking about packets being dropped, etc... focusing on minutae of a particular application, and pointing out that a general solution (a standard network) doesn't allow for pet application x.
The question here is not to compare both hardware solutions in terms of meeting that narrow problem of sending video. The question is, do you need a specialized network, or will a general purpose one do? If the general purpose one will work, it will be a better, cheaper, more flexible choice.
For the specific points about data loss. That is a clear demonstration of not understanding the general nature of ethernet/IP communications. There are lossy transmission protocols, that is an application decision. The standards people just could start from UDP instead of TCP if they don't want to guaranteed delivery.
It is virtually certain that the signal being received is compressed, either for transmission over the air, or a cable, or storage on a disk. It is virtually certain that the output device will be a digital flat panel, with a processor, so going to some analog stream and coming back, is a merry go-round.
It would just be consistent to de-compress only at the end point, rather than inserting layers of trans-coding along the way.
The HDMI switch you link to was 250$ at normal price. The monster cable version is 900$ The deal you are pointing at is some clearance price. Looking around, 150$ to 250$ is a normal price.
The switch you link to can only be programmed with an IR remote, or RS-232. HDMI doesn't have any addressing. So to switch arbitrary signals from arbitrary rooms (arbitrary devices) in the house, you need separate IR or RS-232 switching to control which input goes to which output. Further, since it only has a single IR or RS-232 interface, you need to network whatever connects to the RS-232 in order to provide the same flexibility of configuration (route any input to any output) as a similarly priced gigabit switch. 'need to network' means you need the network wiring and a network switch on top of the HDMI hardware. And HDMI cable limits are far more restrictive. And I cannot run more than one signal on a single cable. Multiplexing comes for free with ethernet, but is out of the question with HDMI.
And my ethernet network can serve web pages, email & videos from the internet,etc... at the same time. You will wire for that anyways. So really you are arguing about adding another network of cables on top of a network you are going to need anyways.
the 'encoder' box you point to is to convert from analog to digital. For this device, you don't go looking for an industrial part, such as thec conexant chip linked by my last article, but point to a brand-name, but obscure retail product. A Monster-Cable version of such a device, which today is niche. If the standard were set, then the price would drop like a stone.
A separate point is that none of the likely data sources for this are analog. A disk player is going to be digital on the disk. digital to digital conversion is not specialized and complex as the box you point to, it's just churning bits.
Lastly, a Wii will not do 1080p any time soon, and a cheap encoder will work just fine for that. If you are talking about something that produces 1080p you are in the >200$ range, and the encoder chip at that point is minor consideration.
in-expensive cabling? you are going to compare the HDMI monstrosities with UTP, and claim they are cheap? on what planet is a 20-pin connector with shielding cheaper than UTP? Switching methods? show me an HDMI switch with 8 ports for 70$. I can buy those at any corner computer store... I can wire my entire house with them. What's the cable length limit on HDMI?
Gaming consoles already have hardware in there to do all sorts of graphics operations in hardware. MPEG encoding is right up their alley.
The cable boxes are what I was thinking might require trans-coding, purely for DRM reasons. Cableco's might want to be able to use their own special coding on their cables, so a settop box would have to de-code the other format, and reencode into MPEG.
The only case where you have a point is disk players. Frankly, the customized menus annoy the hell out of me, and I would be thrilled if the disk players could agree to some XML protocol that the TV would interpret to provide disk menus in a standardized way.
Barring that, sure, the disk players would need mpeg encoding hardware... It's no big deal:
All the devices providing this information either will receive it MPEG encoded to start with (they they can just pass it on) or need fancy hardware with cpu's and memory to do what they do anyways. This is a well trodden path, nothing new required in terms of chips. Volumes will only bring the price down over time.
HDMI is an expression of people going down a path without considering the bigger picture of what the capabilities of the devices being inter-connected are.
The problem with the parent post filled with references and precision, is that in all the technicalia, folks are losing sight of the purpose, and the equipment on hand.
There is a thing in a TV called... hmm... a tuner... The purpose of a tuner is to decode a signal sent over the air... in MPEG format. All HDtv's readily decode MPEG in real-time. That's what they are for.
The source media invariably store the data compressed, usually in some variation of MPEG format. So stop de-compressing it on some external box, just feed the compressed stream, encrypted if you must. Standardize the decode to be done by the television, and that's it. scaling up dedicated hardware to de-code an MPEG stream is already standard stuff.
At worst, the external box could trans-code the stuff. Using a general purpose CPU that would be painful, but with the volumes here, dedicated hardware should be easily justified and dirt cheap.
If you do that, a 1080i stream is something like 6 mbits/second. Go ahead, go to 1080p, you'll probably go to 20 mbits/second with sound and every bell and whistle imaginable. No matter the choice, 100 base-T would probably be fine, but go ahead and use gigabit, I can buy an 8 port switch for 70$, so it cannot be that expensive.
This is essentially exactly what mythtv does, and I have no problem watching an 1080i broadcast in any room in my house with an 100 BaseT connection and a decent cpu. So the whole mess about sending decoded data is a complete red-herring.
Ethernet would be fine, simpler, and cheaper for everyone.
I'm assuming the person is getting on in years, and so would appreciate a large screen. Small, fanless atom based units can be had, such as:
Get a fit-pc (http://www.fit-pc.com) or an
eee box (http://hothardware.com/News/ASUS_Eee_Box_B202_Details_Emerge/ )
and can be hooked up to a large monitor (or even attached to the back of the monitor, for zero foot print.) The systems come with SATA HDD, for long life, The only change I might make would be to replace the HDD with an SSD. count on 300 US$ for the server, and 400$ for a nice monitor, kb & mouse. (another 200$ for the SSD)
As others have suggested, put the whole existing system in a vm or emulator...and he will be able to use the same, familiar system, and make it fill the whole screen.
This will last as long as anything else. and If you ever do need to replace it, by that time, it will be with a cell-phone...
How exactly does your pointing out that language evolves refute my assertion that the term "dweeb" as applied to language is stupid? It's stupid not because it's an "evolution" of language, but just because it's a stupid term that some dipshit came up with to sound cool, and other dipshits copied so as not to be left out. The same thing with "dork" and other bullshit abusive words. It's stupid, and you are stupid for buying into this nonsense.
Look up dweeb at Dictionary.com
1968, U.S. college student slang, probably a variant of feeb "feeble person." -- Dweeb is a word made up by college students, earliest reference is 1968. Why do you use their neo-logism, instead of 'feeble person'?
Why did you not use some existing word rather than inventing your own? I suspect you were trying to sound cool by using a modern word, even though it likely dates back to your father's generation.
Go back forty years and look up the word 'entree' . It didn't exist in US English. It is also highly confusing to French speakers, because whoever imported it into English got it wrong. In French, an entree is an appetizer. In English, it's a main course.
Cool it brother, organic means that you're going with the flow dude, just learning what you need to "on demand", "just in time", and not trying to cram for "crunch time". When a project is five or ten years long, there is this management idea that you build a big mpp file in the first two months, get it vetted by the managers, and then execute the next five years of software development, feature by feature, on schedule...
If you're looking at it organically, you are understanding as much as you can at first, doing a little functionality, hopefully delivering it, then moving on, getting small wins, and the system gets more functional over time... naturally.
In the former approach, you are doing all the planning when no-one has the faintest idea what needs to be actually done. In the latter method, you are doing small, incremental, plans right before you start working on a component, when you have the most information possible, and you are dealing with specific clients for specific requirements.
Isn't it kind of useful for people doing identity theft? I mean, the more stuff that's out there, the more questions a bad person can accurately answer, making it harder for banks and such to tell you apart.
> Rem,ember this is one country without a domestic
> car concern...the only such country in the entire
> so called G8! Canada? Give me a break!
You are aware of something called the auto pact.
Basically the deal is that we agreed to allow
Canadian makers to be taken over in exchange for complete integration into the north american market. So our branch plants of automakers represent approximately double the number of employees, per capita of population in comparison to the US.
We didn't get the names, but we got the jobs.
Canadians used their noggins for what was important to them. And the most popular segment in the late nineties was the Chrysler Mini-van, which was designed and built in Canada from day 1 until today, where it is now sold as a VW Touran.
As for being alone in the G8... Name me a British automobile brand that is still in British hands, and still in business. Show me a Russian car you can buy in North America (nope, no Lada's) Please attempt to find an affordable Italian Car in North America. Fiat doesn't exist here. Your choices are: Alfa, Lambo, Ferrari,... If those count, then check out: T-Rex, http://www.auto123.com/en/car-reviews/new/2008-t-rex-1400r-road-test-video?printable=1&artid=91050
or zenn http://www.zenncars.com/
there are a half-dozen other boutique style manufacturers.
Further, there are many non G8 countries with automobile brands, such as Korea, Sweden, India, China, Brazil, etc... So what's your point?
P.S. Canada's Bombardier is:
#1 manufacturer of train wagons in the world, to the point where folks are considering anti-monopoly rules.
#3 manufacture of aircraft, after Boeing, and Airbus.
oh, and they started out in Snow mobiles, and are still big there.
So on the one hand, there are other G8 countries without meaningful presence in one of the largest auto markets in the world (North America), on the other hand, some G8 countries' manufacturers' are economically insignificant. On the third hand, the presence/absence of an auto brand says little about the overall economy... and many non G8 countries have auto brands. So It's hard to see how that could be a condition of entry into the club.
discrete graphics are nearly dead, or really dead within 5 years. Intel is doing fine with GMA 3000 etc... AMD has ATI, so they are going to be doing GPGPU, but the other way round (absorbing graphics into northbridge or cpu itself.)
If Nvidia doesn't get into the cpu market, they will follow the discrete market into oblivion.
I see no reason why having more than 2 suppliers is not a good thing for customers. duopoly is certainly far better than monopoly, but the more the merrier.
and that is exactly the sort of commercial conditions negotiated by government... good satisfactory or money refunded. Which is entirely useless. Sometimes they go the other way... you get government people wanting vendors to sign up for unlimited liability, which they tend to balk at... for years... that's no fun either.
What government often succeeds at is volume discount. But having government sue a tax paying corporation, likely employing someone who plays golf with the Minister/Secretary of.../ grand poobah... ? unlikely.
first thing to do is boot a live linux CD.
run a bunch of performance benchmarks.
Does it seem slow?
If it is still slow, or you have obvious messages
in logs (timeouts, retries, etc...) then it is hardware.
If it is lively, then it's sw.
others have posted about what to do in each case.
Slashdot Mirror
I have no way of knowing how expensive the part it, but even if we grant that it is expensive, it is just replacing the de-code chip. It will not be an addition to the parts-list, but replacement. The delta is not going to be that horrific.
You clearly only have a single TV in one room,and it must be a 60"... I have an 32" HDTV that "does 1080i" (marketing speak) onto 1366x766 screen. I want real 1080i. I can't get it without replacing the TV. I want 1080p... cannot get it without replacing the TV. Supposedly, the next thing is 3D. Again it will involve replacing the TV. If the processor is sized to the capabilities of the display, then chances are that when you decide you need to upgrade a box, the TV needs to go too.
You refer to the TV as the expensive part, with a long lived standard. That was the case in analog days, but looking at the list of improvements above, one can rapidly ascertain that TV standards are getting fluid now too. Is your ten year old HDTV still good? Most likely it was CRT based, consumed about 10x the power of tv's today, and cost about as much as a decent motrocycle.
a Dynex 19" HD LCD TV @ BestBuy is 149$. granted, it only does 720p, but tell me again how much money we are saving with a 200$ STB? If we have a 400$ STB, will the TV do better than 720p?
The idea that TV is the expensive component applies only to a Home theater setup. Most people have smaller vision systems scatterred througout the house, and in those cases, you are at least doubling the cost.
I agree with you that just having an ethernet port will not magically produce interoperability, but it will be a step in the right direction, and is a pre-condition for inter-operability to occur down the road.
It doesn't really matter whether there is an STB with a computer in front of every TV, or the TV incorporates STB functionality. What matters is that shunting raw video around is a legacy of the days when go-go dancing was all the rage.
yes, but I'm afraid you are not returning the courtesy. The chipset spec already sent describes reading from HDMI and encoding, for example, to write to a disk on a PVR.
You claim we cannot afford another transition...
for HD-TV, we have had composite, VGA, DVI, HDMI 1.x, y, and z. this in about ten years. many of those "standards" have multiple connector types and sizes. Just add one more connector to the back, and let the others die over time.
You are constantly referring to ''a cheap box'' The problem is that it is never one cheap box, but usually five. The problem I am trying to get around is that fixed function boxes are more expensive when you need five of them. And those fixed function boxes do not interoperate intelligently anyways. On the other hand, if it really is just one cheap box, and it does inter-operate with the TV and any cable provider, and the internet, and surveillance systems, and various brands of home automation... well then I accept that it's a moot point. However, if it's so standard and interoperable, economics would dictate it would be cheaper to include it in the TV after a while...
The reason we have STB's is because there are no standards for these devices, and the application specific connectors are a symptom of the problem.
never seen in any device...
It's hard to get hard data of what chipset is
in what product. However, it was all over the tech news last winter that Samsung went with Broadcom chipsets for the BD players...
BD players from samsung:
http://www.highbeam.com/doc/1G1-190874810.html
a chinese OEM:
http://www.bikudo.com/product_search/details/118262/blu_ray_disc_player_sbd5102.html
and 2 wire...
http://www.reuters.com/article/pressRelease/idUS125072+06-Jan-2009+PRN20090106
There are undoubtedly others.
STB's originated when TV's were analog, electro-mechanical devices. when stuff was analog, fixed function and hard-coded, so to speak, they made sense. These days, when everything has a microprocessor in it already, it's hard to see the added value, for the consumer, of an extra box, with an extra power supply, containing an extra processor, requiring an extra remote control, just to run some software that could run on the tv anyways.
From a technical perspective, the STB function is a software one, that could run on an arbitrary CPU. It would be cheaper for the consumer to run it on an existing cpu that is needed anyways, the one in the tv. For example, folks are supposed to be able to get air-Cards from the cable provider to make virtual STB's in their TV's.
I don't want a PVR, and sling box, and a NAS, and a disk player, and a VCR, and a computer, and some weirdo video switching between them. I don't disagree that boxes can be made to meet all these functions. One can do all these functions in software instead, with practically no hardware. It would be cheaper once we got there. It would be better to have fewer connections, fewer protocols, and far more flexibility. All these gizmos are going to have encoding/decoding h/w anyways, that's most of what they do. Using a general purpose network lets us easily add flexible control layers that would require heavy duty investments to do in an application specific way, and so would never be economically viable. I gave some examples of the sorts of things that would be possible, they would probably emerge over time. With an application specific standard, there is no room for that, you have to bake it in from day 1.
Today, I have five computers and two televisions, and I view tv shows on any screen that is handy. for my purposes, I need a PC beside any television. That bugs me, because I know that there is a perfectly decent processor in there, usually running Linux. A TV should be a display device, with the ability to accept a number of inputs, and select a sub-set of them to display at any given time, or even all of them. Cheaper ones could be able to work with 1 input, a little more, for 2 inputs, 4 inputs, resolution, 1080i, 1080p, etc... There is plenty of room for product differentiation.
The flexibility from an IP interface is way better over the long term. That's why you see the surveillance cameras going IP at source, why you see professionals transforming raw output into compressed video on the camera itself, etc... It is happenning slowly, I just wish it would hurry up.
from the third chip in the original linked document (the one labelled "HD encoder"):
BCM7043 HD/SD AVC/MPEG Video/Audio Encoder and Transcoder/Transcaler/Transrater
The BCM7043 is a real-time high definition H.264/AVC, MPEG-2, and MPEG-4SP encoder and transcoder that is designed for use in cable, satellite, IP and terrestrial set-top boxes, home media centers, personal digital video recorders and HD DVD, Blu-ray, and DVD player/recorders. The BCM7043 is able to perform real-time high definition H.264/AVC and MPEG-2 encoding from the BCM7043's HDMI input (HD and SD) or ITU-R BT.656 input (SD). Additionally, the BCM7043 is capable of transcoding up to four SD streams simultaneously and one stream at up to six times the real-time rate.
The part is several years old. Granted, it doesn't mention 1080p directly, but it does mention HD and BD,and... "encoding from the HDMI input" which means it capable of taking precisely the high bandwidth flow you are describing, and encoding it real-time. It has to do that to work in a PVR storing something received via HDMI input on disk.
The reason why HDMI doesn't have functional addressing is because if you go down that road, you have to create a full general purpose networking stack to make it useful, and that will just result in re-inventing IP badly.
If folks instead spent probably less effort designing a standard adaptive encoding method, perhaps using delta's when the images are relatively static to maximize fidelity, and only moving to MPEG when the images are sufficiently dynamic to warrant it, or even better, negotiating the compression protocols available (so more expensive displays could support a wider variety of algorithms.) and firmware could be flashed to improve displays after sale.
You ask why bother with network connected displays? You point out that devices already exist to send video over networks. They exist because there is demand for this functionality. Such a scheme would achieve this functionality at lower cost (fewer separate boxes.), be more flexible, and has a lot of potential for future improvements:
The behavior of the Sink after detecting an error is implementation-dependent. However, Sinks
should be designed to prevent loud spurious noises from being generated due to errors. Sample
repetition and interpolation are well known concealment techniques and are recommended.
You wouldn't need to read many IEEE 802.whatever documents see just how far computer networking is from the design of HDMI. It is an entirely distinct use case.
Finally, HDMI provides timing guarantees that are totally absent in Ethernet. Devices are made cheaper through accurate timing (your TV doesn't need a larger high speed buffer for instance.) Recently so-called "Data Center Ethernet" has emerged to address this so that Ethernet can be used in latency sensitive applications. HDMI had this baked-in on day #1.
This sounds exactly like bell-heads a decade ago.
talking about packets being dropped, etc... focusing on minutae of a particular application, and pointing out that a general solution (a standard network) doesn't allow for pet application x.
The question here is not to compare both hardware solutions in terms of meeting that narrow problem of sending video. The question is, do you need a specialized network, or will a general purpose one do? If the general purpose one will work, it will be a better, cheaper, more flexible choice.
For the specific points about data loss. That is a clear demonstration of not understanding the general nature of ethernet/IP communications.
There are lossy transmission protocols, that is an application decision. The standards people just could start from UDP instead of TCP if they don't want to guaranteed delivery.
It is virtually certain that the signal being received is compressed, either for transmission over the air, or a cable, or storage on a disk.
It is virtually certain that the output device will be a digital flat panel, with a processor, so going to some analog stream and coming back, is a merry go-round.
It would just be consistent to de-compress only at the end point, rather than inserting layers of trans-coding along the way.
The HDMI switch you link to was 250$ at normal price. The monster cable version is 900$
The deal you are pointing at is some clearance price. Looking around, 150$ to 250$ is a normal price.
my 70$ was an MSRP...
http://shop.buynetgear.com/servlet/ControllerServlet;jsessionid=95570351C3A4B725726E5775FE07937B?Action=DisplayPage&Locale=en_US&SiteID=netgear&id=ShoppingCartPage
The switch you link to can only be programmed with an IR remote, or RS-232. HDMI doesn't have any addressing. So to switch arbitrary signals from arbitrary rooms (arbitrary devices) in the house, you need separate IR or RS-232 switching to control which input goes to which output. Further, since it only has a single IR or RS-232 interface, you need to network whatever connects to the RS-232 in order to provide the same flexibility of configuration (route any input to any output) as a similarly priced gigabit switch. 'need to network' means you need the network wiring and a network switch on top of the HDMI hardware. And HDMI cable limits are far more restrictive. And I cannot run more than one signal on a single cable. Multiplexing comes for free with ethernet, but is out of the question with HDMI.
And my ethernet network can serve web pages, email & videos from the internet,etc... at the same time. You will wire for that anyways. So really you are arguing about adding another network of cables on top of a network you are going to need anyways.
the 'encoder' box you point to is to convert from analog to digital. For this device, you don't go looking for an industrial part, such as thec conexant chip linked by my last article, but point to a brand-name, but obscure retail product. A Monster-Cable version of such a device, which today is niche. If the standard were set, then the price would drop like a stone.
A separate point is that none of the likely data sources for this are analog. A disk player is going to be digital on the disk. digital to digital conversion is not specialized and complex as the box you point to, it's just churning bits.
Lastly, a Wii will not do 1080p any time soon, and a cheap encoder will work just fine for that.
If you are talking about something that produces 1080p you are in the >200$ range, and the encoder chip at that point is minor consideration.
in-expensive cabling? you are going to compare the HDMI monstrosities with UTP, and claim they are cheap? on what planet is a 20-pin connector with shielding cheaper than UTP? Switching methods? show me an HDMI switch with 8 ports for 70$. I can buy those at any corner computer store... I can wire my entire house with them. What's the cable length limit on HDMI?
Gaming consoles already have hardware in there to do all sorts of graphics operations in hardware. MPEG encoding is right up their alley.
Cameras, etc... Already have real-time encoders, because that is how they store movies on their SD cards or whatever media. Even professionals are
doing this sort of thing:
http://www.advanceddigital.ca/products/dvb/FlashXDR_encoder_recorder.php
The cable boxes are what I was thinking might require trans-coding, purely for DRM reasons. Cableco's might want to be able to use their own special coding on their cables, so a settop box would have to de-code the other format, and reencode into MPEG.
The only case where you have a point is disk players. Frankly, the customized menus annoy the hell out of me, and I would be thrilled if the disk players could agree to some XML protocol that the TV would interpret to provide disk menus in a standardized way.
Barring that, sure, the disk players would need mpeg encoding hardware... It's no big deal:
http://www.broadcom.com/products/Cable/MPEG-2-Digital-Audio-Video-Encoders
All the devices providing this information either will receive it MPEG encoded to start with (they they can just pass it on) or need fancy hardware with cpu's and memory to do what they do anyways. This is a well trodden path, nothing new required in terms of chips. Volumes will only bring the price down over time.
HDMI is an expression of people going down a path without considering the bigger picture of what the capabilities of the devices being inter-connected are.
Things could be way simpler.
The problem with the parent post filled with references and precision, is that in all the technicalia, folks are losing sight of the purpose, and the equipment on hand.
There is a thing in a TV called... hmm... a tuner... The purpose of a tuner is to decode a signal sent over the air... in MPEG format. All HDtv's readily decode MPEG in real-time. That's what they are for.
The source media invariably store the data compressed, usually in some variation of MPEG format. So stop de-compressing it on some external box, just feed the compressed stream, encrypted if you must. Standardize the decode to be done by the television, and that's it. scaling up dedicated hardware to de-code an MPEG stream is already standard stuff.
At worst, the external box could trans-code the stuff. Using a general purpose CPU that would be painful, but with the volumes here, dedicated hardware should be easily justified and dirt cheap.
If you do that, a 1080i stream is something like 6 mbits/second. Go ahead, go to 1080p, you'll probably go to 20 mbits/second with sound and every bell and whistle imaginable. No matter the choice, 100 base-T would probably be fine, but go ahead and use gigabit, I can buy an 8 port switch for 70$, so it cannot be that expensive.
This is essentially exactly what mythtv does, and I have no problem watching an 1080i broadcast in any room in my house with an 100 BaseT connection and a decent cpu. So the whole mess about sending decoded data is a complete red-herring.
Ethernet would be fine, simpler, and cheaper for everyone.
noobs.
and she can get a date? I'd sooner expect a tear in the space-time continuum.
As others have suggested, put the whole existing system in a vm or emulator...and he will be able to use the same, familiar system, and make it fill the whole screen. This will last as long as anything else. and If you ever do need to replace it, by that time, it will be with a cell-phone...
This is just the U.S. military doing R & D for U.S. companies to be able to deploy cell towers @ 65K feet to cover vast swaths of rural areas for way cheaper than cell towers. Might be great for wireless cable or internet too. Just have a micro-wave link to the ground and a land-line from there. lest you think this preposterous... http://www.swissinfo.org/eng/feature/detail/Mobile_phone_airship_to_conquer_stratosphere.html?siteSect=108&sid=6873540&cKey=1152528169000
How exactly does your pointing out that language evolves refute my assertion that the term "dweeb" as applied to language is stupid? It's stupid not because it's an "evolution" of language, but just because it's a stupid term that some dipshit came up with to sound cool, and other dipshits copied so as not to be left out. The same thing with "dork" and other bullshit abusive words. It's stupid, and you are stupid for buying into this nonsense.
Why did you not use some existing word rather than inventing your own? I suspect you were trying to sound cool by using a modern word, even though it likely dates back to your father's generation.
Go back forty years and look up the word 'entree' . It didn't exist in US English. It is also highly confusing to French speakers, because whoever imported it into English got it wrong. In French, an entree is an appetizer. In English, it's a main course.
language evolves. get over it.
If you're looking at it organically, you are understanding as much as you can at first, doing a little functionality, hopefully delivering it, then moving on, getting small wins, and the system gets more functional over time... naturally.
In the former approach, you are doing all the planning when no-one has the faintest idea what needs to be actually done. In the latter method, you are doing small, incremental, plans right before you start working on a component, when you have the most information possible, and you are dealing with specific clients for specific requirements.
Organic: not just for produce any more...
I'm multi-lingual you insensitive clod!
Then again I'd like to see Mac OSX opensourced, too,
umm... http://www.opensource.apple.com/darwinsource/
Isn't it kind of useful for people doing identity theft? I mean, the more stuff that's out there, the more questions a bad person can accurately answer, making it harder for banks and such to tell you apart.
http://documentation.wikia.com/wiki/METRo
http://metpx.sourceforge.net/
http://iti-iit.cnrc-nrc.gc.ca/colloq/0708/07-10-25-print_e.html
usage: http://openconcept.ca/blog/mgifford/what_people_arent_saying_about_nrcan_wiki_and_gcpedia
You are aware of something called the auto pact. Basically the deal is that we agreed to allow Canadian makers to be taken over in exchange for complete integration into the north american market. So our branch plants of automakers represent approximately double the number of employees, per capita of population in comparison to the US.
We didn't get the names, but we got the jobs. Canadians used their noggins for what was important to them. And the most popular segment in the late nineties was the Chrysler Mini-van, which was designed and built in Canada from day 1 until today, where it is now sold as a VW Touran.
As for being alone in the G8... Name me a British automobile brand that is still in British hands, and still in business. Show me a Russian car you can buy in North America (nope, no Lada's) Please attempt to find an affordable Italian Car in North America. Fiat doesn't exist here. Your choices are: Alfa, Lambo, Ferrari, ... If those count, then check out: T-Rex, http://www.auto123.com/en/car-reviews/new/2008-t-rex-1400r-road-test-video?printable=1&artid=91050
or zenn http://www.zenncars.com/
there are a half-dozen other boutique style manufacturers.
Further, there are many non G8 countries with automobile brands, such as Korea, Sweden, India, China, Brazil, etc... So what's your point?
P.S. Canada's Bombardier is:
#1 manufacturer of train wagons in the world, to the point where folks are considering anti-monopoly rules.
#3 manufacture of aircraft, after Boeing, and Airbus.
oh, and they started out in Snow mobiles, and are still big there.
So on the one hand, there are other G8 countries without meaningful presence in one of the largest auto markets in the world (North America), on the other hand, some G8 countries' manufacturers' are economically insignificant. On the third hand, the presence/absence of an auto brand says little about the overall economy... and many non G8 countries have auto brands. So It's hard to see how that could be a condition of entry into the club.
discrete graphics are nearly dead, or really dead within 5 years. Intel is doing fine with GMA 3000 etc... AMD has ATI, so they are going to be doing GPGPU, but the other way round (absorbing graphics into northbridge or cpu itself.) If Nvidia doesn't get into the cpu market, they will follow the discrete market into oblivion. I see no reason why having more than 2 suppliers is not a good thing for customers. duopoly is certainly far better than monopoly, but the more the merrier.
and that is exactly the sort of commercial conditions negotiated by government... good satisfactory or money refunded. Which is entirely useless. Sometimes they go the other way... you get government people wanting vendors to sign up for unlimited liability, which they tend to balk at... for years... that's no fun either. What government often succeeds at is volume discount. But having government sue a tax paying corporation, likely employing someone who plays golf with the Minister/Secretary of.../ grand poobah... ? unlikely.
maybe the window manager is too much for it? are you using something that wants 3D? maybe try a xfce or some such, and see if it makes a difference?
ok but errant flash regularly sends ff into fits too. the blockers will still help, and killing off hung ff too.
first thing to do is boot a live linux CD. run a bunch of performance benchmarks. Does it seem slow? If it is still slow, or you have obvious messages in logs (timeouts, retries, etc...) then it is hardware. If it is lively, then it's sw. others have posted about what to do in each case.