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

Tue May 6 10:08:32 EEST 2025

> On 6 May 2025, at 07:49, Kieran O Leary <kieran.o.leary at gmail.com> wrote:
> 
> 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.

Since I eat TC for breakfast:

Decent capture systems detect TC discontinuities and create new clips.
So in that case, each clip has only on TC ’track’.

In QuickTime unlimited TC tracks are allowed, and each track can be flagged as ’normal’, ‘Aux1’ or ‘Aux2’.
(But only FCP7 and some of my software knows that.)

A QuickTime TC track has a startpoint and duration, as wel as frame rate, negative OK or not, and drop/non drop indicator.
 This is stored in an atom, and that atom points to a place where the first TC (written as frames) is stored.

Note, there can also be another track for TC to be displayed / overlayed, but I have never seen that in use. (This is sorta kinda a subtitle track)

Another way to store breaks is to use VITC (With either the blanking of the VCR set to Off, or otherwise generated.)

Since this travels the video path, it can stay during cuts to trace back the sources. (I’ve used that to generate EDL’s for re-cutting an offline.)

In other formats (I think MpegII), each frame can have VITC info. 

Also, DPX and alike store TC per frame, so in theory you could rename each frame.

Now, if you need TC, you are either a researcher or a video pro. Why on earth use Matroska? (I have never seen it except on the pirate bay, and I have been a video professional for 37 years.)

Bouke

> 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".
>> 
> _______________________________________________
> 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".