> ------------------------------
>
> 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
>
<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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
