[FFmpeg-user] retain timecode stream when transcoding v210 to FFV1/MKV

[Kieran O Leary]

Yes. My understanding of how most timecode tracks are stored during tape
digitisation is that it just stores the first timecode value when you start
capturing. Any discontinuities in the tape (for example timecode resets
when multiple episodes are on a single tape) are not stored. So all you’re
really getting is first timecode value plus frame rate and the player or
decoder then figures out all the other timecodes based on that initial
timecode value and the frame rate.
When FFMPEG generates an MKV file from an input that has a timecode track,
it also stores that initial timecode value but as as a piece of metadata,
not a timecode track.
So the loss of timecode track isn’t quite as “lossy” as it might first
appear, as timecode isn’t always captured super well during digitisation to
begin with.
My experience with timecode comes from using FCP, media express and control
tool where I’ve never seen beta sp, hdcam or digibeta tape transfers
capture anything more than the first timecode value.

Best,

Kieran

On Mon 5 May 2025 at 15:38, Christian Sievers via ffmpeg-user <
ffmpeg-user at ffmpeg.org> wrote:

> Hi Kieran,
>
> Thanks for chipping in! If I understand you correctly, you are asking if
> the advantage of FFV1/MKV doesn’t outweigh the loss of timecode data? I
> guess that’s the question now.
>
> I’d be grateful for any informed opinions on that.
>
> Best regards,
> Christian
>
>
>
> > On 5. May 2025, at 12:45, Kieran O Leary <kieran.o.leary at gmail.com>
> wrote:
> >
> > Hi,
> >
> > Not sure if this is still the case, but I think most digitisation
> software (non-DV) will just capture the starting timecode anyhow. Any
> discontinuities on the tape itself then won’t make their way over to the
> actual timecode track. So Ffmpeg storing the timecode of first frame for
> MKV as metadata can be good enough (depending on context), as it will
> generate a new timecode track for further transcodes with that initial
> starting timecode value if the container supports those tracks.
> >
> > Best,
> >
> > Kieran
> >
> > On Mon 5 May 2025 at 10:43, Christian Sievers via ffmpeg-user <
> ffmpeg-user at ffmpeg.org <mailto:ffmpeg-user at ffmpeg.org>> wrote:
> >> Hello everyone,
> >>
> >> Thank you, this has been very helpful! So I think I have two options:
> >>
> >> - Wait until Matroska fully supports timecodes, which might take a
> while.
> >>
> >> - Or continue to use Quicktime, but with FFV1. Not as open and free,
> but supports timecode data. This would be a somewhat unusual way to go, I
> suppose.
> >>
> >>
> >>
> >> > On 3. May 2025, at 13:39, Jerome Martinez <jerome at mediaarea.net
> <mailto:jerome at mediaarea.net>> wrote:
> >> >
> >> > Le 03/05/2025 à 12:57, BloodMan a écrit :
> >> >> Hello Christian,
> >> >>
> >> >> OK. right.
> >> >> But in general you have answer in error description: " Only audio,
> video, and subtitles are supported for Matroska." This means that timecodes
> was not supported by matroska.
> >> >
> >> > Tiny correction: not (yet) supported by FFmpeg for Matroska
> >> >
> >> >
> >> >>
> >> >> In RFC you have confirmation:
> https://datatracker.ietf.org/doc/rfc9559/
> >> >> "11.  Timestamps - Historically, timestamps in Matroska were
> mistakenly called timecodes."
> >> >>
> >> >> So, or at least that's how I understand it, Matroska doesn't have
> timecode support, only timestamp support - which is not the same and
> apparently "doesn't convert" - or at least that's not the role of the
> encoder.
> >> >
> >> > It is relatively new but there is now a support timecodes in Matroska:
> >> >
> https://github.com/ietf-wg-cellar/matroska-specification/blob/master/cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md
> >> >
> >> > We are working on implementing that, we plan to send a patch to
> ffmpeg-devel when it is ready.
> >> >
> >> > Jérôme
> >> > _______________________________________________
> >> > ffmpeg-user mailing list
> >> > ffmpeg-user at ffmpeg.org <mailto:ffmpeg-user at ffmpeg.org>
> >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >> >
> >> > To unsubscribe, visit link above, or email
> >> > ffmpeg-user-request at ffmpeg.org <mailto:ffmpeg-user-request at ffmpeg.org>
> with subject "unsubscribe".
> >>
> >> _______________________________________________
> >> ffmpeg-user mailing list
> >> ffmpeg-user at ffmpeg.org <mailto:ffmpeg-user at ffmpeg.org>
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-user-request at ffmpeg.org <mailto:ffmpeg-user-request at ffmpeg.org>
> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>