Hi, i was thinking about FEC (Forward Error Correction) as thats what i heard people use in WAN IPTV Products to protect against low probability ip packet loss. Does anyone of you use something like this today? Does anyone have a client which supports something like this (would need testing) and at which level do you add FEC? Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
In the world of telco grade IPTV installations error correction is done when you have a bad copper pais in your ADSL network. There are 2 ways to do an error correction on a multicast udp/rtp: 1. FEC - you have product from Bitband - additional multicast FEC stream is createad alongside original multicast tv channel stream. STB joins to both streams and when an error occurs on a channel multicast stream it tries to reconstruct missing packets using FEC data. This requires a client on a STB. http://www.bitband.com/general_cat.aspx?CatID=18 This solution is not widely used as it requires more bandwidth than second solution (Cisco VQE aproach). 2. Unicast retransmission of missing packets - Cisco VQE is most popular solution for error correction in the IPTV world. They have many installations around the world. This solution also requires Cisco VQE client on the STB - it is open source (Cisco sells server side equipment). This solution requires tv channels to use multicast UDP/RTP. When a packet is found missing on an STB, VQE client request a retransmission of a packet from VQE server - it knows exactly which packets are missing as it uses RTP sequence numbering. Server sends back required data using unicast. This requires additional bandwidth on top of the tv channel bandwidth, but only at the time of retransmission. Lately there are some other companies offering Cisco VQE based server side solutions (as the protocol itself is open). -- Denis Lackovic On Thu, Sep 30, 2010 at 9:48 AM, Florian Lohoff <f@zz.de> wrote:
Hi,
i was thinking about FEC (Forward Error Correction) as thats what i heard people use in WAN IPTV Products to protect against low probability ip packet loss.
Does anyone of you use something like this today? Does anyone have a client which supports something like this (would need testing) and at which level do you add FEC?
Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iQIVAwUBTKRA4ZDdQSDLCfIvAQgVBA/+IQzLet201zYF7isdU5ftKZarf/oa2Qzi IdH4YpBQjHJmrTuLrAyhWoJWI2fqtW3F6FN61Sjvf0qawf38YU8UQcTcRLly9Raj i8Ztdl2eO2IJDpsbbeDXf9WBH3Tjphxs4d3Zi6Ubk2EHKJCZqZH5Qlo4/7khViL9 +noCzvqVFNnhxPjmG/N2IJuZztWZQYNoLWZZDOyUgA7nHkpVumllQz8hUE7S/G0S gfBXdW7GAqrTTgdXrXzpzQUWzdLQIBSwQY+QaE5tB+EE4pO1oKwypsDIjwQCSBud qJZHOkcSIzOEfX1BEgqWqu87oIlLbNj/r+3YT+Wt0Xcepr+qLoLSudGqNbZxkWGC RPwUhesiur1ig5xMwbc8bm3irjjtR4y6HCDl8G0Q/b12AOZO9EL/tpUkUJ2AnzLI NdGebhICntebHZybYkNXJ+OYSn9+uZwQOmWJSacrrObd0YTYZh6Lk8H8tpZzzamA +jYPHm00AVraIBJa0Sx25rnXVUyVgkEL1SkqlGdiXQ+7xET54W0EY2gVypj+b2/P YzNDkZfbISB82dg8wHHLEAc0XaUWhCEEcqgR8Uj7wbUV2fx/To18py1pS+5zoJVh IvzyqWdYOTnuKXTPcspyKF1yvSlx5H8YvrFk4kF35FRtgVD4LOUE25huMSwDRQWl 8LWiKg6c4sM= =su8N -----END PGP SIGNATURE-----
_______________________________________________ Getstream mailing list Getstream@gt.owl.de http://gt.owl.de/mailman/listinfo/getstream
-- Denis Lackovic
On Thu, Sep 30, 2010 at 10:15 AM, Denis Lackovic <denis.lackovic@iskon.hr> wrote:
2. Unicast retransmission of missing packets - Cisco VQE is most popular solution for error correction in the IPTV world. They have many installations around the world. This solution also requires Cisco VQE client on the STB - it is open source (Cisco sells server side equipment).
This solution requires tv channels to use multicast UDP/RTP. When a packet is found missing on an STB, VQE client request a retransmission of a packet from VQE server - it knows exactly which packets are missing as it uses RTP sequence numbering.
Server sends back required data using unicast. This requires additional bandwidth on top of the tv channel bandwidth, but only at the time of retransmission.
I prefer RTP retransmissions over FEC too. Especially because it's similar to RTP Bursts for rapid channel changing. I looked into this topic some time ago, for me cisco's VQE seems to be the way to. RTP Retransmission specification: http://www.ietf.org/rfc/rfc4588.txt VQE-Client reference implementation: ftp://ftp-eng.cisco.com/ftp/vqec/ Rapid synchronization related specs (I'm not sure how it's implemented by VQE): http://tools.ietf.org/html/draft-ietf-avt-rapid-rtp-sync-12 http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-... http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-15
Lately there are some other companies offering Cisco VQE based server side solutions (as the protocol itself is open).
Do you have some links for me? I couldn't find anything. Anyone knows about an open source VQE-Server implementation?
On Thu, Sep 30, 2010 at 01:26:40PM +0200, Frederik Kriewitz wrote:
I prefer RTP retransmissions over FEC too. Especially because it's similar to RTP Bursts for rapid channel changing. I looked into this topic some time ago, for me cisco's VQE seems to be the way to.
Okay - so basically in the SDP you see the definition of the history buffer on the streaming source. Once you see gaps in the RTP sequence numbers you request the retransmission of those sequence numbers. I guess this request is done unicast to the source address of the multicast stream. Or is the VQE server listed in the SDP? Doesnt seem to be too complicated. Does anyone have a comparison on fec/vqe induced receiver delay? I mean the VQE delay has to be something like 2*rtt between multicast source and receiver. Or will the receiver buffer for the amount of time listed in the SDP to be shure? fec will have some delay too especially when done with large packet interleave. Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
On Thu, Sep 30, 2010 at 2:05 PM, Florian Lohoff <f@zz.de> wrote:
On Thu, Sep 30, 2010 at 01:26:40PM +0200, Frederik Kriewitz wrote:
I prefer RTP retransmissions over FEC too. Especially because it's similar to RTP Bursts for rapid channel changing. I looked into this topic some time ago, for me cisco's VQE seems to be the way to.
Okay - so basically in the SDP you see the definition of the history buffer on the streaming source. Once you see gaps in the RTP sequence numbers you request the retransmission of those sequence numbers.
I guess this request is done unicast to the source address of the multicast stream. Or is the VQE server listed in the SDP?
I believe this depends on the implementation. Almost certainly in large (expensive) IPTV installations VQE server is not listed in the SDP - because there is not just one VQE server (due to redundancy), and there are redundant receivers going into redundant encoders and then they go into (in some cases) redundant streamers. They have existed for a few years when you add your first bunch of VQE servers - which run independent on the rest of the hardware. Probably configuration of which VQE servers are responsible for which channel streams is info transfered to STB during boot process (probably in proprietary way).
Doesnt seem to be too complicated.
Does anyone have a comparison on fec/vqe induced receiver delay? I mean the VQE delay has to be something like 2*rtt between multicast source and receiver. Or will the receiver buffer for the amount of time listed in the SDP to be shure?
I believe STB buffer has to be big enough. I will have one of the implementations (Edgeware) on test next month, so then I wil be able to see how it's implemented.
fec will have some delay too especially when done with large packet interleave.
Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iQIVAwUBTKR9DZDdQSDLCfIvAQhhlQ/+PQrSzJYu/y7oXnO3BJwNeMEfEZ4WPifo FUgp7jNO1saiqPa3Ahxb4F9WamuR8m8pQrZZzfxvHsCOCiLowzXIUSS0mB5AvMlb bdgaLzebFAQFRxhLYb8JSP38xykF/NwcFaPo7pQ4oKdjhZ+C+30hXzSP5z/S3dRn Ut7Js1KOTgfs/7rrLf4A8dCHqnXUm/Dx03Ep31daQ5AosqSmMaW8hK1ZChXWoDma 4nvF2Hq/m0Z7iijZbAHgJN+PHE/i+0eQD4lLG07laEFz6nQ2jlK88gJjJiwyCfwc toGuflQea3/u1RNxKYq2aOdMBB1AjLzDLsXvs1+LC/K98pM1z1eYwmSShdmZWJQ5 6lzuwVj+PZSPu/GVUuweoMQ6ufQG7iYdLIOAyJmWCNgTkon38DHTVu0Gi+/Ju8TP fyGYTWIH8xT9ZdpprgFlW7Sx602vFwcC+/QxvLh1LMqBRX8QrdAQWV62rROKz5uf G8TQIwBqQ39+qG8d2Dd9stYYprKyDWNaOshDyf0HGm4busNVrsSw4iB7NkXcVpqk 9pBFCDDiPiuUajqnXJ54tT4GpRkc9jCzeq3GUy3b/oikKdsDP9SdoiR/pjGDdl2j zxZLSDNnRoMMssitDe1MSxlN5SdX+vRXpNsfiq7Y+/3FrErfp+iFFNV1cpfY62ik wfvCXPL1O5Y= =rWi0 -----END PGP SIGNATURE-----
_______________________________________________ Getstream mailing list Getstream@gt.owl.de http://gt.owl.de/mailman/listinfo/getstream
-- Denis Lackovic
On Thu, Sep 30, 2010 at 04:05:37PM +0200, Denis Lackovic wrote:
I believe this depends on the implementation. Almost certainly in large (expensive) IPTV installations VQE server is not listed in the SDP - because there is not just one VQE server (due to redundancy), and there are redundant receivers going into redundant encoders and then they go into (in some cases) redundant streamers. They have existed for a few years when you add your first bunch of VQE servers - which run independent on the rest of the hardware.
Probably configuration of which VQE servers are responsible for which channel streams is info transfered to STB during boot process (probably in proprietary way).
Which would be no problem - VQE is UDP based so one could easily use anycast to let the IGP decide which Server to use.
I believe STB buffer has to be big enough. I will have one of the implementations (Edgeware) on test next month, so then I wil be able to see how it's implemented.
The point is the delay - Buffer/Memory is not the problem but broadcast delay. Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
On Thu, Sep 30, 2010 at 1:26 PM, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
On Thu, Sep 30, 2010 at 10:15 AM, Denis Lackovic <denis.lackovic@iskon.hr> wrote:
2. Unicast retransmission of missing packets - Cisco VQE is most popular solution for error correction in the IPTV world. They have many installations around the world. This solution also requires Cisco VQE client on the STB - it is open source (Cisco sells server side equipment).
This solution requires tv channels to use multicast UDP/RTP. When a packet is found missing on an STB, VQE client request a retransmission of a packet from VQE server - it knows exactly which packets are missing as it uses RTP sequence numbering.
Server sends back required data using unicast. This requires additional bandwidth on top of the tv channel bandwidth, but only at the time of retransmission.
I prefer RTP retransmissions over FEC too. Especially because it's similar to RTP Bursts for rapid channel changing. I looked into this topic some time ago, for me cisco's VQE seems to be the way to.
RTP Retransmission specification: http://www.ietf.org/rfc/rfc4588.txt VQE-Client reference implementation: ftp://ftp-eng.cisco.com/ftp/vqec/
Rapid synchronization related specs (I'm not sure how it's implemented by VQE): http://tools.ietf.org/html/draft-ietf-avt-rapid-rtp-sync-12 http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-... http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-15
Lately there are some other companies offering Cisco VQE based server side solutions (as the protocol itself is open).
Do you have some links for me? I couldn't find anything. Anyone knows about an open source VQE-Server implementation?
For example Edgeware (edgeware.tv) VQE implementation should be available next month. I'm waiting for a software upgrade to test it myself. They are well known as a VOD server vendor (high performance flash storage based unicast). I'm not aware of an open source VQE server implementation. -- Denis Lackovic
On Thu, Sep 30, 2010 at 01:26:40PM +0200, Frederik Kriewitz wrote:
Lately there are some other companies offering Cisco VQE based server side solutions (as the protocol itself is open).
Do you have some links for me? I couldn't find anything. Anyone knows about an open source VQE-Server implementation?
Writing a VQE-S should be straight forward from what i read here: http://nil.si/ipcorner/VQ_IPTV/ Receiving Multicast RTP and putting it into a ring buffer which then gets queried by RTCP messages is easy. Thats for the error repair path. The Rapid Channel Change is more complicated as one has to look deeper into the TS stream e.g. cache the PAT, PMT and mark the ring buffer for I-Frames. Not that complicated - looks like a ~1000 LOC thing ... Flo -- Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben ....
participants (3)
-
Denis Lackovic -
Florian Lohoff -
Frederik Kriewitz