WWW : World Wide Wonsama

출처 : http://siking.tistory.com/118

[Event]

컴포넌트에 사용자가 직접 이벤트를 구성하고자 할때 사용한다.

기본 구성 방법은 아래와 같다.

[Event(name="eventName", type="package.eventType")]

아래는 myClickEvent 라는 이름으로 Event라는 이벤트를 만들어 낸 것이다.

[Event(name="myClickEvent", type="flash.events.Event")]

이와같이 이름은 사용자가 원하는 것으로 만들 수 있으며
type은 기본 이벤트 클래스의 Event 또는 서브 클래스 Event중 하나를 사용한다.

아래는 Event 메타데이터를 실제로 사용해본 예제이다.
textInput 에 키를 입력하면 해당 키 코드를 메세지로 출력하고 그 글자를 바로 지워준다.
소스에 나와있듯이 설정한 Event 를 사용자가 지정한 이름으로 mxml에서 불러올 수 있다.

EventTestKeyEvent.mxml
<?xml version="1.0" encoding="utf-8"?> <mx:TextInput xmlns:mx="http://www.adobe.com/2006/mxml" <br /> keyDown="keyDownMethod(event)"> <mx:Metadata> [Event(name="numberCheck", type="flash.events.Event")] </mx:Metadata> <mx:Script> <![CDATA[ import mx.controls.Alert; private function keyDownMethod(e:KeyboardEvent):void { mx.controls.Alert.show( e.charCode.toString() ); this.text = ""; dispatchEvent(new Event("numberCheck")); } ]]> </mx:Script> </mx:TextInput>
EventTest.mxml
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:myComp="*" layout="absolute"> <mx:Script> <![CDATA[ private function eventResult():void { trace('numberCheck Event'); } ]]> </mx:Script> <myComp:EventTestKeyEvent numberCheck="eventResult();" /> </mx:Application>

[Style]

컴퍼넌트의 스타일 properties 의 MXML 태그 속성을 정의할 수 있다.
글자 색, 크기, 백그라운드 색 등등의 style을 지정할 수 있다.

기본적인 문장 구조는 아래와 같다.

[Style(name="style_name"[, property="value",...])]

name String Style 이름을 지정한다. type String 스타일 properties 에 기입하는 값의 데이터형을 지정한다. Number 나 Date 등의 ActionScript 데이터형이 아닌 경우는, packageName.className 라고 하는 형식의 수식 클래스명을 사용한다. arrayType String 데이터형이 Array 인 경우,arrayType 는 Array 요소의 데이터형을 지정한다. Number 나 Date 등의 ActionScript 데이터형이 아닌 경우는, packageName.className 라고 하는 형식의 수식 클래스명을 사용한다. format String properties 의 단위를 지정한다. 예를 들어,데이터형으로서 "Number" 을 지정하는 경우는,format="Length" 를 지정해 스타일의 길이를 픽셀 단위로 정의할 수 있다. 또는,type="uint" 를 지정하는 경우는,format="Color" 를 설정해 스타일의 RGB 칼라를 정의할 수 있다. enumeration String 스타일 properties 의 후보치의 열거형 리스트를 지정합니다. inherit String properties 를 상속 받을 수 있는지 여부를 설정한다. 유효한 값은,yes 및 no 이다.

Flex 내의 Button.as 에는 아래와 같이 사용되었다.

Style 속성을 지정한다.
[Style(name="paddingBottom", type="Number", format="Length", inherit="no")]

getStyle로 paddingButton값을 받아 설정한다.
( 물론 값을 설정하기 위해 더 복잡한 구성으로 되어있지만 간단하게만 나타낸 것이다.)
var paddingBottom:Number = getStyle("paddingBottom");

mxml에서 아래와 같이 사용한다.
<mx:Button paddingButtom="20" />

[IconFile]

Flex Builder 의 [Insert] 바에 있는 컴퍼넌트를 나타내는 이미지를 변경 할 수 있다.

기본 문장 구조는 아래와 같이 구성되어 있다.

[IconFile("fileName")]

Flex 내의 Button.as 에는 아래와 같이 사용되었다.

[IconFile("Button.png")]

[Bindable]

public properties 가 데이터 바인딩식의 소스인 경우, Flex 는 소스 properties 의 변경시에 자동적으로 소스 properties 의 값을 destination properties 에 복사합니다. 다만, 복사를 실행하도록(듯이) Flex 에 통지하기 위해서는,[Bindable] metadata tag 를 사용해 properties 를 Flex 에 등록해, 소스 properties 에 이벤트를 송출(Dispatch)시킬 필요가 있습니다. 라고 FlexDoc에 나와있다.
다시 말해 두개의 서로 다른 data를 연결하여 한쪽에서 값의 변경이 이뤄지면 다른 한쪽에서도
똑같이 값의 변경이 이뤄지게 하는 것이다.

기본 문장 구조는 아래와 같이 구성되어 있다.

[Bindable] [Bindable(event="eventname")]

이벤트 명을 생략하면 자동적으로 propertyChange 라고 하는 이벤트를 생성한다.

사용예는 아래와 같다.

1.

view plaincopy to clipboardprint?
[Bindable]   
public class TextAreaFontControl extends TextArea {}  
[Bindable]
public class TextAreaFontControl extends TextArea {}

클래스에 설정을 하는 경우 클래스 내의 모든 data에 적용이 된다.
이렇게 하는 경우 [Bindable(event="propertyChange")] 와 같은 표현이 된다.

2.

[Bindable] public var maxFontSize:Number = 15; [Bindable] public var minFontSize:Number = 5; 특정 변수에 Bindable을 설정할 수도 있다.

3.

private var _maxFontSize:Number = 15; [Bindable(event="maxFontSizeChanged")] // public getter 메소드를 정의한다 public function get maxFontSize() :Number { return _maxFontSize; } // public setter 메소드를 정의한다 public function set maxFontSize(value:Number) :void { if (value <= 30) { _maxFontSize = value; } else _maxFontSize = 30; // 이벤트 오브젝트를 작성한다 var eventObj:Event = new Event("maxFontSizeChanged"); dispatchEvent(eventObj); } getter/setter에 bindable을 지정할 수도 있다.

[Inspectable]

inspectable은 mxml 코드상에서 코드힌트가 나오도록 정의하는 역할을 한다.
[Inspectable] metadata tag 는, properties 의 변수 선언, 또는 그 properties 에 바인드 되는 setter 및 getter 메소드명 위에 선언할 수 있다.

기본적인 문장구조는 아래와 같다.

[Inspectable(attribute=value[,attribute=value,...])]
property_declaration name:type;

[Inspectable(attribute=value[,attribute=value,...])]
setter_getter_declarations;

properties	데이터형	설명
category	String	properties 를, Flex Builder 유저 인터페이스로 Property inspector 내의 특정의 부범위로 분류합니다.
defaultValue	String 또는 Number	Inspectable properties 의 디폴트치를 설정합니다. 이 properties 는, getter 함수 또는 setter 함수로 사용되는 경우에 필요합니다. 디폴트치는 properties 정의에 의해 정해집니다.
enumeration	String	그 properties 로 허용 되는 정당한 설정치의 칸마 단락 리스트를 지정합니다. item1,item2,item3 등의 값만 지정할 수 있습니다.
environment	String	허용 하지 않는 Inspectable properties (none), Flex Builder 에서만 사용하는 properties (Flash), 또는, Flex 에서만 사용해 Flex Builder 에서는 사용하지 않는 properties (MXML)를 나타냅니다.
format	String	properties 가 값을 파일 패스로 보관 유지하고 있는 것을 나타냅니다.
listOffset	Number	List 치에의 디폴트의 인덱스를 지정합니다.
name	String	properties 의 표시명 (예를 들어,Font Width 등)을 지정합니다. 지정하지 않으면_fontWidth 등의 properties 명이 사용됩니다.
type	String	형태 지정자를 지정합니다. 생략 하면, properties 의 데이터형이 사용됩니다. 사용할 수 있는 값은 다음과 같습니다. Array Boolean Color Font Name List Number Object String properties 가 배열인 경우는, 그 배열로 유효한 값을 리스트 할 필요가 있습니다.
variable	String	이 파라미터를 바인드 하는 대상의 변수를 지정합니다.
verbose	Number	verbose properties 를 포함하도록(듯이) 유저가 지정했을 경우에게만, 이 Inspectable properties 가 Flex Builder 유저 인터페이스에 표시되는 것을 나타냅니다. 이 properties 가 지정되어 있지 않은 경우, Flex Builder 에서는, 그 properties 를 표시하는 것이라고 봅니다.

아래는 실제 사용 방법이다.

[Inspectable(type="String", enumeration="left,right", defaultValue="left)]private var textPlacement:String;이렇게 하면 mxml상에서 해당 컴포넌트를 사용할 때 lt;myComp:TextP textPlacement 라고 하면 left, right값을 설정할 수 있도록 code hint가 보여지게 된다.

[지디넷코리아]동영상 포털 엠엔캐스트가 이달 7일 돌연 서비스를 중단했다. 시스템 점검중으로 9일 낮 12시에 서비스를 재개하겠다는 공지를 띄웠으나 13일인 지금도 '점검중'이란 문구가 올라와 있다.

 

엠엔캐스트는 9일 서비스 재개 약속을 지키지 못한 뒤 12일 저녁 8시로 늦추더니 이를 다시 15일까지 연장한 상황이다.

 

 

 

 

이에 따라 사용자들의 불만이 높아지고 있다. 13일 오전 현재 각종 포털 게시판과 블로그에는 엠엔캐스트를 비판하는 글들이 계속 올라오고 있다.

 

많은 사용자들은 “엠엔캐스트는 얼마나 큰 사고가 터졌기에 서비스를 열흘 가까이 중단하는지 제대로 해명도 하지 않았다”며 “이런 상태라면 다른 동영상 포털로 떠날 수밖에 없다”고 날을 세웠다.

 

엠엔캐스트의 서비스 재개가 자꾸 늦춰지는 이유는 뭘까.

 

시장에는 엠엔캐스트가 자금난으로 동영상 전송 업체(CDN)에 외주 비용을 상당량 밀렸고, 결국 서비스가 강제로 끊겼다는 소문이 정설로 돌고 있다. 엠엔캐스트는 CDN 업체들과 합의점을 찾으려 협상에 나섰지만 난항을 겪고 있다는 것.

 

확인 결과 엠엔캐스트가 유명 CDN 업체 A사와 동영상 운영 관련 협의에 들어간 것은 사실인 것으로 나타났다. 이에 따라 시스템 점검이란 기술적 문제 보다는 외주 업체와의 비즈니스 관계가 서비스 중단 원인이라는 관측에 무게가 실린다.

 

엠엔캐스트 측은 이같은 관측에 대해 말은 아꼈지만 부인도 하지 않았다. 엠앤캐스트 관계자는 “회사 운영진이 외부와 무언가 협의 중인 것은 사실이다”며 “최선을 다하고 있지만 서비스 재개 시점을 확실히 장담할 수는 없는 상황이다”고 밝혔다.

 

자금난과 관련해서는 “모든 공식 입장은 서비스를 정상화 시킨 후에나 내놓을 수 있을 것”이라고 전했다.

동적으로 계속 생성되고 삭제되는 자식 컴포넌트인 경우에는 꼭 createChildren()에 들어갈 필요 없지만
무엇인가 그 컴포넌트의 베이스가 되는 자식 컴포넌트인 경우에는 createChildren()함수에 들어가는 것이 좋습니다.

UIComponent의 createChildren() 메소드에 자식들을 추가하는 것은
UIComponent만의 Life Cycle이 있기 때문입니다.
UIComonent가 처음 생성될때 preinitialize, initialize, addChild, createComplete, updateComplete 와 같은 이벤트를 발생합니다.
그 때마다 createChildren(), measure(), commitProperties(), updateDisplayList()와 같은 함수를 자동으로 호출합니다.
특별히 createChildren()은 이 Life Cycle중에 딱 한번만 호출됩니다. 그래서 자식 컴포넌트를 추가할때
여기에 추가할 것을 권고하고 있습니다.
만약 크기가 조정되는 경우는 measure(), 설정정보가 바뀌는 경우에는 commitProperties(),
화면정보가 바뀌는 경우에는 updateDisplayList()와 같은 함수를 호출하기 위해
각각 invalidateSize(), invalidateProperties(), invalidateDisplayList() 등과 같은 함수를 호출하여
다음 Rendering 시점에 호출되게 만들 수 있습니다.

출처 : http://blog.naver.com/lp7176?Redirect=Log&logNo=30033650104

[지디넷코리아]4세대 이동통신기술 도입은 지금과는 차원이 다른 모바일 서비스를 고객들에게 제공할 수 있다는 의미를 갖는다. 단순한 실시간 비디오 서비스나 네트워크 게임 단계를 넘어 화상회의, 모바일 HDTV등 IMS(IP멀티미디어 서브시스템) 기반의 커뮤니케이션형 복합서비스 제공이 가능하기 때문이다.

 

이 4세대 이동통신기술은 표준에 대한 후보 기술 제안이 2009년 예정되어 있으며 오는 2011년 쯤 서비스가 시작될 전망이다.

 

현재 4세대 이동통신기술의 국제 표준을 선점하기 위해 삼성전자와 KT, SK텔레콤이 주도하는 모바일 와이맥스(Mobile WiMAX : 이하 와이브로) 진영와 노키아 및 유럽의 통신 업체가 주도하는 롱텀에볼루션(Long Term Evolution : 이하 LTE) 진영이 촉각을 곤두세우고 있다.

 

따라서 올해부터 4세대 이동통신기술을 둘러싼 표준 경쟁은 와이브로와 LTE를 중심으로 각 진영간에 세불리기가 본격화되는 양상을 띨 전망이다.

 

■와이브로(Mobile WiMAX)와 롱텀에볼루션(LTE)

 

국제전기통신연합(ITU)은 지난 2005년 4세대 이동통신 기술을 'IMT-Advanced'로 명명했다. 4세대 이동통신은 고속 이동시에 100Mbps 이상, 저속 이동시나 정지 시에 1Gbps 이상의 전송속도가 보장되어야 한다.

 

이를 위해 3GPP(3rd Generation Partnership Project : WCDMA 관련 국제협력기구)와 IEEE(Institute of Electrical and Electronics Engineers : 美전기전자학회) 등은 4세대 이동통신 후보기술 개발 경쟁에 돌입했다.

 

▲ 삼성전자가 개발한 와이브로 단말기를 통해 달리는 버스 안에서 서비스 시연을 하고 있다.

한국전자통신연구원(ETRI)와 삼성전자 등이 와이브로 개발을 진두지휘 한 결과, 지난 2005년 IEEE에 의해 국제표준으로 채택되었고 이후 2007년 10월 국제전기통신연합은 와이브로를 3세대(3G) 이동통신의 6번째 기술표준으로 채택했다. 국내에서는 지난 2006년 전 세계 최초로 와이브로 상용서비스를 시작했다.

 

상용화를 시작한 와이브로는 120Km 정도의 속도에서 최대 다운로드 속도가 37Mbps, 업로드 속도가 10Mbps에 이르고 ADSL 수준의 서비스를 제공하고 있다. 최근에는 기존 와이브로보다 한 단계 더 진화한 와이브로 에볼루션이 등장해 350Km의 속도에서 최대 다운로드 속도 149Mbps, 업로드 속도 43Mbps를 실현해 VDSL 성능에 이르고 있다.

 

이에 반해 LTE는 3세대 이동통신 기술인 WCDMA(HSDPA/HSUPA)에서 진화한 형태로 최대 다운로드 속도가 1Gbps, 업로드 속도가 500Mbps에 이르고 있다. 주로 WCDMA를 이용하는 유럽계 통신업계가 주축이 되어 기술개발에 나서고 있으며 대부분의 유럽 이동통신사들이 4세대 이동통신 기술로 LTE를 최종 선택할 가능성이 높은 상황이다.

 

▲ LG전자는 지난해 말 안양시 소재 LG전자 이동통신기술연구소에서 LTE 단말기용 모뎀칩을 선보였다.

■국내에서는 와이브로가 한 발 앞서···유럽은 대부분 LTE 선호

 

와이브로는 ETRI와 삼성전자가 주축이 되어 개발한 이동통신 기술로, 다른 기술과는 달리 국산 원천 기술이 대거 포함되어 있는 것이 강점이다.

 

와이브로가 4세대 이동통신 표준이 된다면 무한 경쟁의 국제 환경 속에서 원천 기술 확보 및 시장 확보 그리고 수익 증대에 큰 역할을 담당할 것으로 기대된다. 특히 전 세계적으로 표준화가 미래 시장 창출 및 선점을 위한 핵심 수단으로 이용되고 있는 만큼 와이브로가 4세대 이동통신 표준이 된다면 국가 및 기업의 경쟁력 강화와 글로벌 시장에서 살아남을 수 있는 티켓을 손에 쥘 수 있을 전망이다.

 

특히 국내에서는 방송통신위원회가 와이브로에 음성 서비스까지 탑재할 수 있는 주파수 환경을 제공하기로 결정함에 따라 와이브로는 데이터 서비스는 물론 음성 통신 기능까지 제공하게 된다.

 

현재 와이브로 기술을 채택한 국가는 한국을 포함해 총 19개국에 이르고 있으며 도입을 검토 중인 곳까지 포함하면 30여 개국에 이르고 있다.

 

▲ 카드 결제 시스템인 KT의`‘WIBRO 체크라인`을 이용해 카드 결제를 하고 있다. 최근 와이브로 관련 서비스들이 시장에 등장하고 있다.

 

■국내 이통사업자, 4세대 관련 입장 ‘각각 달라’

 

와이브로와 LTE의 대결 양상 속에서 국내 이동통신사업자의 입장도 각각 다르게 나타나고 있다.

 

우선 LG텔레콤은 정일재 LG텔레콤 대표가 4세대 이동통신망 구축을 계획했던 것 보다 빠르게 진행하겠다고 밝히고, 4세대 이동통신 시장 선점을 위한 전략을 마련하고 있다. LG텔레콤은 오는 2013년 4세대 이동통신서비스 상용화를 목표로 하고 있다.

 

이에 따라 LG텔레콤은 올해부터 본격적인 4세대 기술 투자에 나설 계획이지만, 국내에서 4세대 기술방식에 대한 논란이 있는 만큼, 와이브로와 LTE 중  어느쪽으로 투자를 할지는 아직 결정하지 않았다. 다만 지난해 말 LG전자가 세계 최초로 LTE 단말 칩 개발에 성공하면서, LTE쪽으로 기울지 않겠냐는 의견도 일각에서 나오고 있다. LG텔레콤이 LTE 편에 설 경우, LG전자와의 공조로 4세대 이동통신 단말기 수급에도 청신호가 켜질 것으로 예상되기 때문이다.

 

반면 SK텔레콤은 4세대 이동통신 서비스에 관해 아직 구체적인 판단은 내리지 않고 기술적인 검토를 진행중이다. 현재 3세대 이통통신 시장이 안정화 되지 않은 상태라 4세대 이통통신 관련 내용은 조금 이르지 않느냐는 판단이다. 내년이나 내후년 쯤 3세대 이동통신 서비스가 안정화 된 이후 본격적으로 4세대 이통통신서비스 기술 및 서비스 방향의 구체적인 모습을 보여줄 수 있다는 것이다.

 

SK텔레콤 관계자는 “와이브로와 LTE는 상호 보완적인 관계라고 생각한다. 와이브로가 최근 음성 서비스 탑재가 가능하게 됐지만 기반은 데이터 통신이며, LTE는 WCDMA를 기반으로 했기 때문에 만약 4세대 이동통신 시장이 열린다면 서로 보완재적 관계로 발전할 것”이라고 설명했다.

 

▲ SK텔레콤이 제공 중인 와이브로 서비스. SK텔레콤은 4G 이동통신 시대에는 와이브로와 LTE가 상호 보완하는 기술이 될 것으로 보고 있다.

 

KTF의 경우에는 4세대 이동통신서비스가 그리 달갑지만은 않은 상태다. KTF는 3세대 이동통신서비스에 ‘올인’하면서 3세대 이동통신서비스 시장 선두에 앞장섰다. 3세대 이동통신 시장의 주도권을 잡기 위해 막대한 투자를 한 KTF는 4세대 이동통신 시장이 빠르게 열리면 열릴수록 망 투자금 회수에 어려움을 겪을 전망이다.

 

KT와의 입장도 KTF로선 난처한 상황이다. WCDMA 망을 기반으로 제공하던 3세대 이동통신 서비스가 주력이었던 입장에서 KT의 와이브로에만 손을 들어줄 수는 없는 것. 특히 LTE의 경우 WCDMA망을 활용할 수 있고, 다른 기술과의 호환성도 가능하기 때문에 쉽게 결정할 수 있는 부분이 아니라는 판단이다.

 

최근 KTF는 HSPA+망을 구축, 상용화하는 것을 준비 중에 있으며, 이는 4세대 네트워크로 진화하는 단계가 될 것으로 보인다. 2013년 이후에는 4세대 이동통신 상용서비스가 도입될 것으로 예상된다.

 

이에 따라 4세대 이동통신 시장 선점을 위해 포석을 깐 LG텔레콤을 제외하고는 SK텔레콤이나 KTF의 경우 3세대 이동통신 시장을 좀 더 안정화 시키고 고도화 시킨 후에 4세대 이동통신 시장에 진입하려는 분위기다.

 

■와이브로-LTE, '같이 갈까'

 

3세대 이동통신 기술 표준도 ▲비동기식(WCDMA) ▲동기식(cdma2000) ▲TD-CDMA 등 다양한 기술들이 표준으로 결정된 전례를 볼 때, 4세대 이동통신 기술도 표준 조건에 부합한다면 와이브로나 LTE가 기술 표준에 나란히 등극할 것으로 전망된다. 물론 현재까지는 기술적인 측면이나 상용화에 앞선 와이브로가 좀 더 나은 위치에 올라있지만 4세대 이동통신 시장이 열리게 되면 와이브로나 LTE 등 관련 기술 2~3개가 각각 공존하면서 발전할 것으로 예상되는 것.

 

이 경우 결국 와이브로가 LTE보다 기술적 우위에 서거나 글로벌 마켓을 늘리지 않는 이상 노키아와 에릭슨 등 유럽 기업들이 주도하는 LTE가 규모의 경제를 앞세워 와이브로를 넘어설 것이라고 업계는 예상하고 있다.

 

와이브로는 미국을 비롯해 최근 신흥시장을 중심으로 세를 넓혀가고 있다. 이미 와이브로 사업을 진행중인 미국, 일본, 러시아, 브라질을 비롯해 19개국 23개 사업자가 한국의 와이브로를 상용 혹은 시범 사업으로 추진 중이며 10여개 국가 20여개 사업자가 와이브로 도입 여부를 추가로 협의 중이다.

 

최지성 삼성전자 정보통신총괄 사장은 "이미 상용화에 나서고 있는 와이브로 기술 및 관련 단말기를 기반으로 새로운 비즈니스 모델이 다양하게 등장할 것으로 기대된다"며 "이를 통해 더 많은 시장에서 와이브로가 확산 될 수 있을 것"이라고 설명했다.

 

한편 LTE 기술을 주도하고 있는 LG전자 안승권 MC사업 본부장은 "4세대 이동통신 시장에서 LTE 관련 단말 및 기술을 대거 개발해 나가겠다"며 "와이브로는 결국 니치마켓에 머무를 수 밖에 없을 것"이라고 주장했다.
전 세계 이동통신 시장을 주도하고 있는 대부분의 유럽 국가들이 LTE기술을 표준으로 밀고 있다는 판단에서다. 실제로 유럽 시장의 70% 이상이 4세대 이동통신 표준 기술로 LTE를 사용할 의향을 보이고 있다.

 

와이브로 기술을 주도하고 있는 삼성전자는 우선 상용화에 돌입한 와이브로를 주력사업으로 추진하는 동시에 앞으로 LTE 시장이 열리면 그쪽으로도 자원을 집중할 수 있게 한다는 전략이다. 이를 뒷받침하듯이 최근 삼성전자는 LG전자에 이어 자체 개발한 LTE 칩셋을 내년 상반기 쯤 공개할 것으로 알려졌다.

 

국내의 경우에는 최근 주무부처인 방송통신위원회가 와이브로에 음성 서비스 기능을 추가하고 새로운 와이브로 사업자 선정에도 나서고 있어 우리나라가 원천기술을 대거 보유하고 있는 와이브로에 한 표를 던진 상황이다.

 

통신업계 관계자는 "와이브로가 이미 상용화에 들어가는 등 LTE에 비해 1년 정도 빠른 행보를 걷고 있는 상태지만 4세대 이동통신 시장이 열린다면 와이브로나 LTE 등 한쪽 기술에만 쏠리지는 않을 것이다"고 전망하며 "와이브로나 LTE 중 어느 한 쪽이 기술이나 시장의 우위에 서는 순간 다른 한 쪽은 자연스럽게 틈새시장으로 전락할 가능성이 있다"고 전했다.

 

[지디넷코리아]

▲ 신생 IT벤처기업과 기술혁신을 한 회사에게 시상하는 `2009크런치스` 시상식이 10일 미 샌프란시스코에서 열렸다. 이번 행사에서는 MS 라이브메쉬가 기술혁신상을 수상한 것을 비롯, 관련 기업이 16개 부분에서 수상의 영광을 안았다.

 

▲ 구글의 마리사 메이어 부사장이 구글 `RSS Reader`에게 주어진 `최고의 서비스상`을 수상했다.

 

▲ 마이크로소프트 레이 오지 CSA(아키텍처 최고 책임자)는 `최고의 기술혁신상`을 수상했다.

 

▲ 시상식 후 열린 파티에서는 아이폰을 이용한 연주가 진행됐다.

 

▲ 파티 참석자들이 마이크로소프트 태블릿 컴퓨터 주변에 앉아 담소를 나누고 있다.

The Adobe Flash Media Server family of products provides the rich media delivery platform of choice that reaches more people, securely and efficiently, than any other technology. From user-generated content to movies and television shows to corporate training, Flash Media Server (FMS) offers enterprise-level solutions to deliver content and communications.

To help you better understand the streaming functionality of FMS, this article explains the overall FMS server architecture and protocols. It also lists the supported media file types and discusses the differences between the various delivery methods available.

Flash media communication protocol: RTMP

Flash Media Server solutions have both a server-side and a client-side architecture. The client experience is deployed as a SWF or Adobe AIR file created in either Adobe Flash or Adobe Flex. Clients run within a web browser (Flash Player), mobile device (Flash Lite 3), or as a desktop application (Adobe AIR). A client could also be another Flash Media Server, Adobe ColdFusion 8, Adobe Flash Media Live Encoder, or licensed third-party technology that can stream or communicate with Flash Media Server. The server manages client connections and security, reads and writes to the server's file system, and performs other tasks.

The client is the initiator of the connection to the server. Once connected, the client can communicate with the server and with other connected clients. Clients connect to instances of applications; for example, a chat application may have many rooms. Each room is an instance of the chat application. Multiple instances of an application can be running simultaneously. Each application instance has its own unique name and provides unique resources to its connected clients.

Flash Media Server communicates with its clients using the Adobe patented, Real-Time Messaging Protocol (RTMP) over TCP that manages a two-way connection, allowing the server to send and receive video, audio, and data between client and server (see Figure 1). In FMS 3, you also have the option to utilize stronger stream security with encrypted RTMP (RTMPE). RTMPE is easy to deploy and faster than utilizing SSL for stream encryption. RTMPE is just one of the robust new security features in FMS 3. (This will be discussed more in the following sections.)

Figure 1. Flash media server client/server architecture

There are five configurations of RTMP with FMS 3:

• RTMP: This is the standard, unencrypted Real-Time Messaging Protocol. The default port is 1935; if a port is not specified, the client will attempt to connect to ports in the following order: 1935, 443, and then via RTMPT on port 80. Port 1935 is a registered IANA port.
• RTMPT: This protocol is RTMP "tunneled" over HTTP; this means that the RTMP data is encapsulated as valid HTTP data. The default port is 80.
• RTMPS: This protocol is RTMP sent over a secure socket layer (SSL). SSL is a protocol that enables secure TCP/IP connections. (FMS natively supports both incoming and outgoing SSL connections.) The default port is 443.
• RTMPE: This new protocol is an enhanced and encrypted version of RTMP. RTMPE is faster than SSL and does not require certificate management as SSL does. If you specify RTMPE without explicitly specifying a port, Flash Player scans ports just as it does with standard RTMP, in the following order: 1935, 443, 80, and 80 (RTMPTE) (supported with Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player).
• RTMPTE: Flash Media Server 3 introduces this enhanced version of the RTMP protocol which encrypts the communication channel, tunneling over HTTP. The default port is 80 (supported with Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player). The key benefits over SSL (RTMPS) are performance, ease of implementation, and limited impact on server capacity.

Utilizing the appropriate RTMP type, FMS can send streams through all but the most restrictive firewalls, and protect rights-managed or sensitive content from piracy.

Supported file types

Flash Media Server 3 is completely backwards-compatible with Flash Player 6 or later, Adobe AIR, and Flash Lite 3 clients. Additional formats and features are supported with newer versions of Flash Player (see Table 1). FMS 3 continues support for FLV and MP3 media and AMF 0 for data messaging. Combined with Flash Player 9,0,115,0, FMS 3 now expands support for an industry-standard digital video format, MPEG-4.

Table 1. File formats supported by Flash Media Server 3

Format	Type	Container	Flash Player minimum	Usual codec pairing
Sorenson Spark	Video	FLV	6, 7, 8, 9+	Nellymoser / MP3
On2 VP6	Video	FLV	8, 9+ Flash Lite 3	Nellymoser / MP4
H.264*	Video	MPEG-4: MP4, M4V, F4V, 3GPP	9,0,115,0+	AAC+ / MP3
Nellymoser	Audio	FLV	6+	Spark / On2
MP3	Audio	MP3	6+ Flash Lite 3	Spark / On2
AAC+ / HE-AAC / AAC v1 / AAC v2	Audio	MPEG-4: MP4, M4V, F4V, 3GPP	9,0,115,0+	H.264
AMF 0	Data		6, 7, 8, 9+ Flash Lite 3
AMF 3	Data		8, 9+

Note: H.264 playback in Flash Player supports most popular profiles including Base, Main, and HiP. The F4V format will be a new format moving forward that is a subset of MPEG-4 ISO 14496-10 and AAC+ (ISO 14496-3). For more information on H.264/AAC support, see the Flash Player 9 Update FAQ.

To use H.264/AAC in Flash without any ActionScript, the updated FLVPlayback component will be required and is available as an update to Flash CS3 Professional. This update will also be required to use enhanced RTMP (RTMPE). Without the FLVPlayback component, developers will use ActionScript 1.0, 2.0, or 3.0 to create experiences with H.264.

Streaming vs. HTTP delivery

When determining a method of delivery for video over the Internet in the Adobe Flash Player, you have three choices:

• Embedded video
• Progressive download
• Streaming

Embedded video is rarely used except in very specialized applications with low-quality, short video clips, so I'll just discuss streaming vs. progressive here.

In both progressive and streaming delivery, the video content is kept external to the SWF file. To deploy to the web, the SWF file and the video file would both be uploaded to a server.

Keeping the video external and separate offers a number of benefits over the embedded video method, including:

• Easy to update and accommodate dynamic content: It's relatively easy to add or change content independent of the video player and without the need to republish the SWF file.
• Small SWF file size: Your SWF file can remain very small for fast page loads; then the video can be delivered when the user requests it.
• Better performance: Because the FLV and SWF files are separate, the viewer will have a better playback experience.

Note: Although the focus in this section is on the delivery of video files, the same methods can be used to deliver audio files. In other words, audio files can also be embedded, progressively downloaded, or streamed.

Progressive download video delivery

Since Flash MX 2004, progressive download has been supported for video delivery. This method allows developers to load external video files into a Flash or Flex interface and play them back during runtime. This can be accomplished using ActionScript commands with the Video object or playback components, or by setting parameters for the playback components in the authoring environment (see Figure 2).

Figure 2. Parameters set for an FLVPlayback component to STREAM an external video file into a SWF

When the video is played, the video file first begins to download to the viewer's hard drive, then playback starts. The video will begin to play when enough of it has downloaded to the viewer's hard drive. The file is served from a standard web server through an HTTP request, just like a normal web page or any other downloadable document.

In comparison to streaming video, there's really only one consistent benefit to progressive download—you don't need a streaming server to deliver the video. Progressive download video can be served from any normal web server.

While this can be convenient and potentially cost-effective, the following potential issues should be noted:

• There are limited seek and navigation capabilities
• Viewers can access and repurpose content

Progressive download is a perfect use for hobbyists or websites that have low traffic requirements, don't mind if their content is cached on the viewer's computer, and only need to deliver shorter length videos (under 10 minutes). Customers who need advanced features and control over their video delivery, and/or those who need to display video to larger audiences (e.g. several hundred simultaneous viewers), need to track and report usage or viewing statistics for the video, or want to offer the best interactive playback experience, will need to stream their video. Streaming delivery also consumes less bandwidth than progressive delivery, because only the portion of the video that is watched is actually delivered.

Streaming video delivery

When you use streaming delivery, as is the case with progressive download, the video files are kept external to the other content. Developers can use ActionScript commands (and parameter settings with media components) to load external video files into a SWF and play them back at runtime. In fact, the ActionScript code needed for streaming is almost identical to that for progressive download.

This is where the similarities between progressive download and streaming delivery end. In the case of streaming video, each client opens a persistent connection to the streaming server, and the server streams the video bits to the client. Those bits are displayed by the viewer and then immediately discarded.

This tight connection between the server and the client, and the server's ability to precisely control and deliver any portion of a stream as requested, enables the developer to take advantage of some advanced capabilities. These include the following:

• Determining the client bandwidth and serving a stream with an appropriate bitrate.
• Measuring and tracking the stream's quality of delivery and switching to a lower (or higher) bitrate stream if needed—if network congestion increases, for example.
• Automatically generating thumbnails or play short previews of your video clip without having to create separate image or video clips, and without downloading the entire video in the background.
• Automatically creating "chapters" (with appropriate thumbnails) that can be used for navigation of longer videos, without having to break the video up into smaller files.
• The ability to seamlessly switch mid-stream from one camera angle, or one stream to another.
• The ability to "edit" video clips together to create one continuous video for playback. For example, playing the first 10 seconds of clip 1, followed by the content between the 30- and 40-second marks of clip 2, followed by the last 20 seconds of clip 3.
• The ability to webcast live or recorded events where all viewers see the same thing at the same time.

If progressive download is a "dumb" method of video delivery with very little control—it's basically a simple HTTP download call—then streaming is a very "smart" method of media delivery that enables publishers to control every aspect of the video experience.

Why streaming is better

The advantages of streaming video from Flash Media Server are numerous:

• Fast start: Streaming video is the fastest way to start playing any video on the web.
• Advanced video control: Features such as bandwidth detection, quality-of-service monitoring, automatic thumbnail creation, server-side playlists, and more.
• Efficient use of network resources: Customers who pay for their video hosting or bandwidth by the amount that is transferred will benefit from streaming video, since only the bits that the client actually views are transferred.
• Secure, protected media delivery: Because the media data is not saved to the client's cache when streamed, viewers can't retrieve the video or audio file from their temporary Internet files folder. There are also additional security features in FMS 3 that prevent stream ripping and other risks to your file's security. Refer to the article, Scaling and securing streaming media applications with Flash Media Server 3, for more details.
• Minimal use of client resources: Resources such as memory and disk space are significantly reduced with streaming, because the clients do not need to download and store the entire file.
• Tracking, reporting, and logging capabilities: Because progressive download is just a download of a file, you can't easily log specific relevant statistics such as how long the video was viewed; if the user navigated forward, backward, or paused the video; how many times the viewer played the video; if the viewer left the web page before the video completed playing, etc. Streaming enables you to easily capture this important data.
• Full seek and navigation: Viewers can immediately seek to any point in the video and have it start playing immediately from that point. This makes streaming a great solution for longer-playing videos or applications such as video blogging, classroom lectures, and conference sessions, where you may want to jump into the video at a specific point rather than requiring the viewer to watch it from the beginning.
• Deep interactivity: The precise control found in streaming enables developers to create extensive interaction in their video applications. For example, the ability to switch camera angles, have one video spawn another video, or seamlessly switch to alternate endings are all enabled by streaming.
• Live video: Streaming provides the ability to deliver live video and audio from any connected webcam or DV camera, and even directly from some video cards, natively in Flash Player.
• Video capture and record (FMIS only): In addition to live streaming, Flash Media Server also gives you the ability to record video either in conjunction with the live stream (e.g. for archiving an event) or on its own (e.g. video messaging).
• Multiuser capabilities (FMIS only): In addition to live one-to-many streaming, Flash Media Server also enables multiuser streaming of audio, video, and data for the creation of video communication applications.

While streaming may be perceived as being more difficult than progressive download, they're actually extremely similar—they both use the same components and the same ActionScript commands. Streaming just gives the developer more power to create rich, interactive video applications.

The only potential downside to streaming is that it requires special server software. Just as a robust data application would require you to install an application server in addition to your web server, robust media delivery applications require a streaming server in addition to the web server.

Customers with high-volume streaming needs, popular content, or critical uptime requirements who don't want to build their own infrastructure can get the benefits of streaming video in Flash Player by utilizing a Flash Video Streaming Service (FVSS). These Adobe partners offer load-balanced, redundant deployment of FMS over a reliable content delivery network.

When to choose streaming

Streaming with Flash Media Server should be used in any situation where you want or need to do the following:

• Deliver long files (10 minutes or longer) or high-bitrate files (high-definition)
• Perform bandwidth detection, delivering the best quality for available hardware
• Use quality-of-service monitoring
• Support real-time tracking
• Provide real-time data sharing and interactivity to your video experiences
• Stream live video and/or audio
• Record video and/or audio
• Serve more streams with less bandwidth

If your website or blog relies heavily on video, audio, or real-time data sharing for delivering your message, you will want to present it in the best possible manner by utilizing the features of Flash Media Server.

Video delivery techniques in Flash

	Embedded video	Progressive download	Streaming delivery
Encoding	Video and audio are encoded on import into Flash using the Sorenson Spark or VP6-E codec. Alternately, FLV files (encoded elsewhere) can be imported and placed on the Flash Timeline (re-encoding is not necessary).	Video files are encoded in either the built-in or standalone version of Flash Video Encoder, through Flash Video Exporter and a third-party non-linear editing or encoding product, or using a standalone video encoding application such as Sorenson Squeeze or On2 Flix.	Same as progressive delivery. In addition, you can capture and record live video feeds from client-side webcams or DV cameras, or using Flash Media Live Encoder, and control live encoding variables such as bitrate, FPS, and video playback size programmatically.
File size	SWF files contain both the video and audio streams as well as the Flash interface, resulting in a single, substantially larger file size.	SWF and video files are kept separate, resulting in a smaller SWF file size.	Same as progressive delivery.
Start time	Large SWF files often require users to wait a long time before seeing any video, resulting in a negative user experience.	Starts relatively quickly, after enough of the video has downloaded to begin playback.	Immediate. The fastest way to go from initial load to actually playing the video.
Timeline access	When embedded in the Flash Timeline, video appears on individual frames and can be treated like any other object on the Stage.	Video is played back only at runtime. Individual frames are not visible on the Stage. Timeline events can be triggered at selected times during video playback using ActionScript.	Same as progressive delivery.
Publishing	Each time the SWF is published or tested the entire video file is republished. Changes to video files require manually re-importing the files into the Timeline.	Video files are only referenced at runtime. Publishing to the SWF format is much faster than the embedded video approach. Video files can be updated or modified without recompiling the SWF file.	Same as progressive video. You can dynamically pull video files from virtual locations, such as your storage area network (SAN) or a Flash Video Streaming Service or other content delivery network (CDN).
Frame rate	Video frame rate and SWF movie frame rate must be the same.	The video file can have a different frame rate than the SWF file.	Same as progressive delivery. Live video capture has programmable control over frame rate.
ActionScript access	Video playback and control is achieved by manipulating the movie's playback on the Timeline.	The NetStream class can be used to load, play, and pause external FLV files. Seek can also be performed on the portion of the video that has been downloaded.	Same as progressive delivery. Server-side ActionScript can also be used to provide additional functionality such as synchronization of streams, server-side playlists, smart delivery adjusted to client connection speed, and more.
Components	No video-specific components.	Media components (Flash 8 Professional and Flash CS3 Professional) can be used to set up and display external video and audio files together with transport controls (play, pause, seek, etc.).	Same as progressive video. Also, you can use Flash Media Server communication components for streaming live and multiway video.
Seek and navigation ability	Requires the entire SWF file to be downloaded before user can seek or navigate the video.	User can only seek to portions of the video that have been downloaded.	Viewer can seek anywhere at any time.
Web delivery	The entire SWF file must be downloaded to the client and loaded into memory in order to play back video.	Video files are progressively downloaded, cached, and then played from the local disk. The entire video clip need not fit in memory.	Video files are streamed from Flash Media Server, displayed on the client's screen, and then discarded from memory in a play-as-you-go method.
Performance	Audio and video synch is limited. Sync between audio and video will suffer after approximately 120 seconds of video. Total file duration is limited to available RAM on the playback system.	Improved performance over embedded SWF video, with bigger and longer video and reliable audio synchronization. Provides best image quality, which is limited only by the amount of available hard drive space on the playback system.	Improved efficiency from a web delivery perspective, with optimal bitrate delivery on an as-needed basis to as many customers as necessary.
Control over the video stream	None	None	Full control over what gets delivered to the clients and when. Advanced access control via server-side ActionScript.
Live video support	None	None	Yes
Compatibility	Flash Player 6 and later	Flash Player 7 and later	Flash Player 6 and later

출처 : http://www.adobe.com/devnet/flashmediaserver/articles/overview_streaming_fms3.html