Question about framesize value from SDP

Hi Milko,
 
Thank you very much for your reply!
 
>> FrameWidth and FrameHeight should be assumed to match Width and Height if not present.
 
Where will be the appropriate place to put this, our MMF controller or Helix core?
 
Thanks and best regards,
 Carol.

---

From: ext Milko Boic [real.com" eudora="autourl"> mailto:milkoreal.com]
Sent: Monday, May 22, 2006 7:35 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org; clientapps-devhelixcommunity.org
Subject: Re: [Clientapps-dev] Question about framesize value from SDP

At 05:10 PM 5/22/2006, Carol.i.Chennokia.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
     ;    boundary="----_=_NextPart_001_01C67DFD.5E4F920E"

Hi,

We currently have an error that VideoFrameSizeL is returning zero value for streaming MPEG4 3gp format

When I stream a H263 clip, in the SDP from the server I get:
a=Width:integer;176
a=Height:integer;144
a=framesize:96 176-144

And they are set as "Width", "Height", "FrameWidth" and "FrameHeight" property values after being parsed in SDPMediaDescParser.

However, for an MPEG4 clip (in 3GP format), in the SDP there's only:
a=Width:integer;176
a=Height:integer;144

There's no a=framesize attribute line, so "FrameWidth" and "FrameHeight" are not set and HXMMFCtrlImpl::MvpcGetVideoFrameSizeL() will return zero, thus the error.

(1) Why is the framesize attribute not returned in SDP by the server for MPEG4 streams?

I would not generalize for all MPEG4.  You are likely streaming a hinted clip which specifies the data-type (3GPP) specific attributes such as framesize.  As framesize became a requirement later in the spec., there a number of tools that do not include this property in the SDP and server does not enforce its presence but simply obeys what hint-tracks tell it to stream.

For this reason, 3GPP spec. notes that clients need to be prepared for this attribute to be missing.

(2) If framesize value is not available, can I have MvpcGetVideoFrameSizeL() return the "Width" and "Height" instead? These are actually track (view) sizes. Most of the time track size coincide with frame size, so at least they'll be the correct values more often than not, plus it's better than returning zero (which will be the wrong values more often than not).

Yes - as a matter of fact you need to do this. ; FrameWidth and FrameHeight should be assumed to match Width and Height if not present.

The decoder will of course return with the correct frame size but that is too late for MvpcGetVideoFrameSizeL. Putting the functionality in payload format will probably degrade response time and duplicate code - not desired.

In cases where size is not known until packets arrive, you should make best estimate and treat it as dynamic FrameSize change when size becomes known and different from assumed.

Milko

Any comments/suggestions?

Thanks,
 Carol.
_______________________________________________
Clientapps-dev mailing list
Clientapps-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/clientapps-dev

---

From: clientapps-dev-bounceshelixcommunity.org [mailto:clientapps-dev-bounceshelixcommunity.org] On Behalf Of ext Milko Boic
Sent: Tuesday, May 23, 2006 11:32 AM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org; clientapps-devhelixcommunity.org
Subject: RE: [Clientapps-dev] Question about framesize value from SDP

Hi Milko,
 
Thank you very much for your reply!
 
>> FrameWidth and FrameHeight should be assumed to match Width and Height if not present.
 
Where will be the appropriate place to put this, our MMF controller or Helix core?
 
Thanks and best regards,
 Carol.

---

From: ext Milko Boic [real.com" eudora="autourl"> mailto:milkoreal.com]
Sent: Monday, May 22, 2006 7:35 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org; clientapps-devhelixcommunity.org
Subject: Re: [Clientapps-dev] Question about framesize value from SDP

At 05:10 PM 5/22/2006, Carol.i.Chennokia.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
       ;  boundary="----_=_NextPart_001_01C67DFD.5E4F920E"

Hi,

We currently have an error that VideoFrameSizeL is returning zero value for streaming MPEG4 3gp format

When I stream a H263 clip, in the SDP from the server I get:
a=Width:integer;176
a=Height:integer;144
a=framesize:96 176-144

And they are set as "Width", "Height", "FrameWidth" and "FrameHeight" property values after being parsed in SDPMediaDescParser.

However, for an MPEG4 clip (in 3GP format), in the SDP there's only:
a=Width:integer;176
a=Height:integer;144

There's no a=framesize attribute line, so "FrameWidth" and "FrameHeight" are not set and HXMMFCtrlImpl::MvpcGetVideoFrameSizeL() will return zero, thus the error.

(1) Why is the framesize attribute not returned in SDP by the server for MPEG4 streams?

I would not generalize for all MPEG4.  You are likely streaming a hinted clip which specifies the data-type (3GPP) specific attributes such as framesize.  As framesize became a requirement later in the spec., there a number of tools that do not include this property in the SDP and server does not enforce its presence but simply obeys what hint-tracks tell it to stream.

For this reason, 3GPP spec. notes that clients need to be prepared for this attribute to be missing.

(2) If framesize value is not available, can I have MvpcGetVideoFrameSizeL() return the "Width" and "Height" instead? These are actually track (view) sizes. Most of the time track size coincide with frame size, so at least they'll be the correct values more often than not, plus it's better than returning zero (which will be the wrong values more often than not).

Yes - as a matter of fact you need to do this. ; FrameWidth and FrameHeight should be assumed to match Width and Height if not present.

The decoder will of course return with the correct frame size but that is too late for MvpcGetVideoFrameSizeL. Putting the functionality in payload format will probably degrade response time and duplicate code - not desired.

In cases where size is not known until packets arrive, you should make best estimate and treat it as dynamic FrameSize change when size becomes known and different from assumed.

Milko

Any comments/suggestions?

Thanks,
 Carol.
_______________________________________________
Clientapps-dev mailing list
Clientapps-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/clientapps-dev