QuickTime • 50:55
Professional mobile content services are a viable business in the U.S. and abroad. View this session to learn tips and techniques for editing and encoding multimedia for mobile downloading or streaming, using a variety of tools available in today's market.
Speakers: Aliza Hutchison, Kay Johansson
Unlisted on Apple Developer site
Transcript
This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.
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. And 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 product that we do as well. So that's just a brief example. National.
[Transcript missing]
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, etc. 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 operator comes and says, 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.
And they 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 the 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 internet sign because the codex 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 who's actually doing that. So that's one of the things that is very, very important, is to create content that is workable, cell phones 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 the 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 from wireless 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 with QuickTime tools and is in this kind of community, you know this, that the more you should compress it, the smaller 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'm saying 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.
You should, and you can of course use semi-compressed formats and where you've done, you know, 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.
Noisy VHS 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 bit rate 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.5G. In U.S. you have Edge, which is also 2.5G. Usually GPRS or Edge or something like that is about 30 kilobits, 20 kilobits, even if the specifications allow 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 comparison, we have ISMA, which is basically what you would use in QuickDOM 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 specifications 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 on when you do streaming is that in 3GPP, you use LATM packetizing.
In ISMA, you use generic packetizing. So many people sit down and do basic hinting, whatever it is, with their click-time player, and they don't get it to work in old phones because many phones only support according to 3DP 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 bandwidths. You need to be able to do pre-processing, like deinterlacing, maybe do gamma correction, that kind of thing needs to be done as well for cell phones.
Typical thing is to reduce frame rate. And I usually get arguments saying, well, then you get this stuttering video. But the thing is that the 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 that's possible in the encoder. And also using natural key frames. You don't add key frames unless you actually need to do it. So you try to actually get down the amount of key frames. Of course there's a risk with this because if you lose a key frame 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 key frame or not.
[Transcript missing]
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 minutes, you usually have the bit rate, 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, it's still, I mean, 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 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 and in HTTP packets, so that means you can actually send more media data.
and the other two are available on the U.S. and abroad. The next slide is a little bit about the DLM. DLM is a mobile phone that you can use to do a live streaming. 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.
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 supported by old phones at present streaming, so also something to think about which phones can accept streaming. 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 drawbacks 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 argument is it needs, as I say, large stores 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, okay, 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 five, ten minutes for breaking news in your cell phones.
And it's really annoying me even on the Internet today that you usually have this, you know, 56K for more than 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 U.S.
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, etc.
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. So, you need 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, etc. 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 and watch it. I can go back to the producer and say, "Can you make a video for my cell phone?" That's not going to happen either. But at least this is as good source content as you're 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, H.263.
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. So, and you also have, if you move over here for instance, you can do text of course.
If the telephone supports you, you can 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 streaming with this one. But I'm pretty sure that Apple will release LAP packetizing for 3GPP as well, so.
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 times 144, which is QSIF, and 128 times 96, which is subQSIF. 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 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. 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. 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 PAL input 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 JPRS 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 with phones today is that you usually can get three time 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 in 3D PIP. 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 bit rate, you don't really have bit rate 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 in motion jpeg file. But otherwise you have all kind of pre-processing you need to do. Science as well.
[Transcript missing]
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 are also seeing this on wireless networks how hard it is to get the stream through.
I also have frame skip probability of 55%, 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 don't 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, it's level zero.
Since when you're doing an encoder, even if we do our own encoder, the encoder don't see the difference between choosing level one or level zero. So that's why it's a manual thing that you have to do. You have to press to say, you have to write this down as level zero. 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 source file. 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 two.
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. It means that's where the files are going to end. During this process of course I can add on more files, so I can add on for 3D like 64 kilobits or I can actually do on the fly, I can prioritize whatever should be encoded.
[Transcript missing]
The three time slots, 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, it's very, very highly constrained, the stream file to the left side, because I really need to get the bandwidth through. 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 people content on a Mac or PC. The thing is that QuickTime is a great player. It can process.
It can play pretty much whatever, and if it looks crap, it will make it look good. So on sort of a positive/negative way, I'm telling you, you must verify it in your cell phone how it looks. Do not verify it and think, oh, this looks great, because in QuickTime, everything will actually look great.
So that is one of the key things is that really check it. So after a while, you've learned to see that if it looks like this in QuickTime, this is how it will look in the cell phone. And then you can go back to the Mac and try to fix it.
So that's one of the key things. And then you can go back to the Mac and try to fix it. So that's one of the key things is that really check it. So after a while, you've learned to see that if it looks great, because in QuickTime, everything will actually look great.
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.
[Transcript missing]
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 $1,000. You pay $2 for 24 hours to be able to watch that.
Or $5 for seven days, etc. 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 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. 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 happen. 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, you know, 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.
[Transcript missing]
This kind of product will be released on the 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.
Aliza Hutchison, Kay Johansson So what we're releasing is the 3GPP as we say live and recorded, according to ISMA as well. It's fine wire 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. Aliza Hutchison, Kay Johansson But that's also because we're developing on Apple machines, even if it ends up 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's very, 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 designed. It could be on a very, very low technical level that has to be designed.
It also is very important that it's integrated towards existence system 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 a system, get it out. And of course, quick time in this is also a 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 and 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 supports 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, 3GPP2 in the U.S. 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 may be a proprietary format as well.
Use high quality source. I've said this like ten 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. 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 quick time. 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, you know, for a fact, this will cost you more if I do this. So, that's kind of a big false.
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're just barely starting 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 new to you as well. This is new for everyone, and it's going very, very fast at this point, all developments.