[Asterisk-video] video RTP question

[Gallmeier, Jonathan]

> -----Original Message-----
> From: asterisk-video-bounces at lists.digium.com [mailto:asterisk-video-
> bounces at lists.digium.com] On Behalf Of Neil Stratford
> Sent: Monday, August 24, 2009 10:38 AM
> To: Development discussion of video media support in Asterisk
> Subject: Re: [Asterisk-video] video RTP question
> 
> 
> > I'm not sure that the marker bit is passed through if the header is
> > stripped. Let me know how to access the marker if it is stored
> > somewhere. I may have just overlooked it when I read the code.
> 
> IIRC it is in fr->subclass:
> 
> if (mark)
>     rtp->f.subclass |= 0x1;
> 
> > The frame rate would also be necessary to update the time stamp. In
> > theory, you could use the system clock to measure time between RTP
> > packet reception. In practice, I don't know how well this works over
> > real networks with packet loss, and real encoders that may drop
> frames
> > due to negotiated bit rate limits. I'll have to think about this
> > carefully for a while.
> 
> I agree - there are likely issues with sequence number jumping as
well.
> The same issues apply to playing video out from a file, so it would be
> nice if it was all done without relying on RTP headers.
> 
> Neil

I was thinking just the opposite, that using the existing RTP headers is
preferred if they exist. My gut response is that I like to keep things
simple. Reproducing headers is not as simple as using what is there. If
you can preserve the RTP header information and re-produce it as it came
in, then I won't complain. I would really want to ensure that the
sequence number order is preserved to allow the endpoints to realize
when they are receiving out of order packets. I would also like to see
similar behavior with timestamps. 

Video files present an interesting set of problems in video aside from
RTP headers. Fast update requests on file data is problematic, as is
handling negotiated bitrates and codec features/profile levels. You
almost want to use Asterisk as an endpoint to play back video, as
opposed to inserting the video into the existing bitstream between two
endpoints. My general take is that the most robust way to handle file
video is to transcode it to whatever is negotiated. This would naturally
handle the fast update request problem as well as deliver bits at the
requested bitrate with the desired codec features. The cost of this
robustness is added compute & memory. There is also a reduction in video
quality. Both of these are problematic for scaling to a very large
system. I don't know where Digium wants to take Asterisk in terms of
video, so my comments may not necessarily apply to your overall goals.
My perspective obviously comes from a different industry.