On 05/15/2013 02:04 PM, Michael Niedermayer wrote:
Surely feasible, since it is a real-time information can stay on the global header w/out problems.
The wallclock time corresponding to the transmit_ts of 0 does not change throughout the stream. Its just the origin / zero point from where you count time
Its like the day you are born does not change and can be written in your birth certificate. While your age changes in relation to your "birth date" (realtime) over your life.
That is instead of packet 123 transmit time = 2013 01 02 03:04:05.00 packet 124 transmit time = 2013 01 02 03:04:05.02 packet 125 transmit time = 2013 01 02 03:04:05.03
one can use: main_header reference_wallclock = 2013 01 02 00:00:00.00 ... packet 123 transmit time = 03:04:05.00 packet 124 transmit time = 03:04:05.02 packet 125 transmit time = 03:04:05.03
Its the same information, just requires fewer bytes to transmit/store and the stream can continue realtime for millions of years with the same main header if someone really wanted
Though i suspect the stream would be restarted several times a year with new video resolutions, audio sample rates, audio & video codecs and other change
I hope that clarifies what i was suggesting
It was already clear and I do agree with that, the start time can be part of the global header and then we can just record the timedelta. I was wondering between storing it per-stream but seems not necessary, any opinion on the timebase to be used? lu