On 12. okt. 2013, at 10:49, Varun Singh <[email protected]> wrote:
> Hi Michael, > > On Sat, Oct 12, 2013 at 11:32 AM, Michael Welzl <[email protected]> wrote: >> >> On 12. okt. 2013, at 08:53, Varun Singh <[email protected]> wrote: >> >>> Hi Michael, >>> >>> In my experience, Video telephony applications do not generate any >>> b-frames. So #2 packets do not exist. Secondly some generate I-frames >>> only when they really have to (scene change or decoding packet chain >>> is corrupted) otherwise their GOP is set to infinity. >> >> But packet importance is more than just I- vs. P- vs. B-Frames - there are >> blocks that depend on each other, and the more data depends on data in a >> packet, the more important that packet gets. >> > > At the moment, some systems use unequal level of protection (UEP) to protect > the packets they think are more important, I suppose what you are proposing is > to add a kill bit in the packets that are less important. Exactly... > I think there is a tradeoff, redundancy causes overhead (which the > endpoint should > control) and adding priorities pushes the responsibility to the > middlebox and in both > the mechanisms, the sender should probably adapt its rate based on > input from the receiver. Exactly >>> For sending I-frames, there are many tricks that a sending endpoint >>> can play, it doesn't need to burst the whole frame immediately, it can >>> pace out (there are 10s of milliseconds) before the next frames is >>> generated. Alternatively, if the frame is too large, they can send >>> parts of the I-frame with the subsequent frames, this potentially >>> delays rendering. I don't know if any of these have been standardized. >> >> Probably no need to standardize this? >> > > Depends where this is done, at the RTP level or elsewhere. If at the RTP level > there probably needs to be some guidance on how the bits are fed to the > decoding > pipeline from the RTP layer. >>> If a part of a frame is lost, the receiver can send a NACK or packet >>> loss indication Or reference picture selection. >>> >>> Another way is that the sending point uses unequal level of protection >>> (ULP) ie., not all packets or frames are FEC'ed. >>> Lastly it can vary the packet size, ie., it may do this by varying the >>> size of slices (combinations of macro blocks). >>> >>> Applicability of ARQ typically depends on observed end-to-end delay >>> and observed losses. The endpoint won't send a nack or a >>> retransmission if there are too many losses or if it thinks it won't >>> reach in time for decoding. >> >> Yes - the choices are really: >> 1. add FEC for the more important packets >> 2. do ARQ when applicable for the more important packets >> 3. somehow tell the network about the more important packets (but you >> can't, normally) >> >> and there are trade-offs between these choices. I just wonder if we need 3. >> as a part of the API to transport? >> > > when you say transport, you mean DSCP codepoint to indicate to the > middleboxes along the path or > an API from the codec to the transport (RTP/UDP) at the sending endpoint? I was really only thinking aloud - but what I was thinking about was indeed a DSCP codepoint that is set because the codec has told the transport about it, in the API, defined by RMCAT. Cheers, Michael
