bytowisko

Odpowiedź Microsoftu

W połowie stycznia 2007 roku, Microsoft odpowiedział na niektóre ze stawianych przeze mnie zarzutów. Część informacji była rzeczywiście nowa i interesująca (jak na przykład wyjaśnienie, jakie są skutki wycofania sterownika urządzenia), inne z kolei robią wrażenie przygotowanych przez Waggener Edstrom (firma zajmująca się PR Microsoftu) niż przez menedżera projektu, Dave’a Marsha (The Inquirer również nie był pod wrażeniem). Będę sukcesywnie wzbogacał główny tekst opracowania o informacje wynikające z tej wypowiedzi Microsoftu, ale na kwestie, które nie dotyczą bezpośrednio meriutum sporu odpowiem w tym rozdziale. Ważnymi technicznymi uściśleniami były (1) określenie co faktycznie dzieje się w efekcie unieważnienia sterownika, (2) jak działają „bity spustowe” oraz (3) które fragmenty przekazu ulegają pogorszeniu w skutek zadziałania systemu ochrony treści. Specyfikacja była dość niejasna w tym względzie, więc dobrze, że w końcu udało się uściślić pewne dane.

Czy takie techniki jak HFS będą miały wpływ na powstawanie sterowników o otwartych źródłach?

Nie. HFS używa innych charakterystyk poszczególnych układów, niż te, które są wykorzystywane przy pisaniu sterowników. Wymagania stawiane przez HFS nie powinny utrudnić dostępu do informacji, które są niezbędne do tworzenia takiego oprogramowania.

To twierdzenie stoi w sprzeczności z fragmentem dokumentu tego samego autora, w którym czytamy:

Testy te mogłyby polegać na ładowaniu tekstury, poddawaniu jej przekształceniom przez układ graficzny i porównaniu wynikowych pikseli.

i następnie:

Szczegóły działania procesora graficznego muszą być utrzymywane w tajemnicy, tak aby osoba próbująca stworzyć emulator nie mogła uzyskać potrzebnych jej informacji.

Tak więc z dokumentu tego (będącego podstawowym źródłem informacji na temat systemu ochrony treści) wynika coś zupełnie przeciwnego, niż twierdzi teraz Microsoft. Po pierwsze HFS wykorzystuje podstawowe funkcje układu graficznego (renderowanie grafiki), po drugie szczegóły budowy sprzętu mają być ukryte, by uniemożliwić emulację programową.

Czy „zasady jakości” określone przez projektantów systemu wpłyną na zwiększenie kosztów kart graficznych i zredukują liczbę ich wariantów?

Obecny trend i tak jest taki, że wszystkie funkcje są integrowane w jednym układzie, więc rekomendacje nie mają na ten proces żadnego wpływu. Jako że koszt (koszt układów w szczególności) jest determinowany przede wszystkim przez skalę produkcji, to właściwie lepiej jest unikać oferowania dodatkowych rozwiązań poprzez stosowanie zewnętrznych chipów.

Szczerze mówiąc trudno mi w takich momentach powstrzymać się od zacytowania pytania, które padło w komentarzu z serwisu Slashdot: Z czyjego tyłka wyciągnięto takie założenie?. Wyżej zacytowany tekst, z którego wynika że efektem wprowadzenia systemu ochrony treści w Viście będzie spadek cen sprzętu, pochodzi od menedżera projektu odpowiedzialnego za ten system. Menedżer z firmy ATI, który nadzoruje produkcję sprzętu twierdzi coś zupełnie innego:

„Koszty te przenoszone są na konsumenta”

„Koszty przenoszone są na wszystkich konsumentów”

„Koszt ten przerzucany jest na nabywców multimedialnych pecetów”

„Koszty ponoszą konsumenci”

„Koszty ponoszą konsumenci, w szczególności nabywcy sprzętu nowej generacji”

Sami zdecydujcie któremu z nich wierzyć.

(Innym problemem wynikającym z unifikacji urządzeń jest nasilenie się zjawisk błędnego działania systemu zabezpieczeń, co opisano w rozdziale „Ograniczona stabilność systemu”.)

Czy działanie systemu ochrony treści odbije się niekorzystnie na zwiększonym zapotrzebowaniu na moc procesora?

Tak. Jednakże zużycie tych dodatkowych cykli jest nieuniknione, jako że nowy system operacyjny dostarcza dodatkowych funkcji.

Proszę zwrócić uwagę na dobór słów: „dodatkowych funkcji”, nie zaś na przykład „ulepszonych rozwiązań”. System ochrony treści tak naprawdę ogranicza możliwości stojące przed użytkownikiem. Użytkownicy Visty już teraz zwracają uwagę na obciążenie procesora przez proces „Media Foundation Protected Pipeline” (oto odpowiedni zrzut ekranu) i narzekają, że początkowe zużycie procesora sięga 100%, aby potem utrzymywać się na poziomie 10-20% podczas odtwarzania. Jeden z użytkowników pisze, że proces ten zabiera 50% mocy Pentium 4 taktowanego zegarem 3 GHz, podczas gdy podobnych problemów nie ma w XP. Inny z kolei donosi, że „Media Foundation Protected Pipeline” pojawia się na liście procesów również podczas odtwarzania nagrań w formacie DivX i XviD, co sugeruje że nie jest on aktywny tylko owówczas, gdy ma do czynienia z materiałem HD. Podobne problemy stwarza inny komponent systemu AudioDG, „dźwiękowy silnik” Visty.

Szczegóły działania Media Foundation Protected Pipeline są cokolwiek tajemnicze. Na liście procesów pojawia się program mfpmp.exe, tyle że takiego pliku Vista nie zawiera. Wygląda więc na to, że ta nazwa generowana jest „w locie” przez inny program. MFPP pojawia się jedynie wtedy, gdy uruchomiony jest Windows Media Player, nie zaś podczas używania innych odtwarzaczy, jak VLC czy WinAmp i tylko wówczas, gdy odtwarzany jest specyficzny format, jak mp3 lub pliki video. Nie uaktywnia się podczas odgrywania plików WAV, ale – jak już wspomniałem – wydaje się być aktywny przy formatach nie zawierających zabezpieczeń. Karel Donk przeprowadził kilka dalszych testów:

Podczas odtwarzania pliku MP3 w WMP, ręcznie zakończyłem proces mfpmp.exe i wtedy dźwięk zniknął ale Media Player wciąż pracował. Kliknąłem przycisk „stop” i ponownie uruchomiłem odtwarzanie – dźwięk znowu się pojawił a na liście procesów nie było już mfpmp.exe. Odtwarzacz prawdopodobnie wykrył, że coś jest nie tak i przełączył się na odtwarzanie we własnym zakresie. Po kilku senundach mfpmp.exe znowu pojawił się w pamieci, ale tym razem wykazywał brak użycia czasu procesora, co wydaje się logiczne, skoro dźwięk odtwarzany był bezpośrednio przez WMP. Aby ponownie uaktywnić ten proces wymagany był restart Media Playera.

(Czy ktoś jeszcze może to potwierdzić? Nie używam Visty, ale jeżeli te doniesienia się potwierdzą, to twierdzenia Microsoftu, że system ochrony treści nie interesuje się nagraniami innymi niż HD staną się mało wiarygodne).

W podobnym stylu można odpowiedzieć na pytanie „Czy wirusy zwiększają zapotrzebowanie na moc procesora?” – „Tak. Jednak Jednakże zużycie tych dodatkowych cykli jest nieuniknione, jako że PC dostarcza dodatkowych funkcji” (w rodzaju spammingu, phishingu itp.)

Co ze złączami S/PDIF? [...] Czy system ochrony treści będzie wyłączał złącza komponent (YPbPr)?

Podobnie jak w przypadku złącza S/PDIF, Windows Vista nie wymaga by złącza komponentowe musiały być wyłączone – realizuje raczej zasady określone przez wydawców/nadawców, włączywszy w to ograniczenia portów wyjściowych i pogorszenie jakości obrazu.

Czyli „tak, będzie wyłączał”. To kolejny z fragmentów pochodzących z Waggener Edstrom.

Czy redukcja echa będzie działała gorzej w przypadku „treści kwalifikowanych”?

Jesteśmy przekonani, że Vista zapewnia aplikacjom wystarczającą ilość informacji niezbędnych do ich poprawnego działania. Redukcja echa będzie działać w pełni sprawnie.

Powodem, dla którego zwracam Waszą uwagę na kwestię redukcji echa jest dokument, którego autorem jest Dave Marsh – czyli osoba podpisana pod odpowiedzią Microsoftu – a który stwierdza wprost, że system ochrony treści i system redukcji echa wzajemnie się zakłócają. Cytat powyżej twierdzi coś zupełnie przeciwnego. Któryś musi mijać się z prawdą.

Czy ochrona treści audio oznacza, że wyjścia HDMI nie będą pokazywane jako S/PDIF?

Lepiej jest, jeżeli będą rozróżniane, bo to pozwala na rozróżnienie ich w interfejsie użytkownika, co z kolei ułatwia ich rozpoznanie przez użytkownika i usprawnia konfigurację. Użytkownik chce widzieć różnicę między HDMI i S/PDIF, jako że fizycznie są to dwa różne złącza.

Przeglądając komentarze zamieszczone w serwisie Slashdot, miło jest przekonać się, że po przeczytaniu tego fragmentu nie tylko mnie od razu przed oczami staje powieść Orwella:

Wojna to pokój!
Niewolnictwo jest wolnością!
Zawsze walczyliśmy z konsumen^H^H^H^H^H^Hpiratami!

To kolejne z marketingowych stwierdzeń, które wciąż pojawiają się, gdy mowa o najnowszym dziecku Microsoftu. Projektanci złącz HDMI w pełni świadomie uczynili to złącze kompatybilnym (jeżeli chodzi o sygnał audio) ze złączem S/PDIF. Udowadnianie, że tworzenie sztucznych różnic pomiędzy oboma typami połączeń pozwala uprościć życie użytkowikowi jest jak twierdzenie, że ręczna skrzynia biegów jest lepsza, bo umożliwia precyzyjniejszą kontrolę nad zachowaniem pojazdu – z technicznego punktu widzenia to może być prawda, ale jeśli nie jest się kierowcą Formuły 1, to raczej na niewiele się zdaje. Mniej oznacza więcej. Wojna to pokój.

Czy system ochrony treści spowoduje, że układy graficzne będą musiały wspierać sprzętowe dekodowanie video?

Nie. System ochrony treści Windows Vista przez lata nie będzie wymagał, by układy zawierały wsparcie dla dekodowania wideo, ale takie wsparcie na pewno poprawi odtwarzanie materiału HD.

Tak jak w przypadku redukcji echa, moim źródłem był dokument Dave’a Marsha. Oto cytat:

PVP-UAB wymaga, bo układy graficzne wspomagały co najmniej przekształcenia iDCT oraz Motion Comp dla formatu MPEG2 oraz Windows Media® wersja 9/VC-1.

Tak jak w przypadku echa, oba te stwierdzenia wzajemnie się wykluczają.

strona: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24