[streaming] Multicast errors: discontinuity at reception
Marshall Eubanks
tme at multicasttech.com
Sat Mar 8 16:34:08 CET 2008
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.)
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 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.
> 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.
Regards
Marshall
>
>
> 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
More information about the streaming
mailing list