ICS on the Sam­sung Galaxy Tab 10.1

Last week I had a look if there are some news for an of­fi­cial up­date of the Galaxy Tab 10.1 to ICS. To my sur­prise there is one at least in Italy. The one I found to down­load was marked more or less for the European mar­ket. Well… that was good enough for me and the night from Fri­day to Sat­urday I have spend to up­date the Tab by hand (un­for­tu­nately this in­cludes a fact­ory re­set, no smooth mi­gra­tion from an old ver­sion, but at least I still have root ac­cess).

What I no­ticed so far:

  • OpenGL ES speed im­proved from 4.2 to 6.6 FPS.
  • I had some lock-​ups so far, I do not know if this may be re­lated to some re­stored data (app data and e.g. Bluetooth/​WLAN con­fig re­stored with Ti­tani­um­Backup) or to bugs (Dalvik cache and cache par­ti­tion where clean, fact­ory re­set was done too pri­or to restor­ing from the backup). I had to press the power but­ton for some seconds to ini­ti­ate a re­boot. Most of the time it helped to wait a minute be­fore en­ter­ing the PIN for the SIM. One time it did not help at all, the only way to get it work­ing was to take my WLAN Ac­cess Point (AP) off­line, start the Tab, enter the PIN, and to re­start the AP. At that point I had GPS and WLAN in the Tab ac­tiv­ated, in the lock-​ups be­fore I did not have GPS act­ive. I had some­thing sim­il­ar like this with my Nex­us S when it got ICS, some­how this re­solved it­self. Up­date 2012-​08-​14: I googled a bit, there was a bug in ICS 4.0.3 re­lated to WLAN, but I have 4.0.4 on the Tab, so this may not be this. I also got the freeze without WLAN but with the mo­bile data con­nec­tion act­ive. 2nd up­date 2012-​08-​14: If I dis­able ac­count syncing with the mo­bile data con­nec­tion it does not freeze. I have not yet tried this with the WLAN con­nec­tion. Up­date 2012-​08-​16: The syn­chron­iz­a­tion of the cal­en­dar data caused the prob­lem. De­let­ing all data for any app with cal­en­dar in the name and re-​syncing fixed the prob­lem. No freeze since I did this yes­ter­day.
  • When I open/​close a folder (much missed fea­ture in An­droid 3.x), the Tab speaks with me (some­thing like “Folder XXX opened” in the con­figured lan­guage… that is a bit an­noy­ing).
  • I like the de­fault back­ground im­age.
  • Up­date 2012-​08-​14: The bat­tery icon does stay green even when the bat­tery is nearly empty. 🙁

I was not able to test the Email APP yet, I am wait­ing for a warranty-​replacement of the PSU of my serv­er at home (Murphy’s law: Your PSU will break when you just star­ted a big renov­a­tion of your kit­chen and do not have time to take care about it, and when you get time a lot of people from the PSU-​manufacturer which take care about warranty-​replacements are in hol­i­day).

I also need to check the mo­bile data con­nectiv­ity (qual­ity and speed), but I would ex­pect that it is not worse than be­fore. Up­date 2012-​08-​14: The down­load speed test shows sim­il­ar res­ults than be­fore, the up­load speed test is slower, but this may be the mo­bile net­work here where I tested. At least I can con­firm that it works, mod­ulo the prob­lem of the freezes de­scribed above.

Book re­view: FreeBSD Device Drivers

In mid-​April a wo­man from the mar­ket­ing de­part­ment of No Starch Press con­tac­ted me and asked if I am in­ter­ested to do a pub­lic re­view of the FreeBSD Device Drivers book by Joseph Kong (no link to a book shop, go and have a look in your pre­ferred one). Just this simple ques­tion, no strings at­tached.

I had my nose in some device drivers in the past, but I nev­er wrote one, and nev­er had a look at the big pic­ture. I was in­ter­ested to know how everything fits to­geth­er, so this made me a good vic­tim for a re­view (novice enough to learn some­thing new and to have a look if enough is ex­plained, and ex­per­i­enced enough to un­der­stand what is go­ing on in the FreeBSD ker­nel).

Some minutes after I agreed to re­view it (but with a little no­tice that I do not know how long I need to re­view it), I had the PDF ver­sion of the book. That was faster than I ex­pec­ted (maybe I am too old-​school and used to have pa­per ver­sions of books in my hands).

Let the re­view be­gin… but bear with me, this is the first time I do a real pub­lic re­view of a book (in­stead of a tech­nic­al re­view for an au­thor). And as this is my very own per­son­al opin­ion, I will not al­low com­ments here. This page is all about my opin­ion while read­ing the book, ques­tions I have while read­ing the book shall serve as a hint about the qual­ity of the book and they should be answered in the book, not here.

In short, the book is not per­fect, but it is a good book. There is room for im­prove­ment, but on a very high level. If you want to write a device driver for FreeBSD, this book is a must. I sug­gest to read it com­pletely, even chapters which do not be­long to the type of driver you want to write (spe­cially the case stud­ies of real drivers). The reas­on is that each chapter has some notes which may not only ap­ply to the chapter in ques­tion, but to all kinds of device drivers. The long re­view fol­lows now.

The first chapter is titled “Build­ing and run­ning mod­ules”. The au­thor be­gins with de­scrip­tion of the usu­al device driver types (NIC driver, pseudo-​device, …) and how they can be ad­ded to the ker­nel (stat­ic­ally linked in or as a mod­ule). The first code ex­ample is a small and easy ker­nel mod­ule, so that we do not have to re­boot the sys­tem we use to de­vel­op a driver (ex­cept we make a fault dur­ing driver de­vel­op­ment which causes the ma­chine to pan­ic or hang). Every part of the ex­ample is well ex­plained. This is fol­lowed by an over­view about char­ac­ter devices (e.g. disks) and a simple character-​device driver (so far a pseudo-​device, as we do not have real hard­ware we ac­cess) which is not only as-​well ex­plained as the module-​example, but there is also a note where the code was sim­pli­fied and what should be done in­stead.

After read­ing this chapter you should be able to write your own ker­nel mod­ule in 5 minutes (well, after 5 minutes it will not be able to do a lot – just a “hello world” – but at least you can already load/​unload/​execute some code into/​from/​in the ker­nel).

I have not tried any ex­ample my­self, but I com­piled a lot of mod­ules and drivers I mod­i­fied in the past and re­mem­ber to have seen the de­scribed parts.

The second chapter ex­plains how to al­loc­ate and free memory in the ker­nel. There is the pos­sib­il­ity to al­loc­ate maybe-​contiguous memory (the nor­mal case, when your hard­ware does not do DMA or does not have the re­quire­ment that the memory re­gion it makes DMA from/​too needs to be con­tigu­ous), and really con­tigu­ous. For the size ar­gu­ment of the free­ing of the the con­tigu­ous memory there is the sen­tence “Gen­er­ally, size should be equal the amount al­loc­ated.”. Im­me­di­ately I wanted to know what hap­pens if you spe­cify a dif­fer­ent size (as a non-​native eng­lish speak­er I un­der­stand this sen­tence in a way that I am al­lowed to spe­cify a dif­fer­ent size and as such are able to free only parts of the al­loc­ated memory). Un­for­tu­nately this is not answered. I had a look in­to the source, the ker­nel frees memory pages, so the size ar­gu­ment (and ad­dr ar­gu­ment) will be roun­ded to in­clude a full page. This means the­or­et­ic­ally I am able to free parts of the al­loc­ated memory, but this is a source-​maintenance night­mare (needs know­ledge about the ma­chine spe­cif­ic page bound­ar­ies and you need to make sure that you do the ab­so­lutely cor­rect size cal­cu­la­tions).  To me this looks more like as long as nobody is point­ing a gun at my head and tells me to use a dif­fer­ent size, spe­cify­ing the same size as made dur­ing the al­loc­a­tion of this memory re­gion is the way to go.

After read­ing this chapter you should know how to kill the sys­tem by al­loc­at­ing all the RAM in the ker­nel.

Again, I did not try to com­pile the ex­amples in this chapter, but the dif­fer­ence of the memory al­loc­a­tion in the ker­nel com­pared with memory al­loc­a­tion in the user­land is not that big.

The third chapter ex­plains the device com­mu­nic­a­tion and con­trol in­ter­faces (ioctl/​sysctl) of a driver. The ioctl part teached me some parts I al­ways wanted to know when I touched some ioctls, but nev­er bothered to find out be­fore. Un­for­tu­nately this makes me a little bit nervous about the way ioctls are handled in the FreeBSD linuxu­lat­or, but this is not ur­gent ATM (and can prob­ably be handled by a com­mend in the right place). The sy­sctl part takes a little bit longer to fol­low through, but there is also more to learn about it. If you just modi­fy an ex­ist­ing driver with an ex­ist­ing sy­sctl in­ter­face, it prob­ably just comes down to copy&paste with little modi­fic­a­tions, but if you need to make more com­plex changes or want to add a sy­sctl in­ter­face to a driver, this part of the book is a good way to un­der­stand what is pos­sible and how everything fits to­geth­er. Per­son­ally I would have wished for a more de­tailed guide when to pick the ioctl in­ter­face and when the sy­sctl in­ter­face than what was writ­ten in the con­clu­sion of the chapter, but it is prob­ably not that easy to come up with a good list which fits most drivers.

After read­ing this chapter you should be able to get data in and out of the ker­nel in 10 minutes.

As be­fore, I did not com­pile the ex­amples in this chapter. I already ad­ded ioctls and sy­sctls in vari­ous places in the FreeBSD ker­nel.

Chapter 4 is about thread syn­chron­iz­a­tion – mu­texes, shared/​exclusive locks, reader/​writer locks and con­di­tion vari­ables. For me this chapter is not as good as the pre­vi­ous ones. While I got a good ex­plan­a­tion of everything, I missed a nice over­view table which com­pares the vari­ous meth­ods of thread syn­chron­iz­a­tion. Brendan Gregg did a nice table to give an over­view of DTrace vari­able types and when to use them. Some­thing like this would have been nice in this chapter too. Apart from this I got all the info I need (but hey, I already wrote a NFS cli­ent for an ex­per­i­ment­al com­puter with more than 200000 CPUs in 1998, so I’m fa­mil­i­ar with such syn­chron­iz­a­tion prim­it­ives).

Delayed ex­e­cu­tion is ex­plained in chapter 5. Most of the in­form­a­tion presen­ted there was new to me. While there where not much ex­amples presen­ted (there will be some in a later chapter), I got a good over­view about what ex­ists. This time there was even an over­view when to use which type of delayed ex­e­cu­tion in­fra­struc­ture. I would have pre­ferred to have this over­view in the be­gin­ning of the chapter, but that is maybe some kind of per­son­al pref­er­ence.

In chapter 6 a com­plete device driver is dis­sec­ted. It is the vir­tu­al null mo­dem ter­min­al driver. The chapter provides real-​world ex­amples of event-​handlers, cal­louts and taskqueues which where not demon­strated in chapter five. At the same time the chapter serves as a de­scrip­tion of the func­tions a TTY driver needs to have.

Auto­mated device de­tec­tion with New­bus and the cor­res­pond­ing re­source al­loc­a­tion (I/​O ports, device memory and in­ter­rupts) are ex­plained in chapter 7. It is easy… if you have a real device to play with. Un­for­tu­nately the chapter missed a para­graph or two about the sus­pend and re­sume meth­ods. If you think about it, it is not hard to come up with what they are sup­posed to do, but a little ex­pli­cit de­scrip­tion of what they shall do, in what state the hard­ware should be put and what to as­sume when be­ing called would have been nice.

Chapter 8 is about in­ter­rupts. It is easy to add an in­ter­rupt hand­ler (or to re­move one), the hard part is to gen­er­ate an in­ter­rupt. The ex­ample code uses the par­al­lel port, and the chapter also con­tains a little ex­plan­a­tion how to gen­er­ate an in­ter­rupt… if you are not afraid to touch real hard­ware (the par­al­lel port) with a res­ist­or.

In chapter 9 the lpt(4) driver is ex­plained, as most of the top­ics dis­cussed so far are used in­side. The ex­plan­a­tion how everything is used is good, but what I miss some­times is why they are used. The most prom­in­ent (and only) ex­ample here for me is why are cal­louts used to catch stray in­ter­rupts? That cal­louts are a good way of hand­ling this is clear to me, the big ques­tion is why can there be stray in­ter­rupts. Can this hap­pen only for the par­al­lel port (re­spect­ively a lim­ited amount of devices), or does every driver for real in­ter­rupt driv­en hard­ware need to come with some­thing like this? I as­sume this is some­thing spe­cif­ic to the device, but a little ex­plan­a­tion re­gard­ing this would have been nice.

Ac­cess­ing I/​O ports and I/​O memory for devices are ex­plained in chapter 10 based upon a driver for a LED device (turn on and off 2 LEDs on an ISA bus). All the func­tions to read and write data are well ex­plained, just the part about the memory bar­ri­er is a little bit short. It is not clear why the CPU re­order­ing of memory ac­cesses mat­ter to what looks like func­tion calls. Those func­tion calls may be mac­ros, but this is not ex­plained in the text. Some little ex­amples when to use the bar­ri­ers in­stead of an ab­stract de­scrip­tion would also have been nice at this point.

Chapter 11 is sim­il­ar to chapter 10, just that a PCI bus driver is dis­cussed in­stead of an ISA bus driver. The dif­fer­ences are not that big, but im­port­ant.

In chapter 12 it is ex­plained how to do DMA in a driver. This part is not easy to un­der­stand. I would have wanted to have more ex­amples and ex­plan­a­tions of the DMA tag and DMA map parts. I am also sur­prised to see dif­fer­ent sup­por­ted ar­chi­tec­tures for the flags BUS_​DMA_​COHERENT and BUS_​DMA_​NOCACHE for dif­fer­ent func­tions. Either this means FreeBSD is not co­her­ent in those parts, or it is a bug in the book, or it is sup­posed to be like this and the reas­ons are not ex­plained in the book. As there is no ex­pli­cit note about this, it prob­ably leads to con­fu­sion of read­ers which pay enough at­ten­tion here. It would also have been nice to have an ex­plan­a­tion when to use those flags which are only im­ple­men­ted on a sub­set of the ar­chi­tec­tures FreeBSD sup­ports. Any­way, the ex­plan­a­tions give enough in­form­a­tion to un­der­stand what is go­ing on and to be able to have a look at oth­er device drivers for real-​live ex­amples and to get a deep­er un­der­stand­ing of this top­ic.

Disk drivers and block I/​O (bio) re­quests are de­scribed in chapter 13. With this chapter I have a little prob­lem. The au­thor used the word “un­defined” in sev­er­al places where I as a non-​native speak­er would have used “not set” or “set to 0”. The word “un­defined” im­plies for me that there may be garbage in­side, where­as from a tech­nic­al point of view I can not ima­gine that some ran­dom value in those places would have the de­sired res­ult. In my opin­ion each such place is ob­vi­ous, so I do not ex­pect that an ex­per­i­enced pro­gram­mer would lose time/​hairs/​sanity over it, but in­ex­per­i­enced pro­gram­mers which try to as­semble the cor­res­pond­ing struc­tures on the (un­ini­tial­ized) heap (for whatever reas­on), may struggle with this.

Chapter 14 is about the CAM lay­er. While the pre­vi­ous chapter showed how to write a driver for a disk device, chapter 14 gave an over­view about how to an HBA to the CAM lay­er. It is just an over­view, it looks like CAM needs a book on its own to be fully de­scribed. The simple (and most im­port­ant) cases are de­scribed, with the hardware-​specific parts be­ing an ex­er­cise for the per­son writ­ing the device driver. I have the im­pres­sion it gives enough de­tails to let someone with hard­ware (or pro­tocol), and more im­port­antly doc­u­ment­a­tion for this device, start writ­ing a driver.

It would have been nice if chapter 13 and 14 would have had a little schem­at­ic which de­scribes at which level of the kernel-​subsystems the cor­res­pond­ing driver sits. And while I am at it, a schem­at­ic with all the driver com­pon­ents dis­cussed in this book at the be­gin­ning as an over­view, or in the end as an an­nex, would be great too.

An over­view of USB drivers is giv­en in chapter 15 with the USB print­er driver as an ex­ample for the ex­plan­a­tion of the USB driver in­ter­faces. If USB would not be as com­plex as it is, it would be a nice chapter to start driver-​writing ex­per­i­ments (due to the avail­ab­il­ity of vari­ous USB devices). Well… bad luck for curi­ous people. BTW, the au­thor gives point­ers to the of­fi­cial USB docs, so if you are really curi­ous, feel free to go ahead. 🙂

Chapter 16 is the first part about net­work drivers. It deals with ifnet (e.g. stuff needed for if­con­fig), if­me­dia (sim­pli­fied: which kind of cable and speed is sup­por­ted), mbufs and MSI(-X). As in oth­er chapters be­fore, a little over­view and a little pic­ture in the be­gin­ning would have been nice.

Fi­nally, in chapter 17, the pack­et re­cep­tion and trans­mis­sion of net­work drivers is de­scribed. Large ex­ample code is broken up in­to sev­er­al pieces here, for more easy dis­cus­sion of re­lated in­form­a­tion.

One thing I miss after reach­ing the end of the book is a dis­cus­sion of sound drivers. And this is surely not the only type of drivers which is not dis­cussed, I can come up with crypto, firewire, gpio, watch­dog, smb and iic devices with­in a few seconds. While I think that it is much more easy to un­der­stand all those drivers now after read­ing the book, it would have been nice to have at least a little over­view of oth­er driver types and maybe even a short de­scrip­tion of their driver meth­ods.

Con­clu­sion: As I wrote already in the be­gin­ning, the book is not per­fect, but it is good. While I have not writ­ten a device driver for FreeBSD, the book provided enough in­sight to be able to write one and to un­der­stand ex­ist­ing drivers. I really hope there will be a second edi­tion which ad­dresses the minor is­sues I had while read­ing it to make it a per­fect book.

Email app from An­droid 3.1 in An­droid 3.2?

As pre­vi­ously re­por­ted, I tried the up­date to An­droid 3.2 on my Tab and was not happy about the new EMail app. At the week­end I had a little bit of time, so I tried to get the Email.apk from An­droid 3.1 in­to An­droid 3.2.

Long story short, I failed.

Ti­tani­um­Backup PRO was restor­ing or hours (the op­tion to mi­grate from a dif­fer­ent ROM ver­sion was en­abled) un­til I killed the app, and it did not get any­where (I just emailed their sup­port if I did some­thing com­pletely stu­pid, or of this is a bug in TB). And a copy by hand in­to /​system/​apps did not work (app fails to start).

Ideas wel­come.

Sam­sung HMX-​H200 cam­cord­er

My wife de­cided that we need a cam­cord­er. As I am a good hus­band, I do not com­plain (she pays 😀 ).

There was an of­fer in a su­per mar­ket nearby. Not as low as you can find in the in­ter­net, but if there is a prob­lem, it is much more easy to com­plain. For some­thing like this, I/​we prefer this and am-​are OK to spend a little bit more money for this con­veni­ence.

This cam­cord­er is re­cord­ing to SDHC cards. Such cards have a speed rat­ing, and you need to take some min–speed one, to be able to re­cord videos with a cam­cord­er. Un­for­tu­nately Sam­sung does not list the speed rat­ing some­where. I searched on the Sam­sung site in the spe­cific­a­tions and in the FAQ. Noth­ing. After a little bit of googling I at least found a re­view where the re­cord­ing time for spe­cif­ic card-​sizes where lis­ted.

So I took the card-​size in MB, di­vided it by the re­cord­ing time in seconds, and got the data trans­fer rate per second for the spe­cified res­ol­u­tions. The 1080i res­ol­u­tion has the highest trans­fer rate and as such it is the most in­ter­est­ing one to de­cide what kind of card one needs.

The highest trans­fer rate seems to be less than 2.2 MB/​s, so a class 4 SDHC card should be enough.

Sony Bravia and HD videos (via DLNA)

I made some more tests which video res­ol­u­tions my TV ac­cepts via DLNA. While I was look­ing be­fore a SD res­ol­u­tions, this time I took care about some HD res­ol­u­tions.

As the Sin­tel video in the 1024×436 res­ol­u­tion did not play, I tried to reen­code it to 1024×720 (for the en­abled x264 op­tions see be­low). This did not work either. After that I went to the of­fi­cial res­ol­u­tion of 1280×720, and this works. Ini­tially this video was en­coded as High@L3.1, but with this the TV pro­duced some ar­ti­facts on play­back. After chan­ging this to High@L4.0 (simply by re­mux­ing in­stead of reen­cod­ing), the play­back was fine (warn­ing: in­creas­ing the H.264 level is OK, de­creas­ing it if the video does not com­ply to the lowered level, may cause prob­lems). I miss a set­ting in avidemux for the level, it would be nice if there would be the pos­sib­il­ity to set it.

I also tested if the 1280×544 ver­sion of the Sin­tel video plays fine on the TV or not. It does not play fine, so there is prob­ably a hard re­quire­ment on the com­plete res­ol­u­tion for HD video.

While do­ing this I no­ticed that ts­Mux­eR is trun­cat­ing the au­dio, in­stead of the 6 chan­nel au­dio it was be­fore, the re­muxed file has only two chan­nels.

As I did not want to al­ways go through all the set­tings to enter what I want, I made a little avidemux-​script to setup (ECMA script + xml) everything for me. This was easy, I just took an ex­ist­ing one (the Sony PSP one) as a base and changed the en­cod­ing op­tions and the tar­get con­tain­er (un­luck­ily avidemux 2.5.4 does not sup­port H.264 in MPEG-​TS yet, so I have to use a MP4 con­tain­er and re­mux it in­to the MPEG-​TS stream af­ter­wards).

The op­tions I used for the x264-​reencoding are –8x8dct –ana­lyse all –mixed-​refs –bime –weightb –subme 9 –b-​rdo –ref 4 –b-​adapt 2 –bframes 4 –dir­ect auto –me umh (this in­cludes b-​pyramid, for which there are re­ports that it does not work).

Stream­ing video to a Sony Bravia (via DLNA)

I have a Sony Bravia TV with a net­work (eth­er­net) con­nec­tion. Let­ting aside the fact that he is in an­oth­er sub­net than my NAS and as such I can not use a DLNA (UPnP-​AV) serv­er (it is us­ing mul­tic­ast and the Simple Ser­vice Dis­cov­ery Pro­tocol (SSDP) which is not tra­vers­ing sub­nets in the WLAN-​LAN-​ADSL-​router I use), there is no good ex­plan­a­tion from Sony what I can feed to the TV.

When search­ing the net I can find some ob­scure sug­ges­tions and de­scrip­tions, but not all of them work for all people which try them. So it seems I have to re­search this my­self. Luck­ily my router has a build-​in UPnP-​AV serv­er which I can use to play around (the file size is lim­ited to the size of the USB memory stick I have con­nec­ted to the router, as he can not stream con­tent which is avail­able in a NAS in the net­work).

Sony tells the TV is able to re­ceive MPEG2 TS and PS con­tain­ers. MPEG2 PS is more or less what you have on DVD. It is able to play SD and HD con­tent from the PS con­tain­er, and the video format needs to be MPEG2. They do not ex­plain what SD or HD means in this con­text (the val­id res­ol­u­tions), and they do not tell what kind of au­dio is al­lowed.

For the MPEG2 TS con­tain­er they ad­di­tion­ally al­low H.264 video, and they spe­cify EU, EU-​T and EU-​ISO as sup­por­ted in this case. Again, they do not ex­plain what those EU* parts are sup­posed to mean.

For the un­spe­cified au­dio I as­sume this means AC-​3, AAC and MPEG Au­dio Lay­er 2 (some people use MP2 to de­scribe this au­dio format). I suc­cess­fully tested AAC and AC-​3, and I have read that MP2 works too. Based upon my ex­per­i­ences with the video part (more be­low) I as­sume the sampling rate and bitwidth mat­ter. So far I tried with 48 kHz and 16 bit per chan­nel.

For the EU* parts I have not found any trust­worthy ref­er­ence what this could mean, but it looks this refers to some as­pects of DVB/DVB-T/DVB-S(2) as it is used in Europe. I guess this is a bit linked with val­id res­ol­u­tions the TV is able to handle.

For the video part I have found mixed re­ports. From hat I have read in the Wiki­pe­dia page of the H.264 video format, I as­sumed the fail­ures are re­lated to a wrong res­ol­u­tion and maybe the fact that some parts of the video do not con­form to spe­cif­ic “levels” of the H.264 format. Some tell you are not al­lowed to use more than X ref­er­ence frames, some tell you can not use ad­vanced fea­ture Y.

The first test I did was to take the Sin­tel video from Blender. I down­loaded the MP4 ver­sion and re­muxed it in­to a MPEG2-​TS con­tain­er (I used ts­Mux­eR to do this). The TV was able to play the AAC au­dio, but it did not show the video. When I look at the video prop­er­ties, I see that it has a res­ol­u­tion of 1280×544 at 24 FPS. For H.264 videos which use the “High” pro­file and are com­pat­ible up to level 4.1, I do not see this res­ol­u­tion lis­ted as val­id in the Wiki­pe­dia page. Val­id res­ol­u­tions are 1280×720 at 30, 60 and 68.3 FPS, and 1280×1024 at 42.2 FPS. This could ex­plain why it is not work­ing.

As a second test I took a video res­ized it to 624×256 (I did not pay much at­ten­tion to the scale in the pro­gram I used to test this, I just hoped it takes a good one, now that I try to sum­mar­ize what I in­vest­ig­ated so far, I see that this size is not one of the val­id sizes lis­ted in the levels for H.264) at 23.976 FPS and reen­coded it with the de­fault op­tions of the x264 en­coder. The res­ult­ing video played just fine on the TV.

My third test was to en­code a res­ized (from 640×272 to 640×480) video at 23.976 FPS with weighted, upto 4 ad­apt­ive B-​frames, mixed ref­er­ences, 4 ref­er­ence frames, and some oth­er op­tions (this in­cludes B-​pyramid, which seems to be en­abled by de­fault). And again, the res­ult­ing video played just fine (des­pite the fact that I found com­ments in the net which sug­gest that B-​pyramid needs to be dis­abled…).

I still have to test some HD sizes, but it looks like one key as­pect for com­pat­ib­il­ity is that the video is en­coded with the right res­ol­u­tion (I have to ad­mit, I do not really know what this means, as one video had a res­ol­u­tion which was dif­fer­ent from what the val­id sizes for the H.264 levels are) and com­plies to only level 4.1 (or 4) and be­low (ba­sic­ally this means to obey some bitrate lim­it­a­tions and the num­ber of max. ref­er­ence frames for the giv­en res­ol­u­tion). The 23.976 FPS I men­tioned above are not lis­ted as one of the val­id FPS in the levels for H.264, so I do not think the FPS have to strictly con­form to what is spe­cified for the levels. It looks more this is just an up­per lim­it so that the video could also use some lower FPS.

So far I took the sin­tel video and ad­ded some black bor­ders on top and be­low to get to the 1080×720 res­ol­u­tion. I used avidemux 2.5.4 for this. The ver­sion I tried can only pro­duce a MP4 con­tain­er with this video/​audio com­bin­a­tion, and my hope was to re­mux it with ts­Mux­eR to a MPEG2-​TS, but ts­Mux­eR does not find a val­id video or au­dio stream in­side the MP4 con­tain­er. I am still search­ing for a pro­gram which is able to re­mux the res­ult­ing MP4 in­to a MPEG2-​TS. I found a tool which ex­tracts the streams from the MP4 con­tain­er, but the only free MPEG2-​TS mux­er seems to be ts­Mux­eR, which I was not able to con­vince to mux the two streams in­to a MPEG2-​TS file. It seems I have either to wait un­til avidemux knows how to gen­er­ate MPEG2-​TS streams with H.264 and AAC, or un­til it gen­er­ates a MP4 con­tain­er with H.264 and AAC which ts­Mux­eR is able to handle.

What I also want to test is, if I can use the open-​gop op­tions (either in “nor­mal” or in “bluray” mode), but I did not took the time to test this.

The only think I can tell defin­it­ively ATM is, that des­pite to all the in­form­a­tion I found in the net about this, noth­ing can be told about the hard re­quire­ments ex­cept, that the video en­cod­ing can not ex­ceed level 4.1 (or 4), be­cause so far no hard­ware de­coder chip seems to sup­port a high­er level. It seems I can use more or less all op­tions avail­able for the H.264 en­cod­ing, and the res­ol­u­tion and FPS does not seem to mat­ter that much. I looks more that you have to find a ver­sion of an H.264 en­coder which works for you, and after that you can more or less do what you want.

In­tel­li­gent elec­tri­city meters? More be­ne­fi­cial things ex­ist (but need im­prove­ment).

In Ger­many you need to in­stall an in­tel­li­gent elec­tri­city meter if you make lar­ger changes to the elec­tri­city in­stall­a­tion in your house (or if you build a new one). At first this sounds in­ter­est­ing. If you look closer, you need to de­cide if you want to laugh or to cry.

Such an in­tel­li­gent elec­tri­city meter is able to dis­play the cur­rent power con­sump­tion in a di­git­al dis­play (if the power con­sump­tion stays the same, you can test with this how much power a spe­cif­ic device needs). It is also able to at­trib­ute the power con­sump­tion to dif­fer­ent times of the day. An op­tion­al fea­ture (here in Ger­many) is the pos­sib­il­ity to trans­fer cap­tured data to the power com­pany. It is not re­quired that the home-​owner is able to see all or even any data from an in­tel­li­gent elec­tri­city meter.

The prom­ises are, that with such a device people could pay less money by us­ing the wash­ing ma­chine or the dish wash­er or sim­il­ar devices dur­ing times when not much people want to use en­ergy.

So far so good, but…

  • My wash­ing ma­chine or dish wash­er are about 1 – 3 years old. We did not buy the cheapest ones, but they do not of­fer to start the wash­ing upon in­put from an ex­tern­al sig­nal or just by ac­tiv­at­ing the power (if they lose power, the chosen wash­ing pro­gram is re­set to the de­fault pro­gram). Am I sup­posed to buy a new one?
  • The power con­sump­tion of all the ne­ces­sary in­fra­struc­ture (di­git­al stuff in the elec­tri­city meter, net­work con­nec­tion to the power com­pany) is not zero, and it is the own­er who has to pay for this.
  • When every­one is wash­ing when not much people want to use en­ergy, a lot of people want to use en­ergy in such mo­ments. It may still help a bit the power com­pan­ies be­cause they do not have to gen­er­ate power (and have ex­penses be­cause of this) which is not used, but I doubt the con­sumer will get a big re­duc­tion then.
  • The dur­a­tion of such power-​surplus times with a re­duced price may not last dur­ing the com­plete time a wash­ing ma­chine needs. It may be even the case that a high-​price time slot may get ac­tiv­ated shortly after (if this is done by (ma­li­cious) in­tent or not is not even rel­ev­ant, as the con­sumer can not do some­thing about it as he is prob­ably sleep­ing when this hap­pens in the night).
  • The power com­pany may be able to get a de­tailed trace of what hap­pens in a house (the own­ers are get­ting up at 11am, only take a shower every two weeks, have prob­ably a big plasma TV which runs all the day, …).
  • I doubt the device is free of se­cur­ity holes or pro­tec­ted enough against eaves­drop­ping (with all the pro­fil­ing im­plic­a­tions, or pos­sib­il­it­ies to ma­nip­u­late the data (pos­it­ively or neg­at­ively) dir­ectly in the device be­fore trans­mis­sion to the power com­pany).
  • I do not think the most in­tel­li­gent and consumer-​friendly devices will come with enough stat­ist­ics or access-​possibilities to really sat­is­fy the con­sumers.

More in­ter­est­ing would oth­er things which could help cut costs. For ex­ample small low-​power net­worked sensors which de­tect if a window/​door is open, the tem­per­at­ure in a room, the out­side tem­per­at­ure, the sun­light in­tens­ity and so on. To­geth­er with some ac­tu­at­ors like for ex­ample to close the win­dow, close the shut­ter, change the heat­ing, turn off lamps and so on, it would provide much more im­me­di­ate be­ne­fit. In a new build­ing, the net­work could be wired, but in an old build­ing the sensors need to be wire­less and battery-​powered.

A pos­sible solu­tion could be done via bluetooth v3 in a mesh net­work (yes, if it is not open source, I would also be scep­tic­al if the com­pany which pro­duces this has enough know­ledge to make it se­cure), polled by a cent­ral sta­tion which could put the sensors in si­lent standby to re­duce the amount of ra­dio pol­lu­tion and in­crease bat­tery life­time. If some of the sensors and ac­tu­at­ors are con­nec­ted (e.g. room tem­per­at­ure and heat­ing ac­tu­at­or plus a clock), you could even let it run in autonom­ous mode (time based heat­ing to a spe­cif­ic tem­per­at­ure) and only need to con­nect to it if there is a spe­cif­ic need. Such a situ­ation could be that the win­dow sensor de­tects an open win­dow, so the heat­ing can be turned off. Or maybe the sun­light in­tens­ity sensor de­tects (or the base sta­tion es­tim­ates) an intensity-​rise of the sun­light, so the heat­ing could be re­duced in ad­vance.

Some­thing like this would give im­me­di­ate be­ne­fit (in com­fort) to those who in­stall it, and in a long-​term view it would/​could cut the costs down a bit.

I am aware of some wire­less sensors/​actuators, but they are re­l­at­ively ex­pens­ive, the ra­dio pol­lu­tion (and type) is un­known to me, and the pro­tocol is not open, so I do not know if it is se­cure and how to im­prove things I do not like.

Any­one with enough hard­ware know­ledge and open source/​hardware spir­it out there to pro­duce a mod­u­lar base for sensors/​actuators (bluetooth + I/​O for sensros/​actuators/​pc-​connection + con­trol­er)?