On Sun, Feb 17, 2008 at 03:47:27AM +0100, Michael Niedermayer wrote:
On Mon, Feb 11, 2008 at 03:11:45AM +0100, Michael Niedermayer wrote:
On Sun, Feb 10, 2008 at 08:53:17PM -0500, Rich Felker wrote:
On Mon, Feb 11, 2008 at 12:54:56AM +0100, Michael Niedermayer wrote:
On Thu, Feb 07, 2008 at 03:55:46AM +0100, Michael Niedermayer wrote:
Hi
Heres a third try, the first was transmit_ts with unspecified buffers second was transmit_ts with a single specified buffer
Here now comes the buffer state per syncpoint. It trivially allows the demuxer to find the needed preload, and allows trivial clock synchronization.
Iam not sure how much more or less device dependant this is. It surely looks better if one considers broadcasting at a higher bitrate than the intended one. (lower will fail as with all other proposals)
Also this is the smallest solution so far, and likely also has less overhead than the transmit_ts.
Iam planing to commit this in 24h, if someone has objections / wants me to wait say so.
Can you wait a little bit for some more discussion? I'm not rejecting it but I'd like to think it through more.
ok
ping, i waited a week ... Ill add a transmit_ts in 48h (without buffer model) unless there is some sort of discussion happening before.
transmit_ts or your other proposal? I think I like transmit_ts better but I'd like to know the motivations behind how the decision is made rather than a decision being made by default when no one discusses it. Even though this is not a feature I'm particularly interested in. Rich