[M4IF Technotes] confusion about modulo_time_base, vop_time_increment, ...

[Christoph Lampert]

Hello,
thank you for your answer. I have one small additional clarification to
ask for: 
On Wed, 7 Aug 2002, Arcin Bozkurt wrote:
> I will be answering your questions in a different order and hopefully will
> be clear. I will write my interpretation and how I am doing it.
> 
> You are right, modulo_time_base in normal circumstances will never be two.
> You can create a setup where it will be, but it would not be very realistic
> I believe.
> 
> The only time modulo_time_base is non-zero, is when the real time completes
> a one full second from the previous time a modulo_time_base was non-zero.
> 
> Assume the simple fixed rate case: 30 fps. And the
> vop_time_increment_resolution is 300. 300 means each tick is 1/300 seconds
> long and the vop_time_increment is given as number of ticks in this
> resolution.
> 
> Your display times will be 0, 1/30, 2/30, 3/30, .... 29/30, 1, 31/30, etc.
> In this case the values for modulo_time_base will be
> 0, 0, (repeat 29 times), 1, 0 repeat 30 times), 1, 0 (repeat 30 tiems)
> and the Vop_time_increment will be
> 0 10, 20, ... 290, 0 (this corresponds to a "1" in modulo_time_base), 10,
> 20, ... 290, 0 , etc...

That is what I expected, fine. However, this is just for I/P/S-VOPs, not
for B-VOPs. Consider almost a sequence encoded with IBBPBBPBBP...
and only 12fps to keep the lines shorter (vop_time_incr_res=120), 
I understand it would be (display order):
 I   B   B   P   B   B   P   B   B   P   B   B   P   B   B   P 
 0   0   0   0   0   0   0   0   0   0   0   0   1   0   0   0 
000 010 020 030 040 050 060 070 080 090 100 110 000 010 020 030 
now with 11fps (vop_time_incr_res=110) things get complicated.
Would it be: 
 I   B   B   P   B   B   P   B   B   P   B   B   P   B   B   P
 0   0   0   0   0   0   0   0   0   0   0   1   1   0   0   0
000 010 020 030 040 050 060 070 080 090 100 000 010 020 030 040
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