[vlc] Re: videolan over a gprs connection

[galenz at zinkconsulting.com]

Eric,

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.

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.

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.

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 http://phonescoop.com/ ) 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.

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.

Sorry for this lengthy email, but GPRS really is that complex. And  
we've only discussed the theory so far :)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ( http://www.mobitv.com/ ) and they've done a  
fairly good job of pulling it off - but even that isn't great.

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.

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.

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.

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.

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.

-Galen
galenz at zinkcconsulting.com

On May 20, 2006, at 4:28 AM, Antoine Roussel wrote:

> Hi,
>
> I don't know exactly your test configuration so there are two  
> answers :
>
> 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).
>
> 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.
>
> 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.
>
> If you succeed, I would be interested in your experience feedback.
>
> Antoine
>
> -- 
> _______________________________________
>
> Antoine Roussel
> Telecom Lille Student
>
> CV : http://cv.antoine-roussel.info
> _______________________________________
>
>
> On 5/19/06, Melin Eric-AEM024 <erik at motorola.com> wrote:
> Hi
>
>
> 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.
>
> 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).
>
>
> Thanks
>
> Eric
>
>
> Eric Melin
>
> Centre de Recherche de Motorola - Paris (CRM)
>
> ---------
> Classification POPI:
> [*] GBI     General Business Information
> [ ] MIUO   Motorola Internal Use Only
> [ ] MCP    Motorola Confidential Proprietary
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20060520/8c6d0490/attachment.html>