<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Eric,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm not the absolute expert on VLC, particularly when it comes to configuring streaming, but I am extremely familiar with GPRS and media compression. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>First lets talk about GPRS. Maybe this is redundant to some people, I'm not sure, but I think it might be worth explaining. GSM phone calls are allocated what's called "timeslots" - GSM works by breaking up the frequency into many channels, then each channel is split up into many timeslots. Basically, this means multiple phones can share the single channel by alternating which phone is broadcasting, in such a way that each timeslot represents the same amount of access to RF bandwidth.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>GSM voice calls normally use one timeslot up and one timeslot down. GPRS uses up to four up and four down simultaneously. The exact number is limited by your provider and your hardware. Depending on your signal strength, you will see anywhere from 8 to 20 kbps per timeslot (standard encoding rates: 8, 12, 14.4, 20 kbps). In my experience, I have rarely if ever seen 20 kbps, 12 kbps is a more reasonable assumption. If you are driving, reception makes a big difference, and unless you have amazing coverage and an antenna, you're unlikely to have a stable datarate the whole way.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Providers may limit the number of timeslots you can use, particularly if the network is very busy or you have an "unlimited" data plan. The policies may be determined at the local towers, based on predetermined rules or rules that vary with network load, so you can easily be driving and move from a tower allowing four slots to a tower only allowing two slots. You also need to check up on your hardware (use a site like <A href="http://phonescoop.com">http://phonescoop.com</A>/ ) because most hardware will have some limitations. Usually you'll see it noted like this "4+1" which means four downstream timeslots (so 32 to 80 kbps depending on signal quality.) Sometimes you'll see it listed as "Class 4" which has a distinct meaning. (A quick google search will turn up plenty of pages with elaborate tables about this.) Many classes also have a maximum limit on slots - for example, class 10 allows 4 down and 2 up, but no more than 5 simultaneous connections, so (assuming no network restrictions) you will run at 3+2 or 4+1.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Although this only applies in some areas, particularly the US, there is another protocol called "EDGE" which works just like GPRS but uses a more efficient RF encoding approach allowing better throughput. But all the same ideas apply, and it still works within the same timeslots. Being in the US, I use EDGE regularly, sometimes moving in excess of a GB of data per month. With a class 10 device I have certainly seen 200 kbps downstream many times, but the upstream is not nearly so great.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sorry for this lengthy email, but GPRS really is that complex. And we've only discussed the theory so far :)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As a general rule, you will want to ensure you have the best possible signal quality for a GPRS link. However, no matter what you do, even if you're in a fixed location, you're likely to still see some variation in signal quality. Interference, varying atmospheric conditions, even vehicles and people blocking signal can affect it. If you're moving, it's almost certain that your data rate will be varying, even if you have a fairly large antenna.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>All of this will inevitably cause your data rate to vary, and this is what makes streaming particularly maddening on GPRS. Your data rate may drop to 32 kbps, then jump to 80 kbps as soon as you come around a corner and handoff to a new tower. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The actual data is also in question. If you sit there running a ping, you normally will never drop a packet - GPRS is generally quite good at getting packets through reliably. It's just a question of timing! With an idle GPRS connection you may be getting ping times between 500 and 1200 ms, and literally one packet may take 500 ms and the next 1200 ms. Packets seem to always be delivered in a sequential manner - this is handled like a PPP link on most computers - so the busier the link, the higher the latency overall.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sometimes, you'll get bursts of interference (i.e. tower handoffs, other interference) which interrupt the connection and cause packets to queue up, but the sequential delivery method means that everything generally does get through, unless you have an extreme situation where the packets can't be queued up anymore. (I'm not quite sure what defines these parameters, but it will happen.) Packet dropping on a GPRS connection isn't generally like ethernet or 802.11b/g where you have a rather consistant level of drops, due to a bad link or collisions. With GPRS, Similarly, if you take a call most hardware pauses the connection and queues up packets to a certain extent. I'm not entirely sure at what level the queueing is implemented, but I have seen packets queued for 15 minutes or more during a call, and up to 10 or 15 seconds during a connection, particularly if I'm driving.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Another interesting note - it takes more energy to send data than to receive it, by a good bit. You may be shocked at how fast you go through power on your phone and (in many cases) how hot it gets when you're maxing out the upload for long periods of time. I've even seen a number of phones and cards overheat and freeze or act strange when uploading a lot, particularly with poor signal strength where the phone has to broadcast near maximum power.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The result of all these factors is that GPRS seriously sucks for streaming. If you are going to try it, I would suggest you use substantial buffers, at least several seconds of content or more, if you want a smooth experience, or even "progressive download" of the video if it can be pre-recorded. If you want live, you may just want to use RTSP and realize that you'll have places where it drops and stutters, particularly if both client and server are mobile. (Although you said only the client was mobile.) The very limited bandwidth is also very challenging. A typical good case scenario (4 + 1 at 12 kbps each = 48 kbps down, 12 kbps up) is very similar to streaming over a 56k modem with lots of latency. I'm sure a lot has been written about delivering content to 56k users - and the bottom line is that nothing looks very good, particularly in the days of people watching 720p, 1080i, even 1080p video all over the place.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I would concur with the earlier poster that your provider may filter ports or protocols, but I'm sure that can be negotiated. I have in some cases simply setup an ssh tunnel over WAP ports or other allowed ports to enable connectivity on an otherwise restricted network connection.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As for actual compression, the leader of the pack right now is H.264 from the x264 project. Just like other projects like XviD, it's always improving in quality, so be sure you have a recent version for the encoding machine. Be sure to take advantage of all the features it offers to help reduce bitrate - CABAC, etc. If you don't need the video live, I would strongly suggest two-pass encoding for better quality. This would go ideally with the progressive download model, which is (in my opinion) the most preferred means for delivering smooth playback on a mobile. You just end up a waiting a little longer for it to start if your connection is particularly slow - the variable nature of mobile connections is maddening like that.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The audio is an interesting one. The exact codec you want to use is a little variable, sometimes one codec is actually better suited for a certain type of content, and different content may require vastly different settings or bitrates to sound good. I've been most impressed with AAC-HE ("AAC High Efficiency" - aka AACplus or AAC+) which has some quite impressive performance at low bitrates. I'm not sure if VLC can encode AAC-HE yet, however, but I know it can decode it. Alternatively, I would suggest you look at Ogg Vorbis or regular AAC (usually "AAC Low Complexity"). MP3 is an older audio codec, and has a hard time getting the quality of these newer codecs, particularly at low bitrates, so I would not recommend it.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Hopefully this gives you a start on figuring out how to stream content via GPRS with some modicum of quality. Honestly, I don't know if you'll ever get anything really satisfying out of it. The premier service (at least in the US) for streaming content via mobile networks is MobiTV ( <A href="http://www.mobitv.com">http://www.mobitv.com</A>/ ) and they've done a fairly good job of pulling it off - but even that isn't great. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I have tested MobiTV on my class 10 EDGE device with excellent signal (the best case scenario, basically), plenty of CPU (200 MHz ARM CPU), high res bright screen (320x320), high quality stereo headphones, etc and I found it to be pretty terrible - I have unlimited data, and even it were completely free for the service, I don't think I would watch it. I'd sooner listen to a 64 kbps AAC-HE stream of the audio and just hear it in good quality, instead of the tinny sounding voices on MobiTV and distorted, choppy video images. This is what MobiTV calls a "high frame rate experience" device. GPRS only devices are called "standard frame rate experience" and really look even worse.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Fortunately, I believe there is substantial room for doing better than MobiTV, but it probably would require the progressive download approach using multi-pass VBR encoded content and you spending a great deal of time tweaking all the compression settings to maximize the quality.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I think that mobile video applications are only going to take off when we see wide deployment of UMTS (WCDMA), but that's still a ways away from any substantial penetration in the US market, and internationally suffers from a quagmire of different frequencies and modes that phones must now support to be fully "international" friendly (US UMTS is rolling out at 850 MHz and 1900 MHz, most other UMTS runs at 2100 MHz, and GSM/GPRS/EDGE is deployed at 850, 900, 1800, and 1900 MHz around the world, so now we need a five-band seven-mode phone to work fully internationally! ) Fortunately, mobile bandwidth is only going up while compression is only getting better and better, not to mention that CPU speeds on mobiles are also improving, so the situation is just getting better with time.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Interestingly, in the US we are migrating to all DTV / HDTV and we use ATSC which uses 8VSB modulation, which precludes the reception of HDTV while in motion due to it being very time sensitive and the doppler effect. Currently, analog is suitable for small handheld devices, but mobile displays are now ready for HD content (particularly in-vehicle displays) and the FCC is forcing ALL broadcasters to switch to DTV in the near future. Both of these factors will soon make other mobile networks the only means of delivering TV content to mobile viewers, so I foresee this market is going to quickly become quite competitive. There is an E-VSB protocol on the table from the ATSC commission, standardized in 2004, but I don't know of any broadcasters that have adopted it, and I'm not sure how easily E-VSB can be integrated into existing broadcast equipment, and TV stations are wary of spending even more in digital infrastructure after all they've spent by FCC mandate.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As you can tell, I do have a bit of an interest in this matter and I would actually be curious to see what you end up working out in this arena.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-Galen</DIV><DIV><A href="mailto:galenz@zinkcconsulting.com">galenz@zinkcconsulting.com</A></DIV><DIV><BR><DIV><DIV>On May 20, 2006, at 4:28 AM, Antoine Roussel wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">Hi,<BR><BR>I don't know exactly your test configuration so there are two answers :<BR><BR>If you have a "perfect network" between your 2 GPRS devices, you can send your data over UDP. By using UDP protocol, there isn't transmission control or stat return from the client (indeed it isn't "connection oriented" like TCP). <BR><BR>If you use an operator network, this will be trickier... Some of them allow only few ports and few protocols. In this case, you should use the http protocol. This is a problem, as you said, because of the low upload bandwidth. <BR><BR>Concerning the video codec, the best ratio quality/bit rate is gained by h264. For the audio codec, you an use MP3 or ogg for instance.<BR><BR>If you succeed, I would be interested in your experience feedback.<BR> <BR>Antoine<BR><BR>-- <BR>_______________________________________<BR><BR>Antoine Roussel<BR>Telecom Lille Student<BR> <BR> CV : <A href="http://cv.antoine-roussel.info">http://cv.antoine-roussel.info</A><BR>_______________________________________<BR><BR><BR><DIV><SPAN class="gmail_quote">On 5/19/06, <B class="gmail_sendername">Melin Eric-AEM024 </B> <<A href="mailto:erik@motorola.com">erik@motorola.com</A>> wrote:</SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><DIV> <DIV link="blue" vlink="purple" lang="EN-US"> <DIV><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">Hi</SPAN></FONT></P><DIV><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">I'm trying to use videolan for streaming a video between 2 laptops (one vlc server and one vlc client), the client using a gprs connection to connect to the server.</SPAN></FONT></P><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">I was wondering which would be the most appropriate codecs to use to accommodate the low bandwidth available over gprs (in particular, since the uplink from client to server is particulary low, is there a particular mode in which the videolan signalling from client to server would be minimal).</SPAN></FONT></P><DIV><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">Thanks</SPAN></FONT></P><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">Eric</SPAN></FONT></P><DIV><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;" lang="FR">Eric Melin</SPAN></FONT></P><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;" lang="FR">Centre de Recherche de Motorola - Paris (CRM)</SPAN></FONT></P><P><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;">---------<BR> Classification POPI:<BR> [*] GBI General Business Information<BR> [ ] MIUO Motorola Internal Use Only<BR> [ ] MCP Motorola Confidential Proprietary</SPAN></FONT></P><DIV><FONT face="Arial" size="2"><SPAN style="font-size: 10pt; font-family: Arial;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV><DIV><FONT face="Times New Roman" size="3"><SPAN style="font-size: 12pt;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV><DIV><FONT face="Times New Roman" size="3"><SPAN style="font-size: 12pt;"> </SPAN></FONT><BR class="khtml-block-placeholder"></DIV> </DIV> </DIV> </DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>