[FFmpeg-trac] #11249(avcodec:new): `ffprobe` reported MPEG-2 GOP header timecodes 1 frame early

[FFmpeg]

#11249: `ffprobe` reported MPEG-2 GOP header timecodes 1 frame early
---------------------------------------+-----------------------------------
             Reporter:  MaxEliaserAWS  |                    Owner:  (none)
                 Type:  defect         |                   Status:  new
             Priority:  normal         |                Component:  avcodec
              Version:  git-master     |               Resolution:
             Keywords:  mpeg2video     |               Blocked By:
             Blocking:                 |  Reproduced by developer:  0
Analyzed by developer:  0              |
---------------------------------------+-----------------------------------
Comment (by MasterQuestionable):

 ͏    As I'm trying to sort these things out: I have to pay attention to
 every, even the slightest details.
 ͏    So to not retrace the very old mistakes.

 ͏    Based on your description the 10 h alike offset appears constant, and
 applies environment-wide.
 ͏    So there should be no difference just adding/subtracting it to
 satisfy specific use.
 ͏    [ Bear the havoc of alike, of course. ]

 ͏    Legacy workflows have their own expectations.
 ͏    That modern technologies may not satisfy, for each other.

 ͏    Old content may as well be restored in new definitions.
 ͏    And when properly done: likely of higher quality.
 ͏    [ Modern structure is VFR based. 29.976 whatsoever, doesn't really
 matter. ]

 ͏    Whatsoever you seem to miss the core question:
 ͏    "timestamps of GOP be additionally stored"
 ͏    ; not really about SMPTE timecodes in general.

 [[
 ͏    "Why should the timestamps of GOP be additionally stored, when
 directly derivable?"
 ͏    I don't really disagree, for containers/codecs that can signal a
 non-0 starting PTS.

 ͏    I would just note that there are a lot of workflows/software out
 there, which still rely on timecode:
 ͏    And which do not do this derivation, even though it is possible to
 do.

 ͏    An example of where it might not be as easily derivable is in the
 !QuickTime format:
 ͏    Where the STTS/CTTS box structure cannot easily achieve a non-0
 starting PTS.
 ͏    But where timecode can be signaled as a separate track of type
 "tmcd", to start the timeline at 10:00:00:00.

 ͏    It is still standard in television production to start timecodes at
 10 hours (1 hour for film).
 ͏    This practice was established because mechanical tape/film equipment
 needs a little bit of time, to get its motors spinning up to full speed:
 so the tape can't start at 0.
 ͏    If the pre-roll starts at 9:59:52:00, then the actual content can
 start at 10:00:00:00, a nice round number.
 ͏    .
 ͏    Although we don't use this type of equipment anymore, this convention
 is still absolutely standard in television/broadcast.
 ͏    And there are a lot of files out there which signal this in timecode
 but not in PTS.

 ͏    Some information on this is here:
 ͏    [20210407] Why Does TV Timecode Start At 10 HOURS???
 ͏    704 s (11:44)
 ͏    https://www.youtube.com/watch?v=C-aJEhZtnVo
 ͏    The Crow Hill Company (@!TheCrowHillCo)
 [[
 ͏    In a recent series of seminars about writing FACENT or "factual
 entertainment", a few of you asked why did the timecode for TV start at 10
 hours???
 ͏    Well in this vlog I attempt to explain that with a few historical
 nuggets, that even the most seasoned of you may be surprised you didn't
 know!
 ]]
 ͏    (apologies for video, I would have provided a written resource if I
 could find one)

 ͏    If we were to redesign all video software and file formats today, I
 agree it would be better to just focus on PTS and eliminate SMPTE
 timecode.
 ͏    But old technology still has a lot of influence from beyond the
 grave, and people still want to watch the old content.
 ͏    (otherwise we'd have stopped using 29.976 FPS in North America a long
 time ago)

 ͏    For FFmpeg's use case as a self-contained transcoder, it's probably
 easy to avoid using timecode.
 ͏    But for FFprobe's use as a video analyzer tool or "avcodec" 's use in
 other video software, I would argue for its continued usefulness.

 ͏    Anyway, thanks for the opportunity to nerd out about video stuff.
 This was fun!
 ]]
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11249#comment:15>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker