Difference between revisions of "MiniDV2AVI/Todo/Extract milliseconds timestampt from DV capture"
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
I want to extract timecode up to milliseconds from DV capture. | 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: | |
<blockquote> | <blockquote> | ||
Line 15: | Line 15: | ||
</blockquote> | </blockquote> | ||
− | But actually, in my experience (and | + | 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 milliseconds» is not an option, because LTC is different for each cassette. | + | 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> | <blockquote> | ||
Line 49: | Line 49: | ||
Is there any hack to guess real milliseconds (or frames after second) for timecode? | 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.