Dane, pobierane przez sensor, dostarczają informacji o położeniu 20 części ciała, pozwalają one na określenie ich współrzędnych względem sensora. Punkty te tworzą szkielet postaci. Za pomocą tych punktów jesteśmy w stanie rozpoznać aktualne położenie człowieka względem sensora oraz jego pozę w pozycji „En face”, czyli przodem do sensora.

Cały proces odbywa się z wykorzystaniem kamery głębokości i emitera promieni podczerwonych. Znaczy to mniej więcej tyle, że dla sensora Kinect nie ma znaczenia ilość światła, która dociera do pomieszczenia.

Wykorzystując kamerę głębokości, możemy stworzyć trójwymiarowy model pomieszczenia i obiektów znajdujących się w nim.

Należy jednak uświadomić sobie, że dane, pochodzące ze strumienia pobieranego z kamery odległości, nie niosą ze sobą informacji, dotyczących samego obrazu, ale mają zapisane w sobie odległości pojedynczych pikseli.

Postanowiliśmy wykorzystać powyższe rozwiązanie przy projekcie interaktywnej podłogi na bazie gry „LEDerzy Ewolucji” stworzonej dla Samsung Electronics Polska.

Do śledzenia ruchu postaci (widok z góry), użyliśmy kamery głębokości.
Uzyskaliśmy w ten sposób oczekiwany rezultat w postaci zarysu sylwetki.

Poniżej przykład implementacji w C++ z użyciem openFrameworks.

Plik testApp.h
#include "ofMain.h"
#include "ofxOpenCv.h"
#include "ofxKinect.h"
#define KINECT_GAME_WIDTH 800
#define KINECT_GAME_HEIGHT 600
class testApp : public ofBaseApp
{
public:
void setup();
void update();
void draw();
ofxKinect kinect;
ofxCvGrayscaleImage grayImage;
ofxCvContourFinder contourFinder;
int nearThreshold;
int farThreshold;
};

Plik testApp.cpp
#include "testApp.h"
void testApp::setup()
{
// enable depth->rgb image calibration
kinect.setRegistration( true );
kinect.init();
kinect.open();
grayImage.allocate( kinect.width, kinect.height );
nearThreshold = 255;
farThreshold = 100;
}
void testApp::update()
{
kinect.update();
// there is a new frame and we are connected
if ( kinect.isFrameNew() )
{
// load grayscale depth image from the kinect source
grayImage.setFromPixels(
kinect.getDepthPixels(),
kinect.width, kinect.height
);
unsigned char * pixels = grayImage.getPixels();
int numPixels = grayImage.getWidth() * grayImage.getHeight();
for ( int i = 0; i < numPixels; i++ )
{
if ( pixels[ i ] < nearThreshold
&& pixels[ i ] > farThreshold )
{
pixels[ i ] = 255;
}
else
{
pixels[ i ] = 0;
}
}
// update the cv image
grayImage.flagImageChanged ();
contourFinder.findContours(
grayImage, 10,
( kinect.width * kinect.height ) / 2,
20, false
);
}
}
void testApp::draw()
{
grayImage.draw( 320, 0, 320, 240 );
contourFinder.draw( 320, 0, 320, 240 );
if ( contourFinder.nBlobs > 0 )
{
ofxCvBlob blob = contourFinder.blobs [ 0 ];
ofRectangle rect = blob.boundingRect;
ofSetColor( 255, 0, 0 );
ofCircle(
320 + ( rect.x * 0.5 ) + ( rect.width * 0.25 ),
0 + ( rect.y * 0.5 ) + ( rect.height * 0.25 ),
10
);
float currentX = ofMap(
rect.x + ( rect.width * 0.5 ),
0, 640,
0, KINECT_GAME_WIDTH
);
float currentY = ofMap(
rect.y + ( rect.height * 0.5 ),
0, 480,
0, KINECT_GAME_HEIGHT
);
cout << currentX << " x " << currentY << endl;
}
}

Efekt finalny wygląda tak:

 
[1] Źródło: http://msdn.microsoft.com

Dla jednych i drugich przygotowaliśmy fotoreportaż.

Tegoroczny plan warsztatów był ambitny. Jak zawsze.
Goście rodzimi i zagraniczni. Atmosfera twórcza.

Miejsce – dobrze znane – Cybernetyki 2.2.2.

Myśl przewodnia – interakcja.

Już od samego wejścia silna grupa wsparcia. Pomocne dłonie dla wszystkich zagubionych.

Ostatnie testy i… zaczynamy.

Przy stanowiskach zaangażowane osoby. Doświadczone i kompetentne.

Otwarcie warsztatów. Zaczyna Marcin Gaworski – Managing Director w 180heartbeats.

Jan Szarras przedstawia koncepcję tegorocznego spotkania oraz opisuje przygotowane przez nas rozwiązania.

Przestrzeń zapełniona. Jakby zainteresowana tym, co mówimy.

Szymon P. Pepliński opowiada o idei Lab^180.

Wszystko wydaje się być jasne..

Jan Szarras opisuje projekty przygotowane na potrzeby warsztatów.

Szczegółowa mapa interakcji.

Todd Brown – Creative Director z Jung von Matt opowiada o technologiach, które „making the big idea bigger”.

Rozmowa na temat fascynujących rozwiązań marketingowych.

Szczegóły realizacji projektów dla globalnych marek.

Dużo trudnych słów, więc wsparcie tłumaczy.. bezcenne.

Czas szybko płynie…

Pora na checkiny, interakcje, rozmowy.

Interaktywna podłoga, czyli jesteś kursorem w grze LEDerzy Ewolucji.

Próbujemy, gramy, wygrywamy.

Game Over. Ale zawsze można spróbować jeszcze raz..

Z niewiadomych powodów, organizatorzy zdobywają więcej punktów.. ;-p

A dookoła następuje wymiana wiedzy i doświadczeń.

Tak też można. Produkt testowany na ludziach.

Wii on Board.

Łapiemy równowagę.. a czas leci.

Jedni próbują inni komentują.

Nikt nie siedzi.

Publikujemy twórczość tworzoną przy użyciu stołu dotykowego.

Kolejny checkin i…

.. pojawia się nowa praca.

W międzyczasie rozmawiamy z uczestnikami i pytamy o ich spostrzeżenia.

Jak zwykle, przy tego typu rozmowach, pojawia się cała masa interesujących idei.

Czas płynie. Pora na kolejnych gości.

panGenerator – hacking bits&atoms

Prezentacja projektów najprężniej działającego kolektywu nowomedialnego w Polsce.
Opowiada Jakub Koźniewski.

Krzysztof Cybulski z panGenerator’a.

Dodecaudion live.

Cisza na sali. Wszyscy zasłuchani w dźwiękach generowanych przez Dodecaudion’a.

Twórca i tworzywo.

Prezentacja działania za nami. Czas na doświadczanie.

Chętnych nie brakuje.

Jak to na warsztatach. Można posłuchać, podotykać, etc..

Czas na interakcję z pozostałymi pracami.

Olga Górnicka z SWPS przygotowała Like’o'meter. Urządzenie wizualizujące poziom zadowolenia.

Kolejne rozmowy i opinie.

Nie brakuje również autorefleksji..

Robert Lechowicz z Lab^180 prezentuje zasadę funkcjonowania interfejsu multi-touch stołu dotykowego.

Pora na autorską twórczość.

Klika chwil i mamy dzieło gotowe, by je uwiecznić na ścianie..

Nie brakuje również „starych znajomych”. Piotr Mederak – osoba, która zapoczątkowała Lab^180.

W miarę upływu czas poziom interakcji wzrasta.

Kiedy jedni usiłują utrzymać równowagę, inni w zaciszu kanapy grają w Nokia Snake.

Specjalna wersja multiplayer przeznaczona na urządzenia mobilne – smartfony, tablety, etc.

Jeszcze chwila i poznamy zwycięzcę..

Dobra pozycja w rankingu – to jest coś! Tym bardziej, że dla najlepszych mamy nagrody..

Uczestnicy opowiadają o swoich doznaniach.

Trochę tego jest. Czasem trzeba odpocząć.

Ale tylko na chwilę, bo czas nieubłaganie płynie..

A trzeba jeszcze coś narysować.

Może jakiś emotikon albo napis. Może logo?

A potem wyświetlić to coś zdalnie na ubraniu.

Wszystko po to, aby było zabawnie. Umiemy się śmiać z samych siebie.

Teraz tylko trzeba tą całą wiedzę przetrawić. A potem zacząć stosować w projektach.

Ostatnie rozmowy..

.. i to już. Lab^180 edycja druga zbliża się do końca.

Raz jeszcze dziękujemy za kreatywną atmosferę i za to, że byliście.

No i do zobaczenia na kolejnych warsztatach!
Zespół Lab^180.

Niezbędnym elementem podczas prototypowania jest kamera podłączana bezpośrednio do komputera.

Jej celem jest transmisja obrazów płynnych (odbywająca się w sposób ciągły) lub obrazów statycznych (pojedynczy obraz przesyłany co pewien czas).

Kamera, jako interfejs, zmienia swoją funkcję z urządzenia rejestrującego obraz na instrument do interakcji.

Analiza obrazu pozwala na śledzenie ruchu obiektów postrzeganych przez kamerę, w tym również ruchu człowieka.

Ekstrakcja tych ruchów za pomocą oprogramowania nie jest prosta i polega na analizie zmian w sekwencji przekazywanych przez kamerę klatek.

Przetworzony przez komputer obraz, może posiadać elementy realistyczne lub może być kompletną wirtualną abstrakcją.

Badanie ruchu człowieka z informacji przekazywanych przez kamerę, jest analizą bardzo trudną do zrealizowania.

Wynika to z faktu interpretowania ruchu w przestrzeni trójwymiarowej z płaskiego obrazu.

Aby kamera dobrze spełniała swoje zadania, należy zwrócić uwagę na jakość przesyłanego obrazu oraz szybkość działania nawet w słabszym oświetleniu.

SONY Playstation 3 Eye Camera

Po przetestowaniu wielu kamer dostępnych na rynku, najlepsza okazała się SONY Playstation 3 Eye Camera.

PS3 Eye pozwala na analizę obrazu w rozdzielczości 320×240 pikseli przy szybkości transmisji danych na poziomie 125 klatek na sekundę, lub 640×480 pikseli przy 75 klatkach na sekundę.

Sterowniki pod Windows można pobrać ze strony Code Laboratories.
Dla Mac OS X można użyć macam.

Dodatkowym czynnikiem jest cena. Obecnie PS3 Eye można nabyć już za 10EUR.

Rejestracja podczerwieni.

Praktycznie każda kamera cyfrowa widzi podczerwień, ale niemal wszystkie posiadają filtr, który ją blokuje.

Po usunięciu filtra matryca kamery reaguje na zakres światła widzialnego (czyli takiego, na które reaguje siatkówka oka w procesie widzenia) i podczerwonego.

W sieci dostępnych jest wiele przykładów na to, jak należy zmodyfikować PS3 Eye, aby usunąć filtr podczerwieni.

Należy zwrócić jednak uwagę, że po usunięciu tego filtra, przekazywany przez kamerę obraz staje się nieostry, gdyż filtr jest jednocześnie soczewką!

Można użyć standardowego mocowania do obiektywów m12x0.5 oraz obiektywów M12 (S Mount).

Zmodyfikowaną w ten sposób kamerę możemy użyć na przykład do budowy ekranu dotykowego.

Kilka kamer.

Sterownik do Playstation 3 Eye Camera umożliwia podłączenia kilku kamer do jednego komputera i analizy obrazu z każdej z nich w czasie rzeczywistym.

Przykład implementacji o OpenFrameworks.

void testApp::setup()
{
	camWidth = 320;
	camHeight = 240;

	vidGrabber = new ofVideoGrabber[ 6 ];

	// (unavailable) device[0] DV Video
	// (unavailable) device[1] IIDC FireWire Video

	for ( int i = 2; i < 6; i++ )
	{
		vidGrabber[ i ].listDevices();
		vidGrabber[ i ].setVerbose( true );
		vidGrabber[ i ].initGrabber( camWidth, camHeight );
	}
}

void testApp::update()
{
	ofBackground( 100, 100, 100);

	for ( int i = 2; i < 6; i++ )
	{
		vidGrabber[ i ].grabFrame();
	}
}

void testApp::draw()
{
	ofSetHexColor( 0xffffff );

	int offsetX = 0;
	int offsetY = 0;

	for( int i = 2; i < 6; i++ )
	{
		vidGrabber[ i ].draw(
			20 + ( offsetX * camWidth ),
			20 + ( offsetY * camHeight )
		);

		if ( offsetX++ == 1 )
		{
			offsetX = 0;
			offsetY++;
		}
	}
}

NAS ma zainstalowanego w sobie Linuksa z oprogramowaniem IP Stor, jednak jego funkcjonalność pozostawia wiele do życzenia. Między innymi nie można skorzystać z iSCSI na innej platformie niż Windows i występują problemy z podłączeniem NFS-a na Linuksie. W czasie bezowocnych poszukiwań rozwiązania wspomnianych problemów znalazłem kilka stron z informacją, że na SS4000-e można zainstalować Debiana (istnieje specjalna wersja dla tych urządzeń).

Aby móc w pełni wykorzystać potencjał małego NAS-a należy:

• zaopatrzyć się w lutownicę (warunek konieczny)
• pobrać pliki ze strony projektu Debian: http://d-i.debian.org/daily-images/armel/daily/iop32x/netboot/ss4000e/
• zaopatrzyć się w złącze portu szeregowego z kostką 10-pinową z jednej strony i DB9 z drugiej (takie jak w starszych komputerach)
• posiadać kabel szeregowy NULL MODEM

Teraz musimy przerobić kabel z kostką (rozmieszczenie pinów na płycie Intela nie jest standardowe albo mój kabel miał nieodpowiednie wyprowadzenia) zgodnie z poniższym schematem:

• 3 – 2
• 5 – 3
• 9 – 5

Pozostałe kable pozostawiamy bez zmian, odlutowane nie są potrzebne i wystarczy je zabezpieczyć izolacją, aby nie zwierały z żadnym z elementów. Teraz trzeba:

• podłączyć kostkę do złącza na płycie głównej (jak na zdjęciu powyżej)
• podłączyć kabel NULL MODEM do komputera i złącza DB9
• wgrać plik pkg jako aktualizację firmware’u urządzenia
• zmienić nazwę pliku initrd.gz na ramdisk.gz

Po wykonaniu powyższych czynności możemy uruchomić minicom (bądź Windowsowy hyperterminal) i ustawić:

• szybkość połączenia na 115200
• 8 bitów na słowo
• bez bitów stopu
• jeden bit parzystości

Możemy teraz zrestartować Intela i obserwować komunikaty w terminalu. Po restarcie mamy mało czasu, aby anulować ładowanie standardowego oprogramowania. Dlatego należy szybko zacząć wciskać Ctrl+C, aby przerwać proces rozruchu.

Jeśli mamy znak zachęty RedBoota to możemy wydać następujące polecenia:

load -v -r -b 0×01800000 -m ymodem ramdisk.gz
load -v -r -b 0×01008000 -m ymodem zImage
exec -c „console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000″ -r 0×01800000

Po wykonaniu ostatniego polecenia powinien odpalić się standardowy instalator Debiana. Po zakończeniu instalacji i restarcie wciskamy Ctrl+C, aby przerwać standardowe uruchomienie systemu (jeśli tego nie zrobimy to macierz zawiesi się przy ładowaniu kernela). Jak pojawi się znak zachęty RedBoota wpisujemy poniższe polecenia:

fconfig boot_script_data
fis load -b 0×01800000 ramdisk.gz
fis load -b 0×01008000 zImage
exec -c “console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000″ -r 0×01800000

Aby zakończyć wystarczy zostawić pustą linię i wcisnąć Enter. W ten sposób RedBoot zapisze skrypt startowy z nowymi parametrami i system uruchomi się poprawnie.

Po całej operacji mamy do dyspozycji w pełni konfigurowalne urządzenie z Debianem i możemy z nim zrobić rzeczy zarezerwowane dla urządzeń z górnej półki. Należy tutaj zaznaczyć, że Intel SS4000-e nie jest zbyt wydajnym urządzeniem i prędkość zapisu danych na dysk to około 6 MB/s co skutecznie ogranicza jego wykorzystanie. Jednak jako macierz iSCSI przeznaczona do backupów sprawdza się znakomicie.

Tydzień temu testowaliśmy działanie rozwiązania, które nosi nazwę LED Light Plane.
Tym razem, zamiast nadajników podczerwieni LED, użyliśmy modułów laserowych podczerwonych z generatorami linii.

Prezentowane rozwiązanie jest bardzo precyzyjne i pozwala w pełni kontrolować punkty przecięcia pola.

Podstawowym elementem układu są 4 moduły laserowe podczerwone (780nm 25mW) oraz kamera USB (Logitech QuickCam Pro 4000 lub Sony PS3 Eye z filtrem podczerwieni – zakres 780nm).

W celu uzyskania płaszczyzny, (laser emituje skupioną wiązkę) zastosowaliśmy generatory linii laserowej o kącie 120 stopni (w praktyce wystarczą generatory 90 stopniowe). Takie rozwiązanie sprawia, że kamera widzi punkty styku palców z polem.

Zastosowanie w kamerze filtru podczerwieni powoduje zignorowanie rzucanego obrazu projekcyjnego.

Prezentowane rozwiązanie ma posłużyć do budowy interaktywnej powierzchnii dotykowej (stołu, ściany, itp.).

Tak naprwadę to dopiero połowa drogi. Stworzyliśmy sprzęt (hardware). Teraz pora na oprogramowanie (software). Jak zwyle „Sky’s the Limit”..

Pliki źródłowe naszych projektów udostępniamy na GitHubie.

Serwis GitHub to system kontroli wersji Git połączony z mechanizmami społecznościowymi, takimi jak kanały informacyjne, śledzenie czy grafy wizualizujące pracę deweloperów nad repozytoriami.

Testowaliśmy wczoraj z Robertem rozwiązanie, które nosi nazwę LED Light Plane (LED-LP). Podstawowym elementem były nadajniki podczerwieni LED (użyliśmy 950nm 34º) oraz zwykła kamera USB (w naszym przypadku Logitech QuickCam Pro 4000).

Praktycznie każda kamera cyfrowa widzi podczerwień, ale wszystkie posiadają filtr, który ją blokuje.

Dla człowieka światło widzialne, czyli promieniowanie elektromagnetyczne, na które reaguje siatkówka oka w procesie widzenia, zawiera się w przybliżeniu w zakresie długości fal 380-780 nm.

Po usunięciu filtra matryca kamery reaguje na zakres światła widzialnego i podczerwonego.
Gdy już tak się stanie, analizujemy obraz z kamery i przetwarzamy go na dane cyfrowe.

Kamera widzi punkt styku palca z płaszczyzną (szkło, plexiglas, etc.), gdyż diody oświetlają ten palec.
Dopasowanie progu (threshold), umożliwia przekształcanie obrazu kolorowego w obraz czarno-białe z wysokim kontrastem. Piksele jaśniejsze od progu są przekształcane na biel, a ciemniejsze — na czerń.

Oczywiście dużo lepszym rozwiazaniem jest zastosowanie filtra, który przepuszcza fale o określonej długości (np. tylko 950 nm). Prezentowane rozwiązanie może posłużyć do budowy ekranu dotykowego.

Naszym zadaniem było stworzenie rozwiązania, bazującego na obrazie płynnym (wideo), umożliwiającego modyfikację poszczególych klatek filmu przez użytkowników. Efekt zmiany miał być widoczny natychmiast, bez konieczności renderowania całej sekwencji od początku.

Projekt zakładał, że film zbudowany jest z około trzydziestosekundowej, powtarzalnej (zapetlonej), sekwencji. Dodatkowo wiedzieliśmy, że długość odtwarzanego materiału będzie się zmieniać w czasie, gdyż zależy od ilości zmodyfikowanych klatek filmu. Mieliśmy dać również możliwość wyświetlenia dowolnie wskazanego ujęcia (kardu). Ostatnim założeniem była możliwa zmiana szybkości odtwarzanego materiału, podczas jego oglądania.

Idea

Najbardziej oczywistym byłoby użycie poszczególnych kadrów w formie obrazów (plików graficznych).

Wydajność takiego rozwiązania jest jednak odpowiednia wyłącznie dla krótkich sekwencji, dyskwalifikując dłuższy obraz płynny.

Z uwagi na zmienną długość filmu (poszczególne kadry są generowane przez użytkowników) nie jest również możliwe osadzenie go bezpośrednio na listwie czasowej.

Rozwiązanie

Początkowo podjęliśmy próby generowania filmu po stronie serwera z poszczególnych klatek animacji.
Do testów użyliśmy takich rozwiązań jak Adobe Media Server, Red5, FFserver.
Wszystkie z nich miały swoje wady i zalety. Niemniej żadne z powyższych nie spełniło jednego z podstawowych założeń – nie dawało możliwości odtwarzania filmu poklatkowo. Najlepiej radził sobie FFserver, ale był dość niestabilny (co jakiś czas się zawieszał – na CentOS 5.7 i FFmpeg 0.6.1 z repozytorium ATRPMS-testing).

Postanowiliśmy więc z każdego rozwiązania wziąć to, co najlepsze i stworzyć własne, idealnie odpowiadające naszym założeniom.

Po stronie serwera generowaliśmy krótkie (50 klatek) filmy Adobe Flash (SWF) z zaszytymi wewnątrz klatkami zakodowanymi jako wideo (FLV).

Użyliśmy FFmpeg 0.6.1, programowanie w powłoce BASH, curl 7.19.7 oraz PHP 5.3.2 (cli).

Na początku następowała rezerwacja danej klatki filmu.

Plik „reserveFrame.sh„

#!/bin/bash HOST="http://host/reserveFrameComplete"; SHARED_DIR="/home/project/shared"; DURATION=643; # maksymalna ilość klatek filmu if [ -n "$1" ]; then FRAME_ID=$1; LOOP_ID=$((FRAME_ID / DURATION)); LOOP_ID=${LOOP_ID/.*}; # Zaokrąglenie w dół (floor) MODULO=$((FRAME_ID % DURATION)); cp $SHARED_DIR/frames/$MODULO.jpg $SHARED_DIR/drafts/$FRAME_ID.jpg; curl --data "frameId=$FRAME_ID" $HOST > /dev/null 2>&1; fi;

Wykonanie skryptu następowało z kontrolera w PHP:

shell_exec($shared_path."/reserveFrame.sh $frame_id");

Po ukończeniu tworzenia przez użytkownika określonej klatki z filmu, obraz był przesyłany do aplikacji. Następnie wywoływany był skrypt tworzący określoną sekwencję. Zdecydowaliśmy się na dzielenie filmu na krótkie, dwusekundowe ujęcia, które następnie były doczytywane w trakcje odtwarzania filmu, przy zachowaniu odpowiedniego bufora. Jeśli się zdarzyło że bufor jest pusty (np. na skutek wolnego łącza), następowało doładowywanie kolejnych sekwencji, analogicznie jak przy strumieniowym obrazie wideo.
Jeśli ktoś przerwał oglądanie w trakcie odtwarzania, kolejne sekwencje nie były ładowane. Rozwiązanie takie pozwala na oszczędzanie transferu, co jest ważne zwłaszcza przy dużej ilości odtworzeń.

Plik „renderMovie.sh„

#!/bin/bash HOST="http://host/makeMovieComplete" DRAFT_DIR="/home/project/shared/drafts" STREAMS_DIR="/home/project/shared/streams" KEYFRAME=50 DURATION=643 if [ -n "$3" ] then FRAME_HASH=$3 if [ -n "$1" ] && [ -n "$2" ] then FRAME_ID=$1 TOTAL_LOOPS=$2 LOOP_ID=$(( FRAME_ID / DURATION )) LOOP_ID=${LOOP_ID/.*} # floor LOOP_MODULO=$(( FRAME_ID % DURATION )) KEYFRAME_ID=$(( FRAME_ID / KEYFRAME )) KEYFRAME_ID=${KEYFRAME_ID/.*} # floor KEYFRAME_MODULO=$(( FRAME_ID % KEYFRAME )) START_FRAME=$(( DURATION + LOOP_MODULO - KEYFRAME_MODULO )) START_FRAME=$(( START_FRAME % DURATION )) if [ $KEYFRAME_ID -lt $TOTAL_LOOPS ] then KEYFRAME_LENGTH=$(( KEYFRAME - 1 )) else KEYFRAME_LENGTH=$KEYFRAME_MODULO fi START_FRAME=$(( DURATION + LOOP_MODULO - KEYFRAME_MODULO )) START_FRAME=$(( START_FRAME % DURATION )) TEMP_DIR=$(mktemp -d /tmp/ffmpeg_XXXXXXXXXXXXXXXXXXXXXXXX) || { echo "Failed to create temp file" exit 1 } KEYFRAME_INDEX=0 while [ $KEYFRAME_INDEX -le $KEYFRAME_LENGTH ] do FILE=$(( START_FRAME + KEYFRAME_INDEX )) FILE=$(( FILE % DURATION )) if [ ! -f $DRAFT_DIR/$FILE.jpg ] then break else cp $DRAFT_DIR/$FILE.jpg $TEMP_DIR/$KEYFRAME_INDEX.jpg fi KEYFRAME_INDEX=$(( KEYFRAME_INDEX + 1 )) done #ffmpeg bug: fps 24 drop frames! ffmpeg -y -i $TEMP_DIR/%d.jpg -r 25 -s 640x360 -b 1536k -an -vcodec flv -f avm2 $STREAMS_DIR/$KEYFRAME_ID.swf #1>/dev/null 2>/dev/null rm -rf $TEMP_DIR curl --data "frameHash=$FRAME_HASH" $HOST #> /dev/null 2>&1 fi fi

Wywołania z PHP były odpalane „w tle”. Dodatkowo była napisana obsługa kolejkowania, która działała w taki sposób, że jeśli w tym samym czasie było wysłanych kilka, kilkanaście obrazów, generowane były tylko te, które się nie powtarzają w tej samej sekwencji.

exec($shared_path."/renderMovie.sh $frame_id $num_loops $pending_data > /dev/null 2>/dev/null &");

Czas wykonywania renderowania wynosił poniżej sekundy.
Użytkownik mógł zaraz po wysłaniu swojego kadru zobaczyć, jak jego praca prezentuje się w całej sekwencji.

Aplikacja była częścią szerszych działań promocyjnych organizowanych przez miasto stołeczne Warszawa wraz ze sponsorami globalnymi UEFA oraz PKP Polskie Koleje Państwowe.