<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Brian Lesser on O&apos;Reilly Broadcast</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/" />
<link rel="self" type="application/atom+xml" href="http://broadcast.oreilly.com/atom.xml" />
<id>tag:broadcast.oreilly.com,2008-08-07://53</id>
<updated>2011-11-05T19:04:43Z</updated>

<generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>

<entry>
<title>Flash Media Server/FFmpeg Annoyance #2: Clients not allowed to broadcast message.</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/11/flash-media-serverffmpeg-annoy-1.html" />
<id>tag:broadcast.oreilly.com,2011://53.47449</id>

<published>2011-11-05T19:04:43Z</published>
<updated>2011-11-05T19:04:43Z</updated>

<summary>Last year Ryerson University had a booth at NAB and I was part of the crew that demonstrated our (pre-alpha) television studio in the cloud project. During the show Ryerson was invited to the IBC show held in Amsterdam last...</summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Last year Ryerson University had a booth at NAB and I was part of the crew that demonstrated our (pre-alpha) television studio in the cloud project. During the show Ryerson was invited to the IBC show held in Amsterdam last...
</content>
</entry>

<entry>
<title>Flash Media Server/FFmpeg Annoyance #1: RTMP/Stream URIs</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/08/flash-media-serverffmpeg-annoy.html" />
<id>tag:broadcast.oreilly.com,2011://53.47025</id>

<published>2011-08-11T11:54:14Z</published>
<updated>2011-08-11T11:54:14Z</updated>

<summary>Every project has its annoying moments that often are quickly forgotten. So before I forget, I thought I&apos;d make some notes in case this one is useful for someone else. Our FFmpeg-based video compositing engine connects to FMS in order...</summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>

<category term="ffmpegfmsrtmpuri" label="FFmpeg FMS RTMP URI" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Every project has its annoying moments that often are quickly forgotten. So before I forget, I thought I&apos;d make some notes in case this one is useful for someone else. Our FFmpeg-based video compositing engine connects to FMS in order...
</content>
</entry>

<entry>
<title>A Real-Time Component Framework (RTCF)</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2011/08/real-time-component-framework.html" />
<id>tag:broadcast.oreilly.com,2011://53.46955</id>

<published>2011-08-01T19:23:13Z</published>
<updated>2011-08-01T19:23:13Z</updated>

<summary>Over the years I&apos;ve worked on a few moderately complex applications that used Flash Media Server (FMS). Each time I had to create a small component framework so I could manage server-side objects and their resources. In late 2009 I...</summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Over the years I&apos;ve worked on a few moderately complex applications that used Flash Media Server (FMS). Each time I had to create a small component framework so I could manage server-side objects and their resources. In late 2009 I...
</content>
</entry>

<entry>
<title>Adobe&apos;s Real-Time Media Flow Protocol</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/04/adobes-real-time-media-flow-pr.html" />
<id>tag:broadcast.oreilly.com,2009://53.36041</id>

<published>2009-04-24T11:23:24Z</published>
<updated>2009-04-24T11:23:24Z</updated>

<summary>This is a long post. I wrote it while preparing a presentation on RTMFP for Toronto&apos;s FITC Flash festival next week. After I recover from the festival I&apos;ll post the sample files for the demo applications. The Flash player is...</summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>

<category term="flash" label="flash" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="flex" label="flex" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="realtimeweb" label="real-time web" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="rtmfp" label="rtmfp" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
This is a long post. I wrote it while preparing a presentation on RTMFP for Toronto&apos;s FITC Flash festival next week. After I recover from the festival I&apos;ll post the sample files for the demo applications. The Flash player is...
</content>
</entry>

<entry>
<title>The Real-Time Web</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2008/11/the-real-time-web.html" />
<id>tag:broadcast.oreilly.com,2008://53.34067</id>

<published>2008-11-08T14:11:07Z</published>
<updated>2008-11-08T14:11:07Z</updated>

<summary>We need to get away from the idea that we should share and synchronize files or application windows and look at real-time sharing of data models within the browser. </summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>

<category term="collaboration" label="collaboration" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="http" label="http" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="realtimeweb" label="real-time web" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
We need to get away from the idea that we should share and synchronize files or application windows and look at real-time sharing of data models within the browser. 
</content>
</entry>

<entry>
<title>MVC As Anti-Pattern</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html" />
<id>tag:broadcast.oreilly.com,2008://53.33754</id>

<published>2008-10-11T18:19:36Z</published>
<updated>2008-10-11T18:19:36Z</updated>

<summary>Simple standalone Web applications only need three layers: presentation, domain, and data source. If you are using Flex or AJAX and don&apos;t need to submit any forms, do you still need an MVC framework?  I think the answer is no.</summary>
<author>
<name>Brian Lesser</name>
<uri>http://flash-communications.net/</uri>
</author>

<category term="designpatterns" label="design patterns" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="flex" label="flex" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="mvc" label="mvc" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="services" label="services" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Simple standalone Web applications only need three layers: presentation, domain, and data source. If you are using Flex or AJAX and don&apos;t need to submit any forms, do you still need an MVC framework?  I think the answer is no.
</content>
</entry>

</feed> 
