[vlc] Re: videolan over a gprs connection

[Antoine Roussel]

Galen,

Thanks a lot for this huge summary with an amount of information !

Well written.

Antoine


On 5/20/06, galenz at zinkconsulting.com <galenz at zinkconsulting.com> wrote:
>
> 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
> >
> >
> >
> >
>
>


-- 
_______________________________________

Antoine Roussel
Telecom Lille Student

Tel : + 33 (0)6 82 96 79 81
CV : http://cv.antoine-roussel.info
_______________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20060521/2f60dd2e/attachment.html>