What's wrong with ABC's 'Lost' broadcasts?

Freitag, 20. Februar 2009
Lot of people asked what's up with the new 'Lost' episodes lately, why don't they show up on the net in a timely fashion? Not so much a problem for the SD/XviD crowd as they and their encoders don't seem to care, but for the people interested in HD/x264 content.

Well, the problem is that ABC used some kind of alternating frame rate in their broadcast for the whole season to squeeze in more time for advertisements. This is not so much a problem in itself, as the viewer subscribing to the broadcast won't really notice if he doesn't keep track of advertisement time. But it is a problem for distribution on the net. Here's why:

Source material for most movies and series nowadays is 24 FPS. That gets pulled down 3:2 for TV to broadcast the video in 60 Hz, that means 2 frames get broadcasted as 3 frames by interlacing them (Wikipedia has the complete explanation). ABC now cuts away some of those "dupe" frames during some scenes during transmission to save time. This won't get noticed in 60 Hz/30 FPS, as some of these frames exist as dupes anyways. Just speeds up the video a bit.

Now for encoding this for distribution on the internet the pulldown has to be reversed to get 24 FPS again to not waste precious space/bitrate on dupe content (actually it's 24/1.001 FPS, since audio is still slowed down and encoders prefer not to touch it). Unfortunately the programs that do this are quite "dumb" and can't recognize where ABC has meddled with its content.

After application of this "reverse pulldown" the result should be a steady stream of unique progressive pictures (again, Wikipedia knows more about it). Since there are fewer frames aired then there should be the reverse pull down algorithm skips over more frames then he should be in turn, resulting in choppy video. This wouldn't be a problem if ABC somehow manipulated the whole broadcast the same way, stupid reverse pulldown algorithms could be adapted to that. Unfortunately they only use that in some scenes, not all, so it's hard avoid.

SkyHD broadcasts that get released a little later don't suffer from that problem, that's why everyone is seeing the really "good" encodes so late. Just this time one of the big groups seems to have decided not to bother with the bad ones anymore, too. As always smaller groups have jumped in to fill the gap, but this took some time.

android xbmc remote control - proof of concept

Sonntag, 8. Februar 2009
Seit längerem spiele ich mit dem Gedanken eine Fernbedienung für xbmc zu basteln. xbmc ist ein ursprünglich für die XBox programmiertes Media Center das inzwischen auch auf Linux, MacOS und Windows portiert wurde. Um Videos zu verwalten ist das Programm bisher das beste was ich finden konnte, vor allem die Fähigkeit Filme aus komprimierten Archiven abzuspielen ist unglaublich praktisch und zeitsparend. Insgesamt ist das Programm zwar noch etwas buggy, der Konkurrenz aber trotzdem schon um längen voraus.

Es gibt eine Lösung xbmc mit einem J2ME-fähigem Handy fernzusteuern, das benötigt jedoch Bluetooth und jedesmal daran zu denken das auf beiden Geräten einzuschalten finde ich ehrlich gesagt etwas umständlich. WLAN andererseits läuft, falls vorhanden, normalerweise überall 24/7, deshalb halte ich das für die perfekte Lösung um mit xbmc zu kommunizieren. Letzte Woche hat dann Spreeblick bekannt gegeben ein G1 verlosen zu wollen, die perfekte Gelegenheit dieses Projekt zu beginnen. Prinzipiell wollte ich das schon seit längerem machen, nur eben auf meinem Nokia Communicator 9300i.

Am Freitag habe ich mich dann endlich hingesetzt und angefangen mir zu überlegen wie man eine solche Fernsteuerung am einfachsten realisieren kann. Meinen Fortschritt habe ich getwittert. Das Resultat ist eigentlich nicht weiter Bemerkenswert, im Prinzip ist das nur der Beispielcode aus dem xbmc source. Da ich vorher nie irgendwas in Java programmiert habe und auch Eclipse nur vom Namen her kannte bin ich trotzdem ziemlich stolz darauf das ganze auf dem Android Emulator aus dem Android SDK zum laufen gebracht zu haben.

Das Programm selbst macht nicht sehr viel, es verbindet sich mit xbmc, schickt eine Nachricht, schickt einige Escape Signale, schickt noch eine Nachricht und kappt die Verbindung wieder. Es gibt auf dem Android Emulator weiter keine ein/ausgabe. Um das Programm zu starten wird Eclipse und der Android SDK benötigt (Installationsanleitung), die Projektdateien entpackt man am besten in das workspace Verzeichnis, wovon es via "File" -> "Import" -> "Existing Projects into Workspace" -> "workspace" als root directory -> "AndroidXBMC" auswählen importiert werden kann. Gestartet werden kann es dann mit "Run", xbmc muss vorher geladen sein.

Falls ich das G1 nicht gewinnen sollte ist das hoffentlich wenigstens ein Startpunkt für andere die eine solche Fernbedienung programmieren wollen. Wäre allerdings toll, wenn ich selbst weitermachen könnte.

Nachtrag:
War spät gestern... hätte noch erwähnen sollen, dass das Programm so natürlich nicht auf einem echten Android Handy laufen kann. Dazu fehlt die Signatur. Und wie gesagt, auf dem Android Emulator selbst findet kein i/o statt. Das einzige Output das es gibt geht über das Netzwerk. Die Nachrichten im xbmc über die Verbindung sind das einzige sichtbare Ausgabe, das ganze sieht dann so aus (unten rechts im xbmc Fenster - das Fenster selbst sieht immer so zerstört aus, keine Ahnung woran das liegt).