[asterisk-video] How do you send large frames?

[John Martin]

Olle,
  Yes the codec chops up the video frames into udp frames.

  So the code below has len &= 0x7ffff in it. That's 32kBytes... that's
a big video packet. I'd have to look at some more of the code to see if
the file read/write is trying to store whole video frames at a time, or
just the UDP frames. What I do remember is that asterisk uses the
timestamps of the frame to determine when it should be read from disk.
Because udp frames within video frames all have the same timestamp they
get read from the disk almost immediately and put out on the wire at
that time. This can lead to overflowing of network equipment and packet
reversal (sorry to bring that up again) at high bitrates.

  Also its technically possible for video frames (not UDP frames) can be
over that 32k size, but encoders would normally be chopping these up
into 1400 byte packets to fit over the internet. I've not ever got
involved in networks that would allow a big MTU to be used but I suppose
a codec could be aware of that and try to use really big UDP frames but
I'm not sure Asterisk should be supporting this.

John

John Martin
John.Martin at AuPix.com
http://www.AuPix.com
Mobile: +44 (0)7976 743995
Office: +44 (0)1275 371700
Direct: +44 (0)1275 378464
SIP:     464 at voip.AuPix.com


-----Original Message-----
From: asterisk-video-bounces at lists.digium.com
[mailto:asterisk-video-bounces at lists.digium.com] On Behalf Of Olle E
Johansson
Sent: 18 May 2006 07:05
To: Discussion of video media support in Asterisk
Subject: Re: [asterisk-video] How do you send large frames?


17 maj 2006 kl. 23.48 skrev John Martin:

> Hi Olle,
>
>  Maybe you missed Duane's post as the mailing lists switched around...
Yes, I did. Sorry.

Just to check that I understand this: The codec divides the frame  
into several RTP frames itself, so we have individual RTP frames?
Then we really need to fix the formats.

 From format_h624.c:

#define BUF_SIZE        4096    /* Two Real h264 Frames */

------
static struct ast_frame *h264_read(struct ast_filestream *s, int  
*whennext)
{
         int res;
         int mark=0;
         unsigned short len;
         unsigned int ts;
         struct h264_desc *fs = (struct h264_desc *)s->private;

         /* Send a frame from the file to the appropriate channel */
         if ((res = fread(&len, 1, sizeof(len), s->f)) < 1)
                 return NULL;
         len = ntohs(len);
         mark = (len & 0x8000) ? 1 : 0;
         len &= 0x7fff;
         if (len > BUF_SIZE) {
                 ast_log(LOG_WARNING, "Length %d is too long\n", len);
                 len = BUF_SIZE; /* XXX truncate */
         }

--------

Seems like we truncate frames bigger than 4096 bytes on reading from  
file. I don't know where that assumption
came from, but the same BUF_SIZE seems to exist in format_h263 as well.

/O

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-video