FX1 timecode
 

I've been wondering for a while why no vendor preserves timecode when capturing HDV. Turns out they are just lazy. The timecode is in the PES header where anyone familiar with MPEG 2 would expect it to be. I'm not familiar with MPEG 2 and I found it in a day. It's right there, in the m2t file.

The PES (Program Elementary Stream) header can be found before each frame (picture in MPEG 2 speak). It starts with 0x000001e0 (for video) and has a 10 or 15 byte payload. First 5 bytes are some lengths and flags and next is the PTS or a combination of the PTS and the DTS. The PTS (Presentation Time Stamp) says when a frame should be shown, the DTS (Decoding Time Stamp) says when a frame should be decoded. Both are necessary because MPEG 2 reorders frames: B frames come before P frames in an MPEG 2 stream.

The PTS and DTS are both 5 bytes long. They contain a 33 bit value which is a clock tick from a 90 kHz clock. The PTS and DTS are enocded as following: 4 bits flags, 3 most significant bits of PTS, a 1, the next 15 bits of the PTS, a 1, the last 15 bits of the PTS and a 1. The 1 bits are inserted so that there won't be two zero bytes in consecution.

Divide the PTS by 900 and you have the timecode value in hundreds of a second. From then on it's trivial to convert this value to HH:MM:SS:FF format, unless you live in a country where people drop frames from time to time :-)

The PTS values are stable. I captured the same piece twice from diffferent starting points and they stay the same. They accord to the timecode shown on screen. It is the timecode.

This means that a) you can extract timecode from any m2t stream produced by an FX1 and b) you can do it in real time since there is no MPEG 2 decoding necessary. You could also extract the timecode while converting the MPEG 2 stream to something else, provided the MPEG 2 decoder gives you a PTS value for each frame.

Sounds like the perfect "next project" for Satish to add to his Wax and Wink updates.

Thank heavens!
 

Thanks for that invaluable info, as there has been lots of confusion on various sites regarding timecode and the FX1. The lack of timecode support in hdv by software vendors is the main reason that batch capture is a problem. It is currently only supported by Ulead Media Studio Pro, a minor league player! Lack of batch capture makes professional use of hdv challenging - so Adobe, Apple, Pinnacle and Canopus better get cracking and sort it out.

Batch capture is significant but not essential to professional production -- but preservation of timecode is an absolute must in my opinion.

With timecode preservation a project can always be rebuilt from the project file and the source tapes. Even if there is no batch capture, and an entire tape must be captured as one file -- timecode preservation will still ensure that the timeline can be instantly rebuilt from captured material.

If timecode preservation occured with both HDV and the optional DV down-rez output ... a project could be entirely edited in DV proxy mode, then the material recaptured as HDV with the same timecode and an HDV project be generated as a result. This would allow anyone with a RT DV solution to 'work' in DV proxy mode, then generate an HDV output. As discussed elsewhere some caution with titles and complex effects would be important, but for anyone with experience in proxy mode editing this would be a small price to pay for RT work mode.'

Failure to preserve timecode on transfer suggests that the software writers are not the least bit familiar with production work, IMHO. On the other hand, when DV was in its infancy the earliest solutions made no attempt to preserve timecode, and early adopters were obliged to work with QT files using boards like the Bravado/Radius/Digital Origin hardware/software bundle -- I know, as I was one of those that paid over $1,000 for this combination ... which delivered slightly less than a current OHCI & software solution delivers for about $100. But at that time the only other way to 'preserve' timecode was to dub DV over to BetaSP and work with the BetaSP tapes.

GB

Those were the bad old days
 

I remember struggling along in the early DV days as you described. My workflow now for documentary production entails using my DVREX-RT system as an online system - capture DV, edit DV, output DV and then transfer to various delivery formats like BetaSP or Digi Beta for broadcast.

I'm planning to enter the low-budget feature arena shooting on HDV, where proxy editing will play a roll, so the timecode preservation issue is vital. Let's hope the software catches up to the hardware soon.

I too use a DVRexRT solution now -- a cautious move to HDV is on the horizon, but I'd sure like to preserve the solid, real-time performance I enjoy with DV production.

GB

Yes. My forays into hdv editing using demo's, etc have not been very satisfying to date. Stuttery playback, etc marred the experience. Even LE6 on a top-end system wasn't too hot. Thus far the Canopus NX came closest to the stable experience I'm used to.