Hi Jamie,
Thanks for this useful info. This explains why we were
seeing
a=framesize only for H.263 packetization in our testing.
I took a quick look at the Tech Spec as well as the MP4
video payload
code, it seems that for MP4 (and AVC), the value of
framesize is not
separated into the individual width and height. (for example
if the
value is 100, is it 10x10 or 20x5?) This frame size value is
actually
used for allocating frame buffer memory. Since we need the
separate
FrameWidth and FrameHeight data, we'll still fall back to
the Width and
Height values as confirmed by Milko.
Thanks and best regards,
Carol.
-----Original Message-----
From: ext Jamie Gordon [mailto:jgordon real.com]
Sent: Wednesday, May 24, 2006 2:55 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas)
Cc: protocol-dev helixcommunity.org; clientapps-dev helixcommunity.org
Subject: Re: [Protocol-dev] Question about framesize value
from SDP
a=framesize is specific to H.263 packetization (see 3GPP TS
26.234).
For MP4V, the frame size is carried in the 'config' data
in the a=fmtp
and must be extracted by the client's
depacketizer/renderer.
Jamie
Carol.i.Chen nokia.com wrote:
> 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?
> (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).
>
> 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.
>
> Any comments/suggestions?
>
> Thanks,
> Carol.
>
>
>
------------------------------------------------------------
----------
> --
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
_______________________________________________
Clientapps-dev mailing list
Clientapps-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/
clientapps-dev
|