Change AVC timestamp

[mp3dom]

Hi,
Is there a way (tool) to change/alter a raw AVC timestamp?
For example, x264 encodes, as far as I know, always starts at 00:00:00:00 but there are times where there's a need to a custom timestamp (i.e. for adding subtitles at authoring stage when segmenting-encoding). Maybe this could be very helpful feature to add as a parameter inside x264, but, in the meantime, is there a tool that can edit this without loosing compliancy (for bluray).
Thanks,

[MasterNobody]

Raw H.264 doesn't have timestamps in stream (let's ignore picture timing SEI as clock timestamps there are not standardized and x264 doesn't write them). Raw H.264 at maximum have fps (timebase) in VUI. All timestamps are added at container (MP4/MKV) level so you can use any tool for needed container that allow mux with timestamps (like --tcfile-in in x264).

[mp3dom]

Mhmm there should be something else anyway ("timecode"?), because other bluray encoders allows to "write" an initial TC and once the raw file is outputted, Scenarist (for example) read that TC just fine... and the file surely is raw and not in a container (since Scenarist works only with elementary stream). But this can be seen even on lots of commercial blurays out there. Once demuxed, the raw .264 file have embedded TC. That's what I would like to achieve...

[MasterNobody]

Are you sure that it is raw H.264 and not the transport stream (ts)?

[mp3dom]

Yeah, absolutely. It's a raw .264 file, no container at all.

Edit:
Don't know if this can be helpful, but that's the header of this raw .264 file that starts at 01:00:10:00 (1hour and ten seconds):
https://images4.imagebam.com/f6/13/e6/ME41XRM_o.png

I guess that's probably what you were referring to picture timing SEI... but could be extremely helpful at authoring stage.

[Balling]

Raw H.264 doesn't have timestamps in stream (let's ignore picture timing SEI as clock timestamps there are not standardized and x264 doesn't write them). Raw H.264 at maximum have fps (timebase) in VUI. All timestamps are added at container (MP4/MKV) level so you can use any tool for needed container that allow mux with timestamps (like --tcfile-in in x264).

Yeah, no, lets not ignore them. There is also tick metadata in both AVC and HEVC and flag to signal constant framerate in bistream. That is how it is supposed to work in AnnexB files.

[MasterNobody]

Don't know if this can be helpful, but that's the header of this raw .264 file that starts at 01:00:10:00 (1hour and ten seconds):
https://images4.imagebam.com/f6/13/e6/ME41XRM_o.png

I guess that's probably what you were referring to picture timing SEI... but could be extremely helpful at authoring stage.
Yes, that is picture timing SEI.
Yeah, no, lets not ignore them. There is also tick metadata in both AVC and HEVC and flag to signal constant framerate in bistream. That is how it is supposed to work in AnnexB files.
x264 doesn't write it because H.264 spec doesn't say anything about what it mean except:
The contents of the clock timestamp syntax elements indicate a time of origin, capture, or alternative ideal display. This indicated time is computed as (D-1)
in units of clock ticks of a clock with clock frequency equal to time_scale Hz, relative to some unspecified point in time for which clockTimestamp is equal to 0. i.e. some abstract clock source with unspecified starting point. It doesn't say anything how decoder should use it (so it can ignore it and most of them ignore them). It doesn't say if every frame/field (frame doubling/tripling) should always have it specified or can it be written only for some frames (reference points) like IDRs or only first frame and not others.

[mp3dom]

Well, if it can be useful I can give you in some way some different encodes that should cover all the cases (at least the ones that match the allowed bluray framerates)

[MasterNobody]

Well, if it can be useful I can give you in some way some different encodes that should cover all the cases (at least the ones that match the allowed bluray framerates)
Few short (200~500 frames) samples would be good to understand what other encoders do (preferably few different encoders to make sure that they agree between themself) to mimic their behavior. There should be progressive streams, interlaced streams and streams with soft pulldown. What do encoders take from user as input for this timestamps (timestamps for every frame? only starting offset? and at what precision? hh:mm:ss or also ms?).

[mp3dom]

They take tc based on hh:mm:ss:ff as NDF.
Well, this (https://we.tl/t-ZCnCjG9Um0) can be a start. Included 23.98p, 59.94i and 23.98PD (pulldown).

[Balling]

Well, the first file has
[trace_headers @ 00000227afa6cd80] 111 timing_info_present_flag 1 = 1
[trace_headers @ 00000227afa6cd80] 112 num_units_in_tick 00000000000000000000001111101001 = 1001
[trace_headers @ 00000227afa6cd80] 144 time_scale 00000000000000001011101110000000 = 48000
[trace_headers @ 00000227afa6cd80] 176 fixed_frame_rate_flag 1 = 1

and it has timing sei.

[trace_headers @ 00000227afa6cd80] Picture Timing
[trace_headers @ 00000227afa6cd80] 24 cpb_removal_delay 000000000000010100 = 20
[trace_headers @ 00000227afa6cd80] 42 dpb_output_delay 000000 = 0
[trace_headers @ 00000227afa6cd80] 48 pic_struct 0000 = 0
[trace_headers @ 00000227afa6cd80] 52 clock_timestamp_flag[0] 1 = 1
[trace_headers @ 00000227afa6cd80] 53 ct_type 00 = 0
[trace_headers @ 00000227afa6cd80] 55 nuit_field_based_flag 1 = 1
[trace_headers @ 00000227afa6cd80] 56 counting_type 00001 = 1
[trace_headers @ 00000227afa6cd80] 61 full_timestamp_flag 0 = 0
[trace_headers @ 00000227afa6cd80] 62 discontinuity_flag 0 = 0
[trace_headers @ 00000227afa6cd80] 63 cnt_dropped_flag 0 = 0
[trace_headers @ 00000227afa6cd80] 64 n_frames 00001011 = 11
[trace_headers @ 00000227afa6cd80] 72 seconds_flag 1 = 1
[trace_headers @ 00000227afa6cd80] 73 seconds_value 000011 = 3
[trace_headers @ 00000227afa6cd80] 79 minutes_flag 1 = 1
[trace_headers @ 00000227afa6cd80] 80 minutes_value 000000 = 0
[trace_headers @ 00000227afa6cd80] 86 hours_flag 1 = 1
[trace_headers @ 00000227afa6cd80] 87 hours_value 00001 = 1
[trace_headers @ 00000227afa6cd80] 92 time_offset 000000000000000000000000 = 0
[trace_headers @ 00000227afa6cd80] 116 bit_equal_to_one 1 = 1
[trace_headers @ 00000227afa6cd80] 117 bit_equal_to_zero 0 = 0
[trace_headers @ 00000227afa6cd80] 118 bit_equal_to_zero 0 = 0
[trace_headers @ 00000227afa6cd80] 119 bit_equal_to_zero 0 = 0
[trace_headers @ 00000227afa6cd80] 120 rbsp_stop_one_bit 1 = 1
[trace_headers @ 00000227afa6cd80] 121 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 122 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 123 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 124 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 125 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 126 rbsp_alignment_zero_bit 0 = 0
[trace_headers @ 00000227afa6cd80] 127 rbsp_alignment_zero_bit 0 = 0

[benwaggoner]

Did it play back as you wished?

[Balling]

Did it play back as you wished?

Actually yes. Looking into commits timing sei IS supported by ffmpeg. For a long time. I am not sure it is flawless, everything else is not in ffmpeg after all. Like for example eac3 that does not write correct media duration in editlist, only media time. Not that media duration even works even if written correctly.

[benwaggoner]

Actually yes. Looking into commits timing sei IS supported by ffmpeg. For a long time. I am not sure it is flawless, everything else is not in ffmpeg after all. Like for example eac3 that does not write correct media duration in editlist, only media time. Not that media duration even works even if written correctly.
And the files actually didn't display the unwanted frame on your target players?