[Asterisk-Dev] video in iax2 spec

[Steve Kann]

Derek Smithies wrote:

>Hi,
>
>  
>
>>>I think the RTP header used in H323 for video works very well, and should 
>>>be used in the video packets. Yes, I know RTP headers take up bytes.
>>>However, given that we are sending compressed video, an extra couple of 
>>>bytes are not going to "break the bank".
>>> 
>>>
>>>      
>>>
>>I'm not sure that encapsulating RTP inside of IAX is necessarily going 
>>to be a good idea; you basically will then end up with multiple 
>>timestamps, and stuff like that. I'd just get the data portion (payload) 
>>to be the same, and then it should be as easy to translate the headers 
>>as it is for audio.
>>
>>    
>>
>
>the advantage of putting the rtp header in the video frame is when you are 
>changing voip protocols (eg, from h323 to iax2) It becomes easy then to 
>get the conversion to work reliably. Which is what we want - is it not - 
>reliability of conversion?
> The second advantage of using the rtp header is that the packet format 
>(across all video formats) becomes consistant.
>  
>
If the IAX2 frame includes all the information that you need to generate 
a RTP frame, the conversion _will_ be simple. I don't think you can just 
pack a RTP frame inside of IAX2, and expect that you can just unpack it 
at the other end without needing to modify it, and have it just work as 
simply as you think.

Of course, the code is there for you to experiment with:

http://cvs.sourceforge.net/viewcvs.py/iaxclient/iaxclient/lib/video.c?rev=1.1&view=auto
Also see the other commits from yesterday. On-the-wire transmission 
doesn't work yet, though, and there's some pieces that are still not 
committed to even build what I have built, but, e.g., the theora payload 
packetization is kinda there (although, it seems there will be a new I-D 
for it).


>>>I think also that the video packetization should be as  consistant  as 
>>>possible for the major video codecs.
>>> 
>>>
>>>      
>>>
>>Hmm, I was aiming for inconsistency. I figured that the payload format 
>>would be some random number of bytes from one frame, then some random 
>>data, and then some random number of bytes from another frame. This 
>>should change with each frame. Sometimes, you should XOR the frame's 
>>data with some other random data too, just for fun.
>>
>>    
>>
>
>Excuse me - aiming for inconsistency?
>Why?
>All the audio codecs are handled in a relatively consistent fashion.
>iax2 header, audio frame data. This makes a decoder simpler to write.
>
>Surely, video should be handled in as consistant a fashion as possible. 
>For H263, there are control packets (which are sent reliably). these can 
>be sent with video IEs (that are yet to be specced.
>
>If the video codecs are handled in a consistant fashion, the code becomes 
>far more readable, easier to maintain, and should be more reliable.
>  
>
I think it should be unreadable, difficult to maintain, and unreliable.

http://en.wikipedia.org/wiki/Sarcasm

>======
>
>
>My question when evaluating a video packetization algorithm is:
>  a)how will it work when doing protocol conversion (iax-h323)
>  b)is it consistant and simple to understand
>  c)is there duplication of information
>  
>