Voting for a native i386/amd64 flash player

[James Phillips]

> ------------------------------
> 
> Message: 9
> Date: Sat, 3 Oct 2009 06:28:29 +0100
> From: "Lucian @ lastdot.org" <lucian at lastdot.org>
> Subject: Re: Voting for a native i386/amd64 flash player
> To: freebsd-questions at freebsd.org
> Message-ID:
>     <5a3c8f450910022228k3c196b6ay1acc3031716d673d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
<SNIP!>
> 
> 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 degradation.

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.

Regards,

James Phillips

PS: was this too off-topic?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com