No subject

from the synchronization point ""marked by the modulo_time_base"" measured
in the number of clock ticks.
Since only the modulo_time_base is important and it is set to 1, the
increment "010" will advance the time on top of modulo_time_base=1.
Again, I think it is true.
> because reference is always the last I/P/S-VOP, not a B-VOP?
> Then I would finally start getting the point...
>
>
>
> > The confusing part is "local time base" related parts I believe. The
> > standard says:
> > modulo_time_base: This value represents the local time base
> in one second
> > resolution units (1000 milliseconds).
> > vop_time_increment: The local time base in the units of
> seconds is recovered
> > by dividing this value by the vop_time_increment_resolution.
> >
> > Therefore, local time base in resolution of seconds, is given by
> > modulo_time_base (as an increment from the previous) and
> local time base in
> > resolution of "1/vop_time_increment_resolution" is given by
> > vop_time_increment. (as an increment from the last modulo_time_base)
> >
> > If you look at this "division" as a floating point
> operation you will get
> > (increment/increment_resoultion) (in seconds) which is
> exactly what we want.
>
> Of course, I didn't think about floating point calculation
> with integer
> variables. Okay, you are right, then. So it's rather a statement
> about time "units" than something deep about values...
>
> Yours,
>
> Christoph
>
>
>
> > Hi,
> >
> > I still have problem understanding the correct specifications
> > for writing timecodes to the VOP header.
> >
> > First there is modulo_time_base, it consists of a number of
> > 1s followed by a 0, one 1 for every second that passed
> since the last
> > GOV header or last module_time_base of the previously
> decoded I-, S- or
> > P-VOP.
> >
> > Am I right, that this does not mean elapsed "full seconds",
> but is some
> > kind of "carry" flag, when the ticks-counter "overflows"?
> > So if we talked minutes and hours, it would be 1 when the
> clock jumps from
> > 0:59 to 1:00, right?
> > In real life, the chances of this value ever getting 2 is
> very small,
> > correct?
> >
> > And then, there is vop_time_increment:
> >
> > It has a value in [0,vop_time_increment_resolution) and the
> last comment
> > on it is "The local time base in the units of seconds is
> recovered by
> > dividing this value by the vop_time_increment_resolution."
> >
> > That's simply wrong, isn't it? You will always end up with
> 0 when dividing
> > this value by vop_time_increment_resolution... but what
> _is_ really meant?
> >
> > Thank you for your help,
> >
> > Christoph
> >
> > --
> > Christoph H. Lampert chl   math,uni-bonn,de | Diese Signature
> wurde maschi-
> > Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
> > Sprechstunden: keine, aber meistens da    | keiner
> Unterschrift. AZ 27B-6
> >
> > _______________________________________________
> > Technotes mailing list
> > Technotes   lists.m4if.org
> > http://lists.m4if.org/mailman/listinfo/technotes
> >
> >
>
> --
> Christoph H. Lampert chl   math,uni-bonn,de | Diese Signature
> wurde maschi-
> Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
> Sprechstunden: keine, aber meistens da    | keiner
> Unterschrift. AZ 27B-6
>
> _______________________________________________
> Technotes mailing list
> Technotes   lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes
>