Subject: Re: [Fecframe] D parameter of Non-Interleaved Parity FEC scheme

From: "Guy Bonneau" <[email-masked]>
Date: Mon, 3 Nov 2008 09:31:12 -0500

> 
> I believe you are referring to:
> 
> http://tools.ietf.org/id/draft-ietf-fecframe-1d2d-parity-scheme-00.txt

Yes

> 
> D and L values determine the source block size, which is 
> required for both interleaved and non-interleaved FEC.

So the draft requires that both interleave and non-interleave
FEC streams be tied to a source block size of L x D. Would
this means that the block size needs to be a square aligned 
block size? For example the Annex B of SMPTE 2022-1 2007 
(a close relative of this draft) shows a case of Non-Block 
aligned FEC arrangement. Does this draft also allows this king 
of Arrangement ?

Thanks
Guy Bonneau

_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 3 Nov 2008 15:13:45 -0800

> FEC streams be tied to a source block size of L x D. Would

I am not sure what you mean here. Whatever sending arrangement or block
we choose, there will always be a D and L value for that block. It can
be 5x5, 3x5, 1x5 or 100x1...

In interleaved FEC, it is important which value is L and which one is D.
In non-interleaved, Nx1 is exactly the same thing as 1xN. 

> aligned FEC arrangement. Does this draft also allows this king

We have not defined sending arrangements as it is out of the scope of
our rtp payload format draft. But, regardless, if you wanna use Annex B,
that is possible in our draft, too. It should be clear that in the
arrangement you mention, SMPTE 2022-1 still uses specific L and D
values. With our draft, you should use the same values.

Note that the base SN plus the L&D values uniquely identify the source
packets protected by any given FEC packet.

BR,
-acbegen

---

From: "Guy Bonneau" <[email-masked]>
Date: Fri, 7 Nov 2008 08:50:59 -0500

Thanks Ali for your explanations! 

These clarity my understanding of the specification.

I have 2 more questions! I am still refering to :

So please bear with me.

In section 7.2. The specification provides an example of SDP session.
Since the FEC streams are grouped with a video media type I would have 
expected the media type of both FEC streams to be a video media type. 
Yet the FEC streams are tagged as application. Shouldn't it be video?

I'm trying to understand the usefulness of the Top parameter. I can
deduce that value with the help of the a=group parameters as well as
the media subtype interleaved-parityfec and non-interleaved-parityfec of
the grouped media streams.

Thanks
Guy Bonneau

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Monday, November 03, 2008 6:14 PM
> To: Guy Bonneau; [email-masked]
> Subject: RE: [Fecframe] D parameter of Non-Interleaved Parity 
> FEC scheme
> 
> > > D and L values determine the source block size, which is required 
> > > for both interleaved and non-interleaved FEC.
> > 
> > So the draft requires that both interleave and non-interleave FEC 
> > streams be tied to a source block size of L x D. Would
> 
> I am not sure what you mean here. Whatever sending 
> arrangement or block we choose, there will always be a D and 
> L value for that block. It can be 5x5, 3x5, 1x5 or 100x1...
> 
> > this means that the block size needs to be a square aligned block 
> > size? For example the Annex B of SMPTE 2022-1 2007 (a close 
> relative 
> > of this draft) shows a case of Non-Block aligned FEC 
> arrangement. Does 
> > this draft also allows this king of Arrangement ?
> 
> We have not defined sending arrangements as it is out of the 
> scope of our rtp payload format draft. But, regardless, if 
> you wanna use Annex B, that is possible in our draft, too. It 
> should be clear that in the arrangement you mention, SMPTE 
> 2022-1 still uses specific L and D values. With our draft, 
> you should use the same values.
> 
> Note that the base SN plus the L&D values uniquely identify 
> the source packets protected by any given FEC packet.
> 
> BR,
> -acbegen
>  
> > Thanks
> > Guy Bonneau
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 7 Nov 2008 06:44:51 -0800

Hi Guy, 

> These clarity my understanding of the specification.

Cool.
 
> Since the FEC streams are grouped with a video media type I 
> would have expected the media type of both FEC streams to be 
> a video media type. 

This was a little confusing to me at the beginning as well. The source
is video. However, the FEC we produce from this source is not a video
media, it cannot be treated like it were video. For example, it cannot
be decoded by a video decoder. Other folks on the list may explain this
better than me.

> I'm trying to understand the usefulness of the Top parameter. 

Type of protection (ToP) can be used by the receiver or another 3rd
party entity to control the FEC operations at the sender, i.e., it may
be used to make the sender (or fec encoder) generate the desired FEC
stream(s). Normally, the receiver only needs to check the media types in
the "m" lines to find the stream(s) it is looking for.

BR,
-acbegen

> I can deduce that value with the help of the a=group 
> parameters as well as the media subtype interleaved-parityfec 
> and non-interleaved-parityfec of the grouped media streams.
> 
> Thanks
> Guy Bonneau
> 
> > Subject: RE: [Fecframe] D parameter of Non-Interleaved Parity FEC 
> > scheme
> > 
> > I am not sure what you mean here. Whatever sending arrangement or 
> > block we choose, there will always be a D and L value for 
> that block. 
> > It can be 5x5, 3x5, 1x5 or 100x1...
> > 
> > In interleaved FEC, it is important which value is L and 
> which one is 
> > D.
> > our rtp payload format draft. But, regardless, if you wanna 
> use Annex 
> > B, that is possible in our draft, too. It should be clear 
> that in the 
> > arrangement you mention, SMPTE
> the source

---

From: "Guy Bonneau" <[email-masked]>
Date: Fri, 7 Nov 2008 10:30:19 -0500

Hi Ali,

>                 ...However, the FEC we produce from this 
> source is not a video media, it cannot be treated like it 
> were video. For example, it cannot be decoded by a video 
> decoder. Other folks on the list may explain this better than me.

Please bear with me again. I have implemented the draft of this
specification in a feasibility study to better understand the 
technical issue of implementing FEC with video. So this is somewhat 
a practical issue for me. 

So why having section 5.1.2 to define a registration of 
video/non-interleaved-parityfec? My understanding from your
previous comment is that this is not possible! May be some
other folk on this list could clarify this.

Thanks again
Guy Bonneau

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 10 Nov 2008 18:19:57 -0800

Well, there is some history behind this... But I am not in a position to
explain that.

My understanding is that registration as a subtype of audio, video, text
and application is required because the FEC we generate may relate to
such sessions.

-acbegen

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Guy Bonneau
> Sent: Friday, November 07, 2008 7:30 AM
> To: [email-masked]
> Subject: Re: [Fecframe] D parameter of Non-Interleaved Parity 
> FEC scheme
> 
> Hi Ali,
> 
> source is not 
> > a video media, it cannot be treated like it were video. For 
> example, 
> > it cannot be decoded by a video decoder. Other folks on the 
> list may 
> > explain this better than me.
> 
> Please bear with me again. I have implemented the draft of 
> this specification in a feasibility study to better 
> understand the technical issue of implementing FEC with 
> video. So this is somewhat a practical issue for me. 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Nov 2008 09:24:08 +0100

> and application is required because the FEC we generate may relate to

If the FEC packets are going to be sent in the same RTP session as
source data, then SDP and its scheme to identify the RTP payload type
requires one to have the same main media type, i.e. video, audio,
application etc. Thus for generic mechanism one ends up registering it
in all the main media type for which there exist RTP payload formats.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe