> -----Original Message----- > From: [email protected] [mailto:asterisk-video- > [email protected]] 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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-video mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-video
