1. H.263

2. The proposal after reading through h.263 specifications is that we can for this format have it summarised very easily; vcodec_h263_{Profile}={Level 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 doesn’t then my suggestion would be to say that device doesn’t support H.263. H263 levels are all backwards compatible with exception of level 45 which just means support of level 10.

3. H.263 VersionAKA’s H.263H.263_1995 H.263v1 H.263v2H.263+ H.263_1998 H.263v3H.263++ H.263_2000 http://www.itu.int/rec/T-REC-H.263-200501-I/en

6. X.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.

7. X.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.

8. X.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

9. Mpeg4

10. The proposal after reading through mpeg4 specifications is that we can for this format have it summarised very easily; vcodec_mpeg4_{Profile}={Level 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 doesn’t 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 doesn’t then my suggestion would be choose a lower level or state it doesn’t support mpeg4. * MPEG-4 consists of several standards—termed "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)codec

11. http://www.iis.fraunhofer.de/Images/IISMpeg4VideoSoftware_v21-1_tcm97-114945.pdf

12. H.264 Mpeg-4 Part 2

13. 1.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-vid.htm

14. Profile, LevelSP, L0SP, L0bSP, L1SP, L2SP, L3ASP, L0ASP, L1ASP, L2ASP, L3ASP, L3bASP, L4ASP, L5 Max. Bitrate (kbit/s) 6412864128384128 384768150030008000 Max. Buffer (kbit) 160320160640 160 640 104012801792 Max. Delay @ max. Bitrate (sec) 2.5 51.661.25 1.660.860.690.430.22 Max. VP Size (bit) 2048 409681922048 4096 819216384 Max. VOP Size (MB) 99 396 99 396 7921620 Max. Decoder Rate (MB/s) 1485 5940118802970 594011880 2376048600 Max. Framesize @ 30Hz --128x96256x192CIFQCIF 256x192CIF 352x576 704x288 720x576 Max. Framesize @ 25Hz --144x96 304x192 288x208 CIFQCIF 304x192 288x208 CIF 352x576 704x288 720x576 Max. Framesize @ 24Hz --160x96304x208CIFQCIF 304x208CIF 352x576 704x288 720x576 Max. Framesize @ 15Hz QCIF CIF QCIF CIF 352x576 704x288 720x576 Max. Framesize @ 12.5Hz QCIF CIF QCIF CIF 352x576 704x288 720x576 http://www.hthoma.de/video/mpeg4_video_tut/index.html

15. Visual 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 restric­tions Max. bitrate (kbit/s) Max. enhancement layers per object Simple 10 L0QCIF11 x Simple1198991485N.A.10 2048N. A. 64N. A. SimpleL1QCIF44 x Simple1198991485N.A.10 2048N. A. 64N. A. SimpleL2CIF44 x Simple17923965940N. A.4040404096N. A. 128N. A. SimpleL3CIF44 x Simple179239611880N. A.4040408192N. A. 384N. A. http://www.m4if.org/resources/profiles/index.php#MPEG01A

16. Source: http://docs.real.com/docs/rn/whitepapers/CodecSupport.pdfhttp://docs.real.com/docs/rn/whitepapers/CodecSupport.pdf http://en.wikipedia.org/wiki/MPEG-4 PartNumberTitleDescription Part 1ISO/IEC 14496-1Systems Describes synchronization and multiplexing of video and audio. For example Transport stream. Part 2ISO/IEC 14496-2Visual 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 3ISO/IEC 14496-3Audio 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 4ISO/IEC 14496-4ConformanceDescribes procedures for testing conformance to other parts of the standard. Part 5ISO/IEC 14496-5Reference Software Provides software for demonstrating and clarifying the other parts of the standard. Part 6ISO/IEC 14496-6Delivery Multimedia Integration Framework (DMIF). Part 7ISO/IEC 14496-7Optimized Reference Software Provides examples of how to make improved implementations (e.g., in relation to Part 5). Part 8ISO/IEC 14496-8Carriage on IP networksSpecifies a method to carry MPEG-4 content on IP networks. Part 9ISO/IEC 14496-9Reference Hardware Provides hardware designs for demonstrating how to implement the other parts of the standard. Part 10ISO/IEC 14496-10Advanced Video Coding (AVC) A codec for video signals which is technically identical to the ITU-T H.264 standard.

17. H.264 (AKA - mpeg4 part 10 or Mpeg4 AVC)

18. The proposal after reading through mpeg4 specifications is that we can for this format have it summarised very easily; vcodec_H264_{Profile}={Level 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.

19. Level number Max video bit rate (VCL) for Baseline, Extended and Main Profiles Examples for high resolution @ frame rate (max stored frames) in Level 164 kbit/s 128x96@30.9 (8) 176x144@15.0 (4) 1b128 kbit/s 128x96@30.9 (8) 176x144@15.0 (4) 1.1192 kbit/s 176x144@30.3 (9) 320x240@10.0 (3) 352x288@7.5 (2) 1.2384 kbit/s 320x240@20.0 (7) 352x288@15.2 (6) 1.3768 kbit/s 320x240@36.0 (7) 352x288@30.0 (6) 22 Mbit/s 320x240@36.0 (7) 352x288@30.0 (6) 2.14 Mbit/s 352x480@30.0 (7) 352x576@25.0 (6) 2.24 Mbit/s 352x480@30.7(10) 352x576@25.6 (7) 720x480@15.0 (6) 720x576@12.5 (5) 310 Mbit/s 352x480@61.4 (12) 352x576@51.1 (10) 720x480@30.0 (6) 720x576@25.0 (5) H.264 Levels (AKA Mpeg4 part 10, Mpeg4 AVC) source: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVChttp://en.wikipedia.org/wiki/H.264/MPEG-4_AVC ProfileDescription 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.

20. ADDING & 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_format_flv Or 3gp_stream_H264_BP=1b mp4_stream_H264_BP=1b If people agree with my findings then the following are no longer needed; streaming_video_max_bit_rate : streaming_video_max_video_bit_rate : streaming_video_min_video_bit_rate : streaming_video_max_frame_rate : streaming_3gpp - this will be superseded by the format 3gp

21. ADDING & REMOVING Streaming Values The following finding also suggest the end of the next values. This suggestion came from (http://tech.groups.yahoo.com/group/wmlprogramming/message/16024) in 2004 cha_yong2. It’d 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/wmlprogramming/message/19558). Agreed with by Runar Solberg, David Tolnem, Andrea Trasatti, Zev Blut and Andrew Davidson.http://tech.groups.yahoo.com/group/wmlprogramming/message/16024http://tech.groups.yahoo.com/group/wmlprogramming/message/19558 streaming_video_qcif_max_width : 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 WURFL’s 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.

22. ADDING & 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_aac : lc/ltp/aac+/eacc+/ streaming_h264_acodec_amr : nb/wb/wb+ streaming_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_acodec_aac_ltp : Doing this does mean people’s 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.

23. WURFL 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. It’d 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/56http://tech.groups.yahoo.com/group/wurflvideo/message/56 - Runar http://tech.groups.yahoo.com/group/wurflvideo/message/74http://tech.groups.yahoo.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/message/64 http://tech.groups.yahoo.com/group/wmlprogramming/message/19558

24. WURFL 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)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} Streamign_SDP = {True/false} Also it’d 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.

25. 2) Video/streaming processing New 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_rate Possible [codec] names of visual part (these prefixed with vcodec) (with proposed default bit rates and frame rates in brackets) are: h263_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) are: amr (10200, 8000) awb (18250, 16000) aac (96000, 96000) aac_ltp (-, 96000) qcelp (-, 96000) Examples: video_vcodec_h263_0_bit_rate=10547 streaming_video_vcodec_mpeg4_frame_rate=15 video_acodec_amr_sampling_rate=10200 streaming_video_acodec_qcelp_bit_rate=96000 3) Audio processing New capabilities to introduce: - [codec]_bit_rate - [codec]_sampling_rate - [codec]_sampling_resolution Possible [codec] names (with proposed default bit rates, sampling rates and sampling resolutions in brackets) are: mp3 (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 (-, -, -) Examples: mp3_bit_rate=96000 au_sampling_rate=8000 wav_sampling_resolution=16 Jakob did a great job summaries and proposing the following (http://tech.groups.yahoo.com/group/wurflvideo/message/127). Be great to get his opinion on the Video Profile/Levels proposal.http://tech.groups.yahoo.com/group/wurflvideo/message/127

26. 4) Maximum transfer data for streaming New capabilities to introduce: - streaming_max_data_rate Defaults to max_data_rate, which identifies the maximum speed a device can transfer data. Additionally we might assume: streaming_max_data_rate <= max_data_rate, streaming_max_data_rate < 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. ---------------------------------- Details on some particular devices posted at the wurflvideo forum. Samsung D500: video_vcodec_mpeg4_bit_rate=196k (with acc) - common for both audio&video? video_vcodec_h263_bit_rate=128k (with amr) - common for both audio&video? Samsung SGH-E720: video_vcodec_mpeg4_bit_rate=196k video_vcodec_mpeg4_frame_rate=15 video_acodec_acc_bit_rate=128k video_acodec_acc_sampling_rate=44.1 video_vcodec_h263_bit_rate=128k video_vcodec_h263_frame_rate=15 video_acodec_amr_bit_rate=12,2k video_acodec_amr_sampling_rate=8 Samsung SGH-D600e: video_vcodec_mpeg4_bit_rate=256k video_vcodec_mpeg4_frame_rate=30 video_acodec_acc_bit_rate=128k video_acodec_acc_sampling_rate=48 video_vcodec_h263_bit_rate=196k video_vcodec_h263_frame_rate=30 video_acodec_amr_bit_rate=12,2k video_acodec_amr_sampling_rate=8

27. Needs 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

28. User Agent profile help http://motorola.handango.com/phoneconfig/razrv3xx/Profile/razrv3xx.rdf Stereo 1 0 16000 176x144 application/sdp application/x-sdp application/x-rtsp audio/AMR audio/AMR-WB audio/MP4A-LATM video/MP4V-ES video/H263-2000 audio/x-pn-realaudio video/x-pn-realvideo x-asf-pf http://motorola.handango.com/phoneconfig/razrv3xx/Profile/razrv3xx.rdfhttp://www.3gpp.org/profiles/PSS/ccppschema-PSS5#Streaming

29. 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. Sony Ericsson Video Documentation

30. http://developer.motorola.com/docstools/mediaguides/archive/ http://developer.motorola.com/docstools/mediaguides/ http://www.forum.nokia.com/main/resources/technologies/audiovideo/av_features/FN\_vid_table.html http://developer.sonyericsson.com/getDocument.do?docId=65158 http://developer.sonyericsson.com/getDocument.do?docId=84942 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 Manufacturer video profile documents links

31. WURFL contributors to video discussion* David Tolnem/Johansson Anders Magnus Andersen Runar Solberg Miha Valencic Rodney Monsees Luca Passani Andrew 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.