[Ffmpeg-devel] [PATCH] remove drop timecode flag
Sun Apr 15 20:47:13 CEST 2007
On Sun, Apr 15, 2007 at 08:21:42PM +0200, Michael Niedermayer wrote:
> 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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel