Title: H.263
1H.263
2The proposal after reading through h.263
specifications is that we can for this format
have it summarised very easily vcodec_h263_Prof
ileLevel Number The Profile indicates the
decoding capability of handset device. Details
can be seen on page 3. The Level Number will
reduce the need to specify maximum video width
and height, bitrate and frames per second. For a
device to support that profile it should meet the
standard. If it doesnt then my suggestion would
be to say that device doesnt support H.263.
H263 levels are all backwards compatible with
exception of level 45 which just means support of
level 10.
3http//www.itu.int/rec/T-REC-H.263-200501-I/en
H.263 Version AKAs
H.263 H.263_1995 H.263v1
H.263v2 H.263 H.263_1998
H.263v3 H.263H.263_2000
4http//www.itu.int/rec/T-REC-H.263-200501-I/en
5http//www.itu.int/rec/T-REC-H.263-200501-I/en
6X.1 Scope With the variety of optional modes
available in this Recommendation, it is crucial
that several preferred mode combinations for
operation be defined, so that option-enhanced
terminals will have a high probability of
connecting to each other using some syntax better
than the "baseline". This annex contains a list
of preferred feature combinations, which are
structured into "profiles" of support. It also
defines some groupings of maximum performance
parameters as "levels" of support for these
profiles. The primary objectives of this annex
are 1) to provide a simple means of describing
or negotiating the capabilities of a decoder (by
specifying profile and level parameters) 2) to
encourage common enhancement features to be
supported in decoders for achieving maximal
interoperability and 3) to describe feature sets
chosen as particularly appropriate for addressing
certain key applications. The profiles and levels
are defined in the following clauses and in
Tables X.1 and X.2. The minimum picture interval
as specified in Table X.2 is the minimum
difference in time between the decoding of
consecutive pictures in the bitstream. Support of
any level other than level 45 implies support of
all lower levels. Support of level 45 implies
support of level 10.
7X.2.1 The Baseline Profile (Profile 0) The
Baseline Profile, designated as Profile 0, is
defined herein to provide a profile designation
for the minimal "baseline" capability of this
Recommendation. "Baseline" refers to the syntax
of this Recommendation with no optional modes of
operation. This profile of support is composed of
only the baseline design. X.2.4 Version 2
Interactive and Streaming Wireless Profile
(Profile 3) The Version 2 Interactive and
Streaming Wireless Profile, designated as Profile
3, is defined herein to provide enhanced coding
efficiency performance and enhanced error
resilience for delivery to wireless devices
within the feature set available in the second
version of this Recommendation (which did not
include Annexes U, V, and W). This profile of
support is composed of the baseline design plus
the following modes 1) Advanced INTRA Coding
(Annex I) - See X.2.2 item 1. 2) Deblocking
Filter (Annex J) - See X.2.2 item 2. 3) Slice
Structured Mode (Annex K) - The Slice Structured
mode is included here due to its enhanced ability
to provide resynchronization points within the
video bitstream for recovery from erroneous or
lost data. Support for the Arbitrary Slice
Ordering (ASO) and Rectangular Slice (RS)
submodes of the Slice Structured mode are not
included in this profile, in order to limit the
complexity requirements of the decoder. The
additional computational burden imposed by the
Slice Structured mode is minimal, limited
primarily to bitstream generation and
parsing. 4) Modified Quantization (Annex T) -
See X.2.2 item 4. X.2.5 Version 3 Interactive
and Streaming Wireless Profile (Profile 4) The
Version 3 Interactive and Streaming Wireless
Profile, designated as Profile 4, is defined
herein to provide enhanced coding efficiency
performance and enhanced error resilience for
delivery to wireless devices, while taking
advantage of the enhanced features of the third
version of this Recommendation. This profile of
support is composed of the baseline design, plus
the following additional features as follows 1)
Profile 3 - This feature set provides several
enhancements useful for support of wireless video
transmission. 2) Data Partitioned Slice Mode
(Annex V) - This feature enhances error
resilience performance by separating motion
vector data from DCT coefficient data within
slices, and protects the motion vector
information (the most important part of the
detailed macroblock data) by using reversible
variable-length coding. Support of the Arbitrary
Slice Ordering (ASO) and Rectangular Slice (RS)
submodes are not included in this profile, in
order to limit the complexity requirements of the
decoder. 3) Previous Picture Header Repetition
Supplemental Enhancement Information (Annex W,
clause W.6.3.8) - This feature allows the decoder
to receive and recover the header information
from a previous picture in case of data loss or
corruption.
8X.4 Levels of performance capability Eight levels
of performance capability are defined for decoder
implementation. The Hypothetical Reference
Decoder has the minimal size specified in Table
X.1 for all levels of Profiles 0 through 4. In
Profiles 5 though 8 the Hypothetical Reference
Decoder has an increased size and Enhanced
Reference Picture Selection is supported with
multiple reference pictures. Table X.2 defines
the detailed performance parameters of each of
these levels 1) Level 10 - Support of QCIF and
sub-QCIF resolution decoding, capable of
operation with a bit rate up to 64 000 bits per
second with a picture decoding rate up to (15
000)/1001 pictures per second. 2) Level 20 -
Support of CIF, QCIF and sub-QCIF resolution
decoding, capable of operation with a bit rate up
to 2(64 000) 128 000 bits per second with a
picture decoding rate up to (15 000)/1001
pictures per second for CIF pictures and (30
000)/1001 pictures per second for QCIF and
sub-QCIF pictures. 3) Level 30 - Support of CIF,
QCIF and sub-QCIF resolution decoding, capable of
operation with a bit rate up to 6(64 000) 384
000 bits per second with a picture decoding rate
up to (30 000)/1001 pictures per second. 4) Level
40 - Support of CIF, QCIF and sub-QCIF resolution
decoding, capable of operation with a bit rate up
to 32(64 000) 2 048 000 bits per second with a
picture decoding rate up to (30 000)/1001
pictures per second. 4.5) Level 45 Support of
QCIF and sub-QCIF resolution decoding, capable of
operation with a bit rate up to 2(64 000) 128
000 bits per second with a picture decoding rate
up to (15 000)/1001 pictures per second.
Additionally, in profiles other than profiles 0
and 2, support of custom picture formats of size
QCIF and smaller. 5) Level 50 - Support of custom
and standard picture formats of size CIF and
smaller, capable of operation with a bit rate up
to 64(64 000) 4 096 000 bits per second with a
picture decoding rate up to 50 pictures per
second for CIF or smaller picture formats and up
to (60 000)/1001 pictures per second for 352
240 and smaller picture formats. 206 ITU-T Rec.
H.263 (01/2005) 6) Level 60 - Support of custom
and standard picture formats of size 720 288
and smaller, capable of operation with a bit rate
up to 128(64 000) 8 192 000 bits per second
with a picture decoding rate up to 50 pictures
per second for 720 288 or smaller picture
formats and up to (60 000)/1001 pictures per
second for 720 240 and smaller picture
formats. 7) Level 70 - Support of custom and
standard picture formats of size 720 576 and
smaller, capable of operation with a bit rate up
to 256(64 000) 16 384 000 bits per second with
a picture decoding rate up to 50 pictures per
second for 720 576 or smaller picture formats
and up to (60 000)/1001 pictures per second for
720 480 and smaller picture formats. The bit
rate at which a particular profile and level are
used in a system shall never exceed that
specified in this annex. However, particular
systems may include other means to signal further
limits on the bit rate. Other aspects of profile
and level capabilities may also be subject to
additional capability restrictions when used in
particular systems, but the capabilities required
for decoding any bitstream for a particular
profile and level defined herein shall never
exceed those specified in this annex.
Source http//www.itu.int/rec/T-REC-H.263-200501-
I/en
9Mpeg4
10The proposal after reading through mpeg4
specifications is that we can for this format
have it summarised very easily vcodec_mpeg4_Pro
fileLevel Number The Profile is likely to
be SP That will represent the mpeg4 Part 2
Visual Simple Profile. But we may want to
consider adding ASP at a later date (unlikely due
to H.264) The level number will reduce the need
to specify maximum video width, height, and
bitrate. It doesnt have a standard frame rate
per second, however I would recommend that we use
the typical fps table. For a device to
support that profile it should meet the standard
including typical frame-rate. If it doesnt then
my suggestion would be choose a lower level or
state it doesnt support mpeg4. MPEG-4
consists of several standardstermed "parts 2
simple refers a compression codec for visual data
(video, still textures, synthetic images, etc.).
The next part that concerns video is mpeg4 part
10 (or H.264)
11http//www.iis.fraunhofer.de/Images/IISMpeg4VideoS
oftware_v21-1_tcm97-114945.pdf
12Mpeg-4 Part 2
H.264
13- The Simple Profile only accepts objects of type
Simple, and was created with low complexity
applications in mind. The first usage is mobile
use of (audio)visual services, and the second is
putting very low complexity video on the
Internet. Also small camera devices recording
moving video to, e.g., disk or memory chips, can
make good use of this profile. It supports up to
four objects in the scene with, at the lowest
level, a maximum total surface of a QCIF picture.
There are 3 levels for the Simple Profile with
bitrates from 64 to 384 kbit/s.. - The levels also define the maximum total
surface for the objects and the amount of
macroblocks per second that the decoder needs to
be able to decode. Further, they define the size
of various (hypothetical) buffers needed for
decoding. While the maximum total object size is
defined, the aspect ratio is not prescribed. This
gives maximum creative freedom. It could be used
for instance in a personal computer screen, where
a very wide or a very tall object could be
created, or several smaller objects in various
places on the screen, not confined to a typical
QCIF area. The same level philosophy is followed
for restricting the complexity of the natural
video objects in all the visual profiles.
http//www.chiariglione.org/mpeg/faq/mp4-vid/mp4-v
id.htm
14Profile, Level SP, L0 SP, L0b SP, L1 SP, L2 SP, L3 ASP, L0 ASP, L1 ASP, L2 ASP, L3 ASP, L3b ASP, L4 ASP, L5
Max. Bitrate (kbit/s) 64 128 64 128 384 128 128 384 768 1500 3000 8000
Max. Buffer (kbit) 160 320 160 640 640 160 160 640 640 1040 1280 1792
Max. Delay _at_ max. Bitrate (sec) 2.5 2.5 2.5 5 1.66 1.25 1.25 1.66 0.86 0.69 0.43 0.22
Max. VP Size (bit) 2048 2048 2048 4096 8192 2048 2048 4096 4096 4096 8192 16384
Max. VOP Size (MB) 99 99 99 396 396 99 99 396 396 396 792 1620
Max. Decoder Rate (MB/s) 1485 1485 1485 5940 11880 2970 2970 5940 11880 11880 23760 48600
Max. Framesize _at_ 30Hz - - 128x96 256x192 CIF QCIF QCIF 256x192 CIF CIF 352x576704x288 720x576
Max. Framesize _at_ 25Hz - - 144x96 304x192288x208 CIF QCIF QCIF 304x192288x208 CIF CIF 352x576704x288 720x576
Max. Framesize _at_ 24Hz - - 160x96 304x208 CIF QCIF QCIF 304x208 CIF CIF 352x576704x288 720x576
Max. Framesize _at_ 15Hz QCIF QCIF QCIF CIF CIF QCIF QCIF CIF CIF CIF 352x576704x288 720x576
Max. Framesize _at_ 12.5Hz QCIF QCIF QCIF CIF CIF QCIF QCIF CIF CIF CIF 352x576704x288 720x576
http//www.hthoma.de/video/mpeg4_video_tut/index.h
tml
15Visual profile Level Typical visual session size Max. number of objects 1 Maximum number objects per type Max. unique quant. tables Max. VMV buffer size (MB units)2 Max. VCV buffer size (MB)8 VCV decoder rate (MB/s) 4 VCV boundary MB decoder rate (MB/s)9 Max. total VBV buffer size (units of 16384 bits)5 Max. VOL VBV buffer size (units of 16384 bits) Max. video packet length (bits)6 Max. sprite size (MB units) Wavelet restrictions Max. bitrate (kbit/s) Max. enhancement layers per object
Simple10 L0 QCIF 1 1 x Simple 1 198 99 1485 N.A. 10 10 2048 N. A. N. A. 64 N. A.
Simple L1 QCIF 4 4 x Simple 1 198 99 1485 N.A. 10 10 2048 N. A. N. A. 64 N. A.
Simple L2 CIF 4 4 x Simple 1 792 396 5940 N. A. 40 40 4096 N. A. N. A. 128 N. A.
Simple L3 CIF 4 4 x Simple 1 792 396 11880 N. A. 40 40 8192 N. A. N. A. 384 N. A.
http//www.m4if.org/resources/profiles/index.phpM
PEG01A
16Part Number Title Description
Part 1 ISO/IEC 14496-1 Systems Describes synchronization and multiplexing of video and audio. For example Transport stream.
Part 2 ISO/IEC 14496-2 Visual A compression codec for visual data (video, still textures, synthetic images, etc.). One of the many "profiles" in Part 2 is the Advanced Simple Profile (ASP).
Part 3 ISO/IEC 14496-3 Audio A set of compression codecs for perceptual coding of audio signals, including some variations of Advanced Audio Coding (AAC) as well as other audio/speech coding tools.
Part 4 ISO/IEC 14496-4 Conformance Describes procedures for testing conformance to other parts of the standard.
Part 5 ISO/IEC 14496-5 Reference Software Provides software for demonstrating and clarifying the other parts of the standard.
Part 6 ISO/IEC 14496-6 Delivery Multimedia Integration Framework (DMIF).
Part 7 ISO/IEC 14496-7 Optimized Reference Software Provides examples of how to make improved implementations (e.g., in relation to Part 5).
Part 8 ISO/IEC 14496-8 Carriage on IP networks Specifies a method to carry MPEG-4 content on IP networks.
Part 9 ISO/IEC 14496-9 Reference Hardware Provides hardware designs for demonstrating how to implement the other parts of the standard.
Part 10 ISO/IEC 14496-10 Advanced Video Coding (AVC) A codec for video signals which is technically identical to the ITU-T H.264 standard.
http//en.wikipedia.org/wiki/MPEG-4
Source http//docs.real.com/docs/rn/whitepapers/C
odecSupport.pdf
17H.264
- (AKA - mpeg4 part 10 or Mpeg4 AVC)
18The proposal after reading through mpeg4
specifications is that we can for this format
have it summarised very easily vcodec_H264_Prof
ileLevel Number The Profile is likely to
be BP That will represent the H264 Baseline
Profile. Unlikely to require any other
profiles. The level number will reduce the need
to specify maximum video width, height, bitrate,
and frame rate per second. See next page table
for profile and level details .
19H.264 Levels (AKA Mpeg4 part 10, Mpeg4 AVC)
Level number Max video bit rate (VCL) for Baseline, Extended and Main Profiles Examples for high resolution _at_ frame rate (max stored frames) in Level
1 64 kbit/s 128x96_at_30.9 (8)176x144_at_15.0 (4)
1b 128 kbit/s 128x96_at_30.9 (8)176x144_at_15.0 (4)
1.1 192 kbit/s 176x144_at_30.3 (9)320x240_at_10.0 (3)352x288_at_7.5 (2)
1.2 384 kbit/s 320x240_at_20.0 (7)352x288_at_15.2 (6)
1.3 768 kbit/s 320x240_at_36.0 (7)352x288_at_30.0 (6)
2 2 Mbit/s 320x240_at_36.0 (7)352x288_at_30.0 (6)
2.1 4 Mbit/s 352x480_at_30.0 (7)352x576_at_25.0 (6)
2.2 4 Mbit/s 352x480_at_30.7(10)352x576_at_25.6 (7)720x480_at_15.0 (6)720x576_at_12.5 (5)
3 10 Mbit/s 352x480_at_61.4 (12)352x576_at_51.1 (10)720x480_at_30.0 (6)720x576_at_25.0 (5)
Profile Description
Baseline Profile (BP) Primarily for lower-cost applications with limited computing resources, this profile is used widely in videoconferencing and mobile applications.
Main Profile (MP) Originally intended as the mainstream consumer profile for broadcast and storage applications, the importance of this profile faded when the High profile was developed for those applications.
Extended Profile (XP) Intended as the streaming video profile, this profile has relatively high compression capability and some extra tricks for robustness to data losses and server stream switching.
source http//en.wikipedia.org/wiki/H.264/MPEG-
4_AVC
20ADDING REMOVING Streaming Values Going on the
Profile and Level theory. We will need to decide
whether we will need to preceed every vcodec with
a container or whether simply advising the
support container will suffice.
Eg stream_format_3gp stream_format_mp4 stream_fo
rmat_flv Or 3gp_stream_H264_BP1b mp4_stream_H26
4_BP1b If people agree with my findings then
the following are no longer needed streaming_vid
eo_max_bit_rate streaming_video_max_video_bit_r
ate streaming_video_min_video_bit_rate
streaming_video_max_frame_rate streaming_3gpp
- this will be superseded by the format 3gp
21ADDING REMOVING Streaming Values The following
finding also suggest the end of the next values.
This suggestion came from (http//tech.groups.yaho
o.com/group/wmlprogramming/message/16024) in 2004
cha_yong2. Itd be useful if this person is still
an active member to get their opinion on what I
found. Its request to be made defunct has been
since (http//tech.groups.yahoo.com/group/wmlprogr
amming/message/19558). Agreed with by Runar
Solberg, David Tolnem, Andrea Trasatti, Zev Blut
and Andrew Davidson. streaming_video_qcif_max_wid
th streaming_video_qcif_max_height
streaming_video_sqcif_max_width
streaming_video_sqcif_max_height
streaming_video_qcif streaming_video_sqcif
But how will we know the size to offer? My
opinion on this is developers should use WURFLs
Display width and height. This may be cause a
little bit of difficulty as it will require the
developer to realise that video can be played on
a device horizontally or vertically, so a screen
240x320 can support 320x240 video.
22ADDING REMOVING Streaming Values Other needed
video fields is audio This is what I am not
sure and would like some opinion on doing the
audio issues of video. Do we really need to have
vcodec and audio codec together? Do we also need
to worry about containers? Or should we say
device supports audio codec only if it supports
it with all vcodecs that can support that
acodec? Eg we can still have wav although 3gp
container will not support that
acodec. streaming_mpeg4_acodec_amr
nb/wb/wb streaming_mpeg4_acodec_amr
nb/wb/wb streaming_mpeg4_acodec_amr
nb/wb/wbstreaming_mpeg4_acodec_aac
lc/ltp/aac/eacc/ streaming_h264_acodec_amr
nb/wb/wbstreaming_h264_acodec_aac
lc/ltp/aac/eacc/ object_inline_streaming Assume
backwards compatibility. Eg if it supports eacc
then it will support all versions of acc. Same
with amr. Then we can kill streaming_video_acodec
_amr streaming_video_acodec_awb
streaming_video_acodec_aac streaming_video_aco
dec_aac_ltp Doing this does mean peoples
logic gets more complicated than a true/false so
I do accept that maybe a negative and needs
discussion but then again video is quite a
complex beast. This way has the benefit of
reducing the number of fields required to be
entered in.
23WURFL Discussion and Questions Summaries Do we
need to differ Local and Streaming Values? Runar
would like confirmation of the requirement to
separate local playback versus streaming for
video support. - Rod suggested this was needed
for iPhone (Which does progressive download and
not handle streaming.) Rod also suggests
streaming have different fps and bitrates.
Comment I wonder if this is due to connection
speed of the device. Itd be good to know if
these device support different levels for
streaming and local playback? If so my theories
are holding true. I do think we need to specify
what formats video streams support Eg.
Streaming_RTSP- True/false Streamign_SDP
True/false http//tech.groups.yahoo.com/group/
wurflvideo/message/56 - Runar http//tech.groups.y
ahoo.com/group/wurflvideo/message/74 Rod Do we
need all those vide sizing values? Miha would
like to have the values streaming_video_max_width
x streaming_video_max_height y Which
pretty much everyone agrees on and has been in
the process of being decommissioned since 2004.
http//tech.groups.yahoo.com/group/wurflvideo/me
ssage/64http//tech.groups.yahoo.com/group/wmlpro
gramming/message/19558
24WURFL Discussion and Questions Summaries I do
know that frame rates can vary depending on codec
and delivery method. H.264 streaming is typically
10 fps, where MPEG4 streaming is 15 fps. MPEG4
playback sometimes supports up to 25 fps. This
means we need streaming_video_max_frame_rate
separated by codec, at least between MPEG4 and
H.264.Rod Monsees (http//tech.groups.yahoo.com/
group/wurflvideo/message/58) Comment Not if
you agree with my profiles and level
theory. ----------------------- Does anyone know
how to detect if a wap browser supports RTSP
links? which wurfl fields?Thanks,Jim
Handy Comment Good question and one from my
knowledge is not available in WURFL. I propose we
need. Unless RTSP is implied by supporting
streaming? Streaming_RTSP- True/false Streamig
n_SDP True/false Also itd be good to have
Streaming_PSS6 True/false These values can
all be found in the User Agent Profile. Pss6
This field this tells us if we can switch between
100kbps and 50kbps, automatically with the
streaming server and standard handset video
clients.
25Jakob did a great job summaries and proposing the
following (http//tech.groups.yahoo.com/group/wur
flvideo/message/127). Be great to get his opinion
on the Video Profile/Levels proposal.
3) Audio processingNew capabilities to
introduce- codec_bit_rate-
codec_sampling_rate- codec_sampling_resolutio
nPossible codec names (with proposed default
bit rates, sampling rates and sampling
resolutions in brackets) aremp3 (96000, 48000,
-)aac (96000, 96000, -)awb (18250, 16000,
-)amr (10200, 8000, -)au (8000, 8000, 8)wav
(64000, 44100, 16)mmf_ma2 (8000, 8000,
-)mmf_ma3 (46000, 48000, -)mmf_ma5 (12000,
12000, -)mmf_ma7 (24000, 24000, -)qcelp (-,
96000, -)evrc (-, -, -)nokia_ringtone (-, -,
-)imelody (-, -, -)digiplug (-, -,
-)compactmidi (-, -, -)xmf (-, -, -)rmf (-, -,
-)sp_midi (-, -, -)midi_polyphonic (-, -,
-)midi_monophonic (-, -, -)mld (-, -, -)smf
(-, -, -)Examplesmp3_bit_rate96000au_samplin
g_rate8000wav_sampling_resolution16
- 2) Video/streaming processingNew capabilities
to introduce- video_vcodec_codec_bit_rate-
video_vcodec_codec_frame_rate-
video_acodec_codec_sampling_rate-
video_acodec_codec_sampling_resolution-
video_acodec_codec_bit_rate-
streaming_video_vcodec_codec_bit_rate-
streaming_video_vcodec_codec_frame_rate-
streaming_video_acodec_codec_sampling_rate-
streaming_video_acodec_codec_sampling_resolution
- streaming_video_acodec_codec_bit_ratePossib
le codec names of visual part (these prefixed
with vcodec) (with proposed default bit rates and
frame rates in brackets) areh263_0 (10547,
10)h263_3 (10547, 10)h264 (10547, 10)mpeg4
(10547, 15)Possible codec names of audio
track (those prefixed with acodec) (with proposed
default bit rates and sampling rates in brackets)
areamr (10200, 8000)awb (18250, 16000)aac
(96000, 96000)aac_ltp (-, 96000)qcelp (-,
96000)Examplesvideo_vcodec_h263_0_bit_rate105
47streaming_video_vcodec_mpeg4_frame_rate15vid
eo_acodec_amr_sampling_rate10200streaming_video_
acodec_qcelp_bit_rate96000
264) Maximum transfer data for streamingNew
capabilities to introduce- streaming_max_data_r
ateDefaults to max_data_rate, which identifies
the maximum speed a device can transfer data.
Additionally we might assumestreaming_max_data_
rate lt max_data_rate,streaming_max_data_rate lt
GENERAL_DEVICE_LIMIT, which is probably around
400 kpbs, depending on the codec.NOTE Since
these speeds are ridiculously fast these days,
the devices simply can not decode the video
streams so fast. Examples include phones such as
SonyEricsson K850i, which can decode at most
200kbps, but supports HSDPA up to 3,6
Mbit/s.----------------------------------Detai
ls on some particular devices posted at the
wurflvideo forum.Samsung D500video_vcodec_mp
eg4_bit_rate196k (with acc) - common for both
audiovideo?video_vcodec_h263_bit_rate128k
(with amr) - common for both audiovideo?Samsung
SGH-E720video_vcodec_mpeg4_bit_rate196kvideo
_vcodec_mpeg4_frame_rate15video_acodec_acc_bit_r
ate128kvideo_acodec_acc_sampling_rate44.1vide
o_vcodec_h263_bit_rate128kvideo_vcodec_h263_fram
e_rate15video_acodec_amr_bit_rate12,2kvideo_ac
odec_amr_sampling_rate8Samsung
SGH-D600evideo_vcodec_mpeg4_bit_rate256kvideo
_vcodec_mpeg4_frame_rate30video_acodec_acc_bit_r
ate128kvideo_acodec_acc_sampling_rate48video_
vcodec_h263_bit_rate196kvideo_vcodec_h263_frame_
rate30video_acodec_amr_bit_rate12,2kvideo_acod
ec_amr_sampling_rate8
27Needs to be re-polled as the question is not a
Yes or No. Are people saying yes to having
different bitrates for different codecs or are
they saying yes to the not? This is most
disputed by some documentation, Miha, Myself and
Jakub Danilewicz , Robn Yes, I think we will
need a different max video bit rate by codec.
Perhaps even a max audio bit rate by codec. We
may also need a max frame rate by video codec. I
know of at least one phone (Motorola Q9h, look at
the Media Guide) which has a 10 fps max for
H.264, but a 15 fps max for MPEG4 and
H.263. Rod
28User Agent profile help
- http//motorola.handango.com/phoneconfig/razrv3xx/
Profile/razrv3xx.rdfltrdfDescription
rdfID"Streaming"gtltrdftyperdfresource"http/
/www.3gpp.org/profiles/PSS/ccppschema-PSS5Streami
ng"/gtltpss5AudioChannelsgtStereolt/pss5AudioChanne
lsgtltpss5VideoPreDecoderBufferSizegt1lt/pss5VideoP
reDecoderBufferSizegtltpss5VideoInitialPostDecode
rBufferingPeriodgt0lt/pss5VideoInitialPostDecoderBu
ff\eringPeriodgtltpss5VideoDecodingByteRategt16000
lt/pss5VideoDecodingByteRategtltpss5RenderingScree
nSizegt176x144lt/pss5RenderingScreenSizegtltpss5Pss
AcceptgtltrdfBaggtltrdfligtapplication/sdplt/rdfligt
ltrdfligtapplication/x-sdplt/rdfligtltrdfligtapplic
ation/x-rtsplt/rdfligtltrdfligtaudio/AMRlt/rdfligtlt
rdfligtaudio/AMR-WBlt/rdfligtltrdfligtaudio/MP4A-LA
TMlt/rdfligtltrdfligtvideo/MP4V-ESlt/rdfligtltrdfli
gtvideo/H263-2000lt/rdfligtltrdfligtaudio/x-pn-reala
udiolt/rdfligtltrdfligtvideo/x-pn-realvideolt/rdfli
gtltrdfligtx-asf-pflt/rdfligt
29Sony Ericsson Video Documentation
This is quite strange as Profile 0 at level 10
shouldn't be able to encode to this specification
or speed. I wonder if the document is wrong or
the backwards compatibility results in increase
load of bitrate for lower profiles.
30Manufacturer video profile documents links
http//developer.motorola.com/docstools/mediaguid
es/archive/http//developer.motorola.com/docstool
s/mediaguides/ http//www.forum.nokia.com/main/res
ources/technologies/audiovideo/av_features/FN\_vid
_table.htmlhttp//developer.sonyericsson.com/getD
ocument.do?docId65158 http//developer.sonyericss
on.com/getDocument.do?docId84942 http//sw.nokia.
com/id/b652e8f2-81d3-435c-a409-725cac7fbb18/Video_
And_Streaming_In_Nokia_Devices_v3_0_en.pdf
Multimedia_Framework_Architecture_in_S60_Devices_
v1_0_en.pdf
31WURFL contributors to video discussion David
Tolnem/Johansson Anders Magnus Andersen Runar
Solberg Miha Valencic Rodney Monsees Luca
PassaniAndrew Davidson Jakub Danilewicz Sabatini
Stefano Andrea Trasatti Discussions in 2004
contributors Cha Yong Andrea Trasatti Zev Blut
Soon Yee Apologies to
anyone I have missed.