> Stef, > > Why do you want to map them against 'wall time'? > If you want to break it into chinks of the same size - use the pcr values > for chunking. > The PCR is continuous (apart from the wrap at 0xFFFFFFFF...) so you can > choose a sensible binary fraction of the max PCR value to chunk up the > stream. > > There really is no way of synchronising the wall clock against PCR because > of the fact that PCR maximum value occurs at a longer interval than 24 > hours, so the PCR value drifts against wall time.... so on day 1 the PCR > value at 12:00 midday might be X, on day two the PCR value at 12:00 midday > will be X - n, where n is the difference in the 24hr 'day' wrap interval and > the PCR wrap interval (working the wrap out is left as an exercise for the > reader :-) - basically MAX 32 bit value * tick value. > > If you want the same sized chunks - which effectively means the same > duration of play time for each chunk - use the PCR values and chunk on > that.... > > If you want to be able to determine when a chunk was transmitted - just > record the PC time (or GPS time) at the start of each chunk..... > > Note: PCR values are not guaranteed to be continuous... broadcasters do > sometimes reset equipment - which will cause a PCR change.... also some > broadcasters change the PCR value periodically for other operational > reasons... there is a flag that is used to indicate a discontinuity in PCR > values.... > Which measurement is used for PTS/PTR? Nanoseconds? Why don't you just parse the PTS/PTR in realtime while reception, at any discontinue of the PTS/PTR you recalculate the offset to (nano-)seconds since „00:00:00 1970-01-01 UTC“ and replace the PTS/PTR with (nano-)seconds since „00:00:00 1970-01-01 UTC“. For handling the maximum value of PTR/PTS data type you could have some offset table in your application. That way you'd have a linear timeline matching all computers on the world (which would allow to e.g. exchange cutting marks worldwide). Rene
