W dniu 14 czerwca 2009 22:23 użytkownik Daniel Koć <kocio(a)linuxnews.pl> napisał: To by było całkiem fajne rozwiązanie, bo o ile dobrze rozumiem, to konwersja następowałaby przy samym uploadzie pliku. Karol007

On Sun, Jun 14, 2009 at 10:57:00PM +0200, Daniel Koć wrote: Rzeczywiście tak cenne dla nas są te filmiki z komórek... Nie da się zrobić konwertera, który by zgadł o co mogło chodzić userowi (np. że potrzebuje wrzucić filmik na wikipedię). Rozwiązaniem byłyby jakieś ładowane profile (pliki konfiguracyjne) np. dla Handbrake'a, które automatycznie dobierałyby to co trzeba, zadając minimum pytań. -- +---------------------------------------+ | -o) http://wanted.eu.org/ | /\\ Message void if penguin violated + _\_V Don't mess with the penguin

2009/6/16 Daniel Koć <kocio(a)linuxnews.pl> Hihi teraz takie do GIFów idą ;) Mamy więc pomysł na projekt dotowany przez Stowarzyszenie :) --leafnode

2009/6/15 PMG <pmgpmg(a)wp.pl>pl>: To jest nierealne przy ilościach materiałów wrzucanych na projekty. Zużycie zasobów byłoby ekstremalnie wysokie, poza tym taka konwersja zajmuje czas. Czas o wiele dłuższy od wysłania pliku. To natomiast jest w niezgodzie z duchem "wiki wiki". Straciłbym wiarę w Commons, gdybym zaczął oglądać wiadomości, jak na YouTube'ie, że "film jest jeszcze konwertowany i nie jest dostępny". -- Michał "Hołek" Połtyn

W dniu 15 czerwca 2009 10:06 użytkownik Michał <holek.n(a)gmail.com> napisał: Zgadza się, że zasoby stopniałyby przy takim rozwiązaniu jak lody w piekarniku. Ale na serwerach zapisywany by był plik już po konwersji, która trwałaby od momentu naciśnięcia "wyślij" do jej zakończenia, i każdy użytkownik, który później odtwarzały taki film, nie czekałby na konwersję bo korzystałby z już przekonwertowanego filmu. Ewentualnie można by kolejkować konwertowanie, zapisując strony plików już pod docelową nazwą (z .ogg), a sam plik .avi przechowywany w jakimś buforze (niedostępny dla nikogo), zaraz po konwersji, byłby z automatycznie kasowany. Karol007

Że tak z czystej ciekawości i przekory zapytam - dlaczego? Głównym zadaniem istnienia Commons jest wspieranie Wikipedii i projektów pochodnych. Po kie licho mamy wrzucać pliki o rozdzielczości HD, które i tak na Wikipedii są wyświetlane w większości jako 180px (thumb) ewentualnie 220px (infobox)? Owszem po kliknięciu otwiera się większa wersja, ale i tak najpierw jest to wersja o takiej wielkości żeby się zmieściła na jednym ekranie. W pewnym sensie mija się więc z celem dawanie super dużych rozdzielczości, bo tego się w życiu nie spożytkuje internetowo. Co więcej - nic mnie nie wnerwia bardziej niż to jak grafika wyświetla się w oryginalnym rozmiarze 10 na 20 tysięcy pixeli, czy ile tam komuś do głowy przyszło załadować. A nie musimy koniecznie ułatwiać życia innym, którzy pasożytniczo chcieliby materiały wykorzystać komercyjnie. Polecam sobie otworzyć NAJLEPSZĄ polską encyklopedię (Wielka PWN) i zobaczyć że 90% obrazków ma wydruk w wielkości "wizualnej" niewiele większej niż nasze infoboksy. Ja wiem, że zaraz zostanę zakrzyczany przez wszystkich grafików i fotografów profesjonalistów. Ale pokażcie mi gdzie na Wiki wyświetlamy rzeczy szersze niż 500px (no może poza panoramami, które są i tak w większości niestrawne)? Proponuję tutaj po prostu praktyczny punkt widzenia a nie medalowe kryteria ponad wszystko. Osobiście np. nie podoba mi się, że są usuwane kiepskie fotografie z Commons tylko dlatego że są kiepskie, nawet jeśli nie ma lepszych odpowiedników (jeśli są lepsze to OK). Bo dla mnie jako "poszukującego wiedzy" dużo istotniejsze jest zobaczenie kiepskiego zdjęcia 100px niż nie zobaczenie niczego. Pozdrawiam praktycznie Zureks

W dniu 15 czerwca 2009 14:50 użytkownik Stan Zurek &lt;zureks(a)gmail.com&gt; napisał: Wiesz, mi akurat opadła szczęka, jak przeczytałem Twojego posta. Dla mnie to jest zupełnie oczywiste, dlaczego na Commons zdjęcia muszą być w jak najlepszej jakości, dziwię się wręcz, jak można zadawać takie pytanie. W innym wątku toczy się dyskusja na temat Narodowego Archiwum Cyfrowego - otóż Commons działa właśnie tak, jak powinno działać takie archiwum. Proponuję przeczytać [[c:Commons:Welcome]], zwracam szczególnie uwagę na sam początek: "Wikimedia Commons is a media file repository making available public domain and freely-licensed educational media content (images, sound and video clips) to all. It acts as a common repository for the various projects of the Wikimedia Foundation, but you do not need to belong to one of those projects to use media hosted here. " Za 20-30 lat zasoby Commons będą GIGANTYCZNE. Zamiast szukać grafiki w Google, będziesz szukał na Commons, bo będziesz miał gwarancję, że znajdziesz odpowiadający Tobie materiał w oszałamiającej jak na internetowe standardy jakości. Nie wiem jak reszta, ale moim celem nie jest rozwijanie Wikipedii samej w sobie. Moim marzeniem jest stworzenie społeczności i materiałów wolnej kultury, dostępnej dla każdego łatwo i za darmo. Wikipedia, pomimo iż jest to bardzo ważne przedsięwzięcie samo w sobie, jest tylko krokiem ku wolności, ku budowaniu następnego etapu rozwoju kultury. Commons właśnie może służyć jako zbiór zasobów tej kultury. W świetle tego, ograniczanie jakości materiałów, bo lepsze na Wiki nie są potrzebne, wydaje się być nieporozumieniem. -- Adam Michalik vel Dodek Dodecki <dodecki[at]gmail.com>

2009/6/15 Stan Zurek &lt;zureks(a)gmail.com&gt;om>: Ale nie porównujmy materiałów ekranowych z drukiem. Pamiętaj, że zasoby z wikimedii można też drukować, co wcale nierzadko się robi, a tam 1920x1080 to mniej więcej 15x10 cm przy ledwie 300 dpi. --leafnode

Adam Dodek Michalik pisze: Moim także, ale rozumiem, że można mieć inne zdanie i widzieć role Wikipedii/Commons jako ściśle użytkowe. Tak czy inaczej niezależnie od opcji ideowej wszyscy chcielibyśmy jak najlepsza jakość na ile to możliwe. Chciałbym podzielić dyskusję na dwa wątki: jak poprawić proces wrzucania ad hoc oraz jak ewentualnie zabrać się za problem archiwizowania multimediów. Co do pierwszego to chyba naprawdę wystarczy ilustrowany poradnik konwertowania, najlepiej wygodnym (do tego konkretnego celu) narzędziem na wolnej licencji i dostępnego na różne platformy i zaktualizowanie dokumentacji na ten temat gdzie się da. A drugie - jeśli myśleć maksymalnie to myślę, że model przechowywania oryginałów i przekodowywania ich automatycznie w miarę potrzeb nie ma konkurencji. Do tego potrzeba głównie miejsca na dyskach, bo jeśli idzie o moc procesorów, to bardziej sensownym wyjściem byłoby chyba stworzenie projektu przetwarzania rozproszonego z wykorzystaniem wolnego czasu na komputerach ochotników (tak działa np. Tiles@home w Open Street Map, czyli aktualizowana na bieżąco mapa na podstawie danych projektu). W kwestii archiwizacji to trzeba by też coś wiedzieć na temat planów Fundacji, bo to większa sprawa - czy ktoś na tamtejszych listach ten temat poruszał, czy nie bardzo? Bo problem przewodnika to krótka piłka - kto potestuje i znajdzie jak najprostszy sposób niech go opisze i sam lub z pomocą weźmie się za dokumentację. -- Nawet gdy wichura

W dniu 15 czerwca 2009 14:33 użytkownik Adam Dodek Michalik &lt;dodecki(a)gmail.com&gt; napisał: Tak z ciekawości, ile? Chodzi mi o taki np. przelicznik - ile klatek mają łącznie pliki wideo załadowane w maju 2009 (i jaką przeciętnie rozdzielczość). Pytam bo zastanawiam się, skoro mówimy o niezbędnej mocy obliczeniowej, czy gdyby ktoś postawił równolegle do commons serwer dedykowany do rozproszonej konwersji wideo w oparciu o moc komputerów użytywanych przez tzw. "aktywnych użytkowników projektów" (w stylu chyba http://www.codergrid.de/) to czy nie można by wgrywać po prostu plik AVI a formularz importu wstawiałby mu {{ConvertToOGG}} tak jak teraz jest z konwersją na SVG. Czy ilość ozetowców byłaby wystarczająca? Niektórym znudziło się szukanie życia w kosmosie, i procesory się niepotrzebnie chłodzą. Myślę, że ludzie by się mocno cieszyli z wkładu w budowanie commons. Tak tylko się rozmarzyłem... ;)

PMG pisze: To ma jeszcze ten plus, że oryginalny plik ma nieco lepszą jakość, bo zawsze występują jakieś straty konwersji. Jeśli się go przechowuje (choćby tylko wewnętrznie), to w przyszłości będzie można automatycznie udostępniać inne formaty bez niepotrzebnego degradowania jakości. Dajmy na to zamiast Theora+Vorbis/Ogg kiedyś standardem stanie się np. Dirac+FLAC/Matroska albo jeszcze prościej: wzorcowy kodek Theory jest właśnie w fazie poważnego poprawiania, a popularne narzędzia do niedawna zawierały dodatkowo fatalny błąd, który skutkował koszmarną jakością: http://linuxnews.pl/theora-duza-poprawa-dct/ Z tych "popsutych" multimediów nie da się magicznie wrócić do pierwotnej jakości. Z tego samego powodu (nazwijmy go techniczno-metodologicznym) tak samo powinno być z MP3-kami konwertowanymi do Ogg Vorbis i może innymi materiałami multimedialnymi. Robimy encyklopedię/repozytorium na lata, a nie na jutro. -- Nawet gdy wichura