[vlc] Re: videolan over a gprs connection

[Jonas A. Larsen]

I found ur posting very interesting.

So I would basically just like to thank you for explaining the stuff about
mobile technologies. I know that I, and probably others too, learned a lot.

Thanks and cheers

Jonas A. Larsen
 
> 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
> 
> 
> 
> 
> 
> 
> 
> 


-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html