h264 buffer timestamps

[Joe M]

I'm creating a simple test stream from 3 solid color PNGs, using gstreamer:
  gst-launch-1.0 multifilesrc index=0 location="%d.png" ! pngdec ! videoconvert ! videorate ! video/x-raw,framerate=1/2 ! x264enc ! mp4mux ! filesink location=test.mp4
As expected it creates a 6 second video, each color showing for 2s.
I'm then trying to write an app that can consume these frames. I create a pipeline in my app (using vtdec to decode -- I'm on macOS):
  "filesrc location=test.mp4 ! qtdemux name=d d.video_0 ! queue ! h264parse ! vtdec ! videoscale add-borders=false ! videoconvert ! video/x-raw,width=200,height=200,format=NV12 ! fakesink sync=false silent=true enable-last-sample=false"
I hook a signal-handoff callback for fakesink, and in that callback look at the GstBuffer's timestamp:
    timestampBuffer = GST_BUFFER_PTS_IS_VALID(buffer) ? GST_BUFFER_PTS(buffer) : 0;
I'm getting the timestamps 2, 4, and 6 (2,000,000,000 in ns, etc) for the buffers. Why is that? Why not 0, 2 4?
When I run the test.mp4 stream through ffprobe, it tells the "correct" story:
[FRAME]media_type=videostream_index=0key_frame=1pts=0pts_time=0.000000pkt_dts=0pkt_dts_time=0.000000best_effort_timestamp=0best_effort_timestamp_time=0.000000.../FRAME][FRAME]media_type=videostream_index=0key_frame=0pts=100pts_time=2.000000pkt_dts=N/Apkt_dts_time=N/Abest_effort_timestamp=100best_effort_timestamp_time=2.000000
and the same for 4.00000.
One other thing to note -- if I run the playback pipeline using gst-launch and switch to autovideosink, or just let gstreamer handle it and run "gst-play test.mp4", on quite a few invocations, the first color doesn't show up. I just get a black video. When it hits 2s, the second color *always* shows up.
Am I setting something up wrong? Or are my assumptions broken?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220928/8cd0088e/attachment.htm>