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.
But putting it in info packets just doesnt work without allowing changeable info. Putting it in streams is a huge mess and changing nothing wont work as has been shown and i belive isnt disputed anymore?
I agree that it probably won't work "optimally". I still think it's reasonable to ask for transmit_ts-dts to remain constant over moderate-sized windows, but Michael is correct that there are bitrate-utilization gains to be made by bending this rule. So if people want to make use of such gains, some solution is needed. Rich