[streaming] Multicast errors: discontinuity at reception

Sat Mar 8 21:43:20 CET 2008

Hi,

2008/3/8, Marshall Eubanks <tme at multicasttech.com>:
>
> The first question I ask in any 802.11 multicast debugging is :
>
> Are you sure that none of your Access points have multicast rate
> limits set ?
>
> (These are in my experience pretty common and generally turned on by
> default.)

I have checked my problem with 4 different devices: an AP Cisco Aironet
1200, a wifi router Zyxel Prestige 600, a Conceptronic wifi router and an AP
Linksys DWL700, having in these similar loss rates. I have searched for
multicast parameters (multicast packets per second rate limit included) to
change but I have found nothing. Should this parameter be available? It
seems strange to me that the Cisco one has only a multicast parameter but
regarded only to bridges (anyway, it was changed just to see if it took any
effect, but it didn't).

The second is a two part question :
>
> Are you aware that all multicasts on your wired LAN will be flooded
> to your wireless LAN, even if there are no recipients for them
> there ? Are
> you sure that there are no high bandwidth multicasts on your wired
> LAN ? (This, AFAICT, is the reason for the multicast rate limit
> defaults.)

I have monitored the radio channel of the APs and the routers to see how
loaded it was with and without the multicast service and they were less than
1 Mbps.

I have gotten decent multicast throughput at 1 Mbps even for 802.11b,
> so it sounds like you have a problem here.
>
>
> On Mar 8, 2008, at 5:01 AM, Javier Gálvez Guerrero wrote:
>
> > Hi,
> >
> > I think I understood the difference between upstream and
> > downstream. What I wanted to point out is that, although the
> > maximum numerical available bandwidth of 802.11g is 54 Mbps, due to
> > issues like listening the channel, overhead data and dividing the
> > channel in downstream and upstream (the AP is receiving for a while
> > and transmitting for another while, isnt'it? Please, let me know if
> > I am confused in this point.), the real data rate that clients can
> > receive is not 54 Mbps, so it is quite lower. But anyway, what I
> > wondered is why should appear such an amount of packet losses if
> > the available bandwidth was high enough to support the stream.
> >
>
>
> There shouldn't be.
>
>
>
> > It's true that wireless links are much less reliable than wired
> > ones, but I thought that this loss rate being quite near the AP was
> > quite high.
>
>
> If the loss rate is high even when you are near the AP, you may have
> RFI issues (i.e., other WLANs, computer to computer networks, etc.).
> These of course would be more or less the same for unicast and
> multicast.

I have checked in three different environments and with different WiFi
channels and always the same results: unicast working pretty well but
multicast (the same video tested in unicast) losing many packets.

> The other thing that seemed strange to me was why MPEG-4
> > transcoding but even increasing the needed multicast streaming
> > bitrate had less error rate.
>
>
> I don't understand this sentence. Please provide some more detail here.

Sorry, I got confused and this had no sense. If I transcode the streamed
file to lower video and audio bitrates the loss rate is decreased as well
(obviously).

Regards
>
> Marshall

Please, let me  know if exists any tool that can configure any wifi
multicast performance parameter.

Thank you,
Javi

>
> >
> > Anyway, thanks for the links and the info; it is much appreciated.
> > Hope VLC can add reliable multicast streaming over wireless links
> > in a near future.
> >
> > Regards,
> > Javi
> >
> > 2008/3/8, Sebastien Chaumontet <sebastien at chaumontet.net>: Wireless
> > is not a wire: on wireless it is normal to get errors/loss.
> >
> > Have you really understood the difference between upstream and
> > downstream behavior in multicast over wireless?
> >
> > http://www.sydneywireless.com/?p=736
> > ------------------
> > The 802.11 (Wi-Fi) standards specify support for multicasting as part
> > of asynchronous services. An 802.11 client station, such as a wireless
> > laptop or PDA (not an access point), begins a multicast delivery by
> > sending multicast packets in 802.11 unicast data frames directed to
> > only the access point. The access point responds with an 802.11
> > acknowledgement frame sent to the source station if no errors are
> > found in the data frame.
> >
> > If the client sending the frame doesn t receive an acknowledgement,
> > then the client will retransmit the frame. With multicasting, the leg
> > of the data path from the wireless client to the access point includes
> > transmission error recovery. The 802.11 protocols ensure reliability
> > between stations in both infrastructure and ad hoc configurations when
> > using unicast data frame transmissions.
> >
> > After receiving the unicast data frame from the client, the access
> > point transmits the data (that the originating client wants to
> > multicast) as a multicast frame, which contains a group address as the
> > destination for the intended recipients. Each of the destination
> > stations can receive the frame; however, they do not respond with
> > acknowledgements. As a result, multicasting doesn t ensure a complete,
> > reliable flow of data.
> >
> > The lack of acknowledgments with multicasting means that some of the
> > data your application is sending may not make it to all of the
> > destinations, and there s no indication of a successful reception.
> > This may be okay, though, for some applications, especially ones where
> > it s okay to have gaps in data. For instance, the continual streaming
> > of telemetry from a control valve monitor can likely miss status
> > updates from time-to-time.
> > ------------------
> >
> > Some solutions are already in TODO list for VLC :
> > https://trac.videolan.org/vlc/ticket/820
> >
> > ---
> > Seb
> >
> >
> > On 3/8/08, Javier Gálvez Guerrero <dulceangustia at gmail.com> wrote:
> > > Hi again,
> > >
> > > I know some multicast wifi behaviour issues that make multicast
> > streaming
> > > less reliable than unicast but what I can not understand is why,
> > if I have
> > > made sure that every network device is working at 54 Mbps in a
> > mandatory
> > > way, with no power save mode but even with the DTIM wifi
> > parameter set at
> > > the minimum (1) and loading the wifi channel with less than 2
> > Mbps of data
> > > (monitored with Wireshark), I have heavy packet losses (1/10
> > packets are
> > > lost in the wifi channel). I know how huge is the wifi overhead,
> > but even
> > > having an effective rate of 36 or 24 Mbps and having the half for
> > upstream
> > > and the other half for downstream, 12 Mbps (let's say 10 Mbps)
> > should be
> > > more than enough to cope with ONE multicast streaming video (less
> > than 400
> > > kbps) with not such errors.
> > >
> > > I have checked it with the client device at less of one meter
> > from the AP
> > > and there are many lost packets, tested in different
> > environments, networks
> > > and with different client devices. If I transcode the streamed
> > files to mp4
> > > 256 kbps video and 128 kbps audio it works pretty well but the
> > whole bitrate
> > > ( 256 + 128 ) is bigger than the original one (333 kbps), what
> > still gets me
> > > more confused. It has something to do that the original video can
> > be encoded
> > > with MPEG-1 or 2? Anyway, how can be possible that I have this
> > amount of
> > > lost packets if I have the radio channel almost "dedicated" with
> > such a
> > > higher available rate than needed?
> > >
> > >
> > > Thank you all,
> > > Javi
> > >
> > > 2008/3/3, Sebastien Chaumontet <sebastien at chaumontet.net>:
> > > > Hi,
> > > >
> > > > Problem with multicast (as broadcast) over wireless is that it
> > is not
> > > reliable:
> > > > In the unicast world, wireless is retransmitting lost packets.
> > > > With broadcast or multicast on wireless (downstream way: from
> > AP to
> > > > clients) if packets are lost they are not retransmitted.
> > > >
> > > > An other behavior is that multicast is used as the rate of the
> > lowest
> > > > client associated with the AP. ie: if all your clients on the
> > AP are
> > > > using 11Mb/s except one at 1Mb/s, multicast and broadcast will
> > be sent
> > > > at 1Mb/s.
> > > >
> > > > Regards
> > > > Seb
> > > >
> > > >
> > > > On Mon, Mar 3, 2008 at 2:53 PM, Javier Gálvez Guerrero
> > > > <dulceangustia at gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I am trying to stream multicast videos through a hybrid
> > wireless-wired
> > > > > network and I am having some problems at wireless clients. I
> > have
> > > checked
> > > > > with differents devices and even with different networks
> > (laboratory and
> > > > > home), but the results are the same: "ts warning:
> > discontinuity received
> > > 0xX
> > > > > instead of 0xX (pid = 68 or 69)" messages, so having some
> > video and
> > > audio
> > > > > interruptions and poor frame decoding results.
> > > > >
> > > > > I stream from a VLC server (through VLM, VLC 0.8.6d), Ubuntu
> > Linux 32
> > > bits
> > > > > based, running in a laptop. It serves RTSP VOD videos and UDP
> > multicast,
> > > > > both configured with VLM telnet interface. It streams via
> > 802.11g at 54
> > > Mbps
> > > > > to a Cisco Aironet 1200 series access point, connected to a
> > switch with
> > > many
> > > > > other computers. Then I have two clients: a desktop and a
> > laptop. The
> > > > > desktop is wired and it receives both VOD and the multicast
> > streams
> > > > > perfectly, but the laptop, connected to the network with 802.11g
> > > receives
> > > > > VOD with no problems but the multicast stream with many
> > discontinuity
> > > > > errors. If I connect the laptop to the wired network the
> > multicast
> > > streams
> > > > > are received with no problems.
> > > > >
> > > > > I configure the scheduled multicast streaming:
> > > > >
> > > > > > new test broadcast enabled
> > > > > > setup test input
> > > /media/sda2/diptv/server/contents/test.mpg
> > > > > > setup test output
> > > #standard{mux=ts,access=udp,dst=239.255.1.5:60101}
> > > > >  > new test_tv schedule enabled
> > > > > > setup test_tv date 2008/02/28-14:50:00
> > > > > > setup test_tv append control test play
> > > > >
> > > > > I have tried with different videos, different wireless
> > receivers,
> > > different
> > > > > 802.11g channels and transmission rates (and many other
> > access point
> > > > > features), streaming from a wired and wireless server, with a
> > WIFI
> > > > > Conceptronic router or a D-Link DWL700 access point instead
> > the Cisco
> > > > > Aironet 1200 and receiving in a Linux or WinXP client with
> > the same
> > > results,
> > > > > the raw of discontinuity errors at receiver. I have also tried
> > > increasing
> > > > > the buffer size of VLC for UDP muxer with no effect.
> > > > >
> > > > > I have launched Wireshark protocol analyzer to track the udp
> > packets on
> > > the
> > > > > wired desktop and on the wireless laptop and the difference
> > are some
> > > random
> > > > > missing packets on the wireless laptop network interface,
> > obvious
> > > losses.
> > > > >
> > > > > So what I would like to know is if somebody has faced this
> > problem with
> > > > > multicast streaming in a wireless environment and, if it has
> > been
> > > finally
> > > > > solved, how to do it. If the solution is a different access
> > point I
> > > would
> > > > > like to know which ones have worked properly with this issue.
> > > > >
> > > > >
> > > > > Thanks a lot.
> > > >
> > > > > _______________________________________________
> > > > >  streaming mailing list
> > > > >  To unsubscribe or modify your subscription options:
> > > > >  http://mailman.videolan.org/listinfo/streaming
> > > > >
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > >  streaming mailing list
> > >  To unsubscribe or modify your subscription options:
> > >  http://mailman.videolan.org/listinfo/streaming
> > >
> > >
> >
> > _______________________________________________
> > streaming mailing list
> > To unsubscribe or modify your subscription options:
> > http://mailman.videolan.org/listinfo/streaming
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/streaming/attachments/20080308/5efae4c3/attachment-0001.htm 