Can muxers/multifilesink drop frames?

[pisymbol .]

On Mon, Sep 23, 2019 at 11:40 AM pisymbol . <pisymbol at gmail.com> wrote:

> I have a pipeline that looks like this:
>
> matroskamux name=muxer streamable=true ! multifilesink
> max-file-duration=60s  locaiton=capture_%08d.mkv
> .. ! h264parse ! identity ! muxer.video_0
>
> (I believe this is the only pertinent snippet needed for this discussion)
>
> And each frame is timestamped in my identity handoff callback via
> essentially gettimeofday()).
>
> But occasionally we seem to be seeing that the timestamps in the file I am
> writing out don't align with the frames in the final stream. Barring
> obviously flushing errors of the data, shouldn't the timestamps of each
> frame parsed by the h264parse correlate with my timestamp file. The frames
> are also numbered monotonically increasing (1, 2, 3, 4, ...) and I have
> been told that identity doesn't drop frames so this has me confuzzled.
>
> Is there a fundamental assumption I am making that might lead to the
> problem I am describing?
>

Let me re-ask the question given the overwhelming response:

Should I expect every single frame the identity handoff callback processes
to wound up in the stream?

Again, I'm talking about a pipeline that ends with something like this:

matroskamux name=muxer streamable=true ! multifilesink
max-file-duration=60s  locaiton=capture_%08d.mkv
... ! h264parse ! identity ! muxer.video_0
... ! h264parse ! identity ! muxer.video_1

So should I expect the total number of frames in the MKV for stream 0 and 1
equal to the number of times "handoff" is called? I think the answer is
YES, right?

-aps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190925/72e525b7/attachment.html>