Subject: RE: [IPTEL] h323 and Video

From: "Amar, Yigal" <[email-masked]>
Date: Thu, 5 Oct 2000 16:54:10 +0300

Hi Paul,

Thanks for your answers
I'm reading now the links that you send.
As for the second question ,I understand now that I can't modify the MTYPE
of the first frame just like that. I can't also discard all frames up to
first INTRA
because I've look in the H.261 standard and it allowed up to 132 "P frames"
after one INTRA frame,
which is 13 seconds in a 10fps rate - not good.

I think I saw something in H.245 that says to the far endpoint to generate
an INTRA frame
I need to read more about it.

Thanks 

> -----Original Message-----
> From: Paul Long [mailto:[email-masked]]
> Sent: Thursday, October 05, 2000 3:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Yigal,
> 
> 1) JItter buffers are not required by either audio or video, 
> would benefit
> both, but benefit audio the most because of the more 
> ephemeral nature of
> audio. Receiver-generated jitter estimates are very useful to a video
> encoder and media scheduler. B.14.3/H.245v5 describes the 
> semantics for the
> JitterIndication messages as typically applied to a video 
> channel, and SR/RR
> interarrival jitter described in RFC 1889 is media neutral. 
> Also check out
> sections 4.2 and 4.3 in
> http://www.kashpureff.org/nic/drafts/draft-ietf-mmusic-confarc
> h-00.txt.html
> and especially section 7.3 in
> http://www.tik.ee.ethz.ch/~cobrow/deliverables/d3-2/d3-2.html.
> 
> 2) Whether a frame is INTER or INTRA is indicated in the 
> MTYPE field within
> the H.261 data stream (see Table 2 in the H.261 
> Recommendation). But a frame
> is either an INTER or INTRA frame inherently and cannot be 
> converted from
> one to the other simply by changing the MTYPE, so I wouldn't 
> try to modify
> the stream. If the first frame you recorded is not an INTRA 
> because, for
> example, it got lost in transmission, you might want to 
> search the video
> stream for the first INTRA and discard all frames up to that 
> point before
> re-transmission/playback.
> 
> Hope that helps.
> 
> Paul Long
> Smith Micro Software, Inc.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Amar, Yigal
> Sent: Wednesday, October 04, 2000 11:22 AM
> To: [email-masked]
> Subject: [IPTEL] h323 and Video
> 
> 
> Hi ,
> 
> I have two question , and I hope this is the right place to ask ..
> 
> 1)  why is it that video codecs do not require jitter 
> buffering while audio
> codecs do ??
> 
> 2) I'm cupturing a H.261 video stream and writing it to a file , when
> transmiting/playing back  the
>     h.261 frames from the file, I need to indicate that the 
> first frame is
> an " I frame " , or else the playback is fuzzy.
>     How do I do that  ? is it in the h.261 header or RTP header ??
> 
> 
> 
> Thanks in advance
> 
> 
> 
> Yigal Amar
> 972-3-645-4175
> [email-masked]
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Paul Long <[email-masked]>
Date: Thu, 5 Oct 2000 10:55:07 -0500

Yigal,

Yeah, your original video stream should probably have started with a key
frame (INTRA). Don't know why you don't have one. I have seen some H.323
endpoints, e.g., NetMeeting, loose the first one. To fix it, they just
transmit several at the beginning of a call! :-p

Paul Long
Smith MIcro Software, Inc.

-----Original Message-----
From: Amar, Yigal [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 8:54 AM
To: 'Paul Long'; [email-masked]
Subject: RE: [IPTEL] h323 and Video

Hi Paul,

Thanks for your answers

Thanks

---

From: Satish Bansal <[email-masked]>
Date: Fri, 06 Oct 2000 11:16:01 +0530

Hi all,
I here by request all ,please donot send "thanx" type of mails to every member
of
the mailing list. It will save a lot of time of all users.
thanx
satish