Re: [VCDImager Bugs/Devel] timecodes...

[Mike Bernson]

Herbert Valerio Riedel wrote:
> 
> this is just a question due to my wondering :)
> 
> ...that's one of my dumps... from gop to gop (type 'g') timestamp always
> increasing, but the offset's (relative) timecodes seem a bit out of order...
> ...is that ok, because of the nature of those P and B frames, they are
> ordered the way they are needed in the decode process?
> 
> frame      0 offset      0:001051 type g timecode 00107891
> frame      1 offset      0:001117 type I timecode 00000000
> frame      2 offset      0:001051 type g timecode 00107891
> frame      3 offset      0:001117 type I timecode 00000000
> frame      4 offset      0:001873 type P timecode 00000002
> frame      5 offset      0:002709 type B timecode 00000001
> frame      6 offset      0:003857 type P timecode 00000005
> frame      7 offset      0:002293 type B timecode 00000003
> frame      8 offset      0:007029 type B timecode 00000004
> frame      9 offset      0:015377 type P timecode 00000008
> frame     10 offset      0:000853 type B timecode 00000006
> frame     11 offset      0:003605 type B timecode 00000007
> frame     12 offset      0:006769 type P timecode 00000011
> frame     13 offset      0:005365 type B timecode 00000009
> frame     14 offset      0:010389 type B timecode 00000010
> frame     15 offset      0:013553 type P timecode 00000014
> frame     16 offset      0:011381 type B timecode 00000012
> frame     17 offset      0:002229 type B timecode 00000013
> frame     18 offset      0:004363 type g timecode 00107906
> frame     19 offset      0:004429 type I timecode 00000002
> frame     20 offset      0:005285 type B timecode 00000000
> frame     21 offset      0:009125 type B timecode 00000001
> frame     22 offset      0:013857 type P timecode 00000005
> frame     23 offset      0:016901 type B timecode 00000003
> frame     24 offset      0:008741 type B timecode 00000004
> frame     25 offset      0:001665 type P timecode 00000008
> frame     26 offset      0:009957 type B timecode 00000006
> frame     27 offset      0:002373 type B timecode 00000007
> frame     28 offset      0:010465 type P timecode 00000011
> frame     29 offset      0:009253 type B timecode 00000009
> frame     30 offset      0:016933 type B timecode 00000010
> frame     31 offset      0:003553 type P timecode 00000014
> frame     32 offset      0:012133 type B timecode 00000012
> frame     33 offset      0:016997 type B timecode 00000013
> frame     34 offset      0:003803 type g timecode 00107921
> frame     35 offset      0:003869 type I timecode 00000002
> frame     36 offset      0:012501 type B timecode 00000000
> frame     37 offset      0:017141 type B timecode 00000001
> frame     38 offset      0:003537 type P timecode 00000005
> frame     39 offset      0:009685 type B timecode 00000003
> frame     40 offset      0:014709 type B timecode 00000004
> frame     41 offset      0:000497 type P timecode 00000008
> frame     42 offset      0:014645 type B timecode 00000006
> frame     43 offset      0:007061 type B timecode 00000007
> frame     44 offset      0:018577 type P timecode 00000011
> frame     45 offset      0:017045 type B timecode 00000010
> ...
> 
> --
> Herbert Valerio Riedel      /     Finger address@hidden for GnuPG Public Key
> GnuPG Key Fingerprint: AC2A CD57 A5C8 A1CB 0A18  DA95 CB0B DB23 60B6 16F5
> 
> _______________________________________________
> Bug-VCDImager mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-vcdimager

I am not sure what 'g'  timecode are.  I am assume that the
g timecode are hours + min + sec + frames and the other
are just frames.

Here is how thing work.

The gop hold the timestamp for display. The picture hold the
offset since last gop.