As I wrote ear­lier, I try to get some infos which for­mats my Sony BRAVIA 5800 TV is able to play over the net­work. Sony is not really help­ful (they tell only names some­one with a DLNA spec could cor­rectly inter­pret). Now I took the time to move my TV into a dif­fer­ent sub­net (the same where my NAS is in, not like before in a DMZ), and I installed minidlna. After some net­work sniff­ing, the use of the Intel UPnP Device Spy and some minidlna–source read­ing I have now a bet­ter idea what my Sony TV expects.

The DLNA-specification seems to man­date a MIME-type and some DLNA-specific iden­ti­fier which describes the con­tent a player (a DLNA-Renderer) is able to dis­play. In the fol­low­ing I will present the MIME-type, the DLNA-identifier, and prob­a­bly a Sony-specific identifier.

Regard­ing pic­tures the TV only accepts JPEGs, bit in small, medium and large sizes. I did not bother to look up what this means in real val­ues, so far this is not of high inter­est for me. For audio the TV accepts MP3s and LPCM (raw PCM sam­ples). The raw sniffed data from the TV looks like this:

image/jpeg:DLNA.ORG_PN=JPEG_SM
image/jpeg:DLNA.ORG_PN=JPEG_MED
image/jpeg:DLNA.ORG_PN=JPEG_LRG
audio/mpeg:DLNA.ORG_PN=MP3
audio/L16:DLNA.ORG_PN=LPCM

The more inter­est­ing part for me is the video part. The TV sup­ports MPEG2 Video (the MPEG_ part in the DLNA.ORG_PN) and H.264 (the AVC_ part in the DLNA.ORG_PN). For MPEG2 it sup­ports pro­gram streams (PS in DLNA.ORG_PN) and trans­port streams (TS in DLNA.ORG_PN). For PS it sup­ports PAL and NTSC res­o­lu­tions (720×576 is PAL, HD res­o­lu­tions like 720p or 1080i or 1080p are not sup­ported). The packet-length of a trans­port steam can be 188 bytes or 192 bytes. If the width is >= 1288 or the height is >= 720, minidlna adds HD in DLNA.ORG_PN, else it will add SD. The EU in DLNA.ORG_PN is for SD video with a height of 576 or 288 pix­els. Depend­ing of the com­bi­na­tion of the packet-length and if there is a time­stamp in use or not, the DLNA.ORG_PN will have a _ISO or a _T appended.

It also sup­ports H.264. The DLNA.ORG_PN starts with a AVC in this case. Only trans­port streams (TS  in DLNA.ORG_PN) is sup­ported. As with MPEG2, the packet-length of the TS can be 188 or 192 bytes. Depend­ing of the com­bi­na­tion of the packet-length and if there is a time­stamp in use or not, the DLNA.ORG_PN will have a _ISO or a _T appended. Depend­ing on the pro­file used, minidlna adds some more infos to the DLNA.ORG_PN, BL if it is a baseline-profile, MP if it is a main-profile, and HP if it is a high-profile. I do not see this in the valid video for­mats my TV requested over the wire. As with the MPEG2 for­mat, SD or HD is added (in minidlna) depend­ing on the width and height, but also on the bitrate of the video. For the main-profile the width has to be <= 720, the height <= 576 and the bitrate <= 10M (base 10, not base 2) for SD, and the width has to be <=1920, the height <= 1152 and the bitrate <= 20M (base 10, not base 2) for HD. For the high-profile the width has to be <=1920, the height <=1152, the bitrate <= 30M (base 10, not base 2) and the audio has to be AC3 to get the HD added in DLNA.ORG_PN. The audio is spec­i­fied in DLNA.ORG_PN as MPEG1_L3 for MP3, AC3 for AC3, and AAC or AAC_MULT5 for AAC (stereo or 5-channel). As can be seen below, the TV seems only to sup­port AC3 audio for AVC. The TV also has _24_, _50_ and _60_ in DLNA.ORG_PN. I did not find those things in the minidlna source (but I have not really searched for this). I could imag­ine that _24_ stands for 24 pic­tures per sec­ond, and the _50_ and _60_ for pro­gres­sive videos (with 50 respec­tively 60 pic­tures per sec­ond), but this is pure spec­u­la­tion from my side. Here is the raw sniffed data:

video/mpeg:DLNA.ORG_PN=AVC_TS_HD_24_AC3_ISO;SONY.COM_PN=AVC_TS_HD_24_AC3_ISO
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_24_AC3;SONY.COM_PN=AVC_TS_HD_24_AC3
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_24_AC3_T;SONY.COM_PN=AVC_TS_HD_24_AC3_T

video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_PS_PAL
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_PS_NTSC

video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_50_L2_T
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_60_L2_T
video/mpeg:DLNA.ORG_PN=MPEG_TS_SD_EU_ISO
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_EU
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_EU_T
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_50_AC3_T
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_SD_60_AC3_T
video/mpeg:DLNA.ORG_PN=MPEG_TS_HD_50_L2_ISO;SONY.COM_PN=HD2_50_ISO
video/mpeg:DLNA.ORG_PN=MPEG_TS_HD_60_L2_ISO;SONY.COM_PN=HD2_60_ISO
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_HD_50_L2_T;SONY.COM_PN=HD2_50_T
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=MPEG_TS_HD_60_L2_T;SONY.COM_PN=HD2_60_T

video/mpeg:DLNA.ORG_PN=AVC_TS_HD_50_AC3_ISO;SONY.COM_PN=AVC_TS_HD_50_AC3_ISO
video/mpeg:DLNA.ORG_PN=AVC_TS_HD_60_AC3_ISO;SONY.COM_PN=AVC_TS_HD_60_AC3_ISO
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_50_AC3;SONY.COM_PN=AVC_TS_HD_50_AC3
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_60_AC3;SONY.COM_PN=AVC_TS_HD_60_AC3
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_50_AC3_T;SONY.COM_PN=AVC_TS_HD_50_AC3_T
video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=AVC_TS_HD_60_AC3_T;SONY.COM_PN=AVC_TS_HD_60_AC3_T

video/x-mp2t-mphl-188

So far I did not get the time to exper­i­ment with this. I also have the impres­sion that minidlna has still some rough edges (the sin­tel video I used to test before with a dif­fer­ent media server, does not show up in the list with minidlna).

As I already wrote, the­o­ret­i­cally ADSL RAM is avail­able at my place. The analy­sis of the sit­u­a­tion revealed first that the ISP side of my line uses out­dated hard­ware. After the tech­ni­cian I know unof­fi­cially took care about it (remotely switch­ing me to a dif­fer­ent port), I have seen an imme­di­ate improve­ment of the sig­nal to noise ratio. It is about 20 dB better.

Unfor­tu­nately this was not enough to be able to switch to the rate adap­tive mode. Accord­ing to their data­base the line length allows to give me 1.5 MBit. My line is run­ning already at 2 MBit and my ADSL modem tells me it could do 8 MBit, so I dis­agree a bit with their database.

As the tech­ni­cian agrees with me, the next step would be to tem­po­rary move my house by some hun­dred meters towards the ISP end­point of the line, unfor­tu­nately the higher man­age­ment seems to be hav­ing some busi­ness ideas with our region (FTTT, Fiber To The Town (which means we will prob­a­bly get 16 MBit via ADSL) … but maybe even FTTH), so they are now mon­i­tor­ing the data­base for such changes since a while.

I have the impres­sion they seem to pre­vent such changes to the data­base because they think that if peo­ple get 2 MBit (instead of noth­ing, large parts of a town nearby does not even have the slow­est ADSL con­nec­tion) or 8 MBit (instead of 2 MBit), they are not inter­ested in get­ting FTTH (or 16 MBit). Together with their IPTV ini­tia­tive I do not really under­stand it. To get their IPTV, you need to have at least a 8 MBit line. With 8 MBit you can only cover one TV at SD res­o­lu­tion (at least with their IPTV offer), if you want HD res­o­lu­tion, you need to switch to their VDSL stuff (which is not avail­able in our town). What peo­ple are doing cur­rently is to switch to a cable provider where they can get about 32 MBit (I do not switch, switch­ing is a risky action here, I rather stay with a slow con­nec­tion that to have no con­nec­tion at all for some months). With 32 MBit (and TV) peo­ple have less a need to switch to fiber (and pay 150 EUR for the work to get fiber into the house) than with 2 MBit or nothing.

The final out­come is, that the tech­ni­cian I know does not want to ask some­one to play with the data­base to move my house tem­po­rary (which I can under­stand). The good part of those news is, that I may get more than 8 MBit in the not so dis­tant future (the cur­rent plan­ning is to fin­ish the FTTT work until autumn).

I am now wait­ing since Decem­ber that my ADSL line is switched to the rate adap­tive mode (RAM). The­o­ret­i­cally it is pos­si­ble. Unfor­tu­nately the real­ity does not agree to this (yet).

Luck­ily I am not a nor­mal cus­tomer, I know a tech­ni­cian which works for my ISP. He could switch the line with­out prob­lems, but the next update of the sys­tem (which hap­pens from time to time) would can­cel this again, as each update “resets” the sta­tus to what is recorded in the DB. The prob­lem is, that he can not switch my line to RAM in the DB (actu­ally it is not him, he is a net­work tech­ni­cian not one of the sales peo­ple with access to the DB–inter­face). I am not the only cus­tomer where this is not pos­si­ble. So far they where not able to see a pattern.

Cur­rently there are two col­leagues of him, a friend of him and me which he has as good exam­ples where it does not work (there are more, but those are “just” reg­u­lar cus­tomers). We are now his toys, he wants to find out how to con­vince the sys­tem to switch to RAM in those cases. This needs a while, as parts of this need to go the offi­cial way until he sees if it works or not.

I am very happy that I am not just a nor­mal cus­tomer. This way it is much more trans­par­ent for me.

At the week­end a friend vis­ited me. We have not seen since each other since a long time. As we stud­ied both com­puter sci­ence, parts of our dis­cus­sion where off course tech­nol­ogy related. Parts of the dis­cus­sion where about cur­rent TV’s and game con­soles (he par­tic­i­pated in the design of the PS3 CPU, so he is well aware about the tech­ni­cal lim­i­ta­tions of the hard­ware the cur­rent game con­soles use).

Dur­ing our dis­cus­sion we talked about the soft­ware lim­i­ta­tions of such hardware.

Cur­rent TV’s come for exam­ple with some pre­de­fined inter­net chan­nels, but not with a real web browser. We think that peo­ple which keep a TV for 10 years or longer (like for exam­ple our par­ents and prob­a­bly both of us too) this will result in a loss of fea­tures after some years, because those chan­nels will get less atten­tion of case to exist at all. There is also no way to switch to alter­na­tives then, except by buy­ing a new TV (we expect that there will be no firmware update in such a case). With a real web browser this would not be an issue (it may be more easy to enter URL’s with a real key­board than with a remote con­trol, but let us do small steps here). Game con­soles are a bit bet­ter in this regard, but there we have the prob­lem that some web­sites are too much mem­ory hun­gry (they do not include the user agent of the game con­sole browsers in the same class as smart phones or tablet PCs… from the size aspect they are not, but from the mem­ory and com­put­ing power aspect they are more similar).

I would expect that the TV sta­tions do not want to have TVs with really good browsers, because then you may not need a TV sta­tion any­more. But this is what users would use if it would be there.

Another deficit is that there is not a mail pro­gram in game con­soles and TV’s. For writ­ing mails you need a real key­board, but for a quick check if there is mail (e.g. X unread mails, or maybe even dis­play­ing the sub­ject line of the emails) or maybe to just read with­out answer­ing a solu­tion with­out a key­board con­nected would already be enough.

I expect that con­sole man­u­fac­tur­ers do not want to spend money for some­thing peo­ple are not will­ing to give much money for, respec­tively for some­thing where they can not make money with (an email ser­vice from the con­sole com­pany would be another mail ser­vice addi­tional to the one for the PC and maybe addi­tional to the one of the smart phone… peo­ple do not need 10 email accounts, one is enough).

Another over­looked fea­ture is some kind of VoIP+Video fea­ture (at least for the game con­soles which have option­ally a cam­era, but IMO this is also pos­si­ble for the next gen­er­a­tion of TV’s with build-in web­cams). At least the offer­ings from Sony and Microsoft are pow­er­ful enough to come with some kind of video con­fer­enc­ing soft­ware. It does not mat­ter much if this is Skype or the Google ver­sion of this, or some other wide­spread one (MS surely wants to use their own stuff), it just has to be one which is in wide­spread use to be adopted by the people.This does not need to be in HD, even a small video would already be much more than what is avail­able ATM.

Basi­cally I gave the answer to my ques­tion (the title of this post­ing) myself (except for the video con­fer­enc­ing stuff)… but on the other hand this would be some­thing which could set a prod­uct apart from oth­ers. For the PS3 this may be now one of the things which could show up in the Home­brew scene, now that the secu­rity of the PS3 is com­pro­mised. For the Wii at least the email part could be eas­ily done. The rest… would have to catch up in case some­thing like this shows up for the PS3 and is used extensively.

Today I have read an inter­est­ing inves­ti­ga­tion and prob­lem analy­sis from Jim Get­tys.

It is a set of arti­cles he wrote over sev­eral months and is not fin­ished writ­ing as of this writ­ing (if you are deeply inter­ested in it go and read them, the most inter­est­ing ones are from Decem­ber and Jan­u­ary and the com­ments to the arti­cles are also con­tribut­ing to the big pic­ture). Basi­cally he is telling that a lot of net­work prob­lems users at home (with ADSL/cable or WLAN) expe­ri­ence  are because buffers in the net­work hard­ware or in oper­at­ing sys­tems are too big. He also pro­poses workarounds until this prob­lem is attacked by OS ven­dors and equip­ment manufacturers.

Basi­cally he is telling the net­work con­ges­tion algo­rithms can not do their work good, because the net­work buffers which are too big come into the way of their work (not report­ing packet loss timely enough respec­tively try to not lose pack­ets in sit­u­a­tions where packet loss would be bet­ter because it would trig­ger action in the con­ges­tion algorithms).

He inves­ti­gated the behav­ior of Linux, OS X and Win­dows (the sys­tem he had avail­able). I wanted to have a quick look at the sit­u­a­tion in FreeBSD regard­ing this, but it seems at least with my net­work card I am not able to see/find the cor­re­spond­ing size of the buffers in dri­vers in 30 seconds.

I think it would be very good if this issue is inves­ti­gated in FreeBSD, and apart from maybe tak­ing some action in the source also write some sec­tion for the hand­book which explains the issue (one prob­lem here is, that there are sit­u­a­tions where you want/need to have such big buffers and as such we can not just down­size them) and how to bench­mark and tune this.

Unfor­tu­nately I even have too much on my plate to even fur­ther look into this. I hope one of the net­work peo­ple in FreeBSD is pick­ing up the ball and starts playing.