Re: [libdv-dev] [PATCH] dv_encode_timecode_fps

[Richard B. <ba...@th...>]

It's come to my attention that this doesn't perfectly handle drop-frame
timecode correctly still, but opens the door for it.

Quote from an email from Phil Rhodes:

"Just to make this ultra clear, all minutes except tens in DF timecode
look like this:

00:00:59:28 - 00:00:59:29 - 00:01:00:02 - 00:01:00:03

Also refer to Adobe's writeup at
http://www.ledet.com/coolstuff/software/premiere/timecode.pdf - I
haven't looked it over, but I presume they know what they're doing."


Patch in a little bit, exams this and next week.

On Wed, 2004-12-08 at 10:52 -0500, Richard Baverstock wrote:
> Attached is a patch that adds the function "dv_encode_timecode_fps()" to
> headers.c and the public api of libdv. The function acts exactly like
> dv_encode_timecode(), but takes an additional parameter (the frame
> rate). This allows drop frame/non-drop frame timecodes to be encoded, as
> well as non-pal or ntsc frame rates such as film.
> 
> dv_encode_timecode() is maintained so as not to break the api, and
> serves as a wrapper to dv_encode_timecode_fps() (with the same behavior
> as before - 30 fps assumed for NTSC).
> 
> write_timecode_13() is modified to take a double parameter instead of an
> integer to determine the frame rate. In write_subcode_blocks(), 30 fps
> is again assumed to be the frame rate for ntsc when write_timecode_13()
> is called.
> 
> While this fixes the dv_encode_timecode() issue for non-drop frame
> timecode, you can see there are some wrong assumptions still in the rest
> of libdv. I didn't want to delve any further into the library until I
> got some feedback. In some cases, it will be necessary to change the
> internal api (write_subcode_blocks() for example will have to take an
> fps parameter), and the public api (an fps field in dv_encoder_t).
> 
> Anyways, with this patch, everything works as before unless you use
> dv_encode_timecode_fps().
> 
> 
> 
> 
> Richard