On Thu, Feb 07, 2008 at 12:13:23PM -0000, Måns Rullgård wrote:
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.
I believe this will work, but you still need to specify a reference model for the buffer management.
Yes, i know. I am trying to move in small steps to avoid another day of flaming.
It will also require more effort on the receiver side to achieve exact clock recovery. With a timestamp transmitted clock recovery is trivial, whereas this will require the receiver to measure the (perceived) received bitrate in order to work out the necessary clock adjustments.
No, i dont think that is needed. My idea was not to store the number of bytes to preload beginning with the syncpoint. But to store how much should be in the buffer the moment the syncpoint is reached. That way the buffer_fullness stored in the syncpoint will always match exactly the amount the decoder has in its buffer when reading the syncpoint. If it has more in its buffer it just would change its clock to one running at 100.1% and when it has less in its buffer it would choose a 99.9% clock as reference. (Or any approximetaly equivalent process) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato