login
Search
Summary as posted on the OHF Board list for any possible comments. -------- Original Message -------- Subject: [OHF Board of Directors] DHCP and HDMI Date: Sun, 18 Feb 2007 13:52:28 -0700 From: James Richard Tyrer <tyrerj@acm.org> To: board@openhardwarefoundation.org So, we have our first issue regarding the Open Graphics Card. :-( The HDCP license rules require that digital *output* of DRM restricted content higher than certain resolutions be encrypted with HDCP. I note that this also applies to DVI digital connections as well. The issue that has been raised in the trade press is whether this requirement also applies to HDCP *input* (and possibly digital DVI) with those resolutions. If this is true, then in the near future all video cards will need to be capable of HDCP encrypted output. I have looked at the license and I don't immediately see that it contains such a requirement. The only requirement appears to be for devices that could be considered to be "repeaters" that if they receive HDCP input that any digital output generated above the stated resolutions be HDCP encrypted. I see nothing that would forbid a device from accepting unencrypted HDMI as input and outputting encrypted HDMI. So, this is an important question and we need to find the answer. The license is very restrictive, but limited to only the output issues. However, it appears to me that the OGC could easily comply with it as long as all that is needed is to provide an DHCP encrypted HDMI output. This could done by using a HDMI transmitter chip that comes with the keys already programed into it and using a micro-controller (soldered to the board) with on chip ROM to control this transmitter chip. This would make it sufficiently difficult to output unencrypted digital content to comply with the license. The source of the MCU code could be published because it would contain no confidential information. Yes, a professional could obtain another MCU, program it, and replace the ...
I feel the need to state that I'm very much against taking any action in this area. Certainly, there isn't going to be any free software support for HD disc playback, because AACS has their own set of strict restrictions that very much precludes any free software from legitimately decrypting a HD DVD or Blu-ray disc. That leaves monitor interoperability as the only reason left to attempt to support HDCP, and if that becomes a serious concern, the blame would rest on the respective display manufacturers. In that case, I honestly think that the issue would be better dealt with in court, since such crippling would be harmful to both consumers, and to various commercial areas, such as, say, OGP's :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
besides, who cares, the scheme is being hacked at, and thepiratebay already lists 24Gb torrents that are stated to be dumps of HD-DVDs and BlueRay discs... _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Assuming this is a typical length 1h40m movie, 24 GiB works out to 34359738 bits/second. That is the average, the peak rate is likely to be higher. That is twice the bitrate of high bitrate OTA HD in the US (some stations reduce the bitrate to make room for additional subchannels), and H.264 is a LOT harder to decode than OTA's mpeg2. Peter's AMD64 3200+ can't decode mpeg4 in real time. (bitrate?) Even Attila "decode it in software" Kinali admits that a AMD64 3700+ isn't fast enough to decode H.264. (bitrate?) So what is the solution? 1) fully decode in TRV(sp?) chip? adds complexity, chip takes longer to design 2) partly in CPU, partly in TRV chip? from previous discussion, this may be difficult or impossible? 3) wait for AMD to sell a AMD64 30,000+ x16 CPU? 4) wait for TI to sell a faster DSP? 5) find out what the standalone Blu-Ray and HD-DVD players use, and see if we can use that 6) something else? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart2562160.UHjvhlMUfR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If anyone else wants to try the particular video in question, it's the HD=20 version of the Blender Foundation's "Elephant's Dream" project, in case it'= s=20 a peculiarity of that particular file. As I may well have a broken media player/X server set up, I'm kinda loathe = to=20 be held up as a benchmark so frequently. ;) OTOH, I'm getting a new laptop soon(ish), which is probably going to be Int= el=20 Core 2 Duo T5500 with Intel GMA 950 graphics, so I'll try again with that a= nd=20 let everyone know. Peter =2D-=20 =46isher Society committee http://tinyurl.com/o39w2 CUSBC novices, match and league secretary http://tinyurl.com/mwrc9 CU Spaceflight http://tinyurl.com/ognu2 v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4 hackerkey.com peter-b.co.uk --nextPart2562160.UHjvhlMUfR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBF214XZ7Gbq7g7vpoRAmj9AJ9LF+JMAsgw7KaF00FhBQpfCNMHpwCdGsu3 8WXiOPgUzY5HzDE1Me1kE9Y= =EZ9V -----END PGP SIGNATURE----- --nextPart2562160.UHjvhlMUfR--
I tested the HD version of elephant dream on my pc. It work well with only software decoding. The cpu usage was around 50% with low of 40% and max of approximately 80%. A normal mpeg on my computer use ~ 25% at 720x480 resolution. The pc spec are the following : athlon 2GHz, geforce2mx. The video was played using mplayer on Gentoo with the nvidia binary driver. As I can see it playing HD video on a modern computer shouldn't be a problem except if there is crypto present in the stream. André _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I think that unless there's a lot of demand for it, any such decoder should go on either a separate card, or an expansion board, if it's not going to fit properly on the first FPGA. Maybe it can go on a second generation flagship card? I mean, OGP plans to take over the world with the revenue generated from the first OGC, right? Someone confirm this :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Plexor claims that you need 2 3GHz Pentiums to do it in software: http://www.plextor.com/english/products/px-b900a.html and that is with AACS built into their player. The only solution is a hardware accelerator. IIUC, TI does currently sell a DSP that will do it. Specifically one of the TMS320C64x line that runs at at least 600MHz. Another issue is that in order to qualify for an AACS license it appears to me that the simplest way is to have the AACS decoder and key processor and the DSP either on the video card or on a separate card that connects directly to it. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This appears to be new and designed for this specific purpose: http://www.ti.com/lit/gpn/tms320dm642 There are others in that family: http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp&sectionId=2&a... -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
http://focus.ti.com/docs/prod/folders/print/tms320dm642.html click on benchmarks, which is http://www-s.ti.com/sc/techlit/sprt379 says that the TMS320DM6446 only does 720p for mpeg2 amd mpeg4, and only 720x480 for H.264. I don't see a bitrate listed. The bitrate makes a lot of difference. Am I looking at the correct benchmark pdf for the fastest chip? (I'm not sure what the difference is between the dm642 and the DM6446 ?) Am I misreading something? Or otherwise missing something? If there is a faster version that can decode 1080p, it might be a very good solution. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If you want to use TI chip, you should look at chip for phone. I work on 3430. This is a ~20$ chip with a Cortex A8 at 500 Mhz and 2 dsp C64 at ~300Mhz use for H264 ( for a phone...) and a small 3D engine. http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navig... _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
As an ambivalent owner of a Nokia 770 (OMAP 1710, C55x DSP) I don't think that TI would release the hardware docs under conditions that would allow someone to support it with free software (they certainly didn't for Nokia). Also, how likely is it that it is capable of decoding HD resolutions, if it's designed for use in phones? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The newer OMAP chips run are capable of running a Linux software stack. The necessary changes to the Linux kernel are contributed as necessary. There may very well be some binary blob drivers for certain "peripherals", especially when you start talking about the cell The OMAP 3430 is listed as capable of 720x480 @ 30fps in the advertising literature. Patrick M _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
It's hard to tell whether Nokia chose to close things up themselves, or whether they did it because of TI. There is some closed DSP stuff, but maybe the only reason they didn't open it was because they didn't see the point. AFAIK, the only option for targeting the DSP is to use TI's proprietary IDE. There's also a bunch of other stuff they didn't open, hardware related or otherwise, see http://repository.maemo.org/stable/2.2/maemo-packages--2.2.html Also, I'm aware of their ability to run Linux, since that's what comes with the Nokia 770. It was the deciding factor in my purchase. The hardware is nice, but I'm not sure I'd have gotten one if it ran something else, since I can't stand anything Windows related, and Palm OS is a rather antiquated affair that I'm never going to learn how to develop for. I can't say it would be worth my time, considering where Palm OS is headed. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I must be missing something here. I don't see that this is closed hardware. For example: http://focus.ti.com/lit/ds/symlink/tms320vc5501.pdf 197 pages of documentation and there are a lot of application notes on how to use it as well as some free libraries and an IBIS model that is free to download. Yes, TI sells an IDE for about $5C which seems like a fair price although I do prefer companies that give their software away for free. This is the basic information: http://focus.ti.com/lit/ug/spru374g/spru374g.pdf http://focus.ti.com/lit/ug/spru652g/spru652g.pdf I don't call that closed. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Wow, looks like I totally misunderstood the situation. In fact, looking at http://wiki.neurostechnology.com/index.php/DM320_Platform_licensing_issues and http://wiki.neurostechnology.com/index.php/DM320_Platform_development#DSP_Codecs_and_L..., I can see that neither of those two paragraphs imply closed hardware (as I had previously interpreted them), but rather, closed software. Up until now I thought that Neuros and Nokia had obtained the documentation under NDA, and that it wasn't public. In my defense, it is remotely possible that those files weren't publicly available when I last looked on TI's site, which was a while ago, but for all I know, I just might not have looked hard enough. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I'd like to add also that despite the above, the lack of an open source toolchain for those DSPs is still a problem. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yes, that would be nice. However I note that, anyone that wants to is completely free to make an OSS compiler and assembler for the TI chip and to use one of the freely available IDEs. It would also be nice if TI offered at least basic support software for free and for *NIX. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Finding stuff on the TI site is not an easy task. It takes a little practice. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I confirm. The guys that wrote the soft work in the next box of mine. It's not only advertising. But the chip will be deliver in 2008 not _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There are faster Ti DSPs. Actually, that chip is faster than the one benchmarked. http://focus.ti.com/docs/prod/folders/print/tms320c6454.html http://focus.ti.com/docs/prod/folders/print/tms320c6455.html However, I can't seem to find any information on whether or not they will do H.264 HiP 1080p. And, they appear to be too expensive. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If you can dig out the instructions/second for the TMS320DM6446 and for the fastest chip, then we could estimate what the fastest chip might do. I'm not sure how accurate the estimate would be, and we The quantity discounts are significant. And if the TI chip can decode and display video by itself, we don't need an ASIC. We could get a useful, sale-able product out the door sooner. There may be things the TI DSP isn't good at. CAD? Google earth? So we might still need an ASIC for a future board. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I wouldn't really know, but I somehow don't think that this part would cut it at all for desktop graphics, it's not designed for this, but rather as a CPU/DSP for portable computers. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't know either, but I'm guessing that if it can decode and display 1080p it can also display web pages, still images, pdf, and similar. Not everyone does heavy duty 3D CAD. And the first version of the ASIC doesn't promise heavy duty 3D CAD either. IIRC the TI chips have Ethernet builtin, so it wouldn't have to be a PCI/PCIe card. Put it in a small box, plug in a wall-wart DC power supply and hang it on the Ethernet. Have one for your TV, check email during the commercials. Have one for your office. One for the kid's room. Then, with a usable product out the door, the design team can consider taking the time to add the features needed for heavy duty 3D CAD to the ASIC. I get the impression it is intended for consumer electronics. Camcorders and such. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
It's capable of using bluetooth, wifi, cellular, a touchscreen, memory card, and a bunch of other stuff, which I suppose don't have to be taken advantage of, but it still seems like more of a phone/PDA item. Nokia uses two other chips in that line for the 770 and N800. Oh, and the page advertises decoding at DVD resolutions - so, one would assume that means it doesn't go higher than that as far as decoding is concerned. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Tue, 20 Feb 2007 10:52:46 +0000 I can decode h.264. Just not 1080p contend with all filters Have a look at the diagram i made of a video decoding process of a codec based on DCT (which is 90% of the material around). Currently, the border between SW and HW on non-hw solution video decoders is between Filters and Upsampling. Mostly because of the lack of hardware and driver support for more functionality. If you want to make hardware aided video decoding, you have to move the border further left and implement all functions within the process in hardware. You cannot implement just the parts that are easy to do in hardware as then you would need to transfere the stream back and forth between CPU/main memory and the graphics card. So first step would be to implement the filters in hardware But, if you have a look into the h.264 specs on what kind of filters are _required_ by the standard or on what kind of filters an _average_ video player has to support, you'll soon realize that this isn't something you can easily do. Especialy as most of the filters are not stream based filters on pixels, but stream based on lines or even on individual frames. Ie, for each filter operation you have to have access to a large amount of data which has to reside in the graphics card memory (DRAM) because of its size. And if it's a more complex filter to even a few frames. Not very friendly to implement in hardware. Frame reordering is fairly easy, just passing around pointers and having enough memory to store them all. Motion compensation is again quite complicated. Less because of the many algorithms that are around (there are only a hand full of basic styles which can be quite easily abstracted) but because it needs to access the whole frame. Ie you run into the same problem as with the filters. iDCT is again quite easy to implement in hardware and can be easily parallelized and pipelined. Stream decoding is, because of the multitude of formats out there nearly impossible to ...
Economic budget or time budget? Do we have an idea of how much larger the die would be? I suspect the main problem would be But I keep reading that large amounts of data have to go back and forth between CPU and GPU? Would PCIe x16 be enough? There are other ways, like putting the GPU on the hypertransport bus, but that would *greatly* reduce the mainboards you could use. You could put a CPU on the OGC card, but that would increase IIRC they now have 6000+ x2, so they only have to find a 5x speed improvement. (And of course I just made up the 30,000 number, I don't know what the real requirement would be.) I read that Barcelona will have 128 bit SSE instructions and x4. I assume they will eventually have a CPU that is fast enough to decode video and also do other things at the same time. And a few years later it will be affordable. Question is how If TI can bump the speed up 2x or so (just a guess) it should I assume someone makes a chip that decodes in hardware that these things use? If so, then it is possible to do in hardware. What really matters is that we have documentation on how to talk to the board, allowing device drivers to be written. If that is possible, we could hold our nose and use a NDA'd chip. Depends on what information they will make available. Some companies Which is basically the same as 3 - wait for a super fast CPU. And kiss a big part of the market goodbye. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sat, 17 Mar 2007 10:06:14 +0100 Both. It will use too much real estate on the FPGA/ASIC. I assume, that if we want to have a somewhat complete h.264 support, Yes, that's not feasible, that's why i said we have to move Definitly. I think even one or two lanes should be enough. The problem is only whether we can make an architecture that works well enough with this. And this would incooperate the video player too. But, having such an arch wouldnt do us any good. Nobody will support it because it's too complicated to use. (unless we are talking about It would make it impossible to use OGC on the biggest market Yes, but 4GHz is about the limit how fast chips with 2x2cm can be clocked. And even that needs very carefull design of the clock distribution and signal routing. Keep in mind that 2cm is about the distance a signal can travel within one clock cycle (depends a lot on the actually used wire model). And then you still need some safety margin to reliably operate the chip I think a 3GHz cpu should be enough for 1080p content, even without DMA. But i don't have such a system available. CPUs are fast enough to decode video. You just have to use the proper software architecture and use the already available techniques. As i said, none of the video players these days I don't know the underlying architecture Ti uses for I never said it's impossible. It's just infeasible to do And that's usualy the case with setop-box chipsets. You don't even get the information on how to use the video decoders No. Implement fast DMA, upsampling and YUV->RGB support in hardware. Make those things easily availbale to user space programms. Make use of these and you'll get the needed performance. I also plan to have a look whether a deinterlacer and inverse telecine filter could be implemented reasonably well in hardware. Both would allow to skip one filter stage that is currently performed in software and leave it to the hardware. I think, properly designed, a deinterlacer ...
I think everyone can agree that it is not worth it if that is the case. Depending on how big the 3D engine turns out, I would be willing to have software OpenGL along with hardware 2D accel and h.264. Some other cool stuff would probably fit. Maybe even a configurable What levels of H.264 should we support to make an implementation worthwhile? I can try it out over here with my 3Ghz P4D. What software do I need? From what I understand, "HD" DVDs are only 720p. Where would I get a 1080p source to decode? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sun, 18 Mar 2007 10:31:57 -0400 Well, if we want to go that way, we could start from MPEG4, which is a subset of h.264 and then slowly Do you have a G550? If so, get MPlayer[1] and mga_vid[2] from svn, compile, install and load mga_vid, compile MPlayer. While you are downloading, you can get Elephants Dream from [3] (the 1920 version) and try it. If it doesn't play smoothly, try using -framedrop or -nosound and let me know what the percentage of dropped frames is. Attila Kinali [1] svn://svn.mplayerhq.hu/mplayer/trunk [2] svn://svn.mplayerhq.hu/mga_vid/mga_vid/trunk [3] http://orange.blender.org/download -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
MPEG4 part2 is not a subset of H.264. libavcodec's MPEG4 decoder shares no code with its H.264 decoder. Even basic functions like DCT and motion compensation are different. --Loren Merritt _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
A pentium 4 use double frequency ALU (this permit to simulate 2 ALU). Pentium 4 at 3 Ghz exist sine more than 4 years. 3 Ghz cpu imply 6 Ghz ALU in the pentium 4. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart4506870.VmUL7QvGiU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I doubt that that ALU is 2x2cm though, it's probably very small with a=20 localised clock. The Cell chip would perhaps be a better example; it's=20 supposed to go up to 5 GHz I think. But then, that's basically a bunch=20 of loosely coupled DSPs together with a simple PPC core (which I don't=20 think runs at full speed actually, but I'm not sure), so that's another=20 kettle of fish. I do think there's work going on about multiple clock domains and=20 clockless computing, but I don't know whether they are anywhere near=20 production on that. Lourens --nextPart4506870.VmUL7QvGiU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBF/V9VvmNyqZHWDvURAl+gAKCjWQ4x7dBXHYWDFwfYOgpasd6Z6wCfU++m UmfUDlmMjIUSTLvuS+X7K6E= =/8I0 -----END PGP SIGNATURE----- --nextPart4506870.VmUL7QvGiU--
The biggest limit to chip performance is wire delay. That means that any significant sort of routing or interconnect is going to limit your performance. On the other hand, if you can lay out a circuit where the data flows from transistor to transistor, making the interconnects negligible, then you can make circuits that are incredibly fast. I think I read about some GaAs chips doing 100GHz. These are very specialized sorts of circuits, though. With Intel's ALU, they used some kind of differential signalling, and they laid out by hand, allowing them to achieve a 2x throughput. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN 0-465-06710-7 _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sun, 18 Mar 2007 16:18:40 +0100
Video decoding is hard to parallelize on general purpose
CPUs. Thus even if it has two ALUs, you will not be able
to use both to their full potential. Specialized video
decoding hardware is much better in that case.
Also keep in mind, that having two processors does not
mean you have doubled your processing power. How much
you get depends a lot on:
1) How well you can parellize the work tasks.
2) How much communication overhead you have.
3) How much locking you have between the two CPUs.
4) How much cache/memory contention you have due to two
CPUs work in parallel.
For more information on this, please read a book
on high performance and/or parallel computing.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One way to parallelize a process is splitting it up into pieces that can run independently in serial, then running it on a SMP machine. AMD's x2 chips are coming down in price, and x4 chips should be available soon. So this is starting to become practical. The trick will be figuring out how and where to divide a monolithic program into pieces. Ideally you'd want each piece to take about tha same amount of CPU, since SMP machines usually have identical CPUs. And pieces that the GPU can do would ideally go at the end to avoid having to ship data back and forth. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There are some things, like raytracing, that are "embarrassingly parallel", which are very easy to split up into numerous independent subproblems. But the majority of problems are not like this. Parallelizing certain problems can be very challenging or impossible. I get the impression that some of these video codecs require too much global information. For instance, where there is metadata that indicates that a large portion of the image has undergone a simple translation, you can't split up the problem into decoding different slices of the image. Each slice will need to know too much about every other slice. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN 0-465-06710-7 _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't know if this is possible with MPEG decoding. I think that it lends itself more to hardware acceleration. IIRC, this was one of the goals of JPEG 2k -- to design it so that it could be done by multiple processors running multiple threads. If the MPEG decoding requires a lot of X pixel IDCTs then special purpose hardware that can rapidly do an X pixel IDCT would be a great help. This would work best if it could be pipelined since the pipe is going to be rather long. Also, IIUC, the code contains a lot of MACs and requires multiple accumulator registers and s system that is SIMD. In both cases, these are hardware accelerators that accelerate a single thread. OTOH, there is the fractional pixel block move which could operate in parallel, but still in a single thread. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
http://www.linuxdevices.com/news/NS7803461096.html That's a new chip for Set top box. Cost around 20$, i think, so imagine adding that to a OGC cost around 50$. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Wow, that could do a lot of things which we talked about on the list (X terminal, HD video..). What does the devel board cost and where to get one? :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Intel CE2110: http://www.intel.com/design/celect/2110/ce2110_brief.pdf This appears to have a DDR2 interface, and analog + digital video output. The problem with this chip is that the DDR2 interface is only 32 bits and the PCI interface is only 32bits at 33 MHz. This would not be suitable for a high end board. Still, it appears that this could be the basis for a medium priced video board. This would work much better than a northbridge chip. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I just speak about the fact that 4 Ghz logic is not impossible. Because 6 Ghz (or 130 ps of propagation time) still exist. Usualy the problem are in the clock propagation time, but globaly asynchronous design could work at that speed. I never speak about the difficulties or not of parallel computing. I _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sun, 18 Mar 2007 21:04:49 +0100
Yes. But the industry still refrains from using any asynchron
design. Even GALS are only used in research, though they should
be quite straight forward to use.
(Ok, multiple cores are some very coars grained form of GALS,
but well...)
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I miss this one :) Globaly asynchronous/localy synchronous are a design technic where each module use a standard synchonous logic, but connection between each block are asynchrone. This permit different clock speed and avoid all the nighmarre of having a clock at 1ns periode with 20ns of delay depending where you read the clock inside the clock tree. The bigger the design the worst the problem is. Most (all?) SoC design are done like this. So i didn't speak about asynchronous logic at all. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
What are the interest of having most of the decoding done in the graphic card ? I don't see any interest beside the low power consumption but at a great design cost to match all the codec. But what's up if we could use open source codec ? If the gpu include a (fast) cpu. You can compile FOSS codec and use it directly on the board. You can imagine the same for a X server. I don't know the size of ARM core but maybe a cpu as the new Cortex A8 could do the job ? So you will have a cpu in the graphic card to upload all the graphical stuff (video, xserver, ...). Generic cpu must be used to avoid the rewrite of all the codec. Is it realistic ? The interest will be only on the low power, but that became even more important (especially for laptop). If we need only high quality, only the end of the pipeline could stay in the gpu (yuv conversion, scaling, filtering, etc...) Nicolas _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Mon, 16 Apr 2007 17:36:25 +0200
General purpose CPUs are still too slow to decode video
in real time unless you restrict yourself to non-bleeding-edge
video systems (codec+resolution). It has been like this since
i first played a video on my K6-II 350 and i assume this will
stay like this for the next 10 years. If the codecs designer
don't have any new ideas how to waste CPU time i'm sure they'll
Being able to play a video at all?
Ok. There are not that many videos out there that hit the
CPU / Memory Bandwidth limit these days, but they exist and
they are real.
Using a on board general purpose CPU on the graphics card will
not give you any advantage at all. If a PC CPU is too slow, how
do you want to beat that with a CPU that you can put onto a graphics
card without implementing half a PC on it?
No, the only reasonable way to do that is to optimize the hardware
for this specific task.
And your idea about the X-server on a graphic card isn't new either.
I've heard this at least two or three times in the last couple of years.
However nice the idea might be, but it is, because of its specialization
commercialy not feasible.
If you dont believe me, have a look at the market of x terminals.
The market is pretty much dead for the last 5-10 years and has been
replaced by thin clients that are mostly PC based or some simple
Technologically yes, commercially no.
Attila Kinali
PS: In case you wonder, i still think we should not do any
video decoding in hardware and leave everything to the software
running on the CPU. Unless we really have too much space on the
FPGA to waste.
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, ...I think about a generic cpu to avoid the need to create a good compiler. But you could always add an idct in hardware and the need for a powerfull cpu vanished at the cost of few modification in the codec used (motion compensation need power too ?). Beside that, all of Sure you can't add this to the FPGA and test it. Adding a true cpu with low latency access to the graphical pipeline look nice to me. But i imagine that power will never be enought to be interresting. So we could design a specific cpu that look very much like a vertex/pixel shader, that will always be behind ATI or NVIDIA one :/ Beside that, for the 3D world, when i look to all the 3D game, they look always the same. Or we can see there lack are the same. The number of triangle per scene are the same but texture are bigger and shader more complexe. So you could always see around character this shape that look like behind cut by cissor at high speed. It was said that to improve the visual quality with current algorithm, the need for performance are exponential. Is it possible to add something not very big that could enable the use of other primitive rather triangle ? Maybe nurbs are too complexe to manage. Maybe sphere could be used ? I have so nice picture using metaballs, but maybe metaballs are unthinkable in hardware. Ellipse ? Like used in an old game which i forget the name, in the time where Direct3D was not so used. So something that could be used to avoid this sharp looking of edge/border of complexe object (avoid the use of zillion of triangles). Maybe sphere could be a candidate, it look easy to manage it in 3D, but it's interresting if we could make them interract nicely between them and triangles. I know that we lack of ressource. I know that we are bind by opengl. It was said that opengl only knows triangle. But that the problem of chicken and eggs. With no hardware to test, nobody will try thinks differently. Nicolas _______________________________________________ Open-graphics ...
On Mon, 16 Apr 2007 19:26:15 +0200
I don't fully understand what you mean here. Could
you explain it a little bit?
I leave out the rest of your mail, as i don't have any
knowledge about 3D programming at all.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Few years ago, i had profiled ffmpeg. 98% of the cpu was used by the iDCT. I know that things change a lot for HD, motion compensation need now a lot of cpu too. Such iDCT are a 100 ASM line function. It's very localised. So it's very easy to track and modify a codec to use an hardware accelerator or a specific taylord instruction. So for the 2% of generic work you use a generic cpu and for the iDCT a specific core or a new instruction (new instruction or tightly connected coprocesseur that share registers with the cpu are great to _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well actually, you would need half a PC, but half a PC is now one chip -- northbridge. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
shouldnt this go into another card? then arrange the video card to get the decoded image from the decoder and maybe use it as a texture? we let the 3d card focus on 3d then we let the image card focus on -- the thing i like with my linux pc is that i can sum up my complaints in 5 items _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Salut,
On Mon, 16 Apr 2007 17:26:15 +0200
With my Mount Everest like backlog of OGP mails,
I don't know. The SoC design i've seen a few years back were
all synchronus to make the interconnect network simpler. But
that might have changed by now. But GALS are still a research
subject and AFAIK know not that well understood. I'm also not
so sure how many SoC are really used out there in the industry.
Sorry, i missunderstood you.
BTW: Please do not top post.
Attila Kinali
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Have you thought about the problem of runtime synchronizing of vertical refresh to video frame/field rate? DVB and other externally timed streams would need this, to be playable at synchronous/coherent frame rate (50 or 60 Hz). On local files the playback timebase might be video card, so this is not necessary. One can easily test the results using local files on some laptops and mainboards which have only one clock oscillator and all the other clocks generated by PLLs. There are no clock drifts to compensate between system, audio and video. My IBM T30 with Ati 7500 seems to work fine as built-in panel works at 50 Hz. It's just on the verge being underpowered on Kubuntu's Kaffeine with GreedyH and color upsampling filters enabled (1.8 GHz model). Main workstation (Gentoo) AMD64 3400 with Ati 9200 @ 50 Hz ViewSonic panel will drop fields more often even though Kaffeine uses 24% and X 19 % of cpu, so it is different clock domain problem. Test clips were DVB-grabs with real interlaced content and DV-video. I'm eagerly waiting for the 'really working' (tm) video hardware... -Vesa _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I believe video players usually use the sound card as timing source, otherwise they'd have to compensate for the difference between the sound card's clock and system/graphics clock by resampling the sound. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Thu, 22 Mar 2007 14:45:12 +0200
That's MPlayers way of doing. VLC uses the stream as clock source
when available, if not it uses the system clock and of course, compensates
for the drift in the audio stream. I don't know how xine does it,
but i assume that it either syncs to the system clock/stream (the VLC way)
or syncs to the audio output device (the MPlayer way).
The issue of stream synchronus playback can be entirely
solved in software and does not need to be done in hardware.
Unless you need A-V sync below 0.5*frame-time, then you need
at least a little bit information from the graphics card, when
the current image drawing is finished, but any half decend card
supports this.
Attila Kinali
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The problem is _not_ A-V sync, but interference jitter between different frame rates. Please have alook at: http://www.linuxtv.org/wiki/index.php/The_DVB_Decoder_Challenge#Screen.2FDecoder_Sync_... If you imagine multiplying two square wave signals of different frequencies (like 50Hz for deinterlaced framerate and 60Hz refresh of the monitor...) and the resulting signal/spectrum. Then compare that to a case where both signals are of same frequency and in phase... Drawing some graphs on a piece of cross-ruled paper will help :) That will show the need for hw-capability of runtime adjusting of pixel clock around one permille. The means of adjusting may be quite rudimentary like flipping clock synthesizer dividers back and forth with adjustable duty cycle. Synthesizer response time needs to be set low enough so that it does averaging of the pulses. -Vesa _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Tue, 17 Apr 2007 14:27:02 +0300 (EEST)
Nice explanation, but it's wrong IMHO. First you need to
realize that frames in video codecs are sampled _below_
the niquist criteria. That's why there is a need for
motion compensation. The second thing is that human
eyes don't work like ears, they don't percieve movements
as signal modulations. So the whole argumentation
about niquist frequency while showing movies falls flat.
As i said before, the only issue here involved is keeping
high a-v sync ratios. As long as the refresh rate of the
monitor is as high as the frame rate of the video, you can
safely ignore any difference between those two.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Of course they are just sampled on whatever frame rate of choice, but if you _resample_ them while playing... And that's what actually happens when video is played using asynchronous refresh. Nyquist... Please test with the clips from: http://www.kingcot.eclipse.co.uk/unichrome/tvoutTest.html These play _just_ as they should with some real mpeg decoding hw (like dvd-player and dxr3-decoder) and crt. If you know how to do it on linux to 50Hz lcd, I'd really really like to know how. 100 Hz crt is just fine, but my panel can't do that. It should be simple as mplayer -vo xv -vf tfields=1 interlace_test2.mpeg but it's not. -Vesa _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sat, 17 Mar 2007 14:31:18 +0100
Update on this: I tried to get the HD version of elephant dreams
working with MPlayer and mga_vid . Looking at the numbers i get,
i assume that i'm missing around 10-20% of performance to play it
in real time. I think (but i'm not really sure) that it should
be possible to achieve smooth playback with DMA. But i would
need to try that first.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
AACS isn't really a relevant issue since it is a software only issue. IAC, it has already been cracked. The only thing left is for someone to determine how to obtain the keys from the HD-DVD without using Windows We aren't yet sure who to blame. If this has become a requirement for an HDCP license, then all HD displays are going to require either analog VGA or HDCP encrypted digital to display HD video -- even if it is just Yes it will probably become a court issue. It would only be a court issue for us if we could not obtain a license for our hardware because it was Open Hardware with full documentation. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There's no way they'll give OGP a license. The only way to make the system even somewhat hard to crack is to have closed source drivers for the hardware, so that nobody can make an alternative driver that outputs video in the clear. Even so, the whole scheme is basically a misfeature, and there's no reason any user would want to have and use it other than because they have to in order to decrypt their HD content. So, my opinion is that there's no point in investigating this, and the only proper course of action is to legally attack the display manufacturers, should they ever collude to shut out hardware that doesn't support HDCP. There's no other reason to require an HDCP input signal than anticompetitiveness. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This is an interesting theory. However, as I read the license requirements, such a system would not pass the test for robustness. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
My point is that as a prerequisite to meeting the requirements, the drivers and hardware would presumably have to be closed. I didn't mean that being closed would be enough, in itself, just that open hardware would certainly not be able to meet their requirements as I understand them. Apparently Wikipedia mentions the sale of devices that transparently crack HDCP, and cites a paper from 2001 that concludes that it is fully crackable. This would imply that those who really want to solve this problem can work around it with external hardware, though it would be weird, using external hardware to negotiate an encrypted link between the graphics card and the monitor. I really don't think display manufacturers would collectively choose to not manufacture any displays capable of displaying high res digital input without HDCP. Like I said, if it does happen, it's too sneaky not to end up in court, so it's not really OGP's problem, specifically. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
My was that if software running on the computer can turn off HDCP for a video card that the card would not meet the requirements. If software can't turn it off, then the software does not need to be closed. So, closed software is neither necessary nor sufficient to meet the requirements. If that is the case, there is no reason that we could not I don't know if these devices are legal but they appear to be made under license. However those currently available strip HDCP off of a HDMI or DVI signal so that it can be used with a monitor that doesn't support it. There is no reason that the opposite couldn't be done and that should be perfectly legal. However the devices are currently rather There have been reports of TVs that won't accept a HD signal over HDMI unless it is HDCP encoded. As I said previously, we need to find out if this is true. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The license itself assumes the usage of closed software, and prescribes the use of various techniques, such as code signing (this is mandatory), to protect the code. If the software can't turn off the HDCP, that means more logic would need to be implemented in hardware. Plus, you have no way of allowing the software to signal whether content is protected or not, and therefore must assume that all content is protected. This is very contrary to the goals of OGP, but to do otherwise would breach the terms of the license. So, It's impossible that such devices are made under license, they defeat Indeed, but it's not our problem if it is, since there's nothing that can be legally done, and in terms of cracking (illegal, but only in the US and places with similarly strict DMCA-like laws), HDCP seems to be already fully broken. Plus, we wouldn't want to attempt to make an unlicensed implementation of it, because that would probably make it impossible to sell an OGC in certain countries. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One thing I should note is that it's always possible for Traversal to add a small piece of logic to our design that we all agree that we can't legally open. That means anyone else who wishes to implement our design will have to design their own replacement piece of logic. So, it's not great, but we can do it. In the GPL'd version, what you'll get is an empty stub module in place of whatever logic we would otherwise include in order to implement HDCP. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
IIUC from SiliconImages's web site, the complete implementation of HDCP is in their transmitter chip. There is an I2C connection to the chip which I presume can turn HDCP on and off. I don't see right off how this could work with your suggestion unless they (or another company) sell pin compatible chips both with and without HDCP. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This appears to apply to the implementation of HDCP in software. This would appear to be an obsolete provision since new chips implement it in Not much actually. The video controller has registers indicating the resolution of the screen and all the MCU needs to do is read these and Yes, I agree that this is bad. But, it appears that that is what may Yes, we could encrypt all HD video over HDMI. This would satisfy the license terms as long as there was no way for software running on the I agree. However the company -- http://www.spatz-tech.de/ -- making the first one (now discontinued) clearly does have a license. IAC, there is the the PRC (mainland China). I see no way for anyone to stop them from making them and selling them mail order to the USA. OTOH, I see no reason why a device that *adds* DHCP to an HDMI signal that doesn't have it would not be legal and could be produced under the license. This results in a very strange situation. Clearly, it is perfectly legal for us to offer a board with non-HDCP HDMI on it. However, if we obtain a license, it would appear that this would no longer be legal. Would this apply to all products we make or only to individual products. We do not want to crack this. If DHCP is needed, we should see if there is a legal way to offer it. If there isn't a legal way to offer it, then we should contact the EFF or some other legal foundation to see what can be done since this would be a conspiracy in restraint of trade. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
if this turns out to be correct, then we may have to start the OpenLCDController project or something, which would replace the board in the monitor that controls the LCD or plasma or whatever. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Do you think that the HDCP license is clear in its wording? I guess that a definition for the words "output", "input" and "repeater" or alike is given? Otherwise, when does the output start? (if the license focus only on that) and what could be held as a repeater? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Moin,
Without haveing read the whole discussion, a small comment
on HDCP:
On Mon, 19 Feb 2007 18:45:46 -0700
You have no idea, how restricitve the HDCP license is.
It denies you the right to give out documentation of any
system that can encrypt/decrypt HDCP streams to anyone
who does not have a HDCP licnese. It even requires that
no HDCP encryption/decryption chip is sold to any entity
who does not have a license.
I personally don't see any way how we could comply with
these restrictions while still be true to our original
goal of having a completely documented graphics card.
Also, due to this restrictions HDCP will not be possible
on anything but closed source OS, as on any other system
it'll be easily possible to intercept the data stream
in a way that would be prohibited by the license agreement.
So, if we market mostly OSS OS and embedded systems, then
the HDCP-enabled requirement for OGA falls away anyways.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If the encryption is done inside of a commercial chip, then the only issue is how to prevent sending out an unencrypted signal when this is not allowed. There are probably several specific ways to accomplish this but they would probably all require a OTP MicroController potted on the board and the routing of certain PCB traces to the center layers of the PCB. We could easily make something that was more secure than current PC hardware running under Windows Vista. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Sat, 17 Mar 2007 15:33:06 -0700
Yes, technically there wouldn't be an issue. But that doesn't
mean we can comply with the terms of the license. As I said,
the license agreement you need to sign to get access to HDCP
I don't doubt that. No, i'm quite sure that we could easily
build something that would be even secure in an OSS enviroment.
But then again, it doesn't matter what we think or what we can
do, it only matters what the MPAA thinks is right.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Why do we need an HDCP license? So people can watch bluray and hddvd movies on their pcs? I don't think linux users will use bluray and hddvd movies until the encryption is cracked at the software level like dvd was, so what's the point? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_kayan.duskglow.com-578-1174437073-0001-3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I believe they'd also like the option to sell into the Windows and embedded markets. A Tivo-like device with HD miht need HDCP (not sure about the broadcast, cable, satellite standards). So would a Windows Media Center. It might even make sense as the video output chip in a BlueRay / HD-DVD player itself. I believe that some of the current crop of $40 DVD players use some PC hardware. --=20 Zan Lynx <zlynx@acm.org> --=_kayan.duskglow.com-578-1174437073-0001-3 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQBGAHyXG8fHaOLTWwgRAnDSAJ9ZXM2Z4hKtNwzuHHpISubgGSTg3ACfZYxH nYCbmSzerJzKRLwS1CFW5bI= =rKcR -----END PGP SIGNATURE----- --=_kayan.duskglow.com-578-1174437073-0001-3--
Nope. DVD players in that price range are universally single (or very few) chip solutions that are designed specifically to play DVDs. Quite often integrated to the point that the single chip actually directly controls the optical media reader. --tim _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
