Can muxers/multifilesink drop frames?

[pisymbol .]

On Wed, Sep 25, 2019 at 9:42 AM Tim Müller <tim at centricular.com> wrote:

> On Wed, 2019-09-25 at 09:18 -0400, pisymbol . wrote:
>
> Hi,
>
> 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?
>
>
> Nothing in this pipeline should be dropping data (assuming data is
> well-formed and well-timestamped etc.).
>
> However, you have limited control over how the files get split in this
> scenario with multifilesink.
>
> Have you tried splitmuxsink instead? (git master supports multiple video
> streams).
>
> It might behave slightly better (although with two video streams there are
> limits what it can do, since keyframes probably won't exactly align between
> the two video streams).
>

Hey Tim, thanks. Yeah, that was the problem with splitmuxsink. I wanted to
use it for that EXACT reason you mentioned above. But I need master which
complicates distribution.

I realize keyframes won't align between both streams, but I assume if I
concatenate all the 60s timestamp files that should represent every frame
in the stream? Right? :-)

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