Well, it's a strange title. Popwire has actually been around since 2000. We were previously owned by Ericsson. And so we've been doing encoding R&D for wireless networks since then. As I speak, we are being acquired by the company called Teleka, which of course has Ericsson as a customer. They used to be a customer to us as well as a partner. what Teleka does is, for instance, their largest product is something called Obigo, which is a software platform that goes into their cell phones, and there's over 60 million units that ship with that platform in it. They also do end-to-end solutions for operators, operational maintenance systems, etc. And with the acquire of Popwire, it means that they will strengthen the multimedia side of our cell phones and also move into media and to the broadcast side, which is a process that we do as well. So that's just a brief explanation.

Today, my microphone doesn't work. so they're running down here right now. What we'll talk about is content, what is good content, I will talk about source content, how you get it, what are the key issues with getting good source content. So I will show some tools, I will talk about workflow, I will also talk about some live services, which actually means live broadcasting into wireless networks, and I will of course make a summary out of this. So I will go between technology side and a bit on the market side as well.

So first of all, content. One of the major problems for operators is to get content, because it's actually not the operator's business. The operator's business carriers is about having voice, cell phones, it's about having networks, et cetera. So this is completely new to them. So usually, when they ask for content, they ask the wrong questions, and I've seen this so many times.

And I assume a lot of you are content creators. The operators come to say, we want to stream something. And you think, well, I have something that's streamable. And you give it to them. But actually, what I ask about is not really about streamable content. They're asking about content, period.

And usually, if they go, especially to a broadcaster, and ask this, they think, hmm, well, we have something that you can stream on the internet. And they give them that. And of course, they can't use that, because they have to repurpose that. So what they should ask for is, of course, maybe the MPEG-2 files which they have on video servers which they use in their original productions, the things that comes out direct from the editing stations, but usually it's a mismatch of what you ask for and what you're giving them. So that is one of the key issues.

And of course this is that internet content isn't adapted for wireless. No matter what people say, it's not really adapted for it. Then of course productions. I've seen so many productions being made for wireless where they made all the errors you can think about. You have people running around, you have camera movements, things that if you do for internet, you know, you shouldn't do this for the internet sign because the codec won't be able to encode this in a very good way. And they make, you know shows where they stand up they have this chroma key behind them and everything is moving around and on the internet at least you have maybe an image which is like this on a cell phone it's like this and it could be 30 kilobits audio and video so that's another thing productions usually isn't made for cell phones and when they are done for cell phones they still think in a large format the people is actually doing that so that's one of the things that is very very important is to create content that is it's workable for cell to start with.

Rights issues. Many times when they get sports especially, they might get the rights for the images, for the video, but they might not get the rights for the commentators. So that means that they have to put on new speech, which means they have to go into process of editing. And of course, that is not something that an operator usually has. They don't have an editorial room. They don't have all the editors. They don't have that kind of equipment.

And also today, the other issue for them is of course that they need to drive business into the wireless networks, which means that they many times have to act as a content creator, and that's what's causing the issues. So you have two kind of operators, carriers today. You have one who only thinks of them as bit pipes, which takes content from someone else, and you have the second ones which believes that we should create content, and that usually creates a mess on every side. And the thing is that what they really need to do is to make sure that you can migrate the content creation from the operator to the actual content creator who knows what they're doing, so you or those people can create the content which is adapted for MyLS to start with.

So, source content. What is good source content? Well, of course, it's the highest possible quality. I think most of you who's working, you know, with QuickTime tools and is in this kind of community, you know this, that the more you should compress it, the smaller, you know, frame size, whatever it is, the higher quality you should have. This is not really what an operator carrier knows about. So usually, same thing back, they take something from the internet and they say, well, we can probably adapt this. So usually I say the lower the bitrate you have, the higher the quality you need to have on the source content.

So what is good source content? Of course, it's uncompressed video, motion, JPEG, that kind of things, but also MPEG-1 and MPEG-2. And maybe we might argue about MPEG-2 or MPEG-1, but if you think about how much is MPEG-2 that is produced on the broadcasting side, that is a key format as an input, whatever it is. And you can, of course, use semi-compressed formats and where you've done SIFT sizes. But you should, of course, not do a thing like you have a smaller size than the actual output size. I've seen that as well. And many times, you do errors with you taking a movie and you actually resizing it, but you don't think about you need to crop it to get it out of certain areas. So what you're actually doing is a resize anyway when you do the cropping.

So bad source content is of course anything that is compressed to start with. Many times you can't live by this rule, but the idea is of course that you shouldn't use compressed content. And all this kind of internet formats isn't made to be source content for this kind of encoding or for this kind of production. Of course if you use extremely high bit rates it will work as well, but usually when we talk about it, same thing, they think they can use something from the internet. No CVA chase captures. I've seen that many times. Well, it's just going to be this big, so who cares? Same thing again. The lower the bitrate you have, the higher the quality of the source you need to have. And as I said before, smaller size and output size. And many times, well, it's produced for TV, and you just adapt it to put on a cell phone. And that's not really workable.

So let's get into the real stuff about talking about the encoding for 3G. 3G is, of course, third generation. GPRS is 2 and 1/2G. In US, you have Edge, which is also 2 and 1/2G. Usually, GPRS or Edge or something like that is about 30 kilobits, 20 kilobits, even if the specifications allows you for much higher bit rates. But in practice, we talk about 30 kilobits. 3G today is about 64 kilobits.

In theory, it's 384, but we're not really there yet. So the difference is there are certain kind of standards. You have the 3GPP standard and you have the 3GPP2 standard. And then as a comparison, we have ISMA, which is basically what you would use in Quick Done when you do MPEG-4 streaming or MPEG-4 download.

And as you can see, there are many similarities between 3GPP and 3GPP2. The H.263 codec is the mandatory codec in both. Then you have the AMR as a speech codec, which is mandatory in 3GPP. but in 3GPP2 is QSELP, which is the mandatory speech codec. So that's basically the main difference. You have AMR on the 3GPP2 side as an optional codec if you like to use it. And then we have MPEG-4 simple visual profile level 0. And that is basically the same as level 1, which is what you would use on ISMA specification 0 or 1. The difference is from a technical point of view is that on level 1 you're allowed to have four objects and in level 0 you're only allowed to have one object, but this is more of a theoretical problem than a practical problem because no one really makes MPEG-4 with several objects anyway at this point. So you have this simple visual profile level 0, you have AAC and that is also similar with ISMA which also have MPEG-4, but they have level 1 to 3 and they have AAC as well. Streaming isn't defined for 3GPP2 yet, but they are working on this as we speak. And there is a huge difference when you do streaming is that in 3GPP you use Latin packetizing.

In ISMA, you use generic packetizing. So many people sit down and do basic hinting, whatever it is, with the click-tum player, and they don't get it to work in old phones, because many phones only support according to 3DPP standardization. So that means that if you're doing streaming for wireless, you need to be aware of this.

On radio network level, it's a bunch of differences. For us people sitting here, it's IP. And that is the crucial thing. It's IMP we're talking about. We're just talking about another sort of carrier or bearer of that kind of material, if it's internet or whatever it is. But its own radio network is very much different.

So, encoding for 3G or GPS. First of all, we're talking about low bandwidth, typically below 64 kilobits. That's what we're talking about, and that's the total IP level. So that means usually we're talking about media level, maybe 54, 56, if we're lucky, basically. So, same thing again. You need high-quality content to start with. You need to have good-quality codecs, of course. This is very important when you're working on low bandwidth. You need to be able to do pre-processing, like deinterlacing, maybe do gamma correction, that kind of things needs to be done as well for cell phones.

A typical thing is to reduce frame rate. And then usually I get arguments saying, well, then you get this stuttering video. But the thing is that a screen on a cell phone is pretty slow compared to a computer. So the best thing to do is to reduce frame rate to get down to bit rate. And you do that by dropping frames if you have-- if that's possible in the encoder, and also using natural key frames so you don't add key frames unless you actually need to do it. So you try to actually get down the amount of keyframes. Of course, there's a risk with this, because if you lose a keyframe, and it's too long until the next one, you can't recover the video. So it always is a way of going out, how often should I have actually a keyframe or not?

The other thing is of course bandwidth constraints. This is the crucial part about wireless is that 64 kilobits is definitely 64 kilobits. There's no headroom whatsoever and usually it's not 64 when we're talking about a media level. So that means that certain kind of technology is very important to do streaming or download, whatever it is. For streaming, of course, it's using constant bit rate, which many, many times believes as flat bit rate.

Constant bit rates do vary. And what it has to do with is the video buffer verifier. What the video buffer verifier does, it creates a sliding window. So if you put that to five seconds and you do the encoding, it's going to go over the complete encoding. And during this five seconds, if you put it to 64 kilobits, the average bit rate should be 64 kilobits, which of course means that you can have certain peaks, which go above 64 kilobits. And you can't have that in a wireless network. That's just not going to happen. So it's very important that you can lower the video buffer verifier. And I'm going to show you later on some tools and how that can be done. Usually, you're down to things like 0.2 seconds of this sliding window in order to get it through on a wireless network.

Same thing, drop frames, natural key frames, very very important. You have error handling, which usually is about packet size, because in a radio network you have certain gateways. First of all you have the IP gateway, which connects the radio infrastructure into an IP structure. And that can have limitations on how big the packets can be. But typically you have between 6 and 8 different kind of gateways you have to pass. So that means that sometimes you won't get a stream through, and it has to do with some of the gateways is not letting the stream through because the packets is too big. So typically you start with like 600 or something instead of 1200 which you use for internet.

And then we have something called RVLC, reverse length coding. and that is used basically when you have congestion, if you lose packets, the decoder should be able to recreate some of the pixels actually, but that is also decoder specific, if the decoder can handle it or not. The other thing of course is, at this point, short clips, that's what you should do, about 30 seconds, because one thing of course is the attention span. On TV it usually says it's about one minute, one and a half maybe to get attention. On a cell phone it's definitely much lower than that. I don't know if 30 seconds, I think that might be too long because it's on a cell phone, you're moving around. I haven't seen that many people actually walking around watching a video. So usually you have a couple of Senkans actually getting their attention. So try to stick with 30 seconds to start with. unless you're doing some kind of live encoding, of course. It also is another thing is that when a new user enters a radio network cell, the cell is where you actually get your connection. You have a limitation of the total bandwidth. So what happens if I move into a cell and I'm new in that cell, I would be prioritized. It means I will get the highest bitrate possible.

for as long as there's a new user coming in, then they will lower it. And this is just logistics of how the system works. So that also means that 30 seconds is a good span, because usually 30 seconds or a minute, you usually have the highest bit you have when you entered. So that's another thing to think about. And always, speech has priority over data. And you heard in some presentations before, the operator is making more money out of speech than they're making out of video services today. So that means if you have a lot of speech going on in that cell, it would be prioritized.

So, streaming versus download. Well, there are some pros and some cons about it. Of course, one thing is that memory is limited in the cell phones, so therefore streaming is good because you're not relying on how much memory you have in your phone. You also actually have less overhead in RTP packets than in HTTP packets, so that means you can actually send more media data.

if you do a stream. It's a lightweight DRM in itself. It's not that many people that I know of in the world who can actually hijack a stream on a cell phone. And if you know them, you should give them my number because that is extremely hard to do. And it's viewable in about, you know, two to four seconds. It's just about buffering time before you have it. The drawbacks, of course, is firewalls.

That's the major problem when some of you have tested doing streaming on wireless networks and you can't get it to work. It's because the firewalls is locked for RTP traffic. But if the operator wants to have streaming, they need to open up the firewalls and that's what's happening more and more, especially in Europe and Asia at this point.

it's not really support by old phones at present streaming so also something to think about which phones can accept streaming uh... Needs to load storage on the phone. This is actually for the download side, but I think it's been popped up on the wrong slide. So let's move on.

So download, the proof for it is, of course, that it's supported by all phones. All phones can do a download. The drawback is, of course, it's very few phones that can do progressive download. And I think most of you believe that they can do this progressive download. But they actually can't. So you need to download the complete file. So that is one drawback of it. And then this is the right place for the argument is it It needs, as I say, large storage on the cell phones. Compared to computers, it doesn't need anything, because it's very small files. But cell phone thinking, it is really a large file.

And, OK, what about the quality of download files? Usually, I hear this, that you're not constrained to bandwidth limitations when you do a download file, because you're doing a download. And that is, of course, true. But it's not really good experience to wait 5, 10 minutes for breaking news in your cell phones. And it's really annoying me, even on the internet today, that you usually have this 56k for mode and download, and it takes half an hour to download. So I would argue and say, well, that's not really the way to use the internet either. But in this case, it's very important because you pay per packet on a wireless network.

Then if there are some carriers or operators here, they will argue and say, no, no, no, no, we have a unity price, and that's true. Some operators do have a unity price per content, but some use the model of that they're actually paying per packet. But the most important things which usually they don't think about, which US content creators should be extremely aware of, is it's a cost for every packet for the operator.

So if you do a download file and it has twice the bits, twice the size as you're downloading towards the stream, that means that you might be able to serve two people instead of one if you do stream. So therefore, you should handle all downloads as streams when we talk about encoding and bit rates and things like that. Because the content creators that can create files that has a good quality but has as small files as possible is the one that the operators want to go with. It might not be true that they think about this, but this is what's costing them. This is the capacity to download things. So even if they don't have a unit price per packet, it still is a cost per packet when they're downloading it.

So, let's talk about some tools then. Of course, this is the obvious one with QuickTime. And as I said, for small operations, and of course, some of you probably argue with that as well, but first of all, I mean, what you do is that you acquire the content. Many times you edit it. As I said, many operators do edit this. They shorten it. They adopt it for a different kind of cell phone, so it's easier to have it. So it's better viewed in the cell phones, et cetera.

and then you encode it and you distribute it. And then you distribute it as a 3GP or 3GPP2 file or something. And in this case, QuickTime is of course a perfect tool. It's one of the few tools on the market today, mass market, that actually supports 3GPP2 and 3GPP. So this is a perfect tool. But of course when you're growing, when your business is growing, you need more larger systems. And this is one of the things, for instance, that we do at Popper is a product called Compression Master. This is when you're having several stations, where you need to have an encoding workflow, you need to have a larger operation, you need to be able to do pre-processing, et cetera. So let's switch to this machine.

Okay, maybe. So first of all I'm not going to get into every piece of how you do encoding because there's been sessions about this probably all day long and tomorrow and there's something about pre-processing afterwards. I'm going to talk more about the specific things about wireless. So let's start with this is a file Swedish artist I think actually I don't know Patricia McNeil. So this is a file, this is a motion JPEG file, and this is of course a perfect file to make for a cell phone because this is very good produced. It actually isn't produced for a cell phone as you can see because you have all the things that I said, movements, whatever it is, but it's a rock video and I would love to see the person who can go back to the producer and say, "Can you make a video for my cell phone?" That's not going happen either but at least this is as good source content as you as you are able to get. So using QuickTime is extremely simple. So what I do right now is this of course I go down to my options and in this I choose 3GPP and in here I have the 3GPP specs we talked about before where I can choose MPEG-4 H263 On the audio side, I can choose AMR, AAC. If I switch this to 3GPP2, I add it on Q-SELP. So this is a typical example of how this kind of 3GPP2 and 3GPP is differing. And you also have, if you move over here, for instance, you can do text, of course, if the telephone supports you and create text tracks as well. You can do streaming, and here is a small pointer. ISMA, support for streaming, which means not all phones are 100% compatible if you do stream with this one. But I'm pretty sure that Apple will release LAP packetizing for 3GPP as well.

On the advanced features, you have some things like on 3GPP2, for instance, you can do fragment and movie. I'm not going to go into that too much, but you add on headers in the stream, actually. So if you lose some packets or if you lose something else, you can recapture much, much easier. You also have things on the advanced side for different kind of versions of 3GPP, where you do have different kind of restriction or DRM, etc. So you can do this. but let's move on to the 3GPP side. So, in this case my input file is a PAL file because I'm from Sweden and we use PAL, so I'm going to put in 12.5 as well and you do keyframes every 25 seconds. The other thing is that you only have two sizes to choose from which is 176 x 144 which is QSIF and 128 x 96 which is sub QSIF. Those are the sizes that you're allowed to use in 3GPP and 3GPP2. In theory, you're allowed to use SIF, which is 352 times 288, but there's not really any phones that's that large at this point. So you can use it, but you won't be able to play it anyway. So in this case, we're using QSIF. And let's say I'm going to do this for a 64K bearer. I would go down something like 48 or 45 or something like that. In this case, I would use AAC, 16 kilobits per second. And as you see, QuickTime automatically switches to allowed or best used sample rates, which is a really good feature.

So now I set up my encoding, hit OK, and do Save. And hopefully this should work. So now I'm exporting a 3GP file directly from QuickTime. But this also means that all tools that actually work on top of QuickTime, of course, can create 3GP files because it's in the core of QuickTime. So this is my movie I just did. And this will actually fit in a cell phone. Right now it looks extremely large, but it will actually work. So this is how easy it is to do this kind of encoding with QuickTime. So let's move this to the trash.

So, let's take a look at the Compression Master. This is another kind of tool. You have your settings windows, I'll go through this. You have your batch windows where you put in your files, your settings to actually do the encoding. So in this case, I have, for instance, over here, I have bookmarks. I can bookmark files, whatever it is, files, sources, folders where I have my content. But let's start with taking the same kind of file here.

So this is my file I'm going to encode right now. So let's start with some of the templates. So I, of course, get into 3DPP and PaulInput because that's what I'm using. And I'm going to do an extreme one. I'm going to use this template, which is for gPRS, which says three slots. And how it works is that one slot is 12 kilobits.

in theory but you usually calculate with 10 and what you can get in GPS networks the phones today is that you usually can get three times slots which means 30 kilobits but in theory that means probably 20 or something when we talk media level so this is an extreme low bandwidth we're talking about and this is a download file of course this is I can do more things than 3dp I can do a bunch of other things like mp2 or whatever it is but that's not why I'm here and I have my codecs which I'm allowed to do and in this case it's an AMR codec, the speech codec because when you download this low bitrate you don't really have bitrate enough to use ASC.

So now I'm opening the same file but for streaming you see it's the same thing now I can switch between those two so it looks pretty much the same but let's switch to this one. Same kind of thing, same kind of codecs but now when we start looking at this of course you have all this pre-processing you know like deinterlacing all that stuff. I don't need to do this right now because the movie I have is already deinterlaced as a motion jpeg file so but otherwise you have all kind of pre-processing you need to do. Science as well. I use the QSIF size and you have a lot of pre-made sizes which you can use of course. And then let's get into the MPEG-4 side. Oh, 300 kilobits, that's cool. So let's do... download... let's do... 48. I'm not really living by my rules fully.

If we switch to the streaming file right now, we see that on the streaming file, I actually put the bitrate to 18 kilobits. and I use on the audio side, I use 4.75 kilobits. So that means I have something like 23 kilobits in total. And that would probably be possible to get through on a stream on three time slots.

On the download side, I haven't really lived by the rules as I said before because I actually put it in 48 kilobits and on the audio it's the same as 4.75. But that means that I'm setting the level at 64 kilobits or 56 at this point to make sure that I get a file which is not that big. The main difference here is this buffer size, the VBV size. On a download file, I put this to 10 seconds, which means that the sliding windows is 10 seconds, which means that I can fluctuate much more. Because it's not a stream, it's downloading, so you don't really have to think about if you have peaks. You more have to think about the total size of the file. If I move to the stream file, you will see it's very much constrained. It's 0.6 seconds to get this through. And of course this is templates which you can then you can of course change for yourself, you need to fine tune this but these are maybe some areas people say we are extreme but we're also seeing this on wireless networks how hard it is to get the stream through. I also have frame skip probability of fifty five percent which means that I'm telling the codec that you are allowed to really drop frames to maintain data rate. On the download side I have none because I don't need to maintain the data rate. I just need to have the overall bitrate actually. So I'm using natural keyframes on both.

I could add in a distance if I like to. So if I'm afraid that it's content isn't moving that much and I don't want to make sure that I can recover the video I can put in a max distance in the keyframes as well but I'll need to do this. I do two paths on both and then we come into this thing is that different kind of mp4 profiles. This case it's simple profile same thing as you would use in ISMA but this is the important thing is level 0. Since when you're doing an encoder even if we do our own encoder the encoder don't see the difference between choosing level 1 or level 0. So that's why it's a manual thing that you have to press to say you have to write this down as level 0. So that's the reason why. And then we put in all the sizes, all the other things that we did. So let's do some encoding now. So now this is my sofa, I can even I can double click or I can drag it in. So right now I'm putting in Let's see. Save those. So let's do these twos.

I'm adding those and of course now I'm encoding those and they are ending up in my very Swedish name "Klara" which means ready in Swedish means that's why the files are going to end. During this process of course I can add on more files so I can add on for 3G like 64 kilobits or I can I can actually do on the fly I can prioritize whatever should be encoded so Now I've done my 3DP files for wireless for the three time slot and as you can see right now play all movies you see there is a difference between what's happening on the download versus the stream file as you see is very very highly constrained stream file to the left side because of I really need to get the bandwidth through that's what that's that's that's the important thing then of course on top of this you can do a bunch of different kind of you know pre-processing but usually the error people do is that they add on too much pre-processing and I'm using all the time QuickTime to verify if it works because QuickTime as we said before is one of the few players out there that can actually play 3D PP content on a Mac or PC. The thing is that QuickTime is a great player it can play pretty much whatever and if it looks crappy we make it look good so on on sort of a positive negative way I'm telling you must verify it in your cell phone how it looks do not verify the thing all this looks great and because in quick time everything will actually look great so that is one of the key thing is that really check it so after a while you've learned to see that if it looks like this in quick time this is how it will look in the cell phone. So, then I've done two other files here as well for 64k bit.

which is for 3G then. So let's do play all movies and you have the same thing here you see on the stream thing you have it dropping more frames than on the download but basically it's the same approach but I'm giving some more bits on the download side than on the streaming side and it's all due to this that trying to get the file size down is very very important because that means that the operator can serve more users. So let's move away from the demo side.

Almost. Perfect. So when you get into some larger scale operations, well, then the tool like the Compression Master isn't really sufficient either. So for operators, they need an automated system. And this is where we see the expertise from Content Creator comes in, because what I need is like we have something called a compression engine, which is a server-based product which you can cluster among as many XSERVs as you like, whatever. and you create XML settings with a master and you drop them in X amount of watch folders, so if you put ten settings in one watch folder and drop in a file you get ten files out of it of course. So that is having an automated system and this is fully working on the Macintosh environment and it will support metadata input and output as well. So this is like for the high-end system. So this is a real world example of an operator that actually does this and it's not a secret actually, it's Hutchison which brand name is called 3 in Europe and Asia, which is a 3D operator, which is really, really pushing the limits of what you can do with 3D today. So what they do is that they have a post-production company on the top, as you see, which actually works like a sort of quality control. They are making settings, they are verifying settings, they are talking to the content owners, creators to make sure that they are getting the right kind of formatting material, the right kind of source content, whatever it is. And this model has proven to be the best and most sufficient way as I've seen for an operator carrier to do business because they don't really have the skills about how to best optimize content for wireless because it's very much to do with your knowledge of video and how you do codecs and how you not how you do course but how you actually put in settings into coins and how you do so this is a real-life example where they from the left side is that some things comes directly post-production company where they sit down and work with typically would be trailers then it will sit down and work with it if it's 50 video clips coming from like a grass service MPEG-2 going directly into watch folders being encoded automatically ends up in the phone and also it's a lot of getting tapes which the operator actually has they have an editorial staff which actually do editing what they're now working on is replacing the tapes with with a compression engine to actually take it directly from the editing station and do it into like an MPEG-2 or go and directly to the PP2 from the content content owner but it's always they have their post-production company which actually is creating the settings and making sure it works. So live services There's been a lot of services started where they do live or webcasts, or whatever you call it, on wireless networks. One of the things for traffic surveillance. Because it's a really good thing to hang up your phone, calling number 442, whatever it is, seeing how is the traffic on my road.

That's been a killer app in Asia, for instance. But I'm going to show you something that's been, as I not all agree with me, but I would say the first ever successful 3D service and that has to do with live thing. In Sweden or in very many countries over 30 we have something program TV show called Big Brother. It's a extremely stupid you know sort of show but and I actually watch it unfortunately. What it is that you put X amount of people I think is 10 or 12 into house for 100 days you cut off all all they can't talk to anyone outside of except if they bring someone in to stir something up. And they are sitting in this room. And of course there are some key things about it, is that it's a closed environment, so you can monitor them all the time, you can have cameras there. The other thing is that every week they design on two people that we should nominate which the audience can vote out. Which, you hear this, it's a great show. And also is the other thing is that every newspaper, whatever it is, or every kind of media is talking about this. So it's a reality TV show.

It goes directly into the youth segment, and it's a lot of viewers. I don't know if you have this in the U.S., but in Europe, it's pretty big. I see some guys from the U.K. here, and they are laughing with me. So it basically is 24/7 action. It's happening things all the time.

So the service offering from Free, which is the brand name for the operator, but in this case, it's the Hutchison. It's the company which has its base in Hong Kong, but which is visible in Italy, UK, Sweden, Norway, Denmark, I don't know, Japan, but Hong Kong, etc. So in this case, they have six live feeds you can get in on 24-7. You can connect to those live feeds and see what's happening. Of course, the shower cam has been the most popular one.

But they also have, as you see, 20 to 30 news items daily. So it's like ordinary news. Five, six video news as well. Weekly diaries from participants. And they blend this in with SMS, which is what you would call, I think you would say messaging or text messaging in your phone, but that's SMS for me.

And they bring this with ringtones and images, whatever it is. And on top of this, of course, they have all the other offerings like videos, whatever it is, from MTV and stuff like that. So the pricing for this is sold as subscriptions. So what you do is that you buy a Big Brother subscription, and you pay two euros for 24 hours to be able to watch that, or five euros for seven days, et cetera. And downloads to your phones were sold separately as a unity price if you wanted to download some very interesting clips from what happened in the different cameras for the shower cam. But anyway. And you have 24/7 publicity.

Every newspaper is talking about this. And this was reproduced, it was the same kind of concept in Italy as well, it worked the same in Italy. Every newspaper was writing about it. And then something happened, the booster, which the person called Olga, which is a woman, and what happened was it got... a thing happened, I'm not going to get into it that much, but it got all the headlines and all the tabloids. Police were involved, which of course in Sweden means that everyone knows about it. They did banners about seeing this blah blah blah, whatever it is, and the police came there and things like that. And they even used it in commercials. So what happens was, after this, 6% of the subscribers bought access immediately as soon as this hit.

And it started about 180,000 live streams. And for you working in Internet, you know, this is extremely good figures for Internet. Even if many people are saying, you know, there's millions of people that can watch it, usually that's not the fact. And average time was about two minutes. And that might sound very little, but it's pretty much, if you consider this in a cell phone, you might be walking around, whatever it is. And of course, it's that last 24 hours, this is some weeks ago actually, so when this presentation was done, they had 13,200 hits that week. And the last 24 hours, and that week they had 47,000 live streams, so it's pretty immense. And here you can see actually what happened, and you can see just where it dips.

And then Olga came into the picture. And it took like four days. So this is a really successful 3G service. So the outcome, of course, was everyone was sharing. Everyone was really, really happy about this. And suddenly, there was a 3G killer app out there that actually worked. It might have been very stupid, but it did work. And it got a lot of attention. So it was a successful PR marketing thing. It had very much high usage, and it had an international rollout as well. So this is one of the few sources I've seen work, because it was also cross-- I don't know what to say-- cross media. It was in newspapers.

It was on the internet. It was on the cell phones, wherever it is. So this was really, really working. So in this case, the technical setup was, of course, to create this. And now people are going to kill me, but I'm going to recover from that one as well, is that in this case, they used a product from us actually running on Linux on stream. So they have six feeds coming in directly from the vision mixers going 24/7 which could be accessed by phones. The interesting thing is that in Italy there was a transcoding between RTSP traffic and video conferencing H324M. So in Italy they called the number, they didn't browse, they called the number for different cams and I I think the same thing is going to be set up in UK as well. So this was how it was set up.

But then, of course, the good thing is-- this kind of product will be released on OS X platform very, very shortly. So we'll be able to do this end-to-end on an OS X platform and copy pretty much their concept if you like to. Of course you have to find a stupid show to broadcast, but you can still do this because of the QuickTime Stream service for the 3GPP compliance. So what we're releasing is the 3GPP as we say live and code reports according to ISMA as well. It's FireWire input. And of course, we built it on the XSource because of the reliability, because you need to have uptime. It has to run 24/7. It has to be cost effective. That's the reason why it actually ended up on Linux to start with. But that's also because we're developing on Apple machines, even if it ends on Linux. So for us, it was just a matter of time before we released it on the Apple platform. We can remote control it as well. So the summary, top 10 key success factors is, of course, understand the operator's business. Is it unity price? Is it price per packet? How is the service position? It might sound stupid, but it's very important for you as a content creator to understand that, because that can actually influence you on how you need to create the content. It could be on a very, very low technical level that has to be decided depending on how the business model is. It also is very important that it's integrated towards existence systems, legacy systems, especially on the broadcasting or the media science. It works with their workflow within their production environment. That's another key issue.

So you don't have to take your MPEG-2 and reformat that into an AVI file into whatever it is and blah, blah, put it out and then do it. It has to be able to take it directly from the video server, push it through system, get it out. And of course, quick time in this is also key thing because it can pretty much swallow any kind of format. So it's very, very important to have that kind of workflow.

Time to show time. Breaking news must be breaking news. If you have a setup, a system, a way of doing this, that breaking news takes three hours, it's not breaking news. It has to be there in one minute. And I can tell you, if you buy a subscription for breaking news to your cell phone, you're pretty much expected to get it before everyone else, because it's a cell phone. I'm moving around, and that's the whole idea with being mobile and getting this kind of news.

Make sure that the formats are fully compatible with 3GPP and 3GPP2. I know there are proprietary formats out there that works in cell phones, but all cell phones on the market support at least 3GPP or 3GPP2. And the division between 3GPP and 3GPP2 is that 3GPP is basically used in Europe and Asia, and 3GPP2 on the American continent. In Japan, you have both operators which do 3GPP2 and 3GPP, but in general, 3GPP Europe, Asia, 3GPP2M, US. But as you've seen, it's not that much of a difference. But it's very, very important to understand that all phones today do support 3GPP or 3GPP2, and maybe a proprietary performance as well.

Use high quality source. I've said this like 10 times. I'm not going to repeat it anymore. Important to understand the network constraints, because you're not really used to this if you're doing this for internet or whatever it is. It's like, understand the limitations. Make sure you know what's happening on the firewall side. Do you have x amount of gateways? Is there any limitations in your gateways? And really get that kind of understanding. Usually, the operator might not tell you, but if you can find out see how is things prioritized.

Have you prioritizing scheme for how someone gets into a cell. Of course the obvious one is optimize the compression for distribution for wireless networks and for the display in mobile phones. And always start with using as little pre-processing as possible. Only use like D-interlacing to start with and see what's happening in the phone because it's a slow screen and many times I see people use a lot of blur and things like that because they also compare it as I said in QuickTime, but watch it on the phone before you do that.

Streaming versus download, always treat a download as a stream when we talk about this. If you do 64 kilobits, set it to 64 kilobits. But you don't have to be as constrained as dropping a lot of frames and using very, very low video buffer verifiers. But you should always treat it as a download file, except if your operator says, well, go ahead, do whatever you like. But I think that that will be key of you letting the operator know that for a fact, this will cost you more if I do kind of big flaws. And of course, be the expert, because no matter what you've heard people say here, probably here and other places, is that the operators carriers, this is a completely new business to them. They are used to handling speech and having radio networks and they just barely started using IP networks and being sort of IP bit pipes. So try to be the expert because that's what they really need and make sure that they do understand all the complexity about production and of course the most most most important is test this is this is new to you as well this is new for everyone and it's going very very fast at this point all developments it's really important to test out to see both from technical point of view and also to see is this a good service did it work out is it really good to do this music video, maybe we should do something else, whatever it is. So I think that is the key thing. So that's it.