gstreamertimecodes

gst_video_time_code_is_valid assertion failure when adding timecode to stream

I'm trying to add a timecode to a GStreamer pipeline using a timecodestamper element:

    appsrc name=src emit-signals=True format=time
    ! video/x-raw,format=BGR,width=1920,height=1080,framerate=1/10
--> ! timecodestamper
    ! videoconvert
    ! x264enc pass=quant quantizer=0 tune=zerolatency
    ! h264parse
    ! mp4mux
    ! filesink location=output.mp4

However, I get these assertion failures:

gst_video_time_code_add_frames: assertion 'gst_video_time_code_is_valid (tc)' failed
gst_video_time_code_nsec_since_daily_jam: assertion 'gst_video_time_code_is_valid (tc)' failed

As I understand it, without any additional configuration, the timecodestamper will use an incrementing counter to each frame.

Solution

  • The failing function gst_video_time_code_is_valid is defined here and it checks for these things:

    1. The frame rate of the video is not 0/x or x/0. ✅

    2. The individual timecode fields make sense, e.g., the seconds field is not >= 60. ✅

    3. /* We can't have more frames than rounded up frames per second */

    4. /* We either need a specific X/1001 framerate or otherwise an integer framerate */

    5. /* We only support 30000/1001 and 60000/1001 as drop-frame framerates. 24000/1001 is *not* a drop-frame framerate! */ ✅

    6. /* Drop-frame framerates require skipping over the first two timecodes every minutes except for every tenth minute in case of 30000/1001 and the first four timecodes for 60000/1001 */ ✅

    Since the drop-frame property defaults to false, #5 and #6 above don't apply.

    The frame rate is 1/10 so #1 doesn't apply either. And I assume barring a bug in GStreamer, #2 doesn't apply.

    However this condition is questionable:

    } else if (tc->config.fps_n % tc->config.fps_d != 0) {
  return FALSE;
}

    In this case our frame rate is one frame per 10 seconds, but 1 % 10 != 0.

    If I change the frame rate to 1, I don't see the assertion anymore. But possible the restriction here is a bug? I filed it as issue 2465.