> ------------------------------
> Message: 9
> Date: Sat, 3 Oct 2009 06:28:29 +0100
> From: "Lucian @ lastdot.org" <luc...@lastdot.org>
> Subject: Re: Voting for a native i386/amd64 flash player
> To: freebsd-questions@freebsd.org
> Message-ID:
>     <5a3c8f450910022228k3c196b6ay1acc3031716d6...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> Better pray for Theora's mass adoption on streaming sites
> :-)

I have this fantasy that if I design and build a better streaming video format, 
"They" (broadcasters) will use it, if properly marketed.

This would be despite the lack of "strong" DRM or license terms (GPL v3 is OK, 
right?). The idea is I build a "public version", then sell a custom "corporate 
version" that is buzz-word certified with whatever standards they want (except 
"strong" DRM; incompatible with the license) for ~$30,000 a seat, or some 
volume [del]license[del] purchasing agreement. 

I got the idea when I realized that the current formats used by broadcasters 
suck. Most are based on MPEG that had some processing constraints no longer 
present (to the same extent) on modern computers. 
General idea:
1. Do away with the outdated concept of "live". There is always a delay. Make 
the delay predictable and visible to the user by sychronizing clocks with NTP. 
A "live" broadcast would have a calibrated delay ranging from seconds to 
minutes. "pre-recorded" would be minutes to centuries.
2. Modify Bittorrent  protocol for Steaming media. There is already 
(incompatible) work in this area.
3a. Separate "Lossy Compression" from "Lossless Compression". This will result 
in a variable bit-rate stream. I came up with a (fast) transform so that the 
lossless compression stores only the changes between (key) frames.
3b. Optional "Variable frame-rate" stream: new frame only needed after a 
certain percentage of the scene changes.
4. Publishers are authenticated with a Public-key infrastructure
5. For UDP or Broadcast, a format variant tolerates data loss with graceful 

Main stumbling blocks:
1. trying to do too much at once: file format and protocol rolled into one.
2. For interoperability, I need to stabilize key points of the spec before 
publication. Currently struggling with date stamps (taking into account leap 
seconds) (mostly resolved), and a transform to allow the publisher to be 
authenticated even if some data is missing.
3. Because my idea is variable data-rate, I can't predict what "real-world" 
compression will be. need to do testing. As compression may be affected my MPEG 
artifacts, need to test with my own "raw" video. (Loss-less conversion from 
MPEG would be possible.)
4. A dual-license may quickly result in a fork that implements "features" I 
really don't want to see. (Read: anything deliberately incompatible.)
5. I seem to be pre-occupied with the video compression, ignoring sound.


James Phillips

PS: was this too off-topic?

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to