[vlc] Re: videolan over a gprs connection

[galenz at zinkconsulting.com]

Eric,

That was a fairly long lag between my post and your response.  
Hopefully you weren't reading my incredibly wordy post the entire  
time ;)

I would be curious to know where/why you're on a dedicated network.  
Is this like internal use only? I have a hard time seeing how that  
really equates to what a user would typically experience.

A handful of small points I forgot to make in my earlier post:
1) The TCP/IP stack configuration in the host device/machine can make  
a huge difference with EDGE which is by nature high latency -  
tweaking can improve performance a lot.
2) Sometimes the link to your device can be a problem, either in  
software or hardware. Bluetooth 1.x is limited to at most a megabit  
and I usually only clock it around 25 KB/sec to/from my phone and  
actually most devices. 2.4 GHz interference can that number far  
lower. Many interfaces, even if they are USB or something else, are  
set up as a "serial port" and you need to double check the baud rate  
is right. Having your baud rate set to 57,600 is a pretty big problem!
3) There was a small update made to EDGE a while back (I want to say  
"R2" but I could be wrong) that roughly halved latency. I have seen  
it implemented in PC cards only, and it really did what it claimed to  
do. I'm not sure about network support.

As for link level compression, I don't think it would have a  
substantial impact on throughput. Realize that any video bitstream  
worth its salt already will be compressed. Adding another layer of  
compression will simply add a little latency and be unlikely to save  
any useful amount of bandwidth. However, the added latency is likely  
so small compared to latency associated with EDGE, it is not worth  
mentioning. I normally leave compression on - overall, it reduces the  
effect of EDGE's latency by making compressible data smaller.

If you are having issues with EDGE performance, I would encourage you  
to really investigate the "flow" of the packets. Just watching a  
bandwidth graph on a computer using EDGE can be a very telling  
experience. Even better is to use a program like ethereal and monitor  
how packets arrive compared to how they are sent. I would encourage  
you to try a bunch of tests with this. Even just running a simple  
ping could shed a lot of light on your connection.

If you hit interference or have a poor tower to tower handoff or  
something, you will see the data stop completely for up to 10-15  
seconds sometimes, then resume. Interference also causes problems.  
You will rarely if ever get packets out of order with a connection  
like this, nor do you often get lost packets or "collisions" - the  
packets usually just get buffered and transmitted later if you are  
using a protocol like UDP or ICMP that doesn't have SYN/ACK packets  
that monitor response like TCP/IP. Obviously there is some limit to  
this, but I'm not sure what it is, and I suspect it depends on the  
client, the EDGE hardware, the network, etc.

Hopefully this helps a little. You'll probably want to explore your  
link level stuff some and see how much data you can reliably deliver,  
then once you get that under control, you can start really optimizing  
your video settings. There's a lot you can do there (we can go there  
when you're ready), but you've gotta have the transport worked out  
and a bandwidth budget before you should really try and optimize  
compression.

I will be interested to hear how your test comes out. I would be  
curious to know more about exactly what/why you're attempting to  
achieve here. Feel free to email me off-list.

-Galen

On May 29, 2006, at 1:55 AM, Melin Eric-AEM024 wrote:

> Thanks for taking the time to give all these precious details.
>
>
>
> Since I will use a dedicated EDGE test network, I was confident at  
> the beginning since I would not have to share the bandwidth with  
> many users and the coverage would be good. However, the first  
> results were quite disappointing …
>
>
>
> I will take the advice to use the H264 codec, I will also only  
> transmit video and no sound.
>
> One thing we are currently investigating is whether GPRS  
> compression is activated for data, which would also make a difference.
>
>
>
> One thing to investigate also is the timeslot distribution on this  
> test network, thanks for this advice.
>
>
>
> 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
>
>
>
>
>
> From: galenz at zinkconsulting.com [mailto:galenz at zinkconsulting.com]
> Sent: samedi 20 mai 2006 23:52
> To: vlc at videolan.org; Melin Eric-AEM024
> Subject: Re: [vlc] Re: videolan over a gprs connection
>
>
>
> 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/20060529/e2adfb65/attachment.html>