Distribution of player keys would depend on posting a bond that a developer won't make such a player. Misused keys would be revoked and unable to view streams.
Then you've missed a fundamental element of the discussion thread. And in any case how much would this bond be and when would it be returned?
Easy answer, make the standard read MUST support VP8, MAY support additional codecs, then allow codec negotiation.
And that's what they should do, so they should take microsoft's proposal on board and add the minimal modification of must support VP8, that provides a good solution.
Then why in practice did Microsoft not specify it as a default fall-back codec in CU-Web-RTC?
Because that's not necessary and because microsoft's proposal isn't a competitor to WebRTC but an implementation of an alternative that could be adopted in part to the WebRTC standard and as we've seen it is indeed patent encumbered so until now it's not been a better choice than any other codec again they didn't have to do Opus either, but they did.
Microsoft's intent is to be able to have platform-specific, patent-protected codecs so they can block interoperability with other platforms.
So then why would they contribute patents to and collaborate with Mozilla, Xiph.org, Google and others to create Opus which is licensed royalty free and for IETF standardization? This is also the audio codec Google has proposed to accompany VP8 video for Webrtc, also in theory I don't think there's any reason you couldn't use that codec combination with microsoft's cu-web-rtc.
Pretty sure doing the same thing in one place instead of another place has noting at all to do with the definition of convoluted.
If you were doing it on the device you wouldn't need another whole ARM SoC in the adapter, so yes actually it is a convoluted solution.
They are not taking extra steps or doing anything inefficiently.
They have an entire extra ARM SoC! Did you not read the article?!
I would suggest having hardware and software in the device to support 6 different video output formats would be convoluted. Having people simply select the proper dongle that handles the conversion internally is elegant.
No, having an ARM SoC for every format is not elegant at all.
You are attacking others for swallowing Apple's marketing spiel. You are rejecting a solution simply because it came from Apple.
Wrong, in fact that should be obvious from the outset given that I mentioned the performance of this adapter is significantly worse means it's a fairly safe bet that I do in fact have current and previous versions of the hardware, which i do. I'm rejecting the solution because it provides a poor result - the implementation is overly complex but that's just a sidebar to the real issue which is that this product is inferior to the previous solution, which was also an Apple solution that I have no problem with at all.
They said that the DEC CPUs wouldn't ALLOW bad drivers to crash the OS, if a poorly written driver misbehaved the CPU would not allow it to access memory addresses that it shouldn't.
That sounds easy but what does 'misbehaved' actually mean and how does the CPU know and keep track of that before the driver does something bad? In any case your suggestion would imply that Windows NT on Alpha would never BSOD, but it did.
I haven't measured it, it's obvious just by using it, but that comment makes it clear you haven't used it so don't know what you're talking about anyway.
On the contrary it isn't convoluted, it removes the complexity of the specific standard outside of the phone and essentially makes Lightning a future proof technology.
It's an entire SoC in an adapter as opposed to doing it the conversion on the device like the industry has always done, it absolutely is a convoluted solution, unless of course you don't understand the meaning of the term 'convoluted'.
MHL is an industry standard. And that is what the comment was referring to when mention a 'clever wire multiplexing.' The primary problem with it is that it isn't anywhere near universal and not even a standard in the sense there is agreement in implementation.
And deviating and doing something completely different is not the answer, should they do this with all standards that don't have a full reference implementation? Would that be acceptable? No. The reality is that they want vendor lock-in on their hardware - because that's where they make their money - and they don't get that by supporting an industry standard.
The approach taken by Apple means they can support any standard that comes out in the future with a dongle and software update. This of course being very different than the replace your phone approach of Android.
Once again you're swallowing of whatever Apple gives you without thought or question which leads you to that conclusion, but the reality is that any Android phone could do the same thing through the USB interface and an SoC adapter like Apple has done. The fact that you're sold on software updates to your adapter being a good thing is proof that you're not even thinking.
The screen is going to be way too small to type on. And if Apple claims that Siri won't run on even older iPhones, it seems unlikely that it's going to run on this watch.
Product tying. It will require an iPhone to work, and I think it's pretty safe to assume the protocol for interacting with it will be locked down such that you can't use it with other devices.
The 30-pin connector has lag. I can attest to that.
Nowhere near as much though.
So if it worked with 1080p would the SoC solution still be convoluted? Will it still be convoluted if the next iOS software update (something that happens in the world of iOS) resolves the issue?
Yes, of course it will be. If it matches the capability of the old system but requires a whole ARM SoC in the adapter to encode the video stream then yes it absolutely is a convoluted system for achieving that.
The alternative to this would be something akin to the MHL standard. However, that standard is new and is not anywhere close to universal. Even the adherents aren't controversy free.
The answer isn't to then create yet another solution, it's to work with the standards body, but of course that wouldn't result in any vendor lockin that way.
True, but if there is a 1:0 relationship between tablets and cables, integrating into the cable wins.
In theory, but when it results in an inferior result then it doesn't win. You get a better result with the old dock connector or with MHL than you do with Lightning.
So Apple comes out with a connector that seems to be pretty amazing. They pipe the data to a chip and everything magically works.
Wow you couldn't have fallen harder for the marketing spiel could you. It doesn't "magically work" at all, it's a convoluted setup that requires a whole SoC in the connector that provides an ultimately inferior result to the previous setup with artifacts, lower resolution and lag.
Slashdot Mirror
Wrong, when it's on tv it also doesn't have DRM, your argument that the motion picture is ostensibly tied to DRM is false.
So to you, a movie ceases to exist after three months.
No, like i said the motion picture is fine, it's the DRM i don't like.
Wrong, if i go to the cinema and see those films there is no DRM.
Distribution of player keys would depend on posting a bond that a developer won't make such a player. Misused keys would be revoked and unable to view streams.
Then you've missed a fundamental element of the discussion thread. And in any case how much would this bond be and when would it be returned?
Following Kerckhoffs's principle, the algorithm is published but the required cryptographic keys are secret.
How would doing that prevent the creation of a "player" that does nothing more than record the stream ?
Your typical PC or Mac doesn't require such things.
Because they implement the DRM in software.
The movies themselves are fine, it's the DRM i don't like.
Easy answer, make the standard read MUST support VP8, MAY support additional codecs, then allow codec negotiation.
And that's what they should do, so they should take microsoft's proposal on board and add the minimal modification of must support VP8, that provides a good solution.
Then why in practice did Microsoft not specify it as a default fall-back codec in CU-Web-RTC?
Because that's not necessary and because microsoft's proposal isn't a competitor to WebRTC but an implementation of an alternative that could be adopted in part to the WebRTC standard and as we've seen it is indeed patent encumbered so until now it's not been a better choice than any other codec again they didn't have to do Opus either, but they did.
The model of circles of protection also available on other processors permits fencing the activity of a device.
And that only works if you know exactly what the device should and should not do.
Microsoft's intent is to be able to have platform-specific, patent-protected codecs so they can block interoperability with other platforms.
So then why would they contribute patents to and collaborate with Mozilla, Xiph.org, Google and others to create Opus which is licensed royalty free and for IETF standardization? This is also the audio codec Google has proposed to accompany VP8 video for Webrtc, also in theory I don't think there's any reason you couldn't use that codec combination with microsoft's cu-web-rtc.
It seems to me that a royalty-free licence is, by definition, free as in beer. Isn't that what royalty-free means?
No, royalty-free means free of the requirement to pay royalties, not that the license is free.
Pretty sure doing the same thing in one place instead of another place has noting at all to do with the definition of convoluted.
If you were doing it on the device you wouldn't need another whole ARM SoC in the adapter, so yes actually it is a convoluted solution.
They are not taking extra steps or doing anything inefficiently.
They have an entire extra ARM SoC! Did you not read the article?!
I would suggest having hardware and software in the device to support 6 different video output formats would be convoluted. Having people simply select the proper dongle that handles the conversion internally is elegant.
No, having an ARM SoC for every format is not elegant at all.
You are attacking others for swallowing Apple's marketing spiel. You are rejecting a solution simply because it came from Apple.
Wrong, in fact that should be obvious from the outset given that I mentioned the performance of this adapter is significantly worse means it's a fairly safe bet that I do in fact have current and previous versions of the hardware, which i do. I'm rejecting the solution because it provides a poor result - the implementation is overly complex but that's just a sidebar to the real issue which is that this product is inferior to the previous solution, which was also an Apple solution that I have no problem with at all.
From what you've seen where?
In the Android source tree.
Stop letting people who didn't invent a term tell you what "Open Source" means.
Who's telling me what open source means?
It means access to the source code, period the end. It doesn't tell you anything about the terms.
I know. I also know open source doesn't mean OSI-approved, but that's irrelevant if the licenses are OSI-approved anyway, which AFAIK, they are.
No.
From what i've seen it's Apache, GPL or LGPL, are there non-OSI approved ones in there too?
Seriously? I thought Africa was the most populous country in the world!
Africa is not a country. It is the most populous continent though.
There's no reason they couldn't, but if all you do is compile things then disk - and to a degree CPU - is the main bottleneck.
Android is Open Source. Android is not Free Software. Open Source does not mean OSI-approved.
Isn't all of the source that is open released under an OSI-approved license?
There's a lot more to life than gaming. A fast video card won't do a thing to speed up the work I do every day.
There's a lot more to video cards than gaming. What work do you do every day?
They said that the DEC CPUs wouldn't ALLOW bad drivers to crash the OS, if a poorly written driver misbehaved the CPU would not allow it to access memory addresses that it shouldn't.
That sounds easy but what does 'misbehaved' actually mean and how does the CPU know and keep track of that before the driver does something bad? In any case your suggestion would imply that Windows NT on Alpha would never BSOD, but it did.
Nowhere near as much? Quantify, please.
I haven't measured it, it's obvious just by using it, but that comment makes it clear you haven't used it so don't know what you're talking about anyway.
On the contrary it isn't convoluted, it removes the complexity of the specific standard outside of the phone and essentially makes Lightning a future proof technology.
It's an entire SoC in an adapter as opposed to doing it the conversion on the device like the industry has always done, it absolutely is a convoluted solution, unless of course you don't understand the meaning of the term 'convoluted'.
MHL is an industry standard. And that is what the comment was referring to when mention a 'clever wire multiplexing.' The primary problem with it is that it isn't anywhere near universal and not even a standard in the sense there is agreement in implementation.
And deviating and doing something completely different is not the answer, should they do this with all standards that don't have a full reference implementation? Would that be acceptable? No. The reality is that they want vendor lock-in on their hardware - because that's where they make their money - and they don't get that by supporting an industry standard.
The approach taken by Apple means they can support any standard that comes out in the future with a dongle and software update. This of course being very different than the replace your phone approach of Android.
Once again you're swallowing of whatever Apple gives you without thought or question which leads you to that conclusion, but the reality is that any Android phone could do the same thing through the USB interface and an SoC adapter like Apple has done. The fact that you're sold on software updates to your adapter being a good thing is proof that you're not even thinking.
The screen is going to be way too small to type on. And if Apple claims that Siri won't run on even older iPhones, it seems unlikely that it's going to run on this watch.
Product tying. It will require an iPhone to work, and I think it's pretty safe to assume the protocol for interacting with it will be locked down such that you can't use it with other devices.
The 30-pin connector has lag. I can attest to that.
Nowhere near as much though.
So if it worked with 1080p would the SoC solution still be convoluted? Will it still be convoluted if the next iOS software update (something that happens in the world of iOS) resolves the issue?
Yes, of course it will be. If it matches the capability of the old system but requires a whole ARM SoC in the adapter to encode the video stream then yes it absolutely is a convoluted system for achieving that.
The alternative to this would be something akin to the MHL standard. However, that standard is new and is not anywhere close to universal. Even the adherents aren't controversy free.
The answer isn't to then create yet another solution, it's to work with the standards body, but of course that wouldn't result in any vendor lockin that way.
True, but if there is a 1:0 relationship between tablets and cables, integrating into the cable wins.
In theory, but when it results in an inferior result then it doesn't win. You get a better result with the old dock connector or with MHL than you do with Lightning.
So Apple comes out with a connector that seems to be pretty amazing. They pipe the data to a chip and everything magically works.
Wow you couldn't have fallen harder for the marketing spiel could you. It doesn't "magically work" at all, it's a convoluted setup that requires a whole SoC in the connector that provides an ultimately inferior result to the previous setup with artifacts, lower resolution and lag.