Date: Sat, 3 Oct 2009 08:01:07 -0700 (PDT) From: James Phillips <anti_spam256@yahoo.ca> To: freebsd-questions@freebsd.org Subject: Re: Voting for a native i386/amd64 flash player Message-ID: <346226.13848.qm@web65503.mail.ac4.yahoo.com> In-Reply-To: <20091003120028.B0CEA10656A7@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A=0A> ------------------------------=0A> =0A> Message: 9=0A> Date: Sat= , 3 Oct 2009 06:28:29 +0100=0A> From: "Lucian @ lastdot.org" <lucian@lastdo= t.org>=0A> Subject: Re: Voting for a native i386/amd64 flash player=0A> To:= freebsd-questions@freebsd.org=0A> Message-ID:=0A> =A0=A0=A0 <5a3c8f4509100= 22228k3c196b6ay1acc3031716d673d@mail.gmail.com>=0A> Content-Type: text/plai= n; charset=3DISO-8859-1=0A> =0A<SNIP!>=0A> =0A> Better pray for Theora's ma= ss adoption on streaming sites=0A> :-)=0A> =0A=0AI have this fantasy that i= f I design and build a better streaming video format, "They" (broadcasters)= will use it, if properly marketed.=0A=0AThis 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; incompat= ible with the license) for ~$30,000 a seat, or some volume [del]license[del= ] purchasing agreement. =0A =0A=0AI got the idea when I realized that the c= urrent formats used by broadcasters suck. Most are based on MPEG that had s= ome processing constraints no longer present (to the same extent) on modern= computers. =0AGeneral idea:=0A1. Do away with the outdated concept of "liv= e". 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 calib= rated delay ranging from seconds to minutes. "pre-recorded" would be minute= s to centuries.=0A2. Modify Bittorrent protocol for Steaming media. There = is already (incompatible) work in this area.=0A3a. Separate "Lossy Compress= ion" from "Lossless Compression". This will result in a variable bit-rate s= tream. I came up with a (fast) transform so that the lossless compression s= tores only the changes between (key) frames.=0A3b. Optional "Variable frame= -rate" stream: new frame only needed after a certain percentage of the scen= e changes.=0A4. Publishers are authenticated with a Public-key infrastructu= re=0A5. For UDP or Broadcast, a format variant tolerates data loss with gra= ceful degradation.=0A=0AMain stumbling blocks:=0A1. trying to do too much a= t once: file format and protocol rolled into one.=0A2. For interoperability= , I need to stabilize key points of the spec before publication. Currently = struggling with date stamps (taking into account leap seconds) (mostly reso= lved), and a transform to allow the publisher to be authenticated even if s= ome data is missing.=0A3. Because my idea is variable data-rate, I can't pr= edict what "real-world" compression will be. need to do testing. As compres= sion may be affected my MPEG artifacts, need to test with my own "raw" vide= o. (Loss-less conversion from MPEG would be possible.)=0A4. A dual-license = may quickly result in a fork that implements "features" I really don't want= to see. (Read: anything deliberately incompatible.)=0A5. I seem to be pre-= occupied with the video compression, ignoring sound.=0A=0ARegards,=0A=0AJam= es Phillips=0A=0APS: was this too off-topic?=0A=0A=0A______________________= ____________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail= has the best spam protection around =0Ahttp://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346226.13848.qm>