As I wrote earlier, I try to get some infos which formats my Sony BRAVIA 5800 TV is able to play over the network. Sony is not really helpful (they tell only names someone with a DLNA spec could correctly interpret). Now I took the time to move my TV into a different subnet (the same where my NAS is in, not like before in a DMZ), and I installed minidlna. After some network sniffing, the use of the Intel UPnP Device Spy and some minidlna–source reading I have now a better idea what my Sony TV expects.
The DLNA-specification seems to mandate a MIME-type and some DLNA-specific identifier which describes the content a player (a DLNA-Renderer) is able to display. In the following I will present the MIME-type, the DLNA-identifier, and probably a Sony-specific identifier.
Regarding pictures the TV only accepts JPEGs, bit in small, medium and large sizes. I did not bother to look up what this means in real values, so far this is not of high interest for me. For audio the TV accepts MP3s and LPCM (raw PCM samples). The raw sniffed data from the TV looks like this:
The more interesting part for me is the video part. The TV supports MPEG2 Video (the MPEG_ part in the DLNA.ORG_PN) and H.264 (the AVC_ part in the DLNA.ORG_PN). For MPEG2 it supports program streams (PS in DLNA.ORG_PN) and transport streams (TS in DLNA.ORG_PN). For PS it supports PAL and NTSC resolutions (720×576 is PAL, HD resolutions like 720p or 1080i or 1080p are not supported). The packet-length of a transport 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 pixels. Depending of the combination of the packet-length and if there is a timestamp in use or not, the DLNA.ORG_PN will have a _ISO or a _T appended.
It also supports H.264. The DLNA.ORG_PN starts with a AVC in this case. Only transport streams (TS in DLNA.ORG_PN) is supported. As with MPEG2, the packet-length of the TS can be 188 or 192 bytes. Depending of the combination of the packet-length and if there is a timestamp in use or not, the DLNA.ORG_PN will have a _ISO or a _T appended. Depending on the profile 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 formats my TV requested over the wire. As with the MPEG2 format, SD or HD is added (in minidlna) depending 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 specified 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 support 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 imagine that _24_ stands for 24 pictures per second, and the _50_ and _60_ for progressive videos (with 50 respectively 60 pictures per second), but this is pure speculation from my side. Here is the raw sniffed data:
So far I did not get the time to experiment with this. I also have the impression that minidlna has still some rough edges (the sintel video I used to test before with a different media server, does not show up in the list with minidlna).
GD Star Rating
GD Star Rating
Tags: 1080i or 1080p
, 720p or 1080i
, audio mpeg
, packet length
, pcm samples
, program streams
, sony bravia tv
, sony tv
, source reading
, transport streams
As I already wrote, theoretically ADSL RAM is available at my place. The analysis of the situation revealed first that the ISP side of my line uses outdated hardware. After the technician I know unofficially took care about it (remotely switching me to a different port), I have seen an immediate improvement of the signal to noise ratio. It is about 20 dB better.
Unfortunately this was not enough to be able to switch to the rate adaptive mode. According to their database the line length allows to give me 1.5 MBit. My line is running already at 2 MBit and my ADSL modem tells me it could do 8 MBit, so I disagree a bit with their database.
As the technician agrees with me, the next step would be to temporary move my house by some hundred meters towards the ISP endpoint of the line, unfortunately the higher management seems to be having some business ideas with our region (FTTT, Fiber To The Town (which means we will probably get 16 MBit via ADSL) … but maybe even FTTH), so they are now monitoring the database for such changes since a while.
I have the impression they seem to prevent such changes to the database because they think that if people get 2 MBit (instead of nothing, large parts of a town nearby does not even have the slowest ADSL connection) or 8 MBit (instead of 2 MBit), they are not interested in getting FTTH (or 16 MBit). Together with their IPTV initiative I do not really understand 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 resolution (at least with their IPTV offer), if you want HD resolution, you need to switch to their VDSL stuff (which is not available in our town). What people are doing currently is to switch to a cable provider where they can get about 32 MBit (I do not switch, switching is a risky action here, I rather stay with a slow connection that to have no connection at all for some months). With 32 MBit (and TV) people 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 outcome is, that the technician I know does not want to ask someone to play with the database to move my house temporary (which I can understand). The good part of those news is, that I may get more than 8 MBit in the not so distant future (the current planning is to finish the FTTT work until autumn).
GD Star Rating
GD Star Rating
Tags: adsl connection
, adsl modem
, business ideas
, cable provider
, mbit line
, outdated hardware
, signal to noise
, signal to noise ratio
I am now waiting since December that my ADSL line is switched to the rate adaptive mode (RAM). Theoretically it is possible. Unfortunately the reality does not agree to this (yet).
Luckily I am not a normal customer, I know a technician which works for my ISP. He could switch the line without problems, but the next update of the system (which happens from time to time) would cancel this again, as each update “resets” the status to what is recorded in the DB. The problem is, that he can not switch my line to RAM in the DB (actually it is not him, he is a network technician not one of the sales people with access to the DB–interface). I am not the only customer where this is not possible. So far they where not able to see a pattern.
Currently there are two colleagues of him, a friend of him and me which he has as good examples where it does not work (there are more, but those are “just” regular customers). We are now his toys, he wants to find out how to convince the system to switch to RAM in those cases. This needs a while, as parts of this need to go the official way until he sees if it works or not.
I am very happy that I am not just a normal customer. This way it is much more transparent for me.
GD Star Rating
GD Star Rating
Tags: adsl line
, network technician
At the weekend a friend visited me. We have not seen since each other since a long time. As we studied both computer science, parts of our discussion where off course technology related. Parts of the discussion where about current TV’s and game consoles (he participated in the design of the PS3 CPU, so he is well aware about the technical limitations of the hardware the current game consoles use).
During our discussion we talked about the software limitations of such hardware.
Current TV’s come for example with some predefined internet channels, but not with a real web browser. We think that people which keep a TV for 10 years or longer (like for example our parents and probably both of us too) this will result in a loss of features after some years, because those channels will get less attention of case to exist at all. There is also no way to switch to alternatives then, except by buying 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 keyboard than with a remote control, but let us do small steps here). Game consoles are a bit better in this regard, but there we have the problem that some websites are too much memory hungry (they do not include the user agent of the game console browsers in the same class as smart phones or tablet PCs… from the size aspect they are not, but from the memory and computing power aspect they are more similar).
I would expect that the TV stations do not want to have TVs with really good browsers, because then you may not need a TV station anymore. But this is what users would use if it would be there.
Another deficit is that there is not a mail program in game consoles and TV’s. For writing mails you need a real keyboard, but for a quick check if there is mail (e.g. X unread mails, or maybe even displaying the subject line of the emails) or maybe to just read without answering a solution without a keyboard connected would already be enough.
I expect that console manufacturers do not want to spend money for something people are not willing to give much money for, respectively for something where they can not make money with (an email service from the console company would be another mail service additional to the one for the PC and maybe additional to the one of the smart phone… people do not need 10 email accounts, one is enough).
Another overlooked feature is some kind of VoIP+Video feature (at least for the game consoles which have optionally a camera, but IMO this is also possible for the next generation of TV’s with build-in webcams). At least the offerings from Sony and Microsoft are powerful enough to come with some kind of video conferencing software. It does not matter much if this is Skype or the Google version of this, or some other widespread one (MS surely wants to use their own stuff), it just has to be one which is in widespread 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 available ATM.
Basically I gave the answer to my question (the title of this posting) myself (except for the video conferencing stuff)… but on the other hand this would be something which could set a product apart from others. For the PS3 this may be now one of the things which could show up in the Homebrew scene, now that the security of the PS3 is compromised. For the Wii at least the email part could be easily done. The rest… would have to catch up in case something like this shows up for the PS3 and is used extensively.
GD Star Rating
GD Star Rating
Tags: buying a new tv
, course technology
, current tv
, firmware update
, game consoles
, internet channels
, mail program
, small steps
, software limitations
, unread mails
Today I have read an interesting investigation and problem analysis from Jim Gettys.
It is a set of articles he wrote over several months and is not finished writing as of this writing (if you are deeply interested in it go and read them, the most interesting ones are from December and January and the comments to the articles are also contributing to the big picture). Basically he is telling that a lot of network problems users at home (with ADSL/cable or WLAN) experience are because buffers in the network hardware or in operating systems are too big. He also proposes workarounds until this problem is attacked by OS vendors and equipment manufacturers.
Basically he is telling the network congestion algorithms can not do their work good, because the network buffers which are too big come into the way of their work (not reporting packet loss timely enough respectively try to not lose packets in situations where packet loss would be better because it would trigger action in the congestion algorithms).
He investigated the behavior of Linux, OS X and Windows (the system he had available). I wanted to have a quick look at the situation in FreeBSD regarding this, but it seems at least with my network card I am not able to see/find the corresponding size of the buffers in drivers in 30 seconds.
I think it would be very good if this issue is investigated in FreeBSD, and apart from maybe taking some action in the source also write some section for the handbook which explains the issue (one problem here is, that there are situations where you want/need to have such big buffers and as such we can not just downsize them) and how to benchmark and tune this.
Unfortunately I even have too much on my plate to even further look into this. I hope one of the network people in FreeBSD is picking up the ball and starts playing.
GD Star Rating
GD Star Rating
, big picture
, issue one
, network buffers
, network congestion
, network hardware
, os vendors
, packet loss