Csak azért, hogy ne kelljen még egyszer végigpróbálgatnom:

szánSájn, tibiCsoki, wörldPísz!
Csak azért, hogy ne kelljen még egyszer végigpróbálgatnom:

Google Readerben laknak az általam olvasott RSS feedek nagyjából 2006 óta, amikor is Sasvári "angelday" Józsi előadta nekem, hogy miért is jó így olvasni. A Google Reader nagy kedvenc: szinte ipari standard és a webes kliense szinte mindent visz. A "szinte" szó használatát nálam egyedül egyetlen feature hiánya indokolja: nincs olyan keyboard shortcut a webes alkalmazásukban, amellyel a feedek átfutása közben az engem érdeklő cikket a böngésző a háttérben nyitná meg ahelyett, hogy a feedreader elé nyitna egy tab-ot (V shortcut).
Szerencsére mind Safari, mind Google Chrome alatt van a problémára megoldás: Safari fanatikusoknak a Zak Johnson által írt greader-bgtabs extensiont, míg a Chrome usernek a Google Reader: Open in background tab kiterjesztést kell felpakolniuk ahhoz, hogy a "V" shortcutra a Google Readerben olvasott aktuális cikk a háttérben nyíljon meg. Valószínűleg Firefoxra is van hasonló hack, de én azt a browsert csak ritkán szedem elő.
A Google Reader webapp valamennyire iOS optimalizált is, ám én kifejezetten utálom az iPad verziót: egyszerűen nem áll kézre. Szerencsére ezen a problémán gyorsan átugraszt a Reeder nevű natív iOS Google Reader frontend, amely iPhone és iPad változatban is külön-külön létezik, 3 és 5 USD pénzért (nem szeretem az extra pénzért különválasztott iOS portokat, de ez van - nemrég a Reeder for iPhone szülinapi akcióban volt fogható 1 USD ellenében, akkor elköltöttem rá gyorsan egy liter tej árát).
A Reeder fantasztikus alkalmazás, bátran mondom, hogy ha még nem ismered, de Google Reader felhasználó vagy, vedd meg vakon és nem fogsz benne csalódni. Korrekt, ergonómikus, intuitív UI, szemet gyönyörködtető design.

A fejlesztő dolgozik már a Mac OS X porton is - a reederapp twitter feedből épp pár napja derült ki, hogy a desktop verzió bétája a madeatgloria.com/brewery oldalon landol hamarosan. Bár nagy szükségét nem érzem egy asztali Google Reader alkalmazásnak, de azért érdeklődve várom, hogy vajon hasonlóan korrekt eszközt sikerül-e faragni, mint amilyen az iOS port.
Az OS X alapú media center megvalósításról már többször volt szó errefelé: a házimozi HOWTO komplett workflow-t magyaráz el, a Plex + Logitech Harmony HOWTO pedig a kedvenc TV-re kötött médiafogyasztó alkalmazásom és a Logitech Harmony okos távirányítók házasítását ecseteli. Mindkét postban az XMBC alkalmazásból született Plex media centeré volt a frontend főszerepe, aki pár napja váltott a 0.9.0 verzióra.
A 0.9.0-s váltás a Plex Media Server parserei által tömött metadata library teljes megújulását hozta, s ezzel egyidőben megszületett a Plex iOS app is, amely iOS alapú eszközökre teszi lehetővé a media center által látott tartalom streamelését, valamint a desktop Plex frontend alkalmazás távirányítójává alakítja az iOS appot futtató eszközt.
A 0.9.0 még bírkózik pár problémával, de bízom benne, hogy hamarosan kinövi ezeket. Sok esetben az ember egy nyitott platformú ingyen alkalmazásnál csak legyintene egyet erre, ám a Plex-es fiúk valami nagy bejelentést tartogattak még a múlt hét végére, amely eloszlatta bennem az ilyen jellegű aggodalmakat.
A Plex fejlesztői megállapodtak az LG Electronics-szel, hogy a 2011-től megjelenő egyes LG TV-kben és BluRay lejátszóiban a gyártó integrálni fogja a Plex frontend alkalmazást, ami a Plex Media server által streamelt tartalmakat képes majd az LG eszközein megjeleníteni. Ezzel együtt a dédelgetett, szabadidőben fejlesztett Plex-et a srácok mostantól a saját céges kereteik között, főmunkaidőben fejlesztik és nekiállnak a Plex Media Server több platformra történő portolásának is.
Annak ellenére, hogy az LG felkarolta a remek media centert, a fejlesztők nem kötöttek velük kizárólagos szerződést, valamint továbbra is nyitott és ingyenes platformnak tartják meg mind az alkalmazást, mind a plugin API-t.
A sok rizsa után íme egy kis sneak peek a most zajló IFA kiállításról:
Egy szó mint száz: ha mostanában terveznél TV-t upgrade-elni, megéri megvárni, mire a "Plex powered" LG Smart TV-k ellepik a piacot (arról meg majd egy következő postban beszélgetünk, hogy az LG azon kevés televízió gyártók egyike, aki a készülékei seggére szerelt soros port specifikációját nyíltan letölthetővé teszi, szabad utat engedve ezzel a korrekt épületfelügyeleti integrációnak).
Ma reggel csak egy hirtelen-kisült workflow anyagra van idő, mégis elkészítem, mert két fejfájástól is meg tud menteni, ha hozzám hasonlóan belefutsz az alábbi problémákba.
Video vágáshoz én az Apple Final Cut Express 4 alkalmazását használom. Ugyan az aktuális iLife csomagban ott van az erre készült korrekt kis iMovie, azonban valami miatt még a Mac-es életem elején felhagytam vele (talán nem tudott frame-re pontosan vágni) és maradt a FCE, amit a mai napig nagyon szeretek.
Az Apple az utolsó iMovie/Final Cut release után előállt az "open format timeline"-nak nevezett dologgal, ami nagyjából annyit tesz, hogy konvertálás nélkül keverheted a videovágó software-ben a különböző video codec-ű nyersanyagokat, meg fogja emészteni on the fly. Ez így is van, csak éppenséggel precíz munkához a 2008 late harvest MacBook Pro-n használhatatlan a tömörített nyersanyag, úgyhogy video nyersanyagot konvertálni muszáj. A nagytesó Final Cut Studioban erre ott a beépített Compressor alkalmazás és egy fancy Apple ProRes 422 codec, de ez tegyük fel, hogy nekünk most nem áll rendelkezésre és keressünk helyette ingyenes megoldást.
A másik, viszonylag ritkábban jelentkező, éppen azért alattomos kis probléma, mikor az audio sávban használt mp3 "cirpel", pattog, vagy akár 1-1 frame erejéig kihagy, a teljes rendering után is. A ludas ezúttal is a tömörítés, úgyhogy az audio adatunkat is ki kell, hogy csomagoljuk.
A mozink konvertálásához a squared5.com által gyártott ingyenes MPEG Streamclip nevű alkalmazást fogjuk használni, melynek OS X és Windows változata is létezik. Advancedebb arcok persze az ultimate ffmpeg appot használják command line varázslattal, de én lustaságból leragadtam a GUI-s toolnál. Mondjuk pont OS X alatt simán lehetne gyártani egy Folder Action scriptet, ami az erre dedikált "konvertáló pool" jellegű folderbe bedobált file-okat nekiáll ffmpeg-gel azonnal kicsomagoltatni... na, talán egy másik workflow postban megcsináljuk.
Az általam termelt video nyersanyag 1920x1080 PAL (=25fps) felbontású, H.264 codec-kel készül a kamera belsejében. A tömörített file-jainkat az MPEG Streamclip az alábbi beállításokkal kóserolja ki szép uncompressed, ám mégis valamennyire tömör formába (=ezt fedi le a beállított Apple Intermediate Codec):

Az MPEG Streamclip egy kötegben végigcsinálja ezt az összes forrásadatunkkal, plusz a folyamat megállítható, meg még sok egyéb fancy dologra képes, amiket nem részletezünk. Persze egy darab ciklus lenne a kötegelt feldolgozás az ffmpeg-et hívó shell scriptnek is, de hát a lustaság nagy úr...
A zenét Quicktime 7 segítségével konvertáljuk AIFF formátumúra, amit a FCE már gond nélkül fogyaszt:

Ezután más dolgunk már nincs, mint feldolgozni a preparált nyersanyagokat. Have fun!
Az eheti Mac workflow részben üzeneteket fogunk közvetíteni az asztali Mac-ünk és a *.iOS device-unk (=jelenleg iPod Touch / iPhone* / iPad) között.
A probléma onnan indul, hogy lusta vagyok begépelni az iOS eszközön egy hosszabb URL-t - nem is lennék coder, ha ezt nem akarnám automatizálni valahogy. iOS platformon erre kínál remek megoldást a Prowl nevű stuff.
A Prowl az OS X alatt futó Growl notification kliens fizetős iOS verziója (az app iTunes oldala erre - a post írásának pillanatában 2.39 EUR-ba kerül az alkalmazás). Mint azt már említettem korábban, OS X alatt Growl-t több cimborám az ördög szerszámának tartja, de ez ne tántorítson minket el és nézzük át, mit ad nekünk a Prowl.
A Prowl az Apple által kitalált metódus alapján (=majdnem valódi push) képes üzeneteket fogadni az iOS eszközünkön, ha hagyjuk neki (=engedélyezzük globálisan az eszközön a push notificationt a Settings/Notifications menüben, és a Prowl.app-nak is megengedjük a push üzenetek megjelenítését ugyanott).
A Prowl iOS kliensének számtalan módon küldhetünk üzenetet:
A Prowl óránként 1000 üzenetben limitálja a kiküldhető push üzenetek számát, ami a 3.6 másodperc/üzenetet alapul véve szerintem endusernek elég :)
A legszebb, hogy a Prowl kliens az iOS oldalon képes az üzenetek típus alapján történő átirányításra - íme néhány példa:

Az átirányítás definíciónál egyrészt a küldő nevét adod meg, másrészt a jelenleg Prowl által támogatott iOS alkalmazásokból választasz az üzenetnek targetet. A támogatott iOS appok listája server oldalról jön, a lista folyamatosan bővül.
Szóval ha jó lenne, ha a desktop browserből egy clickre átmászna az iPod touch/iPhone/iPad eszközre az aktív ablak URL-je, vagy épp szeretnéd, ha a Transmission szólna, hogy lejött az aktuális Debian ISO, esetleg a HandbrakeCLI-t használó scripted mondaná a mindig nálad levő telefonodnak, hogy végzett, akkor a Prowl mindenképp megér egy próbát. Egyszer ígérem még eljutunk oda is, hogy a saját házad szól rá a mobilra, hogy eleredt az eső otthon - csak győzd kivárni :)
Kifejezetten kerülöm, hogy Apple hardverről írjak, de a mostani mellett nem tudok szó nélkül elmenni. Már régóta várom, hogy megjöjjön az eszük, és letegyék az asztalra ezt:

Ma végre letették. Remélem minél előbb elkészül a driver minden létező OS-re, hogy minél több user élhesse meg, milyen fantaszikus user interface-et alkotott a multitouch trackpaddel az emberiség!
Update: Boot Camp-es Win* alá már itt is van.
Furcsa hibára figyeltem fel nem rég: a Safariban egy linken ⌘-clickelve a háttérben megnyíló tab fület a Safari hibásan rendereli: a háttérbe küldött tab is úgy néz ki, mintha az előtérben lenne. Furán hangzik, megmutatom:

Nem egy nagy probléma, de amikor egérrel szeretnéd az aktív tabot bezárni, akkor nagyon zavaró, ugyanis nem látod, hogy igaziból melyik is az aktív tab. Fogalmam nem volt, mi okozhatja ezt, így tegnap este fds-sel nyomozni kezdtünk.
Kiderült, hogy a hiba mind az aktuális Safariban, mind az utolsó WebKitben jelentkezik, de csak akkor, ha az általam egyébként nagyra becsült 1Password jelszómanager beintegrálja magát a browserekbe. Ezzel úgy gondoltam, hogy a ludas meg is van és írtam egy mailt az 1Password techsupportnak, felhívva az általuk generált anomáliára a figyelmet.
Ma reggel megjött a válasz: mégsem ők a hibásak, hanem a Logitech egérhez adott hibás Logitech Control Center. Íme a support válasza:
Thank you for taking the time to contact us. I'm really sorry for the trouble you're seeing with the graphical glitch with the tabs. By any chance, do you have Logitech Control Center installed? If so, please try this:
- Quit Safari
- Remove
/Library/ScriptingAddons/LCC Scroll Enhancer Loader.osax
- Start SafariFor more information, please refer to the following discussion on our forums:
http://support.agilewebsolutions.com/showthread.php?t=20069
Kidobtam a fent megjelölt hacket és BOOOM! - a probléma eltűnt.
Preface: mielőtt szerzői jogos hisztibe kezdene bárki - az alábbi post természetesen a saját, avi-ba konvertált, ám korábban legálisan vásárolt DVD gyűjteményem transzkódolásáról szól. Na ugorgyunk!
A tegnapi házimozis workflowból kimaradt az eFis bonus: a coder véremnek muszáj hozzátennie valamit a media centeres Nirvánához. Miután egy Perl-ben írt batch DVD konverter scriptet találtam még tegnap este a HandBrake-hez (az van linkelve az előző post-ba), agyaltam egy kicsit tovább, hogy hogy lehetne a kényelmet fokozni. Jöttek egyre vadabb ötletek, amikből készült egy röpke feature lista, aztán ern0 barátomtól jól eltanulva nagy lendülettel dobáltam ki a fancybbnél fancybb dolgokat belőle. Ennek az lett az eredménye, hogy három Excel makró tesztfutás közben megírtam egy scriptet ajándékba.
Elmesélem, hogy miket dobált elő az agyam implementálandó featureként. Az alapötlet az volt, hogy csinálok egy HandBrakeCLI-t hajtó shell scriptet, ami kihasználja a 0.9.4-es release soft subtitle opcióját és jól belegyógyítja a felirat{ok}at a transzkódolt mp4 fileokba. Ez volt a bázis, innen jött az így utólag szerintem tanulságos agymenés:
Miután ern0s vehemenciával kihúztam három izmos dolgot, elkezdtem agyalni, hogy azért valami okosság csak kellene egy rekurzív find híváson túl. Így jött az ötlet, hogy a script megkeresi, hogy van-e az avi file-ok mellé felirat és ha van, akkor bele is rámoltatja őket a készülő mp4-be.
Az algoritmus azt feltételezi, hogy a HandBrakeCLI számára használható subtitle file-ok .srt kiterjesztésűek, bázisnevük (=basename) megegyezik az avi file nevével, illetve opcionálisan a bázisnév kiegészülhetett {-en|-eng} és {-hu|-hun} tagokkal. Magyarul mondva egy példán keresztül az anyámtyúkja.avi-hoz az alábbi subtitle file-okat találja meg a script:
A basename végéhez csapott utótag alapján dönti el a script, hogy a felirat angol vagy magyar nyelvű-e és ennek megfelelően ISO-8859-1, illetve Windows-1250 codepage-dzsel renderelteti bele a készítendő mp4 file-ba. Amennyiben az avi basename-mel megegyező nevű (=utótag nélküli) feliratfile-t talál, azt magyarnak tekinti. Az alábbi scriptben csak három darab echo szerepel, hogy a transzkódolás megindítása nélkül kipróbálhasd a scriptet - ha transzkódoltatni akarsz, az echo-kat értelemszerűen dobáld ki.
A kis minimalista toolt fds Mester lektorálta, amiért ezúton is jár a hála és a köszönet. Have fun:
#!/bin/sh # # Handbrake gyipaci # lmdate 2010.07.05 # # Végigmegy rekurzívan egy könytáron és megkeresi a filmcim-hu{n}.srt, filmcim-en{g}.srt feliratfile-okat, # aztán ha igazán akarod, csinál neked soft subtitle-os mp4-eket az avi-jaidból. # # A script feltételezi, hogy ha csak egy, az avi file-lal megegyező nevű srt file-t talál, akkor abban magyar # subtitle lakik. # getsubs() { film="$*" base="${film%.*}" srt="$base".srt hu="$base"-hu.srt hun="$base"-hun.srt en="$base"-en.srt eng="$base"-eng.srt srthuc=0 srthu="" if [ -e "$srt" ]; then srthuc=1 srthu="$srt" elif [ -e "$hu" ]; then srthuc=1 srthu="$hu" elif [ -e "$hun" ]; then srthuc=1 srthu="$hun" fi srtenc=0 srten="" if [ -e "$en" ]; then srtenc=1 srten="$en" elif [ -e "$eng" ]; then srtenc=1 srten="$eng" fi let srtc=$srthuc+$srtenc srtfiles="" srtcodes="" srtlangs="" case $srtc in 0 ) ;; 1 ) if [ -s "$srthu" ]; then srtfiles="$srthu" srtcodes="WINDOWS-1250" srtlangs="hun" else srtfiles="$srten" srtcodes="ISO-8859-1" srtlangs="eng" fi ;; 2 ) srtfiles="$srthu","$srten" srtcodes="WINDOWS-1250,ISO-8859-1" srtlangs="hun,eng" ;; esac if [ $srtc -ne 0 ]; then echo Found $srtc subtitles: echo "$srtfiles" echo "$srtcodes" echo "$srtlangs" else echo No subtitles found. fi case $srtc in 0 ) # ezt az echo-t akkor dobd ki a /Applications/HandBrakeCLI elől, ha felirat nélkül is konvertálnál echo /Applications/HandBrakeCLI -v -i "$film" -o "$base".mp4 -e x264 -b 3000 -T -E faac -B 192 -R 48 -d slow -5 -8 medium ;; 1 ) # ezt az echo-t akkor dobd ki a /Applications/HandBrakeCLI elől, ha konvertálnád a home videód akkor is, ha csak a default magyar felirat van meg hozzá echo /Applications/HandBrakeCLI -v -i "$film" -o "$base".mp4 -e x264 -b 3000 -T -E faac -B 192 -R 48 -d slow -5 -8 medium --srt-file "$srtfiles" --srt-codeset "$srtcodes" --srt-lang "$srtlangs" ;; 2 ) # ezt az echo-t akkor dobd ki a /Applications/HandBrakeCLI elől, ha konvertálnád a home videód mind az angol, mind a magyar felirat birtokában a kétnyelvű családod számára echo /Applications/HandBrakeCLI -v -i "$film" -o "$base".mp4 -e x264 -b 3000 -T -E faac -B 192 -R 48 -d slow -5 -8 medium --srt-file "$srtfiles" --srt-codeset "$srtcodes" --srt-lang "$srtlangs" ;; esac return } find . -type f -iname '*.avi' -print0 | while read -rd $'\0' f do getsubs ${f} echo . done
Végül, de nem utolsósorban kiemelnék pár apró tuningot, mely a Mester nélkül nem került volna a scriptbe:
find . -type f -iname '*.avi' -print0 | while read -rd $'\0' f
A bash-ba intergrált read parancs -rd $'\0' paramétere az egyik szépség:
Szintén a Mestertől jött, hogy a magyar feliratfile-oknak ne ISO-8859-2 codepage-et definiáljak, hanem jobb lesz helyette a Windows-1250 (btw a használható codepage-ek listáját egy iconv -l mondja meg, ahogy arról a HandBrakeCLI -h is említést tesz). Ahogy ő indokolja:
ISO-8859-2-ben nincs pl „ ” vagy …
Jogos.
Ma Mac Mini alapú media centert pakolunk össze és körbejárjuk az általam kedvelt hozzávaló software komponenseket.
Nálam egy 2. generációs Mac Mini látja el az otthoni média server feladatát. Ezt a perfekt kis Mac-et az Apple épp az elmúlt hetekben tuningolta meg: unibody házba került, vaddisznó GPU-t forrasztottak az alaplapra, akár 8 GB RAM is belefér, 1.3-as, audio jelet is szállítani képes HDMI portot integráltak bele, de ami a legfontosabb: idle állapotában 10 Wattot eszik a kis dög! Sajnos az itthoni ára ijesztően magas (240kHUF), ellenben gyönyörűséges egy szerkezet:

Ha már szó esik az új Mac Miniről, nem állhatom meg, hogy ne osszak ki a gyártónak egy virtuális sallert a CEC kompatibilitás hiánya miatt 2010-ben - ezt nézzük meg kicsit belülről.
A HDMI három kommunikációs csatornát definiál: ezek sorjában a DDC, a TMDS és az opcionális CEC:
A CEC lényegében egy egy lábas soros busz a HDMI madzagban (a 13. láb az övé, a 17. láb pedig a GND-je), ami arra lenne hivatott, hogy a különböző gyártók készülékei egymás között ezen a buszon beszélgessenek és bármelyikük masterként a többit utasíthassa slave funkciók elvégzésére. Humánra fordítva ez kb. úgy hangzik, hogy a master HDMI eszközöd (jellemzően a TV) távirányítója az összes többi, a HDMI láncba kötött eszközt instruálja, azaz mondjuk a TV távirányítóján levő REC button utasíthatja a HDD rekordered, hogy kapcsoljon be, álljon be ugyanarra a csatornára, amit a TV-n nézel és kezdjen el rögzíteni. Vagy egy másik példa: legyen elég egy darab OFF button megnyomása ahhoz, hogy minden komponens (erősítő, HDD rekorder, TV) kikapcsoljon.
Csak hogy lásd, a mocsok gyártók milyen szinten sz@rnak a próbálkozásra, ami a XXI. században eljuttatná a világot a single remote Nirvánába, íme a lista a HDMI-CEC támogatás jelölésére a különböző márkák készülékein:
Klassz. Ezek után bármilyen eladót kérdezhetsz, ha nem kellően kocka, fogalma nem lesz arról, ki fia-borja az a HDMI-CEC.
A CEC dróton (13. láb) tehát bőszen küldhetnénk a Mac Miniről a TV felé a "bekapcsol + csatornát vált + hangerő beállít" commandokat, amint felébresztjük a házi almás media playerünket, de sajna az Apple-t ez egyelőre nem hatja meg. Ha a TV-n van soros port, akkor még mindig nekiállhatunk izmozni némi vezérléssel (egyszer majd lesz erről is post, ígérem), azonban amíg ez nincs, addig marad a Logitech Harmony univerzális távirányító, ami pöpecül képes vezérelni az általam is favorizált media center software-t, a Plexet is (HOWTO erre).
A korrekt média gyűjtemény összeállításához az alábbi alkalmazásokat állítjuk csatasorba:
Mindegyikről érdemes pár szót ejteni, nézzük őket szép sorjában!
RipIt

A RipIt rém egyszerű alkalmazás: app elindít, DVD bedug, némi pörgés azt már meg is kaptuk a másolatot a DVD-nkről. Az app jelenleg az 1.5.1-es verziónál jár, a fejlesztő srácok folyamatosan mennek utána a DVD gyártók által alkalmazott másolásvédelmi trükköknek és adják ki az újabbnál újabb release-eket (saját site-jukon áll, hogy ha találnak egy nem rippelhető DVD-t, abból beszereznek egyet és beépítik az alkalmazásukba a fixet, amint lehet).
A RipIt képes a DiscIdent DVD azonosító szolgáltatását használni ahhoz, hogy felismerje az épp rippelés alatt álló lemezt. A fejlesztők most kezdenek integrálni bele egy "Compress" névre keresztelt (egyelőre beta) feature-t, ami lényegében a DVD leghosszabb trackjének egy darab MP4 file-lá való konverzióját teszi lehetővé.
Azzal sincs gond, ha inkább a full DVD copy mellett maradnál és nem konvertálnád a lemezeidet, akkor megkérheted a RipIt-et, hogy csapja hozzá a DVD folderéhez a .dvdmedia kiterjesztést, amitől OS X alatt a folder tartalmát azonnal az óperenciás rendszerbe épített DVD Player nyitja meg.
A RipIt talán legnagyobb vonzereje, hogy a media centernek használt Mac-en futtatva "zsinórban" etetheted az alkalmazást a még be nem grabbelt lemezekkel: az esetek nagy százalékában (=amikor nincs gondja a rippelendő lemezzel) nem kell ránézned az UI-ra, mivel a kiköpött diszkről már látod, hogy adhatod neki az újabb korongot (nota bene: a RipIt a sok cimborám által gyűlölt Growl notifikációra is képes, ami meg akár értesít a munkagépen, ha kész a rip, sőt, push üzenetet küld a telefonomra a Prowl.app segítségével ha kérem, de ez majd egy másik workflow post témája lesz ;)).
FairMount
A FairMount egy olyan DVD mounter app, ami bármely DVD-t olvasó alkalmazás számára lehetővé teszi a lemez hibamentes olvasását. A FairMount fejlesztői készítik DVDRemaster nevű ripper alkalmazást is - ennek egy része a FairMount, mely a DVDRemasterrel ellentétben ingyenesen szedhető tőlük.
A FairMount-tal felcsatolt DVD lemez tartalmát tehát nagy esélyyel akár egy Finder copyval is lemásolhatod a HDD-re - onnantól pedig semmi nem állíthat meg, hogy meg ne etesd a Handbrake-kel.
Handbrake
A keresztségben a "Kézifék" nevet kapó app az igazi MP4 generátor harcos! Létezik neki remekül scriptelhető, CLI-only verziója is.
A HandbrakeCLI hajtására számos script született - ez például rekurzívan végigmegy az inputként specifikált folderben és az ott található összes VIDEO_TS mappa tartalmát könyörtelenül átzúzza mp4-be - cool.
A 0.9.4-es Handbrake kiadásban megjelent a várva várt soft subtitle támogatás, melynek segítségével kikapcsolható feliratokat (akár többet is) rendelhetünk a mozi mellé, ráadásul úgy, hogy a felirat jöhet egy külső SRT file-ból. Na, erre nemsokára varrok egy scriptet és közzé is teszem itt, csak türelem :)
Plex
A Plexről, mint a Mac-es media centerek királyáról már írtam bőven a Logitech Harmonys postban - ami mégis ide kívánkozik, az a Plex "scraper" funkciója, amivel a media librarynk metaadatait lebányássza a netről.
Nálam a filmek a /Volumes/video/film/a-film-imdb-syntax-szerinti-neve/filmcim.mp4 hierarchiában laknak. Ez a struktúra ideális a Plex scraper számára, aki szépen a háttérben gyűjtögeti a libraryban megjelent mozikhoz a metaadatot. A folder nevében az invalid folderneveket generáló karaktereket (ilyen OS X alatt a kettőspont) egyszerűen elhagyom - a Plex scraper így is megtalálja őket az adatbázisban:
Újmagyarul mondva a /Volumes/video folder a NAS-ról felmountolt AFP share. Igenám, csakhogy mind a Mac Mini, mind a NAS néha bealszanak, a NAS-t firmware update esetén újrabootolom (hosszabb áramszünet esetén az UPS teszi vele ugyanezt), azaz az AFP mount elmúlik. Így volt ez egészen Mac OS X Leopard-ig, amikor jött a megváltó automount! Az automount minden esetben megcsinálja a mountot, amint valamely alkalmazásunk az automount-ra jelölt folder tartalmához nyúlna. Nézzük meg, mi kell a fenti /Volumes/video AFP share automountjához.
Első lépésnek csinálj egy bejegyzést a /etc/fstab file-ban (sudo nano /etc/fstab):
mynas:/mozi /Volumes/video url automounted,url==afp://username:password@mynas/mozi 0 0
A fenti példára az alábbiak igazak:
Ezután már csak egy sudo automount -vc kell és már kész is a csoda: innentől kezdve az AFP share magától mountolódik, valahányszor szükséged van rá.
Air Video
Az Air Video volt az első streaming app, amire rátaláltam. Ez az alkalmazás arra képes, hogy egy tetszőleges Mac-en levő videókat iOS alapú eszközökre (iPod Touch, iPhone, iPad) streameljen. Amennyiben nem a natív H.264 kódolású videót kéred tőle, úgy képes a host gépet megkérve konvertálni, sőt, akár on-the-fly konverzióval azonnal rendelkezésre tudja bocsájtani a streamet.
Az Air Video iOS alkalmazása fizetős. A konverziót FFmpeg végzi, így a server oldal ingyen van. Az FFmpeg backendnek köszönhetően létezik belőle Linux oldali streaming server port, így háttérMac hiányában is remekül használható az app.
Rivet
A végére maradt a frissen felfedezett üdvöske, akinek a server oldala egyelőre még csak trial módban fut a munkaMac-en.
A Rivet-et ugyanaz a The Little App Factory készíti, aki az előbb már emlegetett RipIt alkalmazást. A Rivet az Air Videohoz képest zenét és képet is kiszolgál a saját iOS kliensének, ráadásul a képeket hajlandó a hagyományos folderen kívül iPhoto és/vagy Aperture libraryból is szedni - ez kell nekem!
Számtalanszor fordult már elő, hogy este megmutatnék pár napközben készült képet a családnak, amelyek a frissességükből fakadóan még nincsenek archiválva és csak a munkaMac-en laknak - erre a helyzetre tökéletes megoldást látszik kínálni a Rivet. Liszenszelés szempontjából a Rivet esetében fordított a helyzet: az iOS kliensek ingyenesek, míg a Mac-only server pénzes.
Air Video vs Rivet
Ha videóról van szó, még sokáig marad az Air Video a nyeregben: az UI egyszerűen átgondoltabb / átláthatóbb, a streaming hihetetlen zökkenésmentes. A Rivet esetében sajna ugyanezt nem tudom elmondani: a bufferelés lassú, a videóknál hajlamos valami torz aspect ratio-t használni és a kép minősége is hagy kívánnivalót maga után.
A Rivet ennek ellenére még marad: ezidáig ő az egyetlen eszköz, amivel a workMac-en lakó fotókat mutogathatom a famíliának.
A mai mese arról fog szólni, hogy hogyan készítem el egy-egy postba a szép felgörbült szélű thumbnailes képeket, mint amilyen ez a kovászos uborka itt alant:
A Mac recept
Hozzávalók:
A workflow
A dolog onnan indul, hogy a kívánt képet 1280x1280 max méretre cropolom, majd lementem jpg formátumban. Az így előkészített képet bedobom az Acorn-ba, majd lefuttatom a Framer fedőnevű JSTalk scriptet, aki előállít egy 500 pixel széles smallDoc.png thumbnail image-et a beledobott képből.
A két képet feltöltöm a WordPressbe, majd egy TextExpander makró segítségével berámolom a postba a thumbnailhez és az alatta levő image-hez szükséges HTML kódot.
Nézzük meg a JSTalk scriptet és a TextExpander snippetet, aztán jöhet a kovászos ubi receptje. Elsőként itt a script - ehhez túl sok közöm nincs, Gus csomagolta a JSTalk példák közé, nekem meg nagyon megtetszett az eredménye. Persze lehetne ez egyszer CSS3, de amíg nem, addig jó ez így is, hardcoded módon:
var acorn = [JSTalk application:"Acorn"]; // var doc = acorn.open_("/path/to/SomeImage.jpg"); var doc = [[acorn orderedDocuments] objectAtIndex:0]; // scale our image down [doc scaleImageToWidth:492]; var image = [[[NSImage alloc] initWithData:[doc dataRepresentationOfType:"public.png"]] autorelease]; // close the doc, since we've already got the data we need. [doc close]; var bitmap = [image bestRepresentationForDevice:nil]; var extent = NSMakeRect(0, 0, [bitmap pixelsWide], [bitmap pixelsHigh]); var xOffset = 5; var yOffset = 35; var curveHeight = 15; var imageYOffset = 10; var whiteBorderWidth = 4; var doubleBorderWidth = whiteBorderWidth * 2; var newSize = NSMakeSize(extent.size.width + (whiteBorderWidth * 2), extent.size.height + imageYOffset + (whiteBorderWidth * 2)); var newImage = [[[NSImage alloc] initWithSize:newSize] autorelease]; [newImage lockFocus]; [[NSGraphicsContext currentContext] saveGraphicsState]; var shadow = [[NSShadow alloc] init]; [shadow setShadowColor:[[NSColor blackColor] colorWithAlphaComponent:.6]]; var shadowOffset = NSMakeSize(0, -(yOffset + 5)); [shadow setShadowOffset:shadowOffset]; [shadow setShadowBlurRadius:5]; shadow.set() // make a curved path, at the bottom of our image. bezierPath = NSBezierPath.bezierPath(); [bezierPath moveToPoint:NSMakePoint(xOffset, 40 + yOffset)]; [bezierPath lineToPoint:NSMakePoint(extent.size.width - (xOffset) + doubleBorderWidth, 40 + yOffset)]; [bezierPath lineToPoint:NSMakePoint(extent.size.width - (xOffset) + doubleBorderWidth, 10 + yOffset)]; [bezierPath curveToPoint:NSMakePoint(newSize.width / 2, curveHeight + yOffset) controlPoint1:NSMakePoint(extent.size.width - (xOffset), 10 + yOffset) controlPoint2:NSMakePoint(newSize.width *.75, curveHeight + yOffset)]; [bezierPath curveToPoint:NSMakePoint(xOffset, 10 + yOffset) controlPoint1:NSMakePoint(newSize.width *.25, curveHeight + yOffset) controlPoint2:NSMakePoint(xOffset, 10 + yOffset)]; [bezierPath fill]; // get rid of our shadow [[NSGraphicsContext currentContext] restoreGraphicsState]; // draw a white border [[NSColor whiteColor] set]; [[NSBezierPath bezierPathWithRect:NSMakeRect(0, imageYOffset, newSize.width, extent.size.height + whiteBorderWidth * 2)] fill]; // draw our gray border around the white border [[NSColor lightGrayColor] set]; [[NSBezierPath bezierPathWithRect:NSMakeRect(.5, imageYOffset + .5 , newSize.width - 1, (extent.size.height - 1) + (whiteBorderWidth * 2))] stroke]; // NSImage takes into account dpi of the image. So we force it's size, to avoid small images. [image setSize: extent.size]; // draw our image [image drawAtPoint:NSMakePoint(whiteBorderWidth, imageYOffset + whiteBorderWidth) fromRect:NSMakeRect(0, 0, extent.size.width, extent.size.height) operation:NSCompositeCopy fraction:1]; [newImage unlockFocus]; var smallDoc = [[acorn sharedDocumentController] newDocumentWithImageData: [newImage TIFFRepresentation]]; [[smallDoc dataRepresentationOfType:"public.png"] writeToFile:"/Users/fns/Desktop/smallDoc.png"]; [smallDoc close];
Ez pedig a TextExpander snippet:
<a href="http://fns.csokolade.hu/files/%Y/%m/%clipboard.jpg"><img src="http://fns.csokolade.hu/files/%Y/%m/%clipboard.png" alt="" title="%clipboard"/></a>
A TextExpander snippetnél mindössze annyi dolgom van pluszban, hogy a kép nevét a clipboardba másoljam. Ez meg OS X alatt egy Enter a filenéven, majd ⌘C és Sanyi.
A kovászos ubi recept
Egy 5 literes befőttes üvegbe kb. 3 kiló uborka fér. Az üveget forró vízzel kimosom, majd elfektetem, hogy könnyebb legyen bele pakolni.
Az uborkák két végét levágom, hosszában 4-5-6 vágást ejtek rajtuk. Nekiállok úgy bepakolni az uborkákat, hogy függőlegesen álljanak majd az üvegben, mikor érleli őket a Nap.
Egy réteg uborka után egy nagy adag kaprot teszek be az üvegbe (persze csak akkor, ha épp nem Pappitonak készül a cucc :)), majd megint ubi és ez így megy addig, amíg meg nem telik a bödön.
Óvatosan felállítom az üveget, majd 2 púpos evőkanál sót teszek a tetejére. Felforralok 3-4 liter vizet és egy merőkanállal rákanalazom az uborkákra, amíg tele nem lesz az üveg.
A végén egy szelet kenyeret nyomok a tetejébe, letakarom az egészet egy tányérral és megy ki a Napra, 3-4 napig. Mikor a lé már zavaros, leszedem a kenyeret, de 1-2 napot adok még neki a melegen, hadd érjen össze.