Difference between revisions of "MiniDV2AVI/Todo/Extract milliseconds timestampt from DV capture"

From Wiki4Intranet
Jump to: navigation, search
(Created page with "In most known DV format description: http://dvswitch.alioth.debian.org/wiki/DV_format/ written: <blockquote> Audio/video recording time ;byte 0: pack type = 0x53 (audio), 0...")
 
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
In most known DV format description: http://dvswitch.alioth.debian.org/wiki/DV_format/
+
I want to extract timecode up to milliseconds from DV capture.
−
written:
+
 
 +
Most known DV format description: http://dvswitch.alioth.debian.org/wiki/DV_format/
 +
said:
  
 
<blockquote>
 
<blockquote>
Line 13: Line 15:
 
</blockquote>
 
</blockquote>
  
−
But actually, in my experience, this '''byte 1''' is always FF.
+
But actually, in my experience (and see also «[https://groups.google.com/forum/?fromgroups=#!msg/microsoft.public.win32.programmer.directx.video/3kMuSYZ-KFw/qq09vrGhMNwJ BYTE  magic_FF_6]», [http://social.msdn.microsoft.com/Forums/eu/windowsdirectshowdevelopment/thread/84d5e630-0ba3-42c6-9801-67d82aa09fd6]), this '''byte 1''' is always FF.
  
 
  60 FF FF 00 FF 61 3F 80 FC FF 62 FF F0 E8 12 63 FF 87 C9 E3 FF
 
  60 FF FF 00 FF 61 3F 80 FC FF 62 FF F0 E8 12 63 FF 87 C9 E3 FF
 +
 +
Using «LTC TimeCode frames past second» for guessing «actual/real/universal time milliseconds» is not an option, because LTC is different for each cassette.
 +
 +
<blockquote>
 +
''Time code (TC)''
 +
 +
This is based on [http://en.wikipedia.org/wiki/Linear_timecode LTC] but without the sync word. The user bits may be encoded in a binary group pack.
 +
 +
 +
Appears as pack 3 in each subcode block, and also as pack 5 in subcode blocks in the first half of each frame.
 +
 +
;byte 0: pack type = 0x13
 +
;byte 1:
 +
* bits 0-5: '''frames past second''', binary-coded decimal (BCD)
 +
* bit 6: drop-frame timecode flag
 +
* bit 7: colour frame synchronisation flag (irrelevant for DV?)
 +
 +
;byte 2:
 +
* bits 0-6: seconds past minute, BCD
 +
 +
;byte 3:
 +
* bits 0-6: minutes past hour, BCD
 +
* bit 7: binary group flag 0
 +
 +
;byte 4:
 +
* bits 0-5: hours past midnight, BCD
 +
* bits 6-7: binary group flags 1-2
 +
 +
</blockquote>
 +
 +
Is there any hack to guess real milliseconds (or frames after second) for timecode?
 +
If so, write [mailto:stas-fomin@yandex.ru me], please.

Latest revision as of 01:07, 18 September 2012

I want to extract timecode up to milliseconds from DV capture.

Most known DV format description: http://dvswitch.alioth.debian.org/wiki/DV_format/ said:

Audio/video recording time

byte 0
pack type = 0x53 (audio), 0x63 (DV video) or 0x93 (MPEG-2 video)
byte 1
bits 0-5: frames past second, BCD, or 0x3f = unknown
byte 2
bits 0-6: seconds past minute, BCD
byte 3
bits 0-6: minutes past hour, BCD
byte 4
bits 0-5: hours past start of recording, BCD

But actually, in my experience (and see also «BYTE magic_FF_6», [1]), this byte 1 is always FF. 

60 FF FF 00 FF 61 3F 80 FC FF 62 FF F0 E8 12 63 FF 87 C9 E3 FF

Using «LTC TimeCode frames past second» for guessing «actual/real/universal time milliseconds» is not an option, because LTC is different for each cassette.

Time code (TC)

This is based on LTC but without the sync word. The user bits may be encoded in a binary group pack.


Appears as pack 3 in each subcode block, and also as pack 5 in subcode blocks in the first half of each frame.

byte 0
pack type = 0x13
byte 1
  • bits 0-5: frames past second, binary-coded decimal (BCD)
  • bit 6: drop-frame timecode flag
  • bit 7: colour frame synchronisation flag (irrelevant for DV?)
byte 2
  • bits 0-6: seconds past minute, BCD
byte 3
  • bits 0-6: minutes past hour, BCD
  • bit 7: binary group flag 0
byte 4
  • bits 0-5: hours past midnight, BCD
  • bits 6-7: binary group flags 1-2

Is there any hack to guess real milliseconds (or frames after second) for timecode? If so, write me, please.

Retrieved from "https://wiki.4intra.net/index.php?title=MiniDV2AVI/Todo/Extract_milliseconds_timestampt_from_DV_capture&oldid=4182"