Implementation looks good.

The pace/rate of TS data received by the FF via the socket event is 
determined by the server.  If the rate of the packet consumption by the 
FF's client is less than the rate of the server delivery, the packet 
queue of the demuxer can grow quite large.  Can above situation happen 
in the intended usage?

Qiang

On 2/22/2011 7:50 PM, Jamie Gordon wrote:
> Synopsis
> ========
> Adds a plugin to support raw TS streams
>
> Branches: PRODUCER_14_0_RN, HEAD
> Suggested Reviewer: qluo
>
>
> Description
> ===========
> A file format plugin for raw (UDP/multicast) TS streams.
> A lot like the TS file format plugin (for files) but it
> reads from a socket instead of a file. :)
>
> TODO: loss and out-of-order packet handling, timeouts,
> possible buffer management updates
>
>
> Files Affected
> ==============
> datatype/mpeg2ts/demuxer/Umakefil
> datatype/mpeg2ts/demuxer/tsdemuxer.cpp
> datatype/mpeg2ts/demuxer/pub/tsdemuxer.h
>
> new:
> datatype/mpeg2ts/stream/tsstreamff.cpp
> datatype/mpeg2ts/stream/pub/tsstreamff.h
> datatype/mpeg2ts/stream/guids.cpp
> datatype/mpeg2ts/stream/Umakefil
> datatype/mpeg2ts/stream/win.pcf
> datatype/mpeg2ts/stream/platform/win/tsstreamff.rc
> datatype/mpeg2ts/stream/pub/tsstreamff.ver
>
>
> Testing Performed
> =================
> Played back H.264+AAC TS streams with splay
>
> Platforms Tested: win32-i386-vc9
> Build verified: win32-i386-vc9
>
>
> QA Hints
> ===============
>
> n/a
>