[Ffmpeg-devel] [PATCH] remove drop timecode flag

[Michael Niedermayer]

Hi

On Sun, Apr 15, 2007 at 08:21:42PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Apr 15, 2007 at 10:49:17AM -0700, Trent Piepho wrote:
> > On Sun, 15 Apr 2007, Michael Niedermayer wrote:
> > > On Sun, Apr 15, 2007 at 08:27:55AM -0700, Trent Piepho wrote:
> > > > On Sun, 15 Apr 2007, Michael Niedermayer wrote:
> > > > >
> > > > > attached patch removes the drop timecode encoding support
> > > > > reasoning is that iam not aware of any use (not even obscure) of this feature
> > > >
> > > > Isn't the timecode wrong if you don't use drop frame timecode for NTSC?
> > > >
> > > > e.g., the timecode after exactly 1 hour of NTSC video will be
> > > > '00:59:56:12', which is short 3 seconds and 18 frames from one hour.  With
> > > > drop frame timecode, the timecode after an hour would be '01:00:00:00',
> > > > since 108 timecodes would have been skipped over.
> > >
> > > timecodes are codec specific
> > > if a codec uses the rounded up fps as timebase then the timecode must be
> > > scaled accordingly and if needed the drop flag be set, its not the user
> > > applications job to do this
> > 
> > SMPTE timescodes are hour:minute:second:frame and should be unique for each
> > frame.  The frame wraps from 29 to 0.  E.g., after '0:0:0:29' follows
> > '0:0:01:00'.
> > 
> > In non-dropframe timecode, the timecode is incremented by one after each
> > and every frame.  If you start at 0 and increment the counter 107892 times,
> > it will end up at '00:59:56:12'.  This is just simple counting.
> > '00:00:00:00' then '00:00:00:01', '00:00:00:02', and so on.
> > 
> > Think of the timecode as the frame number.  Not the frame PTS time, but
> > just the ordinal number of the frame.  Instead of writing it in base 10,
> > it's written in a weird base 30/base 60 numeric format.  It is convenient
> > for humans to look at, since we keep time in base 60.
> > 
> > 107892 == 0x1a574 == 00:59:56:12, it's all the same, just an integer
> > written in different formats.
> > 
> > The problem is that a broadcast of 107892 frames will last one hour, not 59
> > minutes 56 seconds and 12 frames.  A broadcaster would like it if he could
> > cue his tape to end after an hour by using a timecode of '01:00:00:00' in
> > his automatic cueing equipment.
> 
> well iam not entirely sure what mpeg2 mandates in the non drop frame case
> but mpeg4 requires 01:00:00:00 after an hour no matter if 30000/1001
> fps or 12.5 fps or anything else, mpeg4 does not even support drop timecode
> 
> now if mpeg2 behaves the same (it doesnt seem so) then we have no problem
> at all, if it differs then timecode is codec specific and IMHO its not
> the users job to know these details, if this is really needed it belongs
> into the encoder

to quote the specific part in mpeg4 about timecode:

time_code: This is a 18-bit integer containing the following: time_code_hours, time_code_minutes, marker_bit and
time_code_seconds as shown in Table 6-19. The parameters correspond to those defined in the IEC standard
publication 461 for time and control codes for video tape recorders. The time code specifies the modulo part (i.e.
                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the full second units) of the time base for the first object plane (in display order) after the GOV header.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

this does not support the view that the hh:mm:ss would missmatch the true
hour/minute/second for non integer fps

if someone has the IEC 461 spec iam surely interrested to take a look ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070415/4cce6fb6/attachment.pgp>